Defense in depth: The Equation Group Leak and DoublePulsar.

by: Rod Soto and Daniel Scarberry

Unless you’ve been living under a rock you are probably familiar with the recent Shadow Brokers data dump of the Equation Group tools. In that release a precision SMB backdoor was included called Double Pulsar. This backdoor is implemented by exploiting the recently patched Windows vulnerability: CVE-2017-0143.

For detection, we are going to first focus on the backdoor portion of the implant, hunting for traces left behind on the network.  JASK customers have access to 90 days of full network meta-data  to reach back in time and historically analyze or hunt for the first entry point.  This allows our customers to quickly determine if they were one of the unlucky ones to be compromised by the newly leaked exploit and implant.

So let’s get straight to it. Double Pulsar is an SMB injected backdoor and that means it is time to focus on the SMB protocol. First of all you should not have SMB open to the public internet!  Why people still do this is beyond us… That being said, SMB is a great protocol for threat hunting, from the SMB attack used in the Sony hack in 2014, to some of the older worm’s. It’s one of those protocols that just seems ripe for behavioral based detection. Baselining the number of requests, who’s making the requests, and what SMB commands are being used seems like a good place for anomaly detection and searching for suspicious behaviors.

To kick things off, let’s replay the attack through a JASK sensor and look at the SMB commands field in Trident Investigation:

Based on SMB commands, there are three fields that stand out for analysis:

  • Commands.status
  • Command.sub_command

Feeding a DoublePulsar Ping to a clean, non-exploited, non-infected host results with SMB meta-data:

  • Commands.status="NOT_IMPLEMENTED"
  • Command.sub_command="SESSION_SETUP"

As seen below in notebooks:

In a Wireshark analysis this clean value shows up a Multiplex_ID of 0x41

Feeding a Double Pulsar ping to a dirty, exploited infected host results with SMB meta-data:

  • Commands.status="NOT_IMPLEMENTED"
  • Command.sub_command="null"

As seen below:

It seems the command.sub_command ends up being null in an exploited machine. In Wireshark this infected host results with a Multiplex_ID of 0x65.

One more interesting piece of data is that a first time exploited host ends up with a Multiplex ID of 0x52..

If you follow the exploitation in sequence you’ll see that during the exploitation, an initial Double Pulsar Ping is sent to check if the host has already been compromised. (Showing the previously discussed 0x41 for a non-exploited host), meaning it’s good to run the exploit against.

Continuing our analysis, I notice that during the CVE-2017-0143 exploitation phase “Eternal Blue” we also see an SMB ECHO command. Checking for the frequency of SMB commands, we observed the SMB Echo command is a rarely used SMB command and perfect for a behavioral-based detection of rarely seen SMB Commands, or even a “first time seen” type of anomaly.

Expanding from that analysis , we realize there’s an entire set of SMB commands that have been deprecated or unused and should be understood as suspicious behavior within the SMB protocol. For that, some behind the scenes SMB protocol reading needs to be done:

After some light protocol review and research, we  ultimately identified a set of SMB commands that are rarely used. By flagging these commands, we create anomlous

“Signal” to be produced in JASK Trident anytime one of these rarely used SMB commands are seen from a particular host for the first time. The goal with that level of signal production is to further protect users and notify threat hunters of any Zero Day attacks with rarely used “NOT IMPLEMENTED” commands. We will feed these signals to our secondary supervised learning model to ultimately end up with high confidence alerts.

The Shadow Brokers leak of NSA tools is already being ported to exploit kits and frameworks to be used in  malicious campaigns. These exploit kits enable malicious actors including those of a lesser technical level, to enhance their ability of targeting and compromising their targets; thus finding vulnerable targets with and other public mass scan tools. There is no hiding!

While the goal of this research is purely technical to ensure defensive measures, it’s a great example of the work we do often in conjunction with helping our customer create agile defense to emerging vulnerabilities and exploits.  We are moving quickly to historically check if our customers were compromised as well as push new algorithms to our customers to further protect them from not only this Shadow Brokers release, but any further SMB attacks as the world continues to move forward as it always does.

Habits of Highly Effective SOC’s: From Security News to Content in One Hour

Good security analysts don’t just consume content, they create it. If you’ve ever read an article or blog that has sparked an idea, perhaps about a novel way to fortify your defense posture, you’re not alone. When you’re collecting rich metadata from your network, reading security articles becomes far more fun. You can now play-along, so to speak, without needing to engage engineers, change-management etc. You’ll be amazed what can be discovered by doing this. When your team is empowered with vast, queryable visibility, your security maturity only grows.

Although the discoveries your team will make by performing the exercise described below won’t always conclude by scrambling the Incident Response Team, they will lead to actionable information creating peace of mind. At the end of this exercise we will create a rule to capture our efforts; this rule will automatically produce new content when new data is received. This new content creation serves three purposes. First, it strengthens the security posture of our network by producing a tangible signal identifying suspicious activity. Secondly, when shared, the content serves to protect the wider community that may go on to produce even better content in turn. Third, and most importantly, providing the ability to capture the result of an analysis easily empowers and satisfies the analyst. Security operations can be a daunting mission with overwhelming negative feedback mechanisms, there needs to be more positive feedback opportunities available, performing this healthy habit is one of them.

We’ve hand picked a blog post from It was chosen for this exercise because it’s short, relevant, and easy to digest. We’ll use Zeppelin notebooks with the data available from a Jask Trident deployment for our explorations.

Source material

Our adventure begins while reading an article from The article is compelling, and outlines the evolution of the EITest campaign that is using a new flavor of ransomware - CryptoShield 1.0, and being delivered via Rig Exploit Kit (RigEK vs. Angler EK). Within the article is a network communication overview diagram of the infection as it occurs.

Screenshot from blog article showing network activity during RigEK compromise

Signal Idea (Hypothesis)

Looking closely at the diagram with seven requests, there are many possibilities for exploration using our own traffic metadata. All seven connections, summarized as rows at the top of the diagram, represent HTTP data similar to what Jask sensors are already providing. In fact, all of the columns (save for the packet numbers) are indexed and ready for querying.

Below are a few quick exploration topics one might gather after reviewing the diagram.

  • IPs,,, or domains thesportspost[.]com, turkiye2075[.]com
  • URI pattern seems to be predictable
  • HTTP POST to an IP address
  • Content types application/x-shockwave-flash, application/x-msdownload

The IPs and hostnames are good for a cursory query, but not so good for signal creation into the future. We’ll leave these to our Threat Intelligence process/vendor.

Of the remaining choices, let’s pick on this one - HTTP Post to an IP address. Sending a web form POST to a web host without a name (hence the IP address in the Host column) seems strange.

Zeppelin Notebook query (Experiment)

Now for the fun part. We’re going to iterate on the idea that a HTTP POST request, where the client header contains an IP address in the host field, is strange. We’ll write the query as below looking for exactly that:

We’ve included many fields by design, this allows rapid evolution of the query. These key fields allow the analyst to use zeppelin’s powerful visualization capabilities to explore the records that match without needing to modify and re-execute the query.

There are many results that return from our first query. It may seem at first that our hypothesis was proven wrong. Before we give up, we’ll examine the results and begin pruning away to see what’s left. With only a couple iterations, this query has tightened up to now only identify highly unusual and infrequent HTTP activity. Let’s look at the process of weeding out some noise.

Scrolling through the results in grid view, we notice a lot of connections to Akamai destinations that match our suspicious pattern, with a shockwave flash user-agent.


Some open source research confirms this communication is consistent with Akamai NetSession; it looks like it’s a peer-to-peer agent often used for streaming services such as Netflix etc.

Let’s switch to a bar chart to see if we can isolate these by using destination organization and user agent string.


Looks like we can. Building the logic for that is simple. Add some SQL to exclude the Akamai NetSession traffic, now rinse and repeat this analysis process for all other matches. The goal isn’t to get to zero, but to reduce the number of hits for the query to a low volume.


We may have just identified a policy violation or two with this. It’s important to respond appropriately to discoveries we make while                performing analysis on our suspect connections; we have folks using a p2p agent associated with video streaming. But don’t take your eyes off the prize, the goal is to identify unusual traffic pattern that corresponds to hostile activity that we learned about in our blog post. This traffic is definitely not that.

Here’s a summary of the two analysis iterations performed that got our results down to less than 5 records per day:

After reducing our output records to a fraction of what they were with only two localized filters, one for Akamai NetSession and one for Fortinet updates, we have proved our hypothesis true. It is indeed unusual to see web POST requests carrying an IP address in the client’s ‘host’ header. There are only two things left to do:

First, perform a deep investigation on the hosts remaining that are exhibiting this unusual behavior. Depending on your data retention, you may have discovered an infection that occurred some time ago.

Secondly, capture this analysis. If you’re using Jask’s Trident product this is accomplished through the Filter dashboard in the UI. In Trident, this allows artifacts (known as signals) to be produced on any new suspicious activity. This task is simple, first copy-and-paste the query logic to the patterns UI. Next choose a category and priority then enable it. Category and priority selection is essential for Jask’s automated analyst to gain the most use of it.

If you have large amounts of metadata covering your network, with a little practice, your team can begin moving the security-maturity higher for your organization every day. Remember to stay focused on the objective, analysis rabbit holes (e.g. Akamai NetSession traffic) are everywhere and can interrupt the rhythm of your content creation.