Overview

This post continues the technical analysis of the BadRabbit ransomware attacks discussed in Part One of this two-part series. Part One described how BadRabbit uses MS17-010 to both leak a transaction data structure, and to take control of two transactions. Doing so allows BadRabbit to modify several areas of kernel memory. Part Two describes the steps taken by BadRabbit to leverage those controlled data structures to elevate the authenticated SMB session to System.

Privilege Escalation Analysis

There is no shellcode involved with this exploit. Instead, BadRabbit modifies a security context for the session to get SYSTEM access. This allows a follow-up connection to ADMIN$ that checks for the existence of cscc.dat, and if it doesn’t exist, writes infpub.dat to ADMIN$.

Figure 1: SMB Traffic, Infect Target with BadRabbit

In the Wireshark output there is a “Close Request, FID: 0x4000” and a “Tree Disconnect Request.” This traffic is what happens after the session privileges have been elevated. Note the lack of an “SMB Logoff” request to close the session. Instead, a new Tree Connect request is made, BadRabbit writes itself to the target host, and then uses the SVCCTL RPC to create a service and launch BadRabbit on the target host.

The following sections cover the steps taken by BadRabbit to elevate session privileges for the SMB connection.

Modifying Session→IsNull and Session→IsAdmin Fields

Based on the next transaction, the InData pointer for MID 5851 is going to be overwritten with the address 0x864CFAEE. This address was calculated using the address of offset 0x10 of the leaked MID 5379 transaction.

Figure 2: SMB Packet, Overwrite IsNull and IsAdmin

Once the InData pointer is modified, a MID 5851 request is sent to overwrite that address with 256 (0x100, last two bytes in hex dump). The original thought was that this had something to do with a buffer-size value, but that was incorrect. According to proof-of-concept code written by Worawit (see the resources section), this is overwriting two bytes of a session structure. The session address + an offset of 0x96 is used to modify the IsNull field with 0x00 and the IsAdmin field with 0x01.

Leaking the Address of the Security Context

Now that everything is in place, the address of the security context can be leaked.

Pointing MID 5851 to the Session Data Structure

MID 5379 is used to to overwrite 48 bytes located at MID 5851 + 0x44. The first three DWORDs are pointers to OutParameters, InData and OutData.

Figure 3: SMB Packet, Modify 5851 to Leak Session Structure

These three addresses are pulled from the MID 5379 information leak:

• 0x86516050
  • Overwrites the OutParameters pointer
  • Offset 0x18 of the MID 5379 leak
  • Used to read the _FLINK for 0x86516038
• 0x86516238
  • Overwrites the InData pointer
• 0x864CFA58
  • Overwrites the OutData pointer
  • Offset 0x10 of the MID 5379 leak
  • According to Worawit, this is the address of a session data structure.

Once the information leak is triggered, the data buffers pointed to by 0x86516050 and 0x864CFA58 are going to be read and sent back to the attacker. The overwritten OutParameters pointer will leak the next transaction. OutData is going to leak the session data structure.

According to the exploit code written by Worawit, the rest of the data is used to limit the amount of data being leaked and to set that transaction function (NT_RENAME).

Leak the Session Data

The attacker sends an NT Trans Rename request, followed by an NT Trans Rename secondary request using MID 5851. The target responds with 264 bytes of data from the location pointed to by the OutData pointer and the OutParameters pointer.

Figure 4: Leaked Session Data Structure

The first eight bytes come from the OutParameters buffer and contain the _FLINK data. The next 256 are from the OutData buffer. The address of the security context is located at offset 0x88.

Prerequisite for Overwriting the Security Context

A MID 5379 transaction modifies itself by using the InParameters pointer to overwrite its own InData pointer with an address calculated from a leaked address located at 0x00 in the OutParameters buffer in Figure 4. Subtracting 0x18 from 0x864EE028 yields the base address of the transaction. This leaked address points to the _FLINK of the transaction located at 0x864EE010.

Figure 5: SMB Packet, Point MID 5379 to 0x864EE010

The InData pointer of MID 5379 now points to the transaction located at 0x864EE010. The MID of the transaction located at 0x864EE010 is changed to 5851.

Figure 6: Use MID 5379 to Change MID of 0x864EE010

It’s currently unknown why MID 5379 is used to take control of another transaction by modifying the MID of 0x864EE010 to 5851. It’s likely related to how the previous one was modified to leak the session data structure. Once this has been completed, the privilege escalation phase begins.

Overwriting the Security Context

A secondary transaction request using MID 5379 is used to overwrite the InData pointer of MID 5851 with the address of the security context to be overwritten. The next MID 5851 request that contains data to be written is going to write at that address. The address of the security context is 0x8CEE9498. This was leaked from the section on using MID 5851 to leak kernel memory.

Figure 7: SMB Packet, Point 5851 at Security Context

This request is followed up with a request using MID 5851 with the data that is going to be used to overwrite the security context structure.

Figure 8: SMB Packet, Write Security Context

This is the same approach taken by the public exploit written by @_sleepya (Worawit). The following is a data structure used to store the security context data from _sleepya’s exploit:

Figure 9: Worawit’s Security Data Structure from the Exploit

The FAKE_SECTX contains the same data that BadRabbit is going to use to overwrite the session security context structure. Doing so, combined with the section on modifying the IsNull and IsAdmin values, completes the exploit. Now, the session has been granted full read/write privileges and BadRabbit can continue its infection.

Reference

Transaction Data Structure

Part of the following is created from the code on _sleepya’s (Worawit’s) github and the rest is from analyzing the SrvSmbTransaction function in the SMB Driver (srv.sys). This is based on Windows 7 SP1 x86.

Figure 10: Transaction Data Structure

Resources

Worawait Wang’s Exploit Code

We discovered Worawit’s (_sleepya on Twitter) github after doing the analysis. It was used to fill in incorrect assumptions and gaps (referenced throughout this article). This exploit code was used to model the exploit used by BadRabbit.

• https://github.com/worawit/MS17-010/blob/20301cc5a96fa367d46d88291637247cc6252488/zzz_exploit.py

Check out the rest of Worawit Wang’s github as it contains a significant amount of analysis on MS17-010.

Nicolas Joly’s HITCON 2017 Presentation

The following is another good resource discovered after doing the analysis:

• Mitigating the Unkn0wn: When your SMB Exploit Fails

The presentation covers multiple MS17-010 exploits that were leaked by the Shadow Brokers. The EternalSynergy slides match what is going on during BadRabbit’s exploitation of MS17-010.

CrowdStrike® Falcon Intelligence

Learn more about the CrowdStrike Falcon® Intelligence™ offerings, and read the white paper, “Threat Intelligence, Cybersecurity’s Best Kept Secret.”