Rebound

Active Directory! Had some help after it ended.

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 3000 10.129.148.205         
Starting Nmap 7.93 ( https://nmap.org ) at 2023-09-12 16:28 +08
Nmap scan report for 10.129.148.205
Host is up (0.16s latency).
Not shown: 65315 closed tcp ports (conn-refused), 194 filtered tcp ports (no-response)
PORT      STATE SERVICE
53/tcp    open  domain
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
5985/tcp  open  wsman
9389/tcp  open  adws
47001/tcp open  winrm
49664/tcp open  unknown
49665/tcp open  unknown
49666/tcp open  unknown
49667/tcp open  unknown
49671/tcp open  unknown
49686/tcp open  unknown
49687/tcp open  unknown
49688/tcp open  unknown
49705/tcp open  unknown
49706/tcp open  unknown
49723/tcp open  unknown
63777/tcp open  unknown

Did a detailed scan on the main services too:

We can take note of the root domain name of rebound.htb and the DC name.

AD Enum --> AS-REP Fail

Used enum4linux to first scan to see if I can find anything using NULL sessions, which I can:

smbmap says we have read access over the Shared share:

However, there's nothing within it:

enum4linux also proceeded to enumerate SIDs out, which did return some but it was really slow. So, I changed to using crackmapexec to enumerate the users out:

Lots of users and groups, but most importantly we have some users. With a username list, we can try AS-REP Roasting without credentials.

However, this hash cannot be cracked for some reason.

Kerberoast W/O Pre-Auth --> Password

I googled a bit more about what I could do with jjones account since it doesn't have the PreAuth flag set for it. Came across a new Kerberoast method I didn't use before:

LogoKerberoast | The Hacker Recipeswww.thehacker.recipes

The edited files can be found here:

LogoSupport for Kerberoasting without pre-authentication and ST request through AS-REQ by ShutdownRepo · Pull Request #1413 · fortra/impacketGitHub

Using this method, we can try using GetUserSPNs.py to find a hash:

We get 2 hashes using this method, one for ldap_monitor and one for delegator. john is able to crack the hash for ldap_monitor.

Bloodhound + Password Spray + Thinking

Using these credentials, we can use bloodhound-python to enumerate the entire domain. Running it the first time reveals that gmsa.rebound.htb is another domain we need to add to the hosts file. Afterwards, we can run it to collect information about the domain:

Afterwards, we can upload the information to Bloodhound. From it, winrm_svc seems to be the next user we have to compromise:

The ServiceMgmt group was also found to have some interesting privileges:

Other than that, Bloodhound provided nothing of use since we aren't part of the ServiceMgmt group. I spent quite a bit of time thinking about how the user we compromised was called ldap_monitor, and what we could do with LDAP.

Attempting to use ldapdomaindump shows that we need 'stronger auth':

Since we still had a username list, I thought to try password spraying with the password I found, and I found another user with the same password:

This user does have access to more shares:

At this stage, I kept thinking about why the user we could compromise is called ldap_monitor, until I googled a bit more about it.

LDAP Monitor --> Change Password

Turns out this is an actual program we can use to monitor the LDAP traffic on the domain, sort of like Wireshark for LDAP.

LogoGitHub - p0dalirius/LDAPmonitor: Monitor creation, deletion and changes to LDAP objects live during your pentest or system administration!GitHub

When we take the script, I realised it doesn't work properly due to the requiring of 'stronger authentication'. Using the -use-ldaps flag doesn't work as well either, because it just says we have invalid credentials.

Since we have the credentials of the user, we can actually grab a Kerberos ticket:

Afterwards, we can use these flags to make it work properly and view the following LDAP changes:

Eventually, something like this appears:

The pwdLastSet is being edited to a more recent time, meaning that there's something resetting the password of these users. The winrm_svc user is the next step, so perhaps we have to change that password to login.

Based on Bloodhound, we need to be part of the ServiceMgmt group to have GenericAll privileges over winrm_svc, and we can use that to change the password of the user.

I tried the exploit with ldap_monitor, but it doesn't work with it. We can only use oorend to exploit this misconfiguration. Searching for tools to exploit this led to bloodyAD.py:

LogoGitHub - CravateRouge/bloodyAD: BloodyAD is an Active Directory Privilege Escalation FrameworkGitHub

I tried adding the oorend user to the ServiceMgmt group, and it surprisingly worked.

From here, what we can do is attempt to give oorend GenericAll privilege over the OU for Service Users, and from there set the password of the winrm_svc user to something else:

Afterwards, we can evil-winrm in as the user:

Privilege Escalation

I should note that because the box resets the passwords of winrm_svc user regularly, the evil-winrm shell dies pretty often.

Enumeration

Earlier in Bloodhound, we saw that the tbrady user has ReadGMSAPassword over the gmsa.rebound.htb domain, so they are probably the next step.

Fortunately, no defences were present on the box and I could download PowerView.ps1 to enumerate stuff. When enumerating Kerberos, I found that the delegator$ computer user had some delegation rights for the DC:

This is probably the last step to root, so we'll keep this in mind. I also ran a SharpHound.exe on the machine itself and updated my Bloodhound database. When taking a look at all the parts of tbrady noticed this:

The user has a session on the DC, and this might be exploitable as we could potentially steal credentials. There weren't any other leads I found, so I went along with this.

Remote Potato --> Tbrady Hash --> ReadGMSAPassword

I got some help from another HTB member, who told me that I should look towards thinking about how logged on users can be exploited, and I googled around to find this repo:

LogoGitHub - antonioCoco/RemotePotato0: Windows Privilege Escalation from User to Domain Admin.GitHub

The above tool would potentially allow us to steal the NTLM hash of the tbrady user. To set it up, first we have to create a socat listener and impacket-ntlmrelayx listener based on the instructions from the repo:

Afterwards, simply run the binary on the machine:

This would give us the hash of the tbrady user:

john can crack this hash to give the password of tbrady. Now that we have the password of tbrady, we can abuse the ReadGMSAPassword privileges given. Using bloodyAD.py, we can easily do this:

The reason why delegator$ is used is because we it has delegation privileges over the DC.

Constrained Delegation --> Root

We must remember that delegator$ is a machine account instead of a user account. We can re-confirm the constrained delegation misconfiguration using PowerView:

We have the NTLM hash of this delegator$ user. I found that abusing delegation without the msds-AllowedToActOnBehalfOfOtherIdentity property was not possible, and as such I focused on enabling this property.

From this point on, someone offered me some help. Whoever you are, thank you!

Their method involved the following:

  • Requesting a TGT using the NTLM hash for delegator$.

  • Using that ticket to allow delegation from ldap_monitor to delegator$ through RBCD.

  • Requesting ticket for ldap_monitor and then proceeding with regular constrained delegation stuff to get a ticket for dc01$.

The part I was stuck on was the RBCD part, since I had no idea why we had to use ldap_monitor to do so. I'll attempt to cover these later.

First, let's get the ticket needed:

Afterwards, we can use impacket-rbcd for this:

Then, we can request a ticket as ldap_monitor using the password we have earlier (same as oorend).

Now we need to request a Service Ticket as the delegator$ user and impersonate dc01$. Based on Bloodhound, this user has a SPN of browser/dc01.rebound.htb:

Then, use this ST to request for the TGT for dc01$.

Afterwards, we can do a DCSync since we have the domain admin ticket to grab the NTLM hash of the administrator and evil-winrm in:

Here are some of the resources linked in the writeup sent to me, good reads overall:

https://snovvcrash.rocks/2022/03/06/abusing-kcd-without-protocol-transition.htmlsnovvcrash.rocks
LogoResource-Based Constrained Delegation Abuseblog.netwrix.com

Further Enumeration

There were 2 things I was puzzled about:

  1. Why did adding oorend to the ServiceMgmt group work?

  2. Why did we have to use ldap_monitor for the last step? I was stuck here because I kept trying with oorend.

Self ServiceMgmt Group

I downloaded PowerView.ps1 to the machine and enumerated it further as the domain admin. There was probably something that the oorend user had that could not be found using Bloodhound. When enumerating the ACLs for the ServiceMgmt group, I came across this:

So all along, the oorend user had Self privileges over this group, which explains why we could add our user into the group via bloodyAD.py.

LogoAbusing Active Directory ACLs/ACEs | Red Team Noteswww.ired.team

The weird part was that Bloodhound failed to pick this up at all. I ran SharpHound.exe again to check, but it still didn't reveal it. This might be intended, since this is an Insane machine and it does require some degree of 'educated guesswork' to finish, as with most other Insane machines I've attempted.

Delegation Issues --> SPN

To enumerate this, I just enabled RDP and created another domain admin user:

Afterwards, I used xfreerdp to get in:

When viewing the delegation settings, I noticed that ldap_monitor had the Delegation tab:

The oorend user did not have this tab:

For some reason, ldap_monitor was technically allowed to delegate and the oorend user was not. I found few resources that explained this well, but basically it seems that ldap_monitor does have an SPN:

LogoDelegation tab missing in ADU&C - Tomek's DS WorldTomek's DS World
LogoConfiguring Kerberos Delegation for Group Managed Service AccountsMicrosoftLearn

This means that delegation is 'possible' for ldap_monitor because it has an SPN set, whereas oorend does not and cannot even process the Kerberos ticket. No wonder I was stuck.

PreviousPilgrimageNextRegistryTwo

Last updated