Voleur

Dear reader, I apologise. For a few months now I’ve had far less time to dedicate to HTB machines. I thought I would at least publish the write-ups for the machines I’d been tackling, but even that lost priority, as I left most of the write-ups in a bit of a rough shape. This one was practically finished though, so here I am trying not to be a stranger.

Voleur felt like a step up from Administrator, in the sense that I didn’t need to learn many new things, especially after going through other machines like RustyKey, TombWatcher and Puppy. Ideally, I would have published the write-ups for those already… but here we are. There are quite a few techniques on display though, which I think makes it interesting.

David Holmes’ “Snake Eyes” music on

Alright, so, what are we dealing with?

We again have a regular, everyday, normal domain controller, except for the SSH service listening on port 2222, which strangely reports running on Ubuntu Linux. Aside from that, we’ll probably end up explicitly interacting with SMB, WinRM and maybe LDAP, and everything else we can consider to be noise at least for now.

This is yet another assumed-breach scenario, so we start by confirming our credentials. NTLM is disabled in this domain, so we’ll see STATUS_NOT_SUPPORTED until we use Kerberos to authenticate. We also need to handle the clock skew with our usual trick:

Before going ahead and whistling our trusty BloodHound over, I thought I would see what I could see with this account. First step, network shares. Turns out there are a few interesting shares, one of which we can read:

I remembered that I had trouble using smbclient with Kerberos recently, and I was being lazy, so I decided to just download the contents of the shares we could read (we might want to inspect SYSVOL as well soon), again using netexec:

Turns out there was only one file in the IT share, but we are looking for quality over quantity. The promisingly-named Access_Review.xlsx is an Office spreadsheet, and it is password-protected to boot:

We will either find the credentials later, or we can crack them if they’re weak. After extracting the password hash from the file, hashcat tells us that yep, it is weak:

Staff only beyond this point

What a treasure trove the file is! We have a list of users, some passwords, and very informative notes. Namely:

• we, Ryan Naylor, are merely a First-Line Support Technician;
• an ex-second-line technician, Todd Wolfe, has had their account removed and password set to something I won’t just tell you;
• Jeremy Combs, a third-line technician, seems to be a High-Value Target and in charge of backups, an even higher-valued target;
• we now know the passwords to svc_ldap and svc_iis, and Lacey Miller might kindly provide us with the one for svc_winrm.

Before moving forward, we keep demonstrating netexec’s features and try to spray our known passwords over our known users, to see if there’s any reuse going on. We only get hits on the credential pairs we know, so no luck there. Everything else gives us a KDC_ERR_PREAUTH_FAILED (“incorrect password” in English), or in Todd’s deleted account’s case, KDC_ERR_C_PRINCIPAL_UNKNOWN:

I realised I hadn’t tested the weird Ubuntu SSH login yet, so now was a good time, but we find out we’re going to need a private key to use it:

Alright, it’s time to take the hound out for a walk:

Looking at the results, the most immediately actionable things are the rights that svc_ldap has over a few objects. First, it has GenericWrite over Lacey’s account, which normally allows us to take over their account. The spreadsheet said they might know how to access the svc_winrm account, so that sounds like a good way to go. But I tried adding shadow credentials to their account, after getting a TGT ticket for svc_ldap, and…

My excuse at the time for quickly moving on was that “there are some requirements for this technique to work”, so before spending too much time debugging this I thought I’d try other low-hanging fruit. It was only when working on this write-up that I noticed I had the wrong domain (-d rustykey.htb) in the command I had recycled from the shell history… aaaanyway. I did move on to try a targeted Kerberoast, though that too was unsuccessful, after hashcat confirmed that the credentials weren’t too weak:

Huh… ok, well, svc_ldap also has WriteSPN rights directly over svc_winrm, so we can try a targeted Kerberoast of that account as well:

Great success! By the way, I know what you’re thinking. Lacey knows to set a strong password for herself, and then goes and sets a weak password for this service account… Pfft! Well, I gotta say, that’s the strongest weak password I’ve ever seen. Alas, your strong passwords can still get leaked, and I guess our fictional support technician had an account on Rockyou.

I tried a spray of this new password, for good measure, but with no new hits. So, we get ourselves a new TGT ticket, set up our Kerberos configuration again with the help of netexec, and [hacker voice] we’re in:

Reanimation room

A foothold on the machine is important, and we got our user flag, but it looks like we won’t get much more out of this account. We do get a particularly important piece of information - even if we don’t have access to them, we can see that there are more folders in the IT share than just the first-level one we knew of:

Aside from this, the account has no particular privilege, and nothing else on the parts of the file system that it can access looks interesting for now. A quick netstat -ano doesn’t show any additional services running locally either. But before we go too deep into something like credential-hunting or checking for vulnerable software, there are two lower-hanging fruit that I want to try.

First, we also have valid credentials for svc_iis. I’ll spare you the details though, because nothing of note came out of a quick enumeration of it. More importantly though, back to our svc_ldap account, BloodHound also told us that it is part of a “Restore_Users” group. Knowing that Todd Wolfe’s account had been removed, and off the heels of the TombWatcher box where we learned about restoring deleted AD objects, this was ringing a lot of bells.

svc_ldap does not have the right to login remotely, but now that we have access via svc_winrm, we can use RunasCS. Also off the heels of RustyKey, I was too familiar with how to use it properly, and used it to connect back to our attack machine:

Back on our machine, where our listener was setup, we get a connection and a session as svc_ldap:

Cool! We get right to work looking for deleted objects, and aside from the container itself, we do indeed find poor Todd:

We perform our dark magic and confirm we did bring him back:

Without wasting time, we spider the shares that Tom can access, as he’s a member of the second-line support group and can probably see into the respective directory in the IT share. This was taking quite a bit of time to resolve, so I canceled that first try and checked for what might be wrong. When everything looked ok, I started it again, and luckily I didn’t set the option to automatically download all the files:

Whoa, ok, what’s in there? Checking the spider’s metadata result, it’s clear that someone made a copy of Todd’s old home directory into the share:

I actually never checked, but I assume that if we logged in as Todd we wouldn’t find these files. We restored his AD object, but that doesn’t mean restoring any files that would have been deleted when the account was removed.

I keep referring to other recent machines in this write-up, but it did have sort of a capstone feel. So, again, off the heels of Puppy, my first thought was to check for Credential Manager files, and indeed there were some:

I could feel the root flag getting close, but I’d first need to download those files, and I sure didn’t want to download 480 other files as collateral damage.

Jezza’s account

It was finally time to troubleshoot smbclient’s refusal to work with Kerberos. My woes had been caused by some very old documentation, giving me a set of arguments that absolutely did not work:

Luckily I wasn’t alone, and with the help of that bit of research and some trial and error, this is what does work (assuming, of course, that your ccache is setup and valid):

The box’s cleanup script re-deleting Todd’s account was quite aggressive, so there’s no time to waste:

Time to get cracking! First, the master key, using Todd’s SID and credentials:

Then, the credentials, using the master key. The roaming one is the one we’re interested in:

Woop woop, we’ve made it to level 3!

Level 3

We quickly check for privileges, where nothing stands out, and then head straight to that third-level IT folder:

Ok, we’ve got:

• a pissed off Admin;
• the private key we’d been waiting for to use on port 2222;
• and a Backups folder that…

… we can’t access. No problem, no problem, we have other things to entertain ourselves with. Let’s test that private key, with a hunch that it belongs to the svc_backup user based on Admin’s frustrated note:

Well, the note pretty much said it, but we are now in an Ubuntu Linux subsystem in Windows. In other words, we have effectively landed in a Linux shell, so you know what I’m going to do next:

Oh. Don’t mind if I do:

Ok… we are now root in this Ubuntu Linux subsystem in Windows. I haven’t played around with WSL much, so for the first time in the box I wasn’t too sure how to proceed. Was I supposed to break out into the host, for example? Before going there, I looked around, and there was nothing to be found in svc_backup’s or root’s home. As root I could get /etc/shadow’s contents, but the only credentials in it (svc_backup’s) didn’t crack. It wasn’t until after I checked a few other locations like /opt and /var that I thought of checking for mounted file systems:

Ooooooh… Well, first things first:

Heheh yeah ok, fair enough. Had to try. Oh, but what about that Backups folder we saw earlier?

Nice backups guys! That ntds.dit file contains the hashed credentials of every user in the domain, admins included, and we have the SECURITY registry hive to unlock it. Let’s get those files:

We’ll use impacket-secretsdump to extract the Administrator’s hash. Because we are using it locally we cannot use the -just-dc-user flag, so we’ll extract everything. I’ve added the grep for the write-up’s sake:

I misunderstood the fact that NTLM authentication was disabled to mean that I couldn’t use the hash to get a TGT ticket. So my first thought was to try to crack the hash, which hashcat and rockyou.txt weren’t able to do. But once again off the heels of RustyKey, where I wondered if something was possible but didn’t actually try it, I just tried it:

So indeed that works. NTLM authentication is disabled, but we didn’t attempt to authenticate with NTLM. We requested a TGT ticket using the NTLM hash (technically, the RC4 key, which is derived from it). Then we authenticated with Kerberos using that TGT. We’ve effectively overpassed the hash (last paragraph).

We just tried, it just worked, and we’re done:

Roll the credits

• That season of HTB machines was great for cementing Active Directory basics, especially with boxes like this one putting it all together.
• Keeping notes on proper usage of tools after some trial and error (like with smbclient and RunasCS) is invaluable.
• As always, for reading this far, you’re a champ.