Preview
Open Original

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 exploitin...

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.

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.

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 ;)

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.

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

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.

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 -

- 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.

rpcclient -U='alt.svc' hacksmarter.local

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.

- 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.

- 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.

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.


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#.

john --wordlist=/usr/share/wordlists/rockyou.txt soulkiller.svc.hash

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.

certipy find -u 'soulkiller.svc@hacksmarter.local' -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.


- 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.

certipy req -u 'soulkiller.svc@hacksmarter.local' -p 'MYpassword123#' -template "AI_Takeover" -upn "Administrator@hacksmarter.local" -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.

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.

evil-winrm -i hacksmarter.local -u Administrator -H 4366ec0f86e29be2a4a5e87a1ba922ec
And 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.
Happy Hacking!
HackSmarter Arasaka AD Lab Writeup was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.