J. Perez Duertojperezduerto.info
← all walkthroughs

Certified

Windows· Medium
owned
2026-09-03
time to own
26m24s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

Starting from a single low-privilege domain credential (judith.mader), I used BloodHound to map a full Active Directory ACL-abuse chain against the certified.htb domain controller. Take-ownership rights over the 'Management' security group let me self-add to that group; Management, in turn, held GenericWrite over the management_svc service account and GenericAll over ca_operator, both of which were escalated using Shadow Credentials (Key Trust) attacks to obtain their NT hashes without ever touching a password.

The final hop abused an Active Directory Certificate Services template (CertifiedAuthentication) that lacked the security extension binding a certificate to a specific account SID (ADCS ESC9): by temporarily setting ca_operator's UPN to 'Administrator' and requesting a certificate from that template, I obtained a certificate the domain controller mapped to the Administrator account, yielding the Administrator NTLM hash. Pass-the-hash authentication as Administrator gave full command execution on the domain controller, from which both user.txt and root.txt were retrieved — a complete domain compromise built entirely on chained AD permission and PKI misconfigurations, no software exploit required.

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 HASH="<the-hash-you-recovered>"

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

Attack path — how the box was taken

1EnumerationAuthenticated Active Directory enumeration (BloodHound)
Mapped the domain with authenticated BloodHound collection
Using the supplied domain credential judith.mader/<withheld>, I resolved the domain controller (dc01.certified.htb) and ran a full BloodHound collection to build the Active Directory object and permissions graph. The 'Outbound Object Control' view for judith.mader revealed a WriteOwner right over the 'Management' security group — the first link in a full ACL-abuse chain leading to Domain Admin.
Domain services on $TARGET enumerated: LDAP/GC (389/636/3268/3269), Kerberos (88), SMB (445), WinRM (5985).
Exact commands 2
shell

Resolve the domain and DC hostname locally before authenticating.

$ echo "$TARGET certified.htb dc01.certified.htb" | sudo tee -a /etc/hosts
shell

Collect the full AD graph as judith.mader; ingest into BloodHound and review Outbound Object Control on judith.mader.

$ bloodhound-python -u judith.mader -p $PASSWORD -d certified.htb -ns $TARGET -c All
2Privilege EscalationAD ACL abuse — WriteOwner / WriteMembers takeover of a privileged group (similar to T1098)
Abused WriteOwner on the Management group to grant self membership rights
Judith.mader held a WriteOwner ACE over the 'Management' security group. I took ownership of the group, then granted judith.mader the WriteMembers right on it, and finally added judith.mader as a member. Active Directory group-membership is baked into a user's Kerberos ticket (PAC), so I had to re-authenticate to actually receive the group's downstream privileges.
Management group carried onward GenericWrite/GenericAll over management_svc and (transitively) ca_operator.
Exact commands 4
shell

Take ownership of the Management group object.

$ owneredit.py -action write -new-owner judith.mader -target Management certified.htb/judith.mader:$PASSWORD -dc-ip $TARGET
shell

Grant judith.mader the right to modify group membership.

$ dacledit.py -action write -rights WriteMembers -principal judith.mader -target Management certified.htb/judith.mader:$PASSWORD -dc-ip $TARGET
shell

Add judith.mader into the Management group.

$ net rpc group addmem "Management" "judith.mader" -U certified.htb/judith.mader%$PASSWORD -S $TARGET
shell

Force a fresh Kerberos TGT so the new group membership is reflected in the PAC — required before the new rights take effect.

$ kdestroy && kinit judith.mader
FixRemove excessive WriteOwner/WriteMembers delegation on privileged groupsHigh
WeaknessThe standard user account judith.mader held a WriteOwner right over the 'Management' security group — an undocumented delegation that let a low-privilege user take ownership of the group, grant itself membership rights, and add itself as a member with no approval workflow.
FixAudit all AD object ACLs for non-default WriteOwner/WriteDacl/GenericAll/GenericWrite grants (BloodHound or PingCastle can enumerate these), remove any that are not explicitly required, and route legitimate group-membership changes through a documented, monitored process (e.g. PAM/JIT elevation) rather than standing ACL grants.
3Privilege EscalationShadow Credentials / Key Trust abuse via GenericWrite (T1098.001-style AD persistence, offensive use)
Escalated to management_svc via a Shadow Credentials attack
As a member of Management, I inherited GenericWrite over the management_svc service account. GenericWrite allows writing to the msDS-KeyCredentialLink attribute, so I attached my own certificate ('Shadow Credential') to management_svc and used it to request a Kerberos PKINIT ticket, converting the write right directly into the account's NT hash — no password guessing or cracking needed.
Exact commands 1
shell

Add a shadow credential to management_svc and authenticate via PKINIT to retrieve its NT hash.

$ certipy shadow auto -u judith.mader -p $PASSWORD -account management_svc -dc-ip $TARGET
FixRestrict who can write to msDS-KeyCredentialLink and monitor Shadow Credential additionsCritical
WeaknessThe Management group had GenericWrite over management_svc, and management_svc had GenericAll over ca_operator. Both rights allowed writing to the target account's msDS-KeyCredentialLink attribute, letting an unauthorised user attach an externally controlled certificate ('Shadow Credential') and authenticate via PKINIT to recover each account's NTLM hash without ever knowing its password.
FixRemove GenericWrite/GenericAll grants that are not operationally required, and specifically deny write access to msDS-KeyCredentialLink for non-administrative principals. Deploy detections for Event ID 5136 (attribute modify) on msDS-KeyCredentialLink and for anomalous PKINIT (Event ID 4768 with certificate-based pre-auth) from accounts that don't normally use certificates.
4Privilege EscalationShadow Credentials / Key Trust abuse via GenericAll
Escalated to ca_operator via a second Shadow Credentials attack
Management_svc held GenericAll over the ca_operator account — an even broader right than the previous hop. I repeated the Shadow Credentials technique, this time authenticating as management_svc using the NT hash captured in the previous step, to mint a certificate for ca_operator and recover its NT hash. Ca_operator's name and rights hinted at certificate-authority-related permissions, making it the pivot into ADCS abuse.
Exact commands 1
shell

Repeat the shadow-credential attack, now authenticating as management_svc via pass-the-hash, to extract ca_operator's NT hash.

$ certipy shadow auto -u management_svc -hashes ':<management_svc_nt_hash>' -account ca_operator -dc-ip $TARGET
5ExploitationAD CS ESC9 — certificate template lacking the security extension (no strong SID binding)
Enumerated AD CS and identified a vulnerable certificate template (ESC9)
Using ca_operator's credentials, I queried the domain's Certificate Authority (certified-DC01-CA) with Certipy. Of 34 templates and 12 enabled, the 'CertifiedAuthentication' template stood out: it carried the CT_FLAG_NO_SECURITY_EXTENSION flag, meaning certificates it issues carry no SID binding back to the requesting account. Because the DC falls back to UPN-based mapping for such certificates, any account permitted to both edit its own UPN and enroll in this template can impersonate any other account — including Administrator.
Certipy find enumerated 34 templates / 12 enabled / 1 CA (certified-DC01-CA); CertifiedAuthentication flagged vulnerable due to CT_FLAG_NO_SECURITY_EXTENSION.
Exact commands 1
shell

Enumerate CA and template configuration and flag ESC1-ESC11 style weaknesses; CertifiedAuthentication reports ESC9.

$ certipy find -u ca_operator -hashes ':<ca_operator_nt_hash>' -dc-ip $TARGET -vulnerable -stdout
6ExploitationAD CS ESC9 exploitation — UPN impersonation via a template with no security extension
Abused ESC9 to obtain the Administrator NTLM hash
I changed ca_operator's UPN to 'Administrator', then requested a certificate from the vulnerable CertifiedAuthentication template as ca_operator. Because the issued certificate carries no SID and the DC maps it by UPN, the DC treated the resulting authentication as the real Administrator account. I immediately restored ca_operator's original UPN to avoid breaking its own logon, then used the certificate to retrieve the Administrator account's NTLM hash via PKINIT.
NT hash subsequently used for pass-the-hash.
Exact commands 4
shell

Temporarily set ca_operator's UPN to Administrator.

$ certipy account update -u management_svc -hashes ':<management_svc_nt_hash>' -user ca_operator -upn Administrator -dc-ip $TARGET
shell

Request a certificate from the vulnerable template while impersonating Administrator's UPN.

$ certipy req -u ca_operator -hashes ':<ca_operator_nt_hash>' -ca certified-DC01-CA -template CertifiedAuthentication -dc-ip $TARGET
shell

Restore ca_operator's real UPN immediately — do this even if a later step fails, to avoid leaving the account broken.

$ certipy account update -u management_svc -hashes ':<management_svc_nt_hash>' -user ca_operator -upn ca_operator@certified.htb -dc-ip $TARGET
shell

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

$ certipy auth -pfx administrator.pfx -dc-ip $TARGET
FixRemediate the AD CS ESC9 misconfiguration on the CertifiedAuthentication templateCritical
WeaknessThe CertifiedAuthentication certificate template was configured with CT_FLAG_NO_SECURITY_EXTENSION, so certificates it issued carried no SID tying them to the requesting account. Combined with the ability to edit an enrolling account's UPN, this let an unauthorised user impersonate Administrator simply by changing ca_operator's UPN before requesting a certificate.
FixRemove the CT_FLAG_NO_SECURITY_EXTENSION flag from the template (or retire the template) and enable strong certificate mapping domain-wide (set StrongCertificateBindingEnforcement to 2 via the KB5014754 registry setting on all DCs). Restrict who can modify the userPrincipalName attribute on service/operator accounts and review certificate template enrollment permissions with certipy find or PSPKIAudit.
7Post-ExploitationPass-the-hash (NTLM) remote code execution (T1550.002)
Authenticated as Administrator via pass-the-hash and captured both flags
With the Administrator NTLM hash, I authenticated directly to the domain controller without ever knowing the plaintext password, using Impacket's wmiexec for remote command execution. From this SYSTEM-equivalent session I confirmed Domain Administrator context, then read the user and root flags directly off disk.
Impacket-wmiexec authenticated as CERTIFIED/Administrator over SMBv3; read C:\Users\management_svc\Desktop\user.txt and C:\Users\Administrator\Desktop\root.txt.
Exact commands 4
shell

Open a command shell as Administrator using pass-the-hash — no plaintext password needed.

$ impacket-wmiexec -hashes "$HASH" 'CERTIFIED/Administrator'@$TARGET
shell

Run in the wmiexec shell to prove Administrator/SYSTEM-equivalent context before reading flags.

$ whoami
shell

Read the user flag; replace output with <user.txt> when reporting.

$ type C:\Users\management_svc\Desktop\user.txt
shell

Read the root flag; replace output with <root.txt> when reporting.

$ type C:\Users\Administrator\Desktop\root.txt
FixReduce exposure to NTLM hash theft and pass-the-hash reuseHigh
WeaknessOnce an NTLM hash for Administrator was obtained, it could be used directly for remote authentication and command execution (pass-the-hash) with no additional factor or restriction, giving an unauthorised user full domain-controller access.
FixAdd Administrator and other Tier-0 accounts to the Protected Users group (or use gMSA/LAPS-managed credentials so no static hash exists to steal), enable Credential Guard on domain controllers and admin workstations, and restrict Administrator logon to a hardened admin workstation/PAW via Authentication Policies and Silos. Enforce SMB signing and disable NTLM where Kerberos is viable.

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
5985/tcp
9389/tcp
49667/tcp
49689/tcp
49690/tcp
49695/tcp
49724/tcp
49732/tcp
53/udp

Techniques used

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