ExtraPulsar backdoor based on leaked NSA code – what you need to know

Most Windows servers, and many Windows laptops, accept file sharing connections – if you run the command net share and you see C$ and ADMIN$ in the list, yours does.

If file sharing is active, you’ll see the the Windows kernel driverSRVNET.SYS loaded – full name Server Network Driver.

The idea is that the Server Network Driver – it’s called that even on non-server versions of Windows – looks after the open network ports and the network traffic that’s part of Windows file sharing.

This traffic-handling driver then hands off incoming packets to one or more additional drivers to deal with remote requests.

For example, the Server Network Driver will usually be accompanied by a “device extension” driver called SRV2.SYS, the Smb 2.0 Server Driver.

SMB is short for Server Message Block, Microsoft’s moniker for its file sharing protocol.

If you’ve enabled the outdated, insecure and now off-by-default SMB 1 – something even Microsoft urges you not to do – you’ll see SRV.SYS as well, listed as plain old Server Driver.

What the researcher figured out is how to persuade the Server Network Driver to load an additional kernel module built from his backdoor code, something that he denoted in his source tree with a diagram described as “slop together a graphic”:

The idea of creating malware that works way is as follows:

• The malware code is registered to handle network packets already received by the top-level server driver. So the malware doesn’t need to open any listening network ports itself, or make any suspicious-looking network calls.
• The malware code runs as a kernel driver, and any code it receives and launches itself acquires kernel privileges too. So this malware and any backdoor code it activates runs at what amounts to a super-admin level.
• The malware code automatically gets woken up and activated when SMB network packets arrive. So it can easily identify its own command-and-control instructions, remove them from the network stream, and act on them.

The proof-of-concept remote code execution delivery tool in Dillon’s project is just 12 lines of Python programming that sends a single network packet of executable code to port 445 on an infected computer.

Normal SMB packets start with the bytes 0xFF 0x53 0x4D 0x42, which shows up as ■SMB when displayed as text.

The malware recognises its own shellcode payloads because they’re tagged with 0x45 0x78 0x50 0x75, which comes out as ExPu, short for ExtraPulsar.

What to do?

If you’ve seen media stories suggesting that this project could lead to “undetectable malware”, don’t panic.

Good security software can block rogue kernel drivers and their side-effects in many ways:

• Kernel drivers are themselves Windows program files, albeit with some special characteristics. (They usually have a .SYS extension instead of .EXE or .DLL.) So they can be detected, blocked and removed by anti-virus software.
• Kernel drivers load into memory and stay there, albeit in a different part of the operating system to regular apps. So they can be detected and ejected by anti-virus software.
• ExtraPulsar SMB network packets could be made to have innocent-looking content, for example by encrypting them, but they have to be recognised as different by the backdoor component. So they can be detected and rejected by network filtering tools.
• Modern Windows versions won’t load rogue kernel drivers by default. Kernel drivers need to be digitally signed, so crooks need to acquire rogue certificates to get any sort of foothold. So rogue drivers can be identified and blocked by security software.

We’re not convinced that Dillon really needed to release his proof-of-concept malware as a freely downloadable GitHub project…

…but ExtraPulsar can’t be used directly to launch an attack, and it doesn’t represent an “undetectable” threat, whatever you may have heard.

So let’s be charitable and say that Dillon’s code is informative to study if you are interested in cybersecurity.

---