[zerosum0x0]

In case you are living under a rock, Shadow Brokers dumped all kinds of remote exploits for Windows today.

Official Microsoft Response:
https://blogs.technet.microsoft.com/msr ... ting-risk/

Allegedly it's all fixed In MS17-010. I actually just got a MS17-010 uncredentialed scanner pulled into Metasploit master repo today, and then NSA shows me up with the full RCEs.

Other Analysis
https://www.reddit.com/r/netsec/comment ... anslation/
https://www.trustedsec.com/blog/equatio ... lt-strike/
https://www.bleepingcomputer.com/news/s ... t-attacks/

My Initial Analysis
FuzzBunch- Metasploit written in Python. Pain in the ass to get the dependencies working, use an older x86 box is the tip.

coli-0.dll- All exploits' main exploit "Run" function is passed as a pointer to a wrapper. This is a framework.

tibe-2.dll- A nice SMB library, I wish it was open source. Pretty easy to reverse though.

DoublePulsar- claimed to be a ring-0 malware for pretty much all versions of modern Windows. I reversed the DoublePulsar.exe and it looks more like the C&C server, not the malware payload (I say this because it wraps itself in coli-0.dll like the exploits do). There's a few driver .sys files deep, they have entries which just spawn threads, and I'm unsure of if they are part of the payloads. I'm still digging through everything looking for the meat and potatoes here.

Eternalblue- Reversing this one is what you would expect, confusing with lots of threads. I'm assuming race condition, it simultaneously exploits SMBv1 and SMBv2. I think Google's protobuf may be statically linked, there were string references to .c files, and lots of stupid functions to reverse. This also seems to exploit Cairo, an undocumented SMB LanMan alternative.

Eternalromance- Very easy to reverse. No symbols or anything, but most of the functions have debug print statements with the original function names. Has 3 exploit "methods", which all have a different "danger zone" before trickle into a common function. Looks like it does a lot of memory "grooming", aka remote heap feng shui?

[zerosum0x0]

Post about the kernel DLL loader. Pretty standard, just map DLL into process memory and queue APC. Still not much info on the backdoor installed in the SMB service in the first place.

https://countercept.com/our-thinking/an ... technique/

Here's some info on the Eternalblue overflow/use-after-free of smbv1 buffer:

http://blogs.360.cn/360safe/2017/04/17/ ... lblue-smb/

[zerosum0x0]

I performed analysis of the DoublePulsar payload.

https://zerosum0x0.blogspot.com/2017/04 ... -ring.html

tl;dr:

Step 0: Shellcode trickery to determine if x86 or x64, and branches as such.
Step 1: Locates the IDT from the KPCR, and traverses backwards from the first interrupt handler to find ntoskrnl.exe base address (MZ header).
Step 2: Reads ntoskrnl.exe's exports directory, and uses hashes (similar to usermode shellcode) to find ExAllocPool/ExFreePool/ZwQuerySystemInformation functions.
Step 3: Calls ZwQuerySystemInformation with the SystemQueryModuleInformation argument, which loads a list of all drivers. It uses this to locate Srv.sys, an SMB driver.
Step 4: Overwrites the SrvTransaction2DispatchTable member function SrvTransactionNotImplemented with its own function.
Step 5: With secondary DoublePulsar payloads (such as inject DLL), it sees if you "knock" correctly and allocates an executable buffer to run your raw shellcode. All other requests are forwarded directly to the original SrvTransactionNotImplemented function. "Burning" DoublePulsar doesn't remove this hook, just makes it dormant.

[bantempmail]

Great writeup.

Quoting from your blog:

If/when this gets ported over to Metasploit, I would probably not copy this verbatim, and rather skip the backdoor idea. It isn't the most secure thing to do, as it's not a big secret anymore and anyone else can come along and use your backdoor.

Here's what can be done instead:

Obtain ntoskrnl.exe address in the same fashion as DoublePulsar, and read export directory for necessary functions to perform the next operations.
Spawn a hidden process (such as notepad.exe).
Queue an APC with Meterpreter payload.
Resume process, and exit the kernel cleanly.
???
Profit
Anyways, just a thought.

I dont understand where it avoids PatchGuard and how? Is it in Step 4, where the .data section already has 'write' permissions set?

Inside of the .data section is generally global read/write memory, and stored here is the SrvTransaction2DispatchTable, an array of function pointers that handle different SMB tasks.
The shellcode allocates some memory and copies over the code for its function hook.
Next the code stores the function pointer for the dispatch named SrvTransactionNotImplemented() (so that it can call it from within the hook code). It then overwrites this member inside SrvTransaction2DispatchTable with the hook.

Also, isnt stealth the point of their ring0 backdoor? If you spawn a process and queue an APC, it happens in usermode, right? So all kinds of HIPS solution could maybe pickup on it. As well as firewall or IDS rules.

[zerosum0x0]

I dont understand where it avoids PatchGuard and how? Is it in Step 4, where the .data section already has 'write' permissions set?

It avoids PatchGuard in that it hooks an obscure part of the system, the SMB driver dispatch table. PatchGuard looks for hooks in the syscall table and things such as win32k.sys, but this seems to not be affected.

Also, isnt stealth the point of their ring0 backdoor? If you spawn a process and queue an APC, it happens in usermode, right? So all kinds of HIPS solution could maybe pickup on it. As well as firewall or IDS rules.

You can make the kernel payload stealthier, even password protected, but the payload provided in FuzzBunch is just global. If you pwn someone, anyone can come along and use your backdoor. A firewall or IDS rule can easily pick up the current payload as well (especially since SMBv1/SMBv2 don't have the encryption capabilities that SMBv3 has).

Creating a process and queuing the APC in the way I described, I did mean head into usermode. You obviously can do everything for post-exploitation you want in the kernel, but it's just a lot easier to work with usermode APIs (not to mention safer for system stability). Also, in this instance I was specifically talking about Metasploit, which only really has usermode malware capabilities.

[EP_X0FF]

You should probably check this with 8.1/10 (th2+) as PatchGuard updated here. PatchGuard on Windows 7 SP1 and it derivative Server 2008 R2 is a merely a joke then anything else.

Code: Select all

0   : A generic data region	
1   : Modification of a function or .pdata
2   : A processor IDT	
3   : A processor GDT	
4   : Type 1 process list corruption
5   : Type 2 process list corruption	
6   : Debug routine modification
7   : Critical MSR modification	
8   : Object type	
9   : A processor IVT	
a   : Modification of a system service function	
b   : A generic session data region	
c   : Modification of a session function or .pdata	
d   : Modification of an import table
e   : Modification of a session import table
f   : Ps Win32 callout modification	
10  : Debug switch routine modification	
11  : IRP allocator modification	
12  : Driver call dispatcher modification	
13  : IRP completion dispatcher modification	
14  : IRP deallocator modification
15  : A processor control register	
16  : Critical floating point control register modification	
17  : Local APIC modification	
18  : Kernel notification callout modification	
19  : Loaded module list modification	
1a  : Type 3 process list corruption	
1b  : Type 4 process list corruption	
1c  : Driver object corruption	
1d  : Executive callback object modification	
1e  : Modification of module padding	
1f  : Modification of a protected process	
20  : A generic data region	
21  : A page hash mismatch	
22  : A session page hash mismatch	
23  : Load config directory modification	
24  : Inverted function table modification	
25  : Session configuration modification	
26  : An extended processor control register	
27  : Type 1 pool corruption	
28  : Type 2 pool corruption	
29  : Type 3 pool corruption	
2a  : Type 4 pool corruption	
101 : General pool corruption	
102 : Modification of win32k.sys 

This list is from ext.dll of windbg and it is a bit obsolete, as there even more undocumented bugcheck ID's in recent Windows 10. Also some scan types here seems were reviewed and improved by MS in win10. Generally as you see there some promising types. None from the above doesn't guarantee instant BSOD, it can take hours to do 109 bugcheck.

[zerosum0x0]

Yea I am sure if newer PatchGuard didn't watch this hook before, it will probably be added now. And some of the "better" antivirus vendors might add checking too. It does seem to bypass the shitty Win7 PatchGuard though.

--

On another note I figured out the DoublePulsar "xor key" (how to authenticate after the first knock).

s = SMB.Signature1
x = 2 * s ^ (((s & 0xff00 | (s << 16)) << 8) | (((s >> 16) | s & 0xff0000) >> 8));

[zerosum0x0]

My colleague and I reverse engineered EternalBlue and ported it to Metasploit.

https://twitter.com/zerosum0x0/status/8 ... 9856016384

Will probably do a blog post in the coming days.