Note
Mission start!
The CTF background notes that we’ll be attacking a Windows box. So no ping responses again.
Activate forward scanners and launch proton torpedoes
The machine we’ll be attacking is at 10.10.223.185. As usual, we’ll start out with an Nmap scan:
Which gives us:
# Nmap 7.92 scan initiated Wed Dec 8 19:55:54 2021 as: nmap -v -oA blaster -Pn -A -T4 -sS -script vuln -p- 10.10.223.185
Pre-scan script results:
| broadcast-avahi-dos:
| Discovered hosts:
| 224.0.0.251
| After NULL UDP avahi packet DoS (CVE-2011-1002).
|_ Hosts are all up (not vulnerable).
Nmap scan report for 10.10.223.185
Host is up (0.23s latency).
Not shown: 65533 filtered tcp ports (no-response)
PORT STATE SERVICE VERSION
80/tcp open http Microsoft IIS httpd 10.0
|_http-server-header: Microsoft-IIS/10.0
|_http-csrf: Couldn't find any CSRF vulnerabilities.
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
3389/tcp open ms-wbt-server Microsoft Terminal Services
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING): Microsoft Windows 2012|2016 (90%), FreeBSD 6.X (85%)
OS CPE: cpe:/o:microsoft:windows_server_2012:r2 cpe:/o:microsoft:windows_server_2016 cpe:/o:freebsd:freebsd:6.2
Aggressive OS guesses: Microsoft Windows Server 2012 R2 (90%), Microsoft Windows Server 2016 (89%), FreeBSD 6.2-RELEASE (85%)
No exact OS matches for host (test conditions non-ideal).
Uptime guess: 0.013 days (since Wed Dec 8 19:54:04 2021)
Network Distance: 4 hops
TCP Sequence Prediction: Difficulty=259 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows
TRACEROUTE (using port 80/tcp)
HOP RTT ADDRESS
1 34.47 ms 10.13.0.1
2 ... 3
4 351.16 ms 10.10.223.185
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Wed Dec 8 20:12:16 2021 -- 1 IP address (1 host up) scanned in 982.31 seconds
Looks like IIS running on port 80. Let’s go take a peek.
…And, it’s just the default IIS “hello world” page. Looks a damn sight prettier than Apache’s.
Since there’s nothing obvious here (and because the CTF is prompting us to do so), let’s sic gobuster on this to see if there’s anything interesting that’s not linked to the (default) index page.
There is a hidden directory here, and browsing to it reveals an entire “Retro Fanatics” website. All posts are by “Wade”.
Poking around a bit more reveals a somewhat cryptic comment on a post:
Leaving myself a note here just in case I forget how to spell it: parzival
Who wants to bet that this is Wade’s password?
Let’s load up XFreeRDP and see if we can log in, shall we?
Boom!
Breaching the control room
There’s no obvious files when pocking around except an hhupd.exe file on the desktop, and IE’s history is empty.
Since I know we’re looking for a CVE name, at this point I just used the Windows File Explorer to search Wade’s home directory for “CVE”. And lo-and-behold, there’s a cached HTML file in C:\Users\Wade\AppData\Local\Microsoft\Windows\INetCache\Low\IE\7Z6YUWVY
called cvename[1].htm
which contains a website referencing CVE-2019-1388 (it looks like a slightly older version of the MITRE CVE page on CVE-2019-1388).
(I feel like the approach I just used — making an educated guess about what the CTF was looking for and then just searching for it — is kind of a cop-out. But, the hint for this question states that I should check IE’s history, which I did… So perhaps the room’s broken?)
Anyways, I’m guessing that the hhupd.exe file on the desktop is the one that will exploit this vulnerability, since it’s badged as needing administrative privileges and CVE-2019-1388 is a vulnerability in the UAC screen.
In fact, a search for “CVE-2019-1388 exploit” pulls up a page that references hhupd.exe and helpfully links to a YouTube video demoing how this exploit works. It looks like the steps here are:
- Try to run hhupd.exe.
- Show details on the UAC prompt.
- Click on the certificate information link.
- Click on the issuer link. This will open up an instance of IE running with elevated permissions in the background.
- Exit the UAC dialog.
- Bring up the save dialog in IE.
- Navigate to
C:/Windows/System32/*.*
and open cmd.exe.
The final flag is in the Administrator’s Desktop folder.
Adoption into the collective
Target information isn’t immediately obvious in Metasploit; after selecting exploit/multi/script/web_delivery
we’ll need to run info
to see all of the options.
Let’s set things up and run the exploit:
Tip
I found that I needed to set the SRVHOST option to get Metasploit to deliver the exploit on the right interface.
This particular exploit outputs and encoded PowerShell script and then starts a local listener to deliver the actual meterpreter shell. All we need to do is cut-and-paste into our elevated shell.
(For whatever reason, I could only get this exploit working with the 32-bit version of meterpreter and the run -j
command. I’m not sure why…)
Caution
meterpreter flags this as being deprecated now; the modern pattern seems to be to background meterpreter and then switch to and exploit the
exploit/windows/local/persistence
module, probably withset STARTUP SYSTEM
.
Elapsed Time: 2 h 15 min