search
Blog

Rebound

A Windows Machine which comprises of a multitude of AD vulnerabilities.

hashtag
Enumeration 

โ”Œโ”€โ”€(kaliใ‰ฟkali)-[~/Desktop/CTF/Boxes/Rebound]
โ””โ”€$ sudo nmap -sC -sV -Pn 10.10.11.231           
[sudo] password for kali: 
Starting Nmap 7.94 ( https://nmap.org ) at 2023-12-23 23:27 EST
Nmap scan report for rebound.htb (10.10.11.231)
Host is up (0.053s latency).
Not shown: 989 closed tcp ports (reset)
PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2023-12-24 11:27:38Z)
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: rebound.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.rebound.htb
| Not valid before: 2023-08-25T22:48:10
|_Not valid after:  2024-08-24T22:48:10
|_ssl-date: 2023-12-24T11:28:26+00:00; +7h00m01s from scanner time.
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: rebound.htb0., Site: Default-First-Site-Name)
|_ssl-date: 2023-12-24T11:28:27+00:00; +7h00m01s from scanner time.
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.rebound.htb
| Not valid before: 2023-08-25T22:48:10
|_Not valid after:  2024-08-24T22:48:10
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: rebound.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.rebound.htb
| Not valid before: 2023-08-25T22:48:10
|_Not valid after:  2024-08-24T22:48:10
|_ssl-date: 2023-12-24T11:28:26+00:00; +7h00m01s from scanner time.
3269/tcp open  ssl/ldap      Microsoft Windows Active Directory LDAP (Domain: rebound.htb0., Site: Default-First-Site-Name)
| ssl-cert: Subject: 
| Subject Alternative Name: DNS:dc01.rebound.htb
| Not valid before: 2023-08-25T22:48:10
|_Not valid after:  2024-08-24T22:48:10
|_ssl-date: 2023-12-24T11:28:27+00:00; +7h00m01s from scanner time.
Service Info: Host: DC01; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
|_clock-skew: mean: 7h00m00s, deviation: 0s, median: 7h00m00s
| smb2-time: 
|   date: 2023-12-24T11:28:20
|_  start_date: N/A

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 57.41 seconds

Enumerating SMB and LDAP yielded me nothing. But i was able to connect to SMB unauthenticated without perms using rpcclient so i proceeded with enumerating potential users with rid cyclingarrow-up-right.

I then tried AS-REP roasting hoping for some quick wins for initial access but could not crack the hash which probbaly meant this was not intended.

After a very long time, I then stumbled across this articlearrow-up-right, talking about kerberoasting without pre-authentication. Similar to AS-REP roasting, the exploit leverages two things which we all have.

To keep myself sane from all the impacket branch errors i was receiving, i decided to use a Windows VM and perform the exploit using Rubeus and the /nopreauth parameter.

We can now try to crack these hashes using hashcat and rockyou giving us the password of ldap_monitor.

hashtag
Initial Foothold

After obtaining domain credentials, I then proceeded to map the domain using bloodhound and managed to see route for lateral movement to obtain user access but not with the users we have on hand.

A path to user maybe?

From the graph above, our main goal is either to

  1. Obtain either PPAUL or FFLOCK user account OR

  2. Enroll ourselves as a group member of SERVICEMGMT somehow

Obtain either PPAUL or FFLOCK user account

Using the existing password obtained from ldap_monitor's account, i performed password spraying using crackmapexec and managed to get a match on the user oorend .

Sadly, the password spraying did not work on both PPAUL and FFLOCK.

Enroll ourselves as a group member of SERVICEMGMT somehow

I then remembered some ACLs permissions are not explicitly shown in bloodhound and must be explicitly enumerated using something like PowerView's FindDomainObjectAcl. However I kept recieving the error Server not operational.

I then struggled to find a Linux alternative till i finally stumbled across impacket's dacledit which essentially allows me to enumerate whether the principal oorend has any permissions over the target SERVICEMGMT group.

Success!, we know that oorend has Self permission meaning that he has the ability to add himself to the SERVICEMGMT group.

We can easily do that using bloodyAD's AddGroupMemberarrow-up-right functionality.

Referencing the bloodhound graph earlier, SERVICEMGMT group has GenericAll privileges over the OU SERVICE USERS or Full Control.

Once again, we can use impacket's dacledit to grant us full control perms as oorend .

As oorend, we have full control over the OU Service Users and subsequently winrm_svc.

We can now change the password of winrm_svc easily using rpcclient and subsequently ps-remote to get the user flag.

hashtag
Privilege Escalation

Using query user, we see that the user tbrady is logged on.

For some reason, the same command no longer gives me this output as of 20/1/2024

From here, we can utilize RemotePotato0arrow-up-right which allows us to get the ntlm hash of any user logged in on the target machine which in this case is tbrady.

Cracking with rockyou, we get the password 543BOMBOMBUNmanda .

Looking back at bloodhound, we see that user tbrady has ReadGMSAPassword over DELEGATOR$.

This means we can actually read DELEGATOR$'s hash via the msDS-ManagedPassword attributearrow-up-right.

The name of the account suggests exploiting something regarding delegations. To enumerate the delegation properties of the DELEGATOR$ account, we need to use PoweView's GetNetComputer and filter the propertiesarrow-up-right.

We see that $DELEGATOR has the msds-allowedtodelegateto property for the service http/dc01.rebound.htb.

However, from our bloodhound output, Administrator user cannot be delegated.

With reference to thisarrow-up-right, RBCD (Resource-based Constrained Delegation) can be used to bypass this. To perform this attack, we need two things which we already have.

  1. A account with SPN - ldap_monitor user fiits the requirement

  2. An account with the capability to edit the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of another object OR

    1. Our own machine account via DELEGATOR$ as machine accounts are allowed to edit their own msDS-AllowedToActOnBehalfOfOtherIdentity attributearrow-up-right

Using impacket's RBCD, we can exploit this by appending value of ldap_monitor to msDS-AllowedToActOnBehalfOfOtherIdentity attribute of DELEGATOR$.

We can now obtain a ticket via delegation operation.

Once the ticket is obtained, it can be used in a S4U2proxy request, made by DELEGATOR$, on behalf of the impersonated user, to obtain access to one of the services DELEGATOR$ can delegate to.

Finally, we can get the Administrator hash via secretsdump.

PreviousAnalysisNextDarkZero

Last updated