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 zerosum0x0.com 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:
126.96.36.199 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.