GitBook: [#3574] No subject

windows-hardening/active-directory-methodology/external-forest-domain-one-way-outbound.md

@@ -42,7 +42,7 @@ MemberDistinguishedName : CN=S-1-5-21-3022719512-2989052766-178205875-1115,CN=Fo
 
 ## Trust Account Attack
 
-When an Active Directory domain or forest trust is set up from a domain _B_ to a domain _A_ (_**B**_\*\* trusts **\_**A**\_), a \_**trust account**\_** is created in domain **\_**A**\_**, named **\_**B$**\_. Kerberos \_**trust keys\*\*,\_ derived from the **trust account’s password**, are used for **encrypting inter-realm TGTs**, when users of domain A request service tickets for services in domain B.
+When an Active Directory domain or forest trust is set up from a domain _B_ to a domain _A_ (_**B**_ trusts A), a trust account is created in domain **A**, named **B. Kerberos trust keys**,\_derived from the **trust account’s password**, are used for **encrypting inter-realm TGTs**, when users of domain A request service tickets for services in domain B.
 
 It's possible to obtain the password and hash of the trusted account from a Domain Controller using:
 

windows-hardening/active-directory-methodology/external-forest-domain-oneway-inbound.md

@@ -74,19 +74,37 @@ In the previous enumeration it was found that the user **`crossuser`** is inside
 
 If you **couldn't** find any **special** access of your user in the other domain, you can still go back to the AD Methodology and try to **privesc from an unprivileged user** (things like kerberoasting for example):
 
+You can use **Powerview functions** to **enumerate** the **other domain** using the `-Domain` param like in:
+
+```powershell
+Get-DomainUser -SPN -Domain domain_name.local | select SamAccountName
+```
+
 {% content-ref url="./" %}
 [.](./)
 {% endcontent-ref %}
 
 ## Impersonation
 
-### With signing key
+### Logging in
+
+Using a regular method with the credentials of the users who is has access to the external domain you should be able to access:
+
+```powershell
+Enter-PSSession -ComputerName dc.external_domain.local -Credential domain\administrator
+```
+
+### SID History Abuse
+
+You could also abuse [**SID History**](sid-history-injection.md) across a forest trust.
+
+If a user is migrated **from one forest to another** and **SID Filtering is not enabled**, it becomes possible to **add a SID from the other forest**, and this **SID** will be **added** to the **user's token** when authenticating **across the trust**.
 
 {% hint style="warning" %}
 As a reminder, you can get the signing key with
 
 ```powershell
-Invoke-Mimikatz -Command '"lsadump::trust /patch"' -ComputerName dc.my.domain.local
+Invoke-Mimikatz -Command '"lsadump::trust /patch"' -ComputerName dc.domain.local
 ```
 {% endhint %}