Reset
This challenge simulates a cyber-attack scenario where you must exploit an Active Directory environment.
Last updated
This challenge simulates a cyber-attack scenario where you must exploit an Active Directory environment.
Last updated
This work by Manav G Krishna is licensed under CC BY-NC 4.0
Machine IP: 10.10.189.115
Nmap Scan:
From the scan we can straight away see that we have an Active Directory environment and we can add the following to our hosts (/etc/hosts) file: thm.corp, haystack.thm.corp ,HAYSTACK(The NetBIOS Name, which is basically nothing but NetBIOS name resolution)
Checking out a few important ports:
Port 53 (DNS):
We can see if we get more FQDNs such as haystack.thm.corp by querying for DNS records by using a utility named dig (dig any thm.corp @10.10.189.115). What this command does is, the any switch fetches all DNS records for the domain thm.corp by sending the DNS requests to the DNS server located at 10.10.189.115.
But in this case we didn't get any new FQDNs.
Port 135 (MSRPC):
We can do a null session enumeration to see if we can get any usernames using a tool named rpcclient.
Command:
If we are able to connect/login successfully we can use the enumdomusers command to fetch usernames:
In this case we were able to connect but we can't enumerate usernames.
An other way to run this is:
Command:
Port 389 (LDAP):
We can try to fetch usernames by querying the LDAP directories if we are allowed to perform an anonymous bind:
But we couldn't get any information as we weren't able to bind successfully.
Port 5985 (WinRM):
This port will come in handy later when we want to connect remotely to a user.
Port 88 (Kerberos):
Now let's check if we can fetch some usernames through Windows SID bruteforcing. To do this we can use impacket's lookupsid as guest. The same command can also be run as anonymous.
Command:
Now since we have a list of potential usernames we can perform stuffs like bruteforcing for valid usernames using a tool called kerbrute. We can make use of various impacket scripts to perform AS-REP Roasting, Kerberoasting etc. Put all these users into a file, we can call it - users
Using kerbrute with the above users list:
Command:
Out of the 42 usernames from the list 40 of them are valid kerberos usernames. In a Kerberos environment, user authentication is based on the user's Kerberos principal, which typically takes the form of username@REALM as we can see in the picture.
We can put all these final list of users into a file named validusernames.
Performing AS-REP Roasting:
AS-REP Roasting is a technique that allows retrieving password hashes for users that have Do not require Kerberos preauthentication property selected.
Command:
We have got the hashes of 3 users: ERNESTO_SILVA, TABATHA_BRITT, LEANN_LONG.
Note:
In the command I have used the format to be john, so the hashes fetched will be in john format. By default it will be in the hashcat form. It doesn't matter what format it is in. I have used the -format switch just for simplicity. The hashcat hash that we get by default can be used with john too to crack. The above command can be also run without the -format switch.
Attempting to crack these obtained hashes for the password:
Command:
Out of the 3 hashes only the hash for TABATHA_BRITT could we cracked.
Note:
Since I had already done the cracking before, I have used the --show switch of john to show the password.
Now since we have valid creds, we can further go ahead to perform Kerberoasting to see if we can get more hashes for other users.
Performing Kerberoasting :
Kerberoasting is a post-exploitation attack technique that is used to obtain a password hash of an Active Directory (AD) account that has a servicePrincipalName (SPN) value.
Command:
We got a bunch of hashes for all those usernames that are marked above. But none of these were crackable.
We can see if anything else can be done using TABATHA_BRITT's creds such as using crackmapexec to see if we have winrm,smb,rdp etc:
It shows Pwn3d! for rdp and we could enumerate smb shares but we can't winrm in.
Note:
Initially while solving the room I had enumerated information from the SMB port without having any valid creds along with Kerberos pentesting in parallel. I have explained about SMB enumeration below. In the above picture for smb, my point was to just show all possibilities for the user TABATHA_BRITT)
Based on the above information, we can RDP in as TABATHA_BRITT, but let's keep that for later.
Port 139/445 (SMB):
We can try to login to see the network shares on the domain using a tool called smbmap. Any name can be used for this as far as we can get in anonymously.
Command:
There is a network share named Data having Write permissions. This is indeed interesting.
Using smbclient to interact with that share:
Command:
We notice that there is a directory named onboarding and the file names keep changing, this is again interesting.
Downloading the files to our system:
Checking out the files:
This file reveals a password.
One of the pdf files had the same contents as in that txt file, but we get the user for which the password belonged to: LILY ONEILL (To view PDF files in Kali, a tool named evince can be used. It is there in the apt repo cache. To install it: apt install evince , command to use it: evince pdf_file.pdf
But from the list of validusernames that we got before we know that LILY_ONEILL ain't a valid user.
Checking for rdp, smb & winrm access:
We can see that the creds are valid for smb but we can't list out the shares. So knowing this user's password was not much of a use.
But the write access on the Data share & the file names changing often in the onboarding directory looks juicy. Since the file names are changing we can come to an assumption that someone might be accessing the contents in the onboarding directory. Let's try to make use of this to steal a NTLM hash of the user that might be making the changes within the share.
Upon Googling: smb ntlm hash steal, I came across this blog that had a mention of a tool named ntlm_theft that can help us in stealing a hash:
Using the tool:
Command:
What the tool does is it generates different file types and it saves it to a directory that we specify, have named it test. These files can then be tried on by uploading them to an SMB share to steal the hash by setting up a tool called Responder .
Responder is a network tool used in penetration testing to capture credential information during man-in-the-middle attacks. Responder listens for LLMNR and NBT-NS requests on the network. When a system on the network sends a name resolution request, it intercepts and responds to these requests with spoofed answers, tricking the requesting system into sending authentication information. When a system falls for the spoofed response and attempts to authenticate, Responder captures the authentication request and collects the NTLMv1/NTLMv2 hash from the authentication exchange. It does not store plaintext passwords but captures the hashed credentials. The captured hash can then be cracked to get the password.
Since we have Write permissions on the Data share we can upload the files that the tool gave us inside the onboarding directory as that is where we think there is someone accessing the contents.
Command to set up Responder:
We have set it up successfully and it is listening.
Files generated by ntlm_theft:
Now let's upload a few of these files into the onboarding directory to steal the NTLM hash:
Command:
This command is being run from within the test directory. Make sure to add the full path for the -c switch if needed.
Note:
I had uploaded a couple of other files while testing and the one that worked was the test.lnk file, which is why I have shown that in the command.
After a couple seconds post uploading, Responder has indeed captured a hash for a user named AUTOMATE. We can maybe say that by looking at this name, the file names changing within the SMB share was mostly automated:
Cracking this hash using John:
The command is the same as the one that was mentioned initially.
Note:
Since I had already done the cracking before, I have used the --show switch of john to show the password.
We can now again use crackmapexec to see if we have winrm access as the user AUTOMATE:
It shows Pwn3d!. Now we can use a tool called evil-winrm to winrm in as this user.
Command:
We can find the user flag in the Desktop folder of AUTOMATE.
An other way of finding AUTOMATE's password is by RDP ing as TABATHA_BRITT and querying the Winlogon registry:
Command:
This is a common place where passwords are usually stored in Windows. The command to RDP in can be found towards the end of the page.
A blog on the same:
We can do some enumeration by traversing different folders etc, but in this case there was nothing interesting that we could find.
Deciding to run a tool called BloodHound:
BloodHound is a sophisticated open-source security tool designed for Active Directory (AD) analysis in Windows environments. Utilizing graph theory, it visually maps and analyzes relationships within an AD infrastructure, providing insight into permissions, trust relationships, and potential attack paths.
It utilizes the Neo4j graph database as part of its architecture.
It is typically executed using an ingestor named SharpHound, which is uploaded to the target machine. Commands are then run to fetch the necessary information. It is basically a data collection tool for BloodHound. But in this case that wasn't working as the AV on the target machine was flagging it as a virus.
But the simpler alternative to running SharpHound is by using this Python based ingestor which can be run remotely from our attacking machine to fetch all the data.
Command:
The -c is used to collect information, using the all argument for it collects everything. We can see that the tool has given us all the needed info to visually analyze this data using BloodHound.
7 json files were generated:
Inorder to run BloodHound we have to start the neo4j console. If anyone's new to it, check out this video on how to set it up:
Starting the neo4j console:
To start BloodHound just type bloodhound in the terminal post starting the console and this will open up the neo4j login page. Once logged in, the generated json files have to uploaded, once this is done we can start to analyze the data:
Analyzing the BloodHound data:
Using this data we can find our way to move laterally to become the Administrator, basically to root the machine.
We can start by checking the AUTOMATE@THM.CORP node, but there were no interesting edges from here.
But we also do have RDP access as TABATHA_BRITT@THM.CORP which we had found initially. So let's check out this user's node to see how we can proceed:
Upon selecting First Degree Object Control under OUTBOUND OBJECT CONTROL , we notice that TABATHA_BRITT@THM.CORP has GenericAll permissions on two users named SHAWNA_BRAY@THM.CORP & RAQUEL_BENSON@THM.CORP:
Upon further inspecting, there was nothing much for the user RAQUEL_BENSON@THM.CORP that could help us move laterally but SHAWNA_BRAY@THM.CORP had interesting permissions on other users.
Now let's check out the node of SHAWNA_BRAY@THM.CORP. Click on this users node for the respective information to load.
Upon selecting Transitive Object Control under OUTBOUND OBJECT CONTROL , we notice that SHAWNA_BRAY@THM.CORP has ForceChangePassword permissions on a user named CRUZZ_HALL@THM.CORP :
Now let's check out the node of CRUZZ_HALL@THM.CORP. Click on this users node for the respective information to load.
Upon selecting First Degree Object Control under OUTBOUND OBJECT CONTROL , we notice that CRUZZ_HALL@THM.CORP has ForceChangePassword permissions on a user named DARLA_WINTERS@THM.CORP :
Now let's check out the node of DARLA_WINTERS@THM.CORP. Click on this users node for the respective information to load.
We straight away notice that we have data for Constrained Delegation Privileges. If we have compromised a user account or a computer (machine account) that has kerberos constrained delegation enabled, it's possible to impersonate any domain user (including administrator) and authenticate to a service that the user account is trusted to delegate to.
Upon selecting that we can see the user DARLA_WINTERS@THM.CORP has the AllowedToDelegate permissions on the computer HAYSTACK.THM.CORP:
Now we have successfully found out our attack path to become Administrator.
To brief it out:
TABATHA_BRITT@THM.CORP -> GenericAll -> SHAWNA_BRAY@THM.CORP
SHAWNA_BRAY@THM.CORP -> ForceChangePassword -> CRUZZ_HALL@THM.CORP
CRUZZ_HALL@THM.CORP -> ForceChangePassword -> DARLA_WINTERS@THM.CORP
DARLA_WINTERS@THM.CORP -> AllowedToDelegate -> HAYSTACK.THM.CORP
Exploitation:
We can check out the Help section at each edge to exploit, but l won't be doing it that way.
TABATHA_BRITT@THM.CORP -> GenericAll -> SHAWNA_BRAY@THM.CORP
The GenericAll permission provides write access to all properties (add users to a group or reset the user’s password). So in this case we (TABATHA_BRITT@THM.CORP) can abuse this permission in two ways.
First way: By RDP ing as TABATHA_BRITT@THM.CORP and changing the password of SHAWNA_BRAY@THM.CORP:
Command to RDP (from attacking machine):
(Type in Y when prompted)
Command to change password after opening CMD:
Second way: Since it is GenericAll we can make use of ForceChangePassword permission abuse too to change the password of SHAWNA_BRAY@THM.CORP:
Command:
Once connected type:
To confirm that the changes were successful we can crackmapexec on rdp as SHAWNA_BRAY as from the BloodHound output this user had RDP privileges:
This shows the password change worked.
SHAWNA_BRAY@THM.CORP -> ForceChangePassword -> CRUZZ_HALL@THM.CORP
The ForceChangePassword permission allows us (in this case SHAWNA_BRAY@THM.CORP) to reset a user's password without knowing their current password. So this user can reset CRUZZ_HALL@THM.CORP's password. (Refer to the ForceChangePassword blog attached above).
Command:
Once connected type:
To confirm that the changes were successful we can crackmapexec on rdp as CRUZZ_HALL as this user too had RDP privileges:
This shows the password change worked.
CRUZZ_HALL@THM.CORP -> ForceChangePassword -> DARLA_WINTERS@THM.CORP
Same as above, this time CRUZZ_HALL@THM.CORP can reset DARLA_WINTERS@THM.CORP's password.
Command:
Once connected type:
To confirm that the changes were successful we can crackmapexec on rdp as DARLA_WINTERS as this user too had RDP privileges:
This shows the password change worked.
DARLA_WINTERS@THM.CORP -> AllowedToDelegate -> HAYSTACK.THM.CORP
The AllowedToDelegate permission allows us (in this case DARLA_WINTERS@THM.CORP) to impersonate the Administrator account by targeting the CIFS service to retrieve a usable TGS ticket .
Blogs:
We can abuse the same by using a tool called Rubeus which involves us uploading this to the target machine, but since we know that there is AV it is again going to flag it is a virus like how it did for SharpHound before.
An other way to do this is by using an impacket script named getST.
Command Syntax:
The FQDN is haystack.thm.local
We could also see this in the BloodHound information:
Command:
The ticket generated: Administrator.ccache
Now we need to export this ticket that we got into memory like so:
We can now dump secrets from the registry hives using an other impacket script named secretsdump or we can use other scripts like psexec, wmiexec to get a shell, in this case as Administrator
Dumping secrets to get the NTLM hash of Administrator did work but we couldn't do a PassTheHash
Using psexec hadn't worked, but wmiexec did:
Command:
We got an admin shell successfully. The -k (Kerberos authentication) switch in the above command is used to grab credentials from the ccache file (KRB5CCNAME) that we had previously exported.
Now we find the root flag in the Desktop folder of Administrator:
Room solved!!
