Certified
Created by ruycr4ft
Last updated
Was this helpful?
Created by ruycr4ft
Last updated
Was this helpful?
The following post by 0xb0b is licensed under CC BY 4.0
We started with an Nmap scan revealing typical Active Directory services, then used the provided credentials for judith.mader to gather AD relationships with BloodHound. Judith had WriteOwner permissions on the Management group, allowing us to take ownership and grant GenericWrite over the management_svc user. We successfully performed a shadow credential attack to retrieve the NT hash and gain a shell with evil-winrm. We escalated to the ca_operator account using GenericAll permissions, changed the password, and exploited an ESC9 misconfiguration in the certificate template to obtain the Administrator hash and gain a shell as Administrator with evil-winrm.
We start with a Nmap scan which revealed multiple services typical of an Active Directory environment, including DNS (53), Kerberos (88), SMB (445), LDAP (389, 636), and Global Catalog (3268, 3269).
We have received additional credentials for the machine:
As is common in real life Windows pentests, you will start the Certified box with credentials for the following account: judith.mader:judith09
We are using bloodhound-python to gather and map Active Directory relationships and permissions on the certified.htb domain, authenticating as judith.mader to identify privilege escalation paths.
We see that judith.mader WriteOwner has permissions on the Management group.
WriteOwner Permissions:
With that we can update the owner of the target object. Since we have credentials for judith.mader we could grant us ownership over the group Management and add the account to the group.
We also see that the Management group has permissions on the GenericWrite user. This means that if we have control of the group, we can perform either a targeted Kerberoast attack or a shadow credential attack on the management_svc user granting us the hash of the user.
The user management_svc, on the other hand, has CanPSRemote permissions, which would allow us to access the machine with evilwin-rm if we compromised the user.
We implement the analysed attack path.
First we add judith.mader as owner to Management group.
Since we now own the group, we can now give the user permission to add members via dacledit
After that we add judith.mader as member to the Management group.
As the user is now part of the group, we can abuse the GenericWrite permission on the management_svc user, which the Management group has. First we will try a targeted Kerberoast attack. See below links for further reading:
We are able to get the Kerberos 5, etype 23, TGS-REP hash of the management_svc user. However, we cannot crack it.
Next, we try the shadow credential attack using certipy.
Further information on the shadow credential attack can be found under the following link:
But in short: If we can write to the msDS-KeyCredentialLink property of a user, we can retrieve the NT hash of that user.
With the following command we issue the attack and are succesful. We retrieve the NT hash of management_svc.
We use that hash to log in as management_svc via evil-winrm and find the flag at C:\Users\management_svc\Desktop\user.txt.
Since the machine is called Certified, we have tested for vulnerabilities on certificate templates with each user we have access to using certipy. However, the user management_svc also does not have any templates that are vulnerable and can be used by the user.
We look at our Bloodhound results again and see that we have GenericAll permissions over the user CA_Operator as management_svc.
This allows us to change the user's password.
We use bloodyAD for this.
We change the password.
Now we are able to query for vulnerable templates as ca_operator.
An we spot one:
The CertifiedAuthentication template is vulnerable to ESC9.
For further reading on ESC9 we can follow the link below:
ESC9 refers to the new
msPKI-Enrollment-FlagvalueCT_FLAG_NO_SECURITY_EXTENSION(0x80000). If this flag is set on a certificate template, the newszOID_NTDS_CA_SECURITY_EXTsecurity extension will not be embedded. ESC9 is only useful whenStrongCertificateBindingEnforcementis set to1(default), since a weaker certificate mapping configuration for Kerberos or Schannel can be abused as ESC10 — without ESC9 — as the requirements will be the same.
To abuse this misconfiguration, the attacker needs
GenericWriteover any account A that is allowed to enroll in the certificate template to compromise account B (target).
ESC9Conditions:
StrongCertificateBindingEnforcementset to1(default) or0Certificate contains the
CT_FLAG_NO_SECURITY_EXTENSIONflag in themsPKI-Enrollment-FlagvalueCertificate specifies any client authentication EKU
Requisites:
GenericWriteover any account A to compromise any account B
We follow the example of https://research.ifcr.dk/certipy-4-0-esc9-esc10-bloodhound-gui-new-authentication-and-request-methods-and-more-7237d88061f7 and update account management_svc with upn pointing to Administrator.
Then we request vulnerable template, but receive an error. This might be cause by the password, since with a different it worked.
We change the password for ca_operator again.
Below are the steps to abuse ESC9:
We change the userPrincipalName of ca_operator to be Administrator.
We request the vulnerable certificate template CertifiedAuthentication (ESC9).
Then, we change back the userPrincipalName of ca_operator back to ca_operator.
Now, if we try to authenticate with the certificate, we will receive the NT hash of the Administrator@certified.htb user. We need to add -domain certified.htb to our command since there is no domain specified in the certificate. We receive the Administrators hash.
We use the Administrators NT hash to log in via evil-winrm and find the final flag at C:\Users\Administrator\Desktop\root.txt.
GitHub - CravateRouge/bloodyAD: BloodyAD is an Active Directory Privilege Escalation FrameworkGitHub
