Hunting for DoublePulsar in your networks

Home » Sled Meta Blog » Incident Response » Hunting for DoublePulsar in your networks
The recent release of the Equation Group’s (NSA) FuzzBunch software by the Shadow Brokers has caused quite a stir in the security community. The volume of files released, (6,547 in one of the dumps), is an extraordinary collection of malicious software including many zero-day exploits.

One of the binaries that caught my interest was DoublePulsar. This is the main tool used by the Equation Group to compromise Windows hosts using a SMB and RDP zero-day exploit.

Although the attack surface is complicated, my fellow researchers at did a highly competent job of describing it. To me, the most interesting step in the attack is the patching of the function dispatch table of the device driver Srv.sys in memory. Slot 0x20 (14) in this table originally pointed to the SrvTransactionNotImplemented() dispatch function. It is hijacked by the malware.

Why is this interesting? Because even though the implementation of this attack is quite brilliant, it is trivial to identify this attack in your network.

I refer you to page 426 of (Microsoft’s Common Internet File System (CIFS) Protocol) protocol document: TRANS2_SESSION_SETUP (0x000E)
“This Transaction2 subcommand was introduced in the NT LAN Manager dialect. This subcommand is reserved but not implemented. Clients SHOULD NOT send requests using this command code. Servers receiving requests with this command code SHOULD return STATUS_NOT_IMPLEMENTED (ERRDOS/ERRbadfunc).”
The CIFS/SMB TRANS2_SESSION_SETUP subcommand was never implemented by Microsoft. The standard states that any call to the command by a Windows client should return a STATUS_NOT_IMPLEMENTED reply. Once DoublePulsar redirects the Srv.sys SrvTransactionNotImplemented[] function pointer to its own code injected in memory, any SMB call to a NOT_IMPLEMENTED SMB subcommand will end up calling the DoublePulsar code.

Knowing this, is it possible to identify DoublePulsar in your network by simply looking for SMB requests for NON_IMPLEMENTED subcommands, or even simpler, any SMB STATUS_NOT_IMPLEMENTED response? Yes.

To illustrate this, look at the WireShark screenshot below that shows a SMB call to the TRANS2_SESSION_SETUP (0x000E) subcommmand.

Figure-1: TRANS2_SESSION_SETUP (0x0E) Request

Since this SMB subcommand was never implemented by Microsoft, if you ever see it anywhere in your network, you should pay close attention. From a detection perspective, alerting on this SMB request has a near zero chance of being a false positive.

Now lets look at the response.

Figure-2 below shows an actual response from a call to a compromised Windows host. The SMB response header contains the correct STATUS_NOT_IMPLEMENTED (0xC0000002) error code, but WireShark was unable to parse the data section of the response since it was hijacked by the malware and contains C&C data. Not what the WireShark parser expected.

Figure-2: TRANS2_SESSION_SETUP (0x0E) Response

One other interesting tidbit is that the malware will query an end-node to determine if it already has been compromised. It does this by sending an SMB ECHO (0x2B) request. If the end-node is compromised, it will return a Multiplex ID value of 0x65 in the SMB response header. This is another SMB command that you can look for when hunting for Shadow Brokers in your network. Remember, other SMB software may issues SMB ECHO commands, so the fact you are seeing them is not definitive proof hooligans are in your network.

Figure-3: ECHO (0x2E) Response

For our PacketSled customers, rest assured you will be alerted to the presence of DoublePulsar if one of your sensors sees this traffic (Figure-4).

Figure-4: DoublePulsar Alert

Figure-5 below shows the complete flow breakdown of the DoublePulsar attack.

Figure-5: DoublePulsar Flows

The PacketSled SMB analyzer is even capable of capturing the entire SMB conversation. As shown below in Figure-6, you can see the DoublePulsar TRANSACTION2 command that was never implemented by Microsoft. You can also see the return status of the command was NOT_IMPLEMENTED.

In summary, it seems the creators of  DoublePulsar brilliantly exploited SMB by high-jacking an unused subcommand, and made no attempt to hide the ‘noise’ of non-implemented SMB subcommand requests and response network traffic. They believed, correctly in my view, nobody would see them because nobody was looking for them.  But now that we know – this traffic is easy to spot and unique enough that if you find this traffic in your network – bad guys are present.

To implement an alert to detect this attack in the PacketSled platform is trivial. A detection alert is available to all of our customers. If you are not a PacketSled user, configure your IDS security controls to alert anytime a SMB STATUS_NOT_IMPLEMENTED response is seen.

Special thanks to zerosum0x0 and Countercept!

in Incident Response, Network Visibility, Security Research, Threat Detection by Mike Spohn Leave a comment

Leave a Comment

© 2017 PacketSled, Inc.