Welcome to the CRTP prep series, aimed at the Certified Red Team Professional certification from PentesterAcademy.
If you've been following the series, I'm sure you would've picked up a few new concepts and tools for your arsenal.
You can access my Gitbook repository here for all the commands.
Without further adu let's get started!
Reconnaissance
Let's begin with a full port scan using threader3000. I find it as a faster alternative for the initial full port scan as compared to nmap.
Let's run an aggressive nmap scan to enumerate the services on all open ports.
-A : Enable OS detection, version detection, script scanning, and traceroute.
-Pn : Skip host discovery [Don't ping].
-oA : Save output to file.
Notes:
Looking at ports 389(LDAP) and 88(Kerberos), our target is likely a Domain Controller.
Domain Name : Roast.csl | Hostname: ROAST-DC
Add "roast.csl 172.31.3.2" >> /etc/hosts, so that we can reference the target via domain name.
Enumeration
Enumerating the SMB service(Port 445) as a guest did not reveal anything useful.
Let's attempt to identify valid users using kerbrute. I explain how this technique works in the Spray writeup.
Let's enumerate LDAP using nmap's scripts.
Notes:
We've identified 3 potential usernames using kerbrute.
It's important to use multiple wordlists to enumerate as many users as you can. I used all the username wordlists from Seclists.
User 'roast' has his password exposed in the Description property.
Using impacket's GetNPUsers.py, we've ruled out the possibility of AS-REP Roasting.
Let's spray the identified password against all users to check for password re-use.
User 'dsmith' did not have PSRemoting privileges, but his password was re-used for user 'crhodes' who did have PSRemoting privileges on ROAST-DC.
We have our ticket in but wait...let's enumerate further as user 'dsmith'.
Impacket-toolkit has a lot of very useful tools for Active Directory. Taking the hint from the name of the box, the intended path is likely Kerberoasting.
The first step in Kerberoasting, is to identify Users accounts where the 'serviceprinciplename' attribute is not null.
Let's take a deeper look at how Kerberoasting works.
Kerberoasting Theory
A attacker authenticates to a domain and gets a ticket-granting-ticket (TGT) from the domain controller that’s used for later ticket requests.
The attacker uses their TGT to issue a service ticket request (TGS-REQ) for a particular servicePrincipalName (SPN) of the form sname/host, e.g. MSSqlSvc/SQL.domain.com. This SPN should be unique in the domain, and is registered in the servicePrincipalName field of a user or computer account. During this request process, the attacker can specify what Kerberos encryption types they support (RC4_HMAC, AES256_CTS_HMAC_SHA1_96, etc).
If the attacker’s TGT is valid, the DC extracts information from the TGT stuffs it into a service ticket. Then the domain controller looks up which account has the requested SPN registered in its servicePrincipalName field. The service ticket is encrypted with the hash of the account with the requested SPN registered, using the highest level encryption key that both the attacker and the service account support. The ticket is sent back to the attacker in a service ticket reply (TGS-REP).
The attacker extracts the encrypted service ticket from the TGS-REP. Since the service ticket was encrypted with the hash of the account linked to the requested SPN, the attacker can crack this encrypted blob offline to recover the account’s plaintext password.
Reference: specterops.io
Service principal names (SPNs) are used to uniquely identify each instance of a Windows service. If the SPN is not null, DC assumes it is a service account.
Service accounts are many times ignored (passwords are rarely changed) and have privileged access.
We target User Accounts used as Service Accounts as Machine Account hashes are nearly impossible to crack.
This attack leaves a 4769 log entry on DC. But this is very common, hence a very silent attack.
Workflow
SPN Discovery
Request a TGS
Export & crack the TGS.
Initial Foothold
We request a TGS from the 'roastsvc' account using GetUserSPNs.py from impacket.
The hash can be cracked with john/hashcat with a wordlist such as rockyou.txt
As always, enumerate all you can with:
Bloodhound (Sharphound.exe)
Soon enough we identify an interesting ACL for 'User 'roastsvc' on the 'Domain Admins' group.
Privilege Escalation
User 'roastsvc' has got WriteProperty on the 'Domain Admins' group. This means we can add users to the Domain Admins group and escalate privileges.
Let's add user 'crhodes' to the 'Domain Admins' group.
With Domain Admin privileges, User 'crhodes' can extract all the secrets from ROAST-DC using secretsdump.py
To Summarize:
Valid usernames were enumerated.
User dsmith's password was exposed in the object 'Description'
User roastsvc had a weak password configured. This enabled us to perform the kerberoast attack and crack the hash offline.
User roastsvc had misconfigured elevated privileges over the 'Domain Admins' group.
This allowed an attacker to grant Domain Admin privileges to any user.
Hence successfully grabbing the Administrator hash leading to complete system compromise!
Comments