diff --git a/windows-hardening/active-directory-methodology/README.md b/windows-hardening/active-directory-methodology/README.md index 929de6d74..504f9f85b 100644 --- a/windows-hardening/active-directory-methodology/README.md +++ b/windows-hardening/active-directory-methodology/README.md @@ -281,7 +281,7 @@ Microsoft considers that the **domain isn't a Security Boundary**, the **Forest At a high level, a [**domain trust**](http://technet.microsoft.com/en-us/library/cc759554\(v=ws.10\).aspx) establishes the ability for **users in one domain to authenticate** to resources or act as a [security principal](https://technet.microsoft.com/en-us/library/cc780957\(v=ws.10\).aspx) **in another domain**. Essentially, all a trust does is **linking up the authentication systems of two domains** and allowing authentication traffic to flow between them through a system of referrals.\ -When **2 domains trust each other they exchange keys**, these **keys** are going to be **saved** in the **DCs** of **each domains** (**1 key per trust direction**) and the keys will be the base of the trust. +When **2 domains trust each other they exchange keys**, these **keys** are going to be **saved** in the **DCs** of **each domains** (**2 keys per trust direction, latest and previous**) and the keys will be the base of the trust. When a **user** tries to **access** a **service** on the **trusting domain** it will request an **inter-realm TGT** to the DC of its domain. The DC wills serve the client this **TGT** which would be **encrypted/signed** with the **inter-realm** **key** (the key both domains **exchanged**). Then, the **client** will **access** the **DC of the other domain** and will **request** a **TGS** for the service using the **inter-realm TGT**. The **DC** of the trusting domain will **check** the **key** used, if it's ok, it will **trust everything in that ticket** and will serve the TGS to the client. @@ -317,6 +317,8 @@ There are three **main** ways that security principals (users/groups/computer) f ### Child-to-Parent forest privilege escalation +#### SID-History Injection + Also, notice that there are **2 trusted keys**, one for _Child --> Parent_ and another one for P\_arent --> Child\_. ```bash @@ -356,6 +358,15 @@ schtasks /create /S mcorp-dc.moneycorp.local /SC Weekely /RU "NT Authority\SYSTE schtasks /Run /S mcorp-dc.moneycorp.local /TN "STCheck114" ``` +#### Exploit writeable Configration NC +The Configuration NC is the primary repository for configuration information for a forest and is replicated to every DC in the forest. Additionally, every writable DC (not read-only DCs) in the forest holds a writable copy of the Configuration NC. Exploiting this require running as SYSTEM on a (child) DC. + +It is possible to compromise the root domain in various ways. Examples: +- [Link GPO to to root DC site](https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-4-bypass-sid-filtering-research) +- [Compromise gMSA](https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-5-golden-gmsa-trust-attack-from-child-to-parent) +- [Schema attack](https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-6-schema-change-trust-attack-from-child-to-parent) +- Exploit ADCS - Create/modify certificate template to allow authentication as any user (e.g. Enterprise Admins) + ### External Forest Domain Privilege escalation In this case you can **sign with** the **trusted** key a **TGT impersonating** the **Administrator** user of the current domain. In this case you **won't always get Domain Admins privileges in the external domain**, but **only** the privileges the Administrator user of your current domain **was given** in the external domain. @@ -364,6 +375,17 @@ In this case you can **sign with** the **trusted** key a **TGT impersonating** t Invoke-Mimikatz -Command '"kerberos::golden /user:Administrator /domain: /SID: /rc4: /target: /ticket:C:\path\save\ticket.kirbi"' ``` +### Attack one-way trusted domain/forest (Trust account attack) +In short, if an attacker has administrative access to FORESTB which trusts FORESTA, the attacker can obtain the credentials for a _trust account_ located in FORESTA. This account is a member of Domain Users in FORESTA through its Primary Group. As we see too often, Domain Users membership is all that is necessary to identify and use other techniques and attack paths to become Domain Admin. + +![]() + +This technique is not limited to forest trust but works over any domain/forest one-way trust in the direction trusting -> trusted. + +The trust protections (SID filtering, disabled SID history, and disabled TGT delegation) do not mitigate the technique. + +[Read more](https://improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-7-trust-account-attack-from-trusting-to-trusted) + ### Domain trust abuse mitigation **SID Filtering:** @@ -373,6 +395,7 @@ Invoke-Mimikatz -Command '"kerberos::golden /user:Administrator /domain: