Using threat_note To Track Campaigns: Returning to PIVY and PlugX Infrastructure

BLUF: I’m starting to find the sweet spot for threat_note in my at-home research workflow. By taking advantage of threat_note’s VirusTotal integration, I was able to discover some new infrastructure associated with the the activity I documented in my August 8 post on Poison Ivy.

A couple of weeks ago, I wrote a post about a new app called threat_note. Since then, Brian Warehime (on behalf of Defense Point Security), has introduced a lot of updates including bug fixes, new features, and a really slick UI. The new interface looks great: clean and simple!

Screen Shot 2015-09-13 at 2.33.21 PM

Note: I initially had trouble running threat_note after having restarted my computer. To get the Vagrant box that threat_note is running on back up, I used the following command as recommended in the Vagrant documentation:

Christians-Air:~ Christian$ vagrant --reload provision

I’ve also been spending some time submitting indicators from my at-home research into threat_note.

I harvested the network indicators from my post on Poison Ivy and PlugX. I bucketed these indicators under the campaign name “PIVY_01” (creative, right?). You can associate an indicator to campaign when you create/submit a new indicator.

From the Campaigns page in threat_note, we can now see our nice bucket of PIVY_01 indicators.

Screen Shot 2015-09-13 at 2.47.22 PM

From here, I started drilling-down into the IP addresses to try and identify any new domain resolutions which would be useful as new pivot-points to track the campaign. This feature is made possible by the VirusTotal enrichment in threat_note (you can submit your VT API key from the Settings page).

Knowing that was the last known resolution for getstrings[.]jumpingcrab[.]com, I chose to investigate this node first. We can see that drilling-down from the Campaign page gives us WHOIS and GeoIP enrichments, and shows us the content we originally submitted with the indicator such as the comments and last seen dates.

Screen Shot 2015-09-13 at 2.55.04 PM

The VT enrichment on this page yields the following pDNS results for

Last Resolved: 2015-08-20 00:00:00 Hostname: 
Last Resolved: 2015-07-24 00:00:00 Hostname: 
Last Resolved: 2015-04-28 00:00:00 Hostname: 
Last Resolved: 2015-05-04 00:00:00 Hostname: 
Last Resolved: 2015-05-02 00:00:00 Hostname:

The host api[.]proxyme[.]net is not one that I had identified in my original research into the Poison Ivy campaign.  This gives us a fresh–well, fresh to me, at least–lead to follow.

A quick Google search provided some interesting results indicating that this host has been known to be associated with PlugX since at least February 2015. Ryan Gibson published a tweet on February 26, 2015 that mentioned api[.]proxyme[.]net and used the tag “PlugX.” Gibson also said that the host was resolving to

So, wanting to keep track of this new hostname, and initially believing it to be linked to PIVY_01 (moderate confidence) I submitted api[.]proxyme[.]net to threat_note and associated it with the PIVY_01 Campaign.

Screen Shot 2015-09-13 at 3.12.54 PM

After submitting the indicator, I also decided to add an Attribute. Threat_note allows you to name and add any Attribute field you want so I created an Attribute called “Registrant” with the value “me bobo” along with a “Registrant Email” Attribute: thierrysy410@gmail[.]com. This appeared to be a unique registrant , so I wanted to document it. The email address was also used to create nasa-uni[.]com on December 11, 2013; I added this domain to threat_note as well. (EDIT: there is a bug with the attribute submission feature right now; I submitted the issue to threat_note’s GitHub page.)

Screen Shot 2015-09-13 at 3.19.57 PM

Returning to the Google results, and also running a query in ThreatCrowd, we find that the following samples have been observed calling to api[.]proxyme[.]net: 

SHA1: cc1b5aa6a304c8348ffac60bd93368ffef93d324
File names National Assembly Proposal on Year 2014.doc
First submission 2014-08-13 01:44:25 UTC

SHA1: 8006ee9e7ec862134b52cd8608f1fb5ae46a6c25
Compilation timestamp 2014-11-11 00:46:08
First submission 2014-11-24 00:31:39 UTC

SHA1 b3ce122c0755e8e06fbb9705d8b19cd3c9371660
Compilation timestamp 2014-08-08 10:01:08
First submission 2015-02-17 09:44:48 UTC

SHA1: 105e195ceab179633d99873229e59c49390c03c6
Compilation timestamp 2015-07-08 07:51:24
First submission 2015-07-25 05:20:43 UTC

All four samples are detected as PlugX. Interestingly, the timestamps (assuming they haven’t been modified) and submission times correlate with the activity I detailed in a previous post.

In that case, a Poison Ivy sample (SHA1 44073031790e5ba419374dc55f6ac1cba688b06c) appeared to be just one payload involved in a broader campaign targeting India, the Tibetan community, and others, that spanned from approximately September 2014 to February 2015. PlugX was also widely deployed in this campaign.

Similar to the decoy documents identified in that PIVY write-up (e.g., CHINA NEWS BRIEF 09 of 2015.doc), the file National Assembly Proposal on Year 2014.doc suggests that government entities, or those in proximate sectors, may have been socially engineered using this document.


I’m starting to find the workflow sweet spot for threat_note. The app is great for documenting indicators as you’re conducting research. With the integrated VT enrichment, we were able to quickly find some additional PlugX infrastructure, api[.]proxyme[.]net.

Pivoting on that hostname also led us to identify some PlugX malware samples and an additional related domain name, nasa-uni[.]com, which I fed back into threat_note. The new links are visualized in the Maltego graph below. This is an updated graph that was originally presented in my PIVY blog post.

Screen Shot 2015-09-13 at 8.34.36 PM

Lastly, below are the network indicators I have thus far associated in my PIVY_o1 Campaign. While I have identified links justifying their relationship, I do not know if these indicators can be attributed to the same or multiple actors. The fact that the domain names use DDNS makes efforts to link these infrastructure nodes to one or more adversaries more difficult. It also means that some of the IP addresses may not be inherently malicious.

Further research may result in new Campaign buckets for some of these indicators as distinct clusters emerge.