Forward
Now is the time to move forward in this AD challenge. - by h4sh3m00
The following post by 0xb0b is licensed under CC BY 4.0
Scenario
[ INITIAL ACCESS GRANTED ]
USER > ctf.local\j.smith
PASS > JSmith@IT2024
You're already in. The breach has been assumed, now it's time to move forward. Navigate through a compromised Active Directory environment, move laterally through the domain, and escalate your way to full control. The question isn't how you got in... it's how far you can go.
Summary
Summary
In Forward we are granted initial access to an Active Directory environment as the low-privileged user j.smith and tasked with seeing how far we can escalate. Enumerating the domain controller DC01.ctf.local with NetExec and BloodHound, we find that j.smith belongs to the Remote Desktop Users group. We RDP into the DC and discover a KeePass database Database.kdbx in the user's Documents folder. Unable to crack the master password, we use Lazagne to confirm the database is unlocked via the Windows user account, open it through KeePass2, and recover credentials for t.jones.
The t.jones account has no notable permissions, so we generate a domain user list and password-spray the recovered password, landing a hit on r.williams. BloodHound shows r.williams has AddAllowedToAct over the DC, enabling a Resource-Based Constrained Delegation attack. We create a controlled machine account ATTACKERSYSTEM$ with addcomputer.py, write it into the DC's msDS-AllowedToActOnBehalfOfOtherIdentity attribute via rbcd.py, and abuse S4U2Self/S4U2Proxy with getST.py to obtain a cifs/DC01.ctf.local ticket impersonating Administrator. Using the cached Kerberos ticket, we land a SYSTEM shell on the DC with smbexec.py, retrieve the flag, and dump NTDS via secretsdump.py.
Recon
The target 10.112.190.54 is a Windows-based Domain Controller (DC01.ctf.local). DNS is exposed on port 53(Simple DNS Plus) and Kerberos on ports 88 and 464 (kpasswd), confirming the host's role as an Active Directory DC for the domain ctf.local. LDAP and LDAPS services are available on ports 389, 636, 3268, and 3269. SMB is exposed via ports 139 and 445 with message signing enabled and required. Remote management and access are available through RDP on port 3389 (NetBIOS_Computer_Name: DC01, Product_Version: 10.0.17763 — Windows Server 2019). The host also exposes a .NET Message Framing service on port 9389 (AD Web Services), RPC over HTTP on ports 593 and 49670, and several MSRPC endpoints on ports 135, 49668, 49671, 49672, and 49697. No web (HTTP/HTTPS) or WinRM services were detected on the scanned ports.
We authenticate as j.smith agains SMB via NetExec and enumerate the shares. We find a readable share Downloads.
Furthermore we will generate an /etc/hosts entry...
... and add the following entry to our /etc/hosts file.
The Downloads share does not contain anything.
BloodHound Enumeration
We proceed with enumeration of the domain using the provided credentials.
The user j.smith is in the REMOTE DESKTOP USERS group which allows us to RDP into the machine.
Furthermore we have kerberoastable user svc.helpdesk without any specific or interesting permissions.
The Administrator is the Domain Admin.
Access as t.jones
We access the machine as j.smith via RDP and find a Keepass file Database.kdbx in Documents.
We run Lazagne to extract possible credentials, since we were not able to crack the password of the Keepass file. Lazagne has a positive hit. The Keepass file can be opened via NTLM... But by opening the kdbx file no proper App is being suggested.
We look for KeePass in the Windows Search bar and find KeePass2 installed.
Opening the application we are prompted to Enter a MAster key for Database.kdbx. But we could also use the Windows user account without providing a password.
The Keepass file openes and we have three entries. The most intersting one is the for t.jones. The password looks like it has been preset.
We test the credentials using NetExec and are able to authenicate as t.jones.
But the user does not hold any special permissions and also we do not find anything intersting remotely on the machine.
Access as r.williams
So we try to password spray the found password from the Keepass file. But first we need to generate a users list. We use NetExec.
Next we run a password spary and are also able to authenticate as r.williams.
Shell as Administrator
That user has AddAllowedToAct permission over the DC which allows us to perform a Resource-Based Constrained Delegation (RBCD) attack. By adding a controlled computer account to the DC's msDS-AllowedToActOnBehalfOfOtherIdentity attribute, we can impersonate any domain user including Domain Admins to the DC via S4U2Self/S4U2Proxy and obtain a service ticket as that use.
If we click on the edge we get the instructions to abuse this via Linux.
We create a new machine account ATTACKERSYSTEM$ in the domain using r.williams's credentials, which we will leverage as the delegated principal in the RBCD attack.
We write our controlled ATTACKERSYSTEM$ account into the DC's msDS-AllowedToActOnBehalfOfOtherIdentityattribute, configuring Resource-Based Constrained Delegation so that ATTACKERSYSTEM$ is now trusted to impersonate any user to the Domain Controller.
Using our ATTACKERSYSTEM$ machine account, we abuse S4U2Self/S4U2Proxy to request a Kerberos service ticket for the cifs/DC01.ctf.local SPN while impersonating the Administrator, granting us privileged access to the DC's file system.
We export the KRB5CCNAME environment variable to point Impacket at the newly obtained .ccache file, so subsequent tools authenticate using the Administrator's Kerberos ticket instead of a password.
Using the cached ticket we use smbexec.py to authenticat to DC01 over SMB with Kerberos -k -no-pass as the Administrator and spawns a semi-interactive SYSTEM shell on the Domain Controller. We find the flag at the Desktop of the Administrator.
Finally, we'll run a DCSync..
Last updated