EternalPulsar — A practical example of a made up name

Yesterday we were talking about this weekends ShadowBrokers dump (I suggest you read that before continuing here) and noted that within the approximately 32 exploit dump there were several that caught our eye, and have been super fun over the past few days.

EasyFun 2.2.0 (EAFU) which is an exploit for some older versions of WDaemon / MDaemon WorldClient (a mail server that is still very commonly used). The exploit is targeting versions 9.5.6 and older. The current version is 18, so there should be very few of these targets available, right? Wrong.

There are still over 5000 identified potential targets for that exploit, lovely!

The next is the main topic of this article; the EternalBlue exploit for the SMBv2 service within the Windows operating systems combined with the DoublePulsar dropper which can be used to upload malicious .DLLs.

In actuality this attack is very, very, simple, which really make it all the more terrifying. We are going to use the FuzzBunch framework (that we discussed previously) with EternalBlue(EB), to exploit the SMBv2 service on a Windows 7 machine. DoublePulsar(DoPu) will be uploaded as our backdoor and shellscript execution platform, and our payload will be the x64 version of Meterpreter’s (MSF) reverse_tcp. I have taken to calling this exact process ‘EternalPulsar’, yea more cool names we can’t have enough of them!

I tested EternalPulsar in a lab environment with the following setup:

Windows 8.1 (Attacker — 192.168.1.252)Windows 7 (Victim — 192.168.1.123)KaliLinux (MSF Handler — 192.168.1.193)

Simple stages that we will go through are:Payload Creation > EB Exploit > MSF Setup > DoPu Upload > Rooted!

Payload:This one is super simple, we just use msfvenom to create a .DLL that will call back to our MetaSploit listener. Our target is x64 architecture so lets make sure to use the right one (I didn’t originally and slapped myself when DoublePulsar told me off). Set the IP address of the machine you want to call back to, in this case our Kali instance and the port you’re going to listen on.

Nothing decidedly complex here simple reverse_tcp that we’ve all used.

**_EB Exploit:_**Just like the MetaSploit framework, FuzzBunch allows you to ‘use’ and configure exploits, and their payloads.

FuzzBunch configuration and execution of EternalBlue

For the example here I had already configured the target and parameters but they’re fairly self explanatory, you select:- Target IP- Target Port- Callback IP- Confirm target OS- Number of exploit attempts- Target exploitability- Define Delivery type - Remote IP/Port for forwarding (Pivoting)

We then get final verification of settings before being asked if we are ready to fire our exploit.The rest of the process connects to the target device, confirms that its OS matches what is expected based on the configuration for the exploit and that the exploit is not already installed. SMBv1 is used to connect and create a buffer in memory that will in turn become free for our exploit code to reside (Use-After-Free).

Our exploit code is uploaded and the implant placed, which then sends a return code to FuzzBunch to let us know its been successful. This has been identified as setting the SMB Multiplex ID to a value of 82 (52 00h) this is not a standard value for this and has aided us in creating signatures for the identification of the exploit, which we will cover at the end of this article:

Multiplex ID = 82

MSF Setup:The next step takes us back to MetaSploit to create a simple handler to receive the connection back that our reverse_tcp payload will execute. We have our expected payload, the IP of the listening machine (get it right or you’ll end up listening on 0.0.0.0 ;) and the port that we configured in the payload.

MetaSploit Reverse TCP Handler

**_DoPu Upload:_**We’re finally ready to upload our DoublePulsar backdoor and payload to the victim. As with the launch of EternalBlue we get the configuration options which are largely the same, except we are asked for details of the payload that we want DoublePulsar to execute once its installed. In this case we are using our ‘meter.dll’ which is the configured meterpreter reverse_tcp that we setup in stage 1, as well as the name of the process that we want to inject into, always best to use a standard windows process so we’re certain its there.

We’re breaking security so lets just use lsass.exe which is conveniently the default, we’re again confirming the protocol that we’re attacking (nbt is also an option that needs to be explored further) and the architecture of the target machine.

We get returns confirming that the DoublePulsar backdoor has staged correctly, then that the .DLL shellcode has been built and injected.

And to be quite honest, that’s all she wrote!

**_Rooted!:_**We can see in our MetaSploit handler that we don’t even have to do anything further, the payload included in our ‘meter.dll’ has been executed and called back to the Kali instance. On the target system we can see our injected process, our shell, and the connection to our staging system.

We use MetaSploit to access the shell we have and can see that as expected we have full system access as user ‘nt authority\SYSTEM’ which if you are not familiar with windows systems is the highest level of privilege, eg root.

.DLL execution called back to Kali and we just grab a shell

So, what can we do against this? Well as we talked yesterday about MS17–010 which was released for systems newer than VistaSP2, which patches these vulnerabilities and makes you super secure*! (*from this, for now).

Patching, disabling CIFS/SMB is your best bet and will protect you from this iteration of the exploit. Additionally we’ve taken some time pulling apart the SMB traffic that is generated specifically by EternalBlue. Two artifacts we identified were that the installation (as shown above) returned a Multiplex ID of 82 and connection to a current EternalBlue injection (its already been exploited and someones connecting to the present payload) has a Multiplex ID of 81.

EternalBlue connection to pre-installed backdoor value 81

EternalBlue initial exploitation success value 82

These MID values are not used as part of the standard SMB protocol, so are a fairly good base to create a rule (at least that is what I have been working from and created working rules using).

So the rule-set we have in place to identify these within Suricata are as so (and they're a bit raw, I've not done much signature writing):

MID=81 — Someone is successfully connecting to EternalBlue

MID=82 - Someone has potentially managed to install EternalBlue

The rules were tested in my lab Suricata instance and worked on the PCAPs from my testing as well as those provided by Eric Conrad via twitter.

Ignore the ET, I based my rules on their EternalRomance rule, because I’m a noob :P

You can grab full version of these signatures from my github: https://github.com/xNymia/Suricata-Signatures

In my opinion, this is going to be an issue for a long time going forward. The number of systems I’ve seen when doing Pentest gigs that are a massive number of patches out of date, sysadmins or devs throwing up test machines of Windows Server 2008 that just get left there unpatched, Windows 7 home machines that people have auto updates disabled. We all know it happens, we all hate it. And now its going bite us. Hard.

And don’t even think about all the people using illegitimately obtained versions of windows in production environments. It’ll give you a headache.