Press enter or click to view image in full size
By: Vedant Bhalgama (@ActiveXSploit)
- HackSmarter is a new cybersecurity learning platform created by Tyler Ramsbey. It offers courses, hands-on labs, and more — an excellent place to sharpen your skills. In this blog, we’ll be diving into a full walkthrough of an Active Directory–themed lab called Arasaka on the platform. From the initial enumeration all the way to gaining Domain Admin, I’ll guide you through every step in detail.
- The lab is built around an assumed-breach scenario where we’re given initial credentials to start with. From there, it focuses on abusing misconfigured ACL permissions to move laterally across multiple accounts and ultimately exploiting ADCS vulnerabilities to escalate privileges to Domain Admin.
- Room Link: https://www.hacksmarter.org/courses/f618f837-3060-40a3-81cf-31beeaadf37a
-0x01: Initial Recon
- As always, I began with a basic Nmap scan to identify the open ports and running services on the target. This helps us map out the attack surface and understand where to focus our efforts. Since the target is a domain controller, the scan revealed the following services running:
- DNS (53)
- SMB (445)
- RPC (135)
- RDP (3389)
- Kerberos (88)
- WinRM (5985)
sudo nmap -p- -sC -sV 10.1.167.43 -oN nmap/arasaka-aggressive.out - Since this was an assumed-breach scenario, I used the initial credentials provided to begin enumerating the available services. These credentials belonged to the user account “faraday”.
- I first tried spraying the credentials against RDP and WinRM to check whether we had direct access to the domain controller through either protocol, but that didn’t work. I then shifted my attention to SMB and enumerated all available shares. According to NXC’s output, only the default shares were present on the DC. However, we did have read access to the IPC$ share, which means we can later leverage it to dump a list of domain users.
Press enter or click to view image in full size
nxc smb 10.1.167.43 -u faraday -p 'hacksmarter123' --shares- Next, we used impacket’s lookupsids.py script in order to dump a list of valid users and groups on the domain.
Press enter or click to view image in full size
impacket-lookupsid 'faraday':'hacksmarter123'@hacksmarter.local >> lookupsid.out- I then filtered out the output to extract only the usernames and save them in a separate file using a bit of Linux-Fu ;)
Press enter or click to view image in full size
cat lookupsid.out | grep SidTypeUser | cut -d ":" -f 2 | cut -d "\\" -f 2 | cut -d "(" -f 1 > valid_users.tx- My next step was to run BloodHound to identify possible lateral movement paths. I used bloodhound-python to query the domain controller over LDAP and collect the necessary information.
Press enter or click to view image in full size
bloodhound-python -u 'faraday' -p 'hacksmarter123' -c all -ns 10.1.167.43 -d hacksmarter.local- While reviewing the BloodHound results, I found a service account named alt.svc that had one outbound object control. I then shifted my focus to performing a Kerberoasting attack to obtain the TGS hash for this service account and determine whether it could give us an opportunity for lateral movement within the domain.
-0x02: Performing Kerberoasting to retrieve alt.svc’s TGS hash
Press enter or click to view image in full size
impacket-GetUserSPNs hacksmarter.local/'faraday':'hacksmarter123' -request -dc-ip 10.1.167.43- I then used JohnTheRipper to crack the retrieved TGS hash. Within a minute, it successfully revealed the service account’s password, which turned out to be babygirl1. With valid credentials in hand, the next step was to examine the outbound object control associated with this account and determine what privileges it held.
Press enter or click to view image in full size
john --wordlist=/usr/share/wordlists/rockyou.txt alt_svc_hash- After reviewing the BloodHound data, I discovered that the alt.svc account had GenericAll rights over another user, yorinobu. This meant we could reset that user’s password and fully take over the account. Checking the outbound object control for yorinobu revealed that it, in turn, had GenericWrite rights over another account named soulkiller.svc. With that level of access, we could perform a targeted Kerberoast attack on this account and attempt to crack its TGS hash.
-0x03: Abusing GenericAll rights to gain access to “yorinobu”’s account -
Press enter or click to view image in full size
- Hence, I next used RPCClient in order to log in as alt.svc, and then change the password for “yorinobu”.
- Yorinobu was also a member of both the “Remote Desktop Users” and “Remote Management Users” groups, which meant we could log in to the Domain Controller via RDP or WinRM and establish our initial foothold.
Press enter or click to view image in full size
rpcclient -U='alt.svc' hacksmarter.localPress enter or click to view image in full size
nxc rdp hacksmarter.local -u 'Yorinobu' -p 'Yorin@123'nxc winrm hacksmarter.local -u 'Yorinobu' -p 'Yorin@123'
- Next, I connected to the Domain Controller as Yorinobu over RDP to establish an initial foothold.
Press enter or click to view image in full size
- I then shifted my attention to gaining access to the soulkiller.svc account. Looking back at the second BloodHound attack path, yorinobu had GenericWrite rights over this account. This allowed us to perform a targeted Kerberoasting attack by adding a Service Principal Name (SPN) to the target account, retrieving its TGS hash, and then removing the SPN afterwards to return everything to its original state.
- Apart from this, I also observed that the description of the “soulkiller.svc” account stated that it is used to manage certificates in the domain, which hinted towards the usage of ADCS within the domain.
Press enter or click to view image in full size
- In order to verify whether if ADCS existed, I ran the following command on the domain controller to list active CA (Certification Authority) servers in the domain.
Press enter or click to view image in full size
certutil -config - -ping- And as expected, a Certificate Authority server was present in the environment — in fact, the Domain Controller itself. The CA (Certification Authority) name was hacksmarter-DC01-CA.
-0x04: Abusing GenericWrite rights to gain access to perform a targeted Kerberoasting attack -
- Next, I carried out a targeted Kerberoast attack against the soulkiller.svc account using targetedKerberoast.py and successfully obtained its TGS hash.
Press enter or click to view image in full size
Press enter or click to view image in full size
python3 targetedKerberoast.py -v -d 'hacksmarter.local' -u 'yorinobu' -p 'Yorin@123'- Once again, I used JohnTheRipper to crack the TGS hash, and within a minute, I had the clear-text password on my screen. Which turned out to be MYpassword123#.
Press enter or click to view image in full size
john --wordlist=/usr/share/wordlists/rockyou.txt soulkiller.svc.hashPress enter or click to view image in full size
nxc smb 10.1.167.43 -u soulkiller.svc -p 'MYpassword123#'-0x05: Abusing ADCS ESC1 to escalate to Domain Admin -
- Since the soulkiller.svc account was involved in certificate management, I ran Certipy to look for any certificate template vulnerabilities that could potentially be exploited to escalate privileges to Domain Administrator.
Press enter or click to view image in full size
certipy find -u '[email protected]' -p 'MYpassword123#' -vulnerable -stdout -dc-ip 10.1.167.43 -enabled- Reviewing the output, I found a certificate template named AI_Takeover that was vulnerable to ADCS ESC1. The soulkiller.svc account had permission to enroll in this template and was also allowed to specify a Subject Alternative Name when requesting a certificate. The template’s EKU included Client Authentication, which meant we could leverage it to authenticate to the Domain Controller and obtain the NTLM hash of a Domain Administrator account.
Press enter or click to view image in full size
Press enter or click to view image in full size
- I then used Certipy again to request a certificate from the AI_Takeover template, specifying the Administrator account as the Subject Alternative Name (SAN) and using hacksmarter-DC01-CA as the CA name.
Press enter or click to view image in full size
certipy req -u '[email protected]' -p 'MYpassword123#' -template "AI_Takeover" -upn "[email protected]" -ca "hacksmarter-DC01-CA" -dc-ip 10.1.167.43- Next, I used certipy again, but this time with the auth module, to authenticate to the domain controller and retrieve the NTLM hash of the Administrator account.
Press enter or click to view image in full size
certipy auth -pfx administrator.pfx -dc-ip 10.1.167.43- With the Administrator’s NTLM hash in hand, I used Evil-WinRM to gain access to the Domain Controller as the Administrator, resulting in a complete domain compromise.
Press enter or click to view image in full size
evil-winrm -i hacksmarter.local -u Administrator -H 4366ec0f86e29be2a4a5e87a1ba922ecAnd with that, the lab was fully compromised — from the initial foothold to the lateral movement chain and finally achieving full domain compromise. Hope you enjoyed the walkthrough! Make sure to subscribe to Avyukt Security to stay updated with the latest cybersecurity content.
Get Avyukt Security’s stories in your inbox
Join Medium for free to get updates from this writer.
Happy Hacking!