Trust Enumeration and Attacks
Cross Forest Attacks Concepts
Enumeration
#Powershell Cmdlet
PS C:\htb> Import-Module activedirectory
PS C:\htb> Get-ADTrust -Filter *
#Powerview
PS C:\htb> Get-DomainTrust
PS C:\htb> Get-DomainTrustMappingAutomatic tools
Intra Forest Attacks
Unconstrained Delegation (Printer Bug - Child to Parent)
Example output:
Configuration Naming Context (NC)
Configuration Naming Context (NC) replication abuse is a malicious strategy in which attackers take advantage of the replication process within the Configuration Naming Context of Active Directory. This exploitation allows them to disseminate unauthorized modifications or configurations throughout the domain infrastructure.
An attacker may exploit this vulnerability to conduct a range of attacks, including those targeting Active Directory Certificate Services (ADCS), manipulating Group Policy Objects (GPOs) at the site level, altering DNS entries, or executing GoldenGMSA (Group Managed Service Account) attacks. Such actions can result in unauthorized access, privilege escalation, or other detrimental activities within the parent domain originating from a child domain.
Abusing ADCS - Make Template vulnerable to ESC1 to privilege escalation (Child -> Parent)
The Certificate Templates container stores templates as pKICertificateTemplate objects that can be published to an ADCS CA.
The Enrollment Services container contains one pKIEnrollmentService object per CA. These objects enumerate the templates that have been published to the CA through their certificateTemplates property.
Simplification of ADCS Attack:
Add a new vulnerable
Certificate Templateinside theCertificate Templatescontainer as apKICertificateTemplateobject.Give the
Administratoruser of the child domainFull Controlrights over the created Certificate Template.Publish the created template to the CA server by modifying the
pKIEnrollmentServiceobject of the CA inside theEnrollment Servicescontainer.After the Configuration NC is replicated back to the parent domain, request the certificate for
root\Administratorfrom the child domain.
Create a new Console on mmc and add Certificate Template

Go to File > Add/Remove Snap-in
Select Certificate Templates
Add it.
Save Changes
Make Template Vulnerable to ESC1
Right-click on the
Usertemplate.Select
Duplicate Template. This action will open a prompt with the properties of the new template.Set the
Subject Nameoption toSupply in the request. This configuration allows for dynamic specification of the subject name during the certificate request process, potentially introducing the ESC1 vulnerability.
Grants Full control to SYSTEM

Right click on Public Key Services
Go to Properties > Security
Go to Advance
Select System and grants Full control and
This object and all descendant objects.Apply
Add the malicious template to PKIEnrollmentService

Go to Enrollment Services
Right click on PkiEnrollmentService > Properties
Select certificate Templates and add the template.
Apply the changes.
Check ADCS ESC1
Active Directory Certificate ServicesGPO On Site Attack Across Trust (Child -> Parent)
Powerview Older Version

GoldenGMSA Attack Across Trust (Child -> Parent)
Access: Configuration > Services > Group Key Distribution Service > Master Root Keys
Performing the Online Attack (Online Computation)
Performing the Offline Attack (Offline Computation)
Convert to NT Hash
Tool: CyberChef
DNS Wildcard Injection
Attackers can exploit wildcard records to redirect or manipulate network traffic by creating malicious DNS entries that match the wildcard pattern. This can lead to unauthorized access, phishing attacks, or the interception of sensitive information.
Arbitrary DNS Record Modification from Child Domain
It is also possible to modify the IP address associated with an already existing DNS record in the parent domain from within the child domain.
To crack NTLMv2 Go to:
Password AttacksKerberoasting cross forest
Asreproasting cross forest
Cross Forest Attacks
Trust Account Attack
Unconstrained Delegation Cross Forest (DomainA > DomainB)
Requirements for exploitation to be possible in a Cross-Forest environment
TGT Delegation must be allowed in the trust (without 2019 updates or enabled manually).
Selective authentication must not be enabled, which would prevent automatic authentication between forests.
A two-way trust must exist between forests.
Authentication levels in Cross-Forest Trusts
Forest-wide authentication → Allows unrestricted access between forests (less secure).
Domain-wide authentication → Restricts access to only users in a specific domain.
Selective authentication → Requires specific permissions for each user (more secure).
If a domain controller (DC) in Forest-A which has unconstrained delegation enabled by default is compromised, we could potentially extract the Ticket Granting Ticket (TGT) of an Administrator from the domain controller in Forest-B who subsequently logs into DC of Forest-A. With this TGT, we gain the ability to compromise the Forest-B.
Alternatively, if no user or Administrator logs into the domain controller (DC) in Forest-A from Forest-B, we can exploit the Printer bug to force an authentication attempt from the DC in Forest-B to the DC in Forest-A. This forced authentication allows us to intercept the TGT of the machine account of Forest-B DC (DC02$). Subsequently, we can leverage this TGT to execute a DCSync attack, allowing us to escalate privileges and further compromise the network
SID History Injection Attack
SID History Injection Attack, commonly referred to as SID Hijacking, is a method employed to escalate privileges by taking advantage of the SID (Security Identifier) history attribute found in Active Directory user accounts. When a user account is transferred from one domain to another within a different forest, the SID history attribute retains the SIDs from the original domain.
An attacker can exploit this functionality by injecting the SID of a user or group with elevated privileges from the target domain into a low-privileged user account in the source domain. This action enables the low-privileged account to inherit the access rights and privileges linked to the injected SID. Consequently, the attacker can elevate their privileges and gain unauthorized access to resources or execute actions within the target domain as if they were part of the highly privileged group or user.
Case #1 High Privileged Migrated User
SID history Enabled
The User in DomainA belongs to Powerfull group
The user has been migrated from DomainA to DomainB
We compromised the Domain B as Administrator and we start to enumerate.
In this point we can move to the target user either kerberos or any type of authentication
Case-2: Low Privileged Migrated User
In scenarios where migrated users do not possess substantial privileges in their previous domain or no users are migrated, it's advisable to verify if SID History is still enabled on the domain.
With the presense of TREAT_AS_EXTERNAL an Extrasids attack becomes possible. This attack involves injecting the SID of a highly privileged group or user from the targetdomain domain into any user object in the currentdomain domain.
Mision: Run bloodhound against target domain and look for high privilege group to be able to inject its SID into current user domain
To perform this attack, we need the following:
The KRBTGT hash for the current domain (Inlanefreight)
The SID for the current domain
The name of a target user in the current domain (Any domain user)
The FQDN of the current domain.
The SID of the high privileged group of the target domain (Infrastructure group)
SID Filter Bypass (CVE-2020-0665)
This vulnerability leverages the intended feature of a Transitive Trust, allowing an attacker to compromise any host or workstation within a trusted forest that has a Two-way Transitive Trust relationship established with the Trusting forest.
Be on the Trusting Forest
Fake a new domain in forest A that has the same SID as the local domain on a server in forest B.
Wait for forest B to pick up the new SID and add it to the allowed SIDs.
Create an inter-realm ticket that includes the SID of the local administrator account of the server in forest B, and give this to the DC in forest B.
See if forest B gives us a ticket that includes the SID of the server in forest B
Connect to the server in forest B with our service ticket having administrative permissions.
Attack Requirements for CVE-2020-0665
DC01 and DC02 must have a Two-way Transitive Trust
DC01 must have a Child Domain (subdomain)
DC02 has at least one domain joined member server or workstation
To perform this attack after compromising the Inlanefreight domain, we need to collect the following:
Local SID of the victim server (SQL02.logistics.ad)
S-1-5-21-2327345182-1863223493-3435513819
getlocalsid.py
Child Domain SID for child.inlanefreight.ad
S-1-5-21-3878752286-62540090-653003637
lookupsid.py
Domain SID for inlanefreight.ad
S-1-5-21-2432454459-173448545-3375717855
lookupsid.py
Inter-realm tickets with RC4 hash (for logistics.ad)
c586031a224f252a7c8a31a6d2210cc1
Get-ADObject and mimikatz
Inter-realm tickets with AES keys (for logistics.ad)
179e4ae68e627e1fd4014c87854e7f60b0c807eddbcaf6136ddf9d15a6d87ad8
Get-ADObject and mimikatz
Next step is convert the SID to binary
Updating SID Values in frida_intercept.py
Before to modify
Run the attack
After modification
Create Golden ticket:
LocalSID of victim server (SQL02.logistics.ad) -
S-1-5-21-2327345182-1863223493-3435513819Child Domain SID for
child.inlanefreight.ad-S-1-5-21-3878752286-62540090-653003637Domain SID for
inlanefreight.ad-S-1-5-21-2432454459-173448545-3375717855Inter-realm tickets with RC4 hash (For Logistics.ad) -
c586031a224f252a7c8a31a6d2210cc1Inter-realm tickets with AES keys (For Logistics.ad) -
179e4ae68e627e1fd4014c87854e7f60b0c807eddbcaf6136ddf9d15a6d87ad8
Abusing SQL Server Links and Trustworthy Databases
[1433] MSSQLAbusing PAM Trusts
Creating Shadow Principals in Bastion forest
If No Shadow Principals Exist you can create one:
Access the resources
Last updated