Rebound
A Windows Machine which comprises of a multitude of AD vulnerabilities.
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 secondsEnumerating 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 cycling.
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 article, 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.
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.
From the graph above, our main goal is either to
Obtain either PPAUL or FFLOCK user account OR
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 AddGroupMember 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.
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 RemotePotato0 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 attribute.
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 properties.
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 this, RBCD (Resource-based Constrained Delegation) can be used to bypass this. To perform this attack, we need two things which we already have.
A account with SPN -
ldap_monitoruser fiits the requirementAn account with the capability to edit the
msDS-AllowedToActOnBehalfOfOtherIdentityattribute of another object OR
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.
Last updated