{
	"id": "dd357b92-5858-4c90-9f37-ec7fd50569b7",
	"created_at": "2026-04-06T00:19:04.938572Z",
	"updated_at": "2026-04-10T03:20:24.700806Z",
	"deleted_at": null,
	"sha1_hash": "d3ea7fadd8578f1b6ac022a2a58e580404c615ca",
	"title": "Carlos García - Pentesting Active Directory Forests [rooted2019]",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 79018,
	"plain_text": "Carlos García - Pentesting Active Directory Forests [rooted2019]\r\nArchived: 2026-04-05 16:48:10 UTC\r\n1.\r\n2.\r\nciyinet CARLOS GARCÍA GARCÍA ComputerScience Eng. OSCP Penetration Testing Hack\u0026Beers, Qurtuba…\r\nOrganizer Co-author book Hacking Windows: Ataques a Sistemas y redes Microsoft PS C:\u003e WHOAMI 2\r\n3.\r\nciyinet WHAT ARE WE GOING TOTALK ABOUT? - Introduction to Active Directory Forests and Trusts - Why\r\nPentesting Trusts? - Authentication Protocols across Trusts - Trusts enumeration - Common Attacks \u0026 Techniques\r\n- Reconnaissance across Trusts - Conclusions 3\r\n4.\r\nciyinet FORESTS - Domains arestructured into trees and forests - A tree is a collection of related domains - A\r\nforest is a collection of trees that trust each others - Only one “Enterprise Admins” group per forest - Exists in root\r\ndomain only - Non-existing in child domains - Added as local admin in child domain’s DCs 4\r\n5.\r\nciyinet TRUSTS - Allow authenticationtraffic to flow between two domains - Establish the ability for users in one\r\ndomain to authenticate to resources in another domain 5\r\n6.\r\nciyinet TRUST DIRECTION - One-way -Domain B trusts A - Users in Domain A can access resources in Domain\r\nB. Users in domain B cannot access domain A - Two-way - Domain A trusts B, domain B trusts A - Authentication\r\nrequests can be passed between the two domains in both directions 6\r\n7.\r\nciyinet TRUST TRANSITIVITY Determines ifa trust can be extended outside of the two domains - Transitive -\r\nExtends trust relationship with other domains - Let a trusted domain pass through to a third domain - Non-transitive - Denies trust relationship with other domains 7\r\n8.\r\nciyinet TYPE OF TRUSTS TypeDirection Transitivity Description Parent-Child 2-way Transitive Automatically\r\nestablished when a new domain is created in a tree Tree-Root 2-way Transitive Automatically established when a\r\nnew tree is added to a forest. Between the new tree root and the forest root domain External 1-way or 2-way Non-transitive Manually created between a domain in a forest and another domain in a different forest that does not\r\nhave a forest trust established Forest 1-way or 2-way Transitive Manually created between one forest root domain\r\nhttps://www.slideshare.net/rootedcon/carlos-garca-pentesting-active-directory-forests-rooted2019\r\nPage 1 of 7\n\nand another forest root domain Shortcut 1-way or 2-way Transitive Manually created between domains in the\r\nsame forest that is used to shorten the trust path in a large and complex domain tree or forest and improve\r\nauthentication times Realm 1-way or 2-way Transitive or Non-transitive Manually created between an AD domain\r\nand a non-Windows Kerberos V5 realm References: https://blogs.msmvps.com/acefekay/2016/11/02/active-directory-trusts 8\r\n9.\r\nciyinet TRUSTS - All trustswithin the same forest are two-way and transitive - This is why all domains within a\r\nforest trust each other - Users from any domain can access resources in any other domain within the forest as long\r\nas: - They have the proper permissions assigned at the resource - They have network access 9\r\n10.\r\n11.\r\nciyinet DIRECTION OF TRUSTVS ACCESS Domain A Trusted domain (inbound) Domain B Trustring domain\r\n(outbound) Direction of access Direction of trust 11\r\n12.\r\n13.\r\nciyinet WHY PENTESTING TRUSTS? -Environments with trusts that were created many years ago without\r\nsecurity in mind - Sometimes domain trusts introduce unintended access paths - Some domains (i.e. testing,\r\ndevelopment…) are not well maintained, controlled or monitored 13\r\n14.\r\nciyinet WHY PENTESTING TRUSTS? Orsimply, what if your target is in a different domain? Reconnaissance\r\nWeaponisation and Exploitation Privilege Escalation \u0026 Lateral Movement Action on Targets Installation and\r\nCommand \u0026 Control ▪ Email harvesting ▪ Social Networking ▪ IP Discovery ▪ Port Scanning ▪ Identify\r\nvulnerabilities ▪ Build and deliver malware via phishing, web, USB drive, network… ▪ Exploit a vulnerability to\r\ncompromise the victim’s system ▪ Install malware ▪ Stablish persistence inside the environment ▪ Command\r\nchannel for remote access ▪ Obtain more credentials ▪ Access other systems ▪ Escalate privileges ▪ Identify critical\r\nassets ▪ Data exfiltration ▪ Encryption of critical assets ▪ Service disruption ▪ Money $$$ References: Kroll\r\nProactive Security Team 14\r\n15.\r\n16.\r\n17.\r\nciyinet NTLM ACROSS TRUSTS 1.User requests access and sends DOMAIN-AUSERNAME Client in\r\nDOMAIN-A 2. Server sends challenge message 3. Client sends response message 4. Server sends DOMAIN-AUSERNAME challenge and response to DC in DOMAIN-B Server in DOMAIN-B DC in DOMAIN-B DC in\r\nDOMAIN-A References: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc773178(v=ws.10) https://blogs.technet.microsoft.com/askpfeplat/2013/05/05/how-domain-controllers-are-located-across-trusts/ https://blogs.technet.microsoft.com/isrpfeplat/2010/11/05/optimizing-ntlm-authentication-https://www.slideshare.net/rootedcon/carlos-garca-pentesting-active-directory-forests-rooted2019\r\nPage 2 of 7\n\nflow-in-multi-domain-environments/ 8. Server sends authentication result to the client 7. Response to authenticate\r\nuser 17\r\n18.\r\nciyinet KERBEROS ACROSS TRUSTS Whena user requests access to a resource in a different domain: - User’s\r\nDC will not be able to issue a TGS of another domain as TGS can only be built using the target service’s password\r\nand DC only contain password data from security principals in their own domain - To solve this, the there is a\r\ntrusts password between two domains in the same AD forest used as a bridge enable Kerberos authentication\r\nacross trust 18\r\n19.\r\nciyinet KERBEROS ACROSS TRUSTS Clientin DOMAIN-A 1. Request TGT (AS-REQ) 2. Receive TGT (AS-REP) Server in DOMAIN-B DC in DOMAIN-A DC in DOMAIN-B References: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc773178(v=ws.10) https://adsecurity.org/?p=1588 3.\r\nPresent TGT, request TGS (TGS-REQ) 4. Receive inter-realm TGT (TGS-REP) Client encrypts a timestamp with\r\ntheir secret (hash/key) Client receives a TGT signed with the DOMAIN-A krbtgt account that proves they are who\r\nthey say they are The TGT is then used to request TGS for specific resources/services on the DOMAIN-B DC\r\nsends a TGT for DOMAIN-B signed and encrypted using the inter-realm key DC sends a TGS ticket encrypted\r\nusing the hash/key of the account that is associated with that service (SPN) The TGT is then used to request\r\nservice tickets (TGS) for specific services on the domain. TGT I-R TGT TGS 19\r\n20.\r\n21.\r\nciyinet TRUSTS ENUMERATION So weland in the organization; the exploitation path will depend on: - Domain\r\nyou land on and its trusts - Privileges you manage to get in it - User’s privileges in foreign domains ? ? ? 21\r\n23.\r\n24.\r\nciyinet TRUSTS ENUMERATION -NLTEST - Different information depending on where it’s executed from\r\nquarantined_domain = Filter_sids nltest /domain_trusts nltest /dclist:DOMAIN nltest /server:DC /trusted_domains\r\n24\r\n25.\r\nciyinet TRUSTS ENUMERATION -POWERVIEW - To enumerate trusts on a foreign domain, you need to able to\r\nbind to a DC (usually PDC) on the foreign domain* - Get-DomainTrust –SearchBase\r\n“GC://$($ENV:USERDNSDOMAIN)” - Return all forest trusts for the current forest or a specified forest Get-DomainTrust –Domain FOREIGN DOMAIN FQDN Get-ForestTrust –Domain FOREIGN DOMAIN FQDN 25\r\n27.\r\n28.\r\n29.\r\nhttps://www.slideshare.net/rootedcon/carlos-garca-pentesting-active-directory-forests-rooted2019\r\nPage 3 of 7\n\n30.\r\nciyinet EXPLOITATION PATH Source (attacker’s location) Target domain Techniqueto use Trust relationship\r\nRoot Child • Golden Ticket + Enterprise Admins group Inter-realm (2-way) Child Child • SID History exploitation\r\nInter-realm Parent-Child (2-way) Child Root • SID History exploitation Inter-realm Tree-Root (2-way) Forest A\r\nForest B • Printer bug + Unconstrained Delegation ? Intra-realm Forest or External (2-way) - Having Domain-Admin-level on the current domain: 30 - Not having Domain-Admin-level on the current domain: Reconnaissance\r\n+ Exploitation (and always depending on type of trusts, direction and transitivity)\r\n31.\r\nciyinet Forest CIYILAB ForestTRICIA ciyilab.local dev.ciyilab.local test.dev.ciyilab.local DA-LEVEL\r\nTECHNIQUES – ROOT TO CHILD Parent-Child trust Parent-Child trust assuan.local Tree-Root trust tricia.local\r\nForest trust Forest CANETE canete.local External trust Golden ticket + EA group 31\r\n32.\r\nciyinet ciyilab.local GOLDEN TICKET +ENTERPRISE ADMINS ciyilabciyi dc01 32 mimikatz.exe\r\n\"kerberos::golden /domain:ROOT_DOMAIN_FQDN /sid:ROOT_DOMAIN_SID\r\n/krbtgt:ROOT_DOMAIN_KRBTGT_NT_HASH /user:USERNAME /groups:500,501,513,512,520,518,519 /ptt\"\r\nIncluded by default. 519: RID of “Enterprise Admins” group\r\n34.\r\n35.\r\nciyinet SID HISTORY - Usedto migrate users from one domain to another - When a user is migrated, his old SID\r\nand all groups’ SIDs he’s a member of can be added to the attribute sidHistory - When the user tries to access a\r\nresource, his SID and the SIDs included in the sidHistory attribute are checked to grant/deny access - sidHistory is\r\nnormally respected by domains within the forest. For external/forest trusts, they are filtered out by the “SID\r\nfiltering” protection References: https://www.itprotoday.com/windows-78/exploiting-sidhistory-ad-attribute\r\nhttps://www.harmj0y.net/blog/redteaming/the-trustpocalypse/ https://gallery.technet.microsoft.com/migrate-ad-users-to-new-2e480804/ http://www.harmj0y.net/blog/redteaming/a-guide-to-attacking-domain-trusts/ 35\r\n36.\r\n38.\r\n39.\r\nciyinet EXPLOITATION PATH - HavingDomain-Admin-level in the domain you are: - Not having Domain-Admin-level on the current domain: Reconnaissance + Exploitation (and always depending on type of trusts,\r\ndirection and transitivy) 39 Source (attacker’s location) Target domain Technique to use Trust relationship Root\r\nChild • Golden Ticket + Enterprise Admins group Inter-realm (2-way) Child Child • SID History exploitation\r\nInter-realm Parent-Child (2-way) Child Root • SID History exploitation Inter-realm Tree-Root (2-way) Forest A\r\nForest B • Printer bug + Unconstrained Delegation ? Intra-realm Forest or External trust (2-way)\r\n40.\r\nhttps://www.slideshare.net/rootedcon/carlos-garca-pentesting-active-directory-forests-rooted2019\r\nPage 4 of 7\n\nciyinet RECONNAISSANCE 1. Enumerate truststhe current domain has and also trusts the other domains have 2.\r\nEnumerate objects: a. Enumerate security principals (i.e. users, groups, computers) in the current domain that have\r\naccess to resources in another domain b. Enumerate groups that have users from another domain 3. Map\r\nexploitation path: what accounts need to be compromised to move from the current position to the target 40\r\nReferences: http://www.harmj0y.net/blog/redteaming/a-guide-to-attacking-domain-trusts/\r\n41.\r\n43.\r\n44.\r\nciyinet 2. OBJECT ENUMERATION Securityprincipals (users/groups) can be configured to have access to\r\nresources in another domain as: - Members of a local group in foreign machines - Look for foreign local group\r\nmembership - Members of a domain group in a foreign domain - Look for foreign domain group membership -\r\nPrincipals in ACEs in a DACL - Look for foreign security principals in ACE in a foreign domain 44\r\n45.\r\nciyinet TYPE OF GROUPS GroupVisibility (available to) Can have members from Same domain Other domains\r\nin same forest Domains outside the forest (forest or external trust) Functional memberships Local Local • Users •\r\nComputers • Domain local groups • Global groups • Universal groups • Users • Computers • Global groups •\r\nUniversal groups • Users • Computers • Global groups • Users in the same forest • Users in other forests (foreign\r\nsecurity principals) AD Domain local Domain (Cannot be used outside the domain they’ve been created in) •\r\nUsers • Computers • Other Domain local groups • Global groups • Universal groups • Users • Computers • Global\r\ngroups • Universal groups • Users • Computers • Global groups • Users in the same forest • Users in other forests\r\n(foreign security principals) AD Global Forest(s) • Users • Computers • Other Global groups None None Cannot\r\nhave users of other domains AD Universal Forest(s) (Stored within the Global Catalog) • Users • Computers •\r\nGlobal groups • Other Universal groups • Users • Computers • Global groups • Other Universal groups None\r\nUsers in the same forest References: https://www.youtube.com/watch?v=aPh8_RB8XEU 45\r\n46.\r\nciyinet FOREIGN LOCAL GROUPMEMBERSHIP - Remote SAM (SAMR) or GPO correlation - Depending on\r\ncurrent configuration (i.e. Windows firewall), in some cases we might need local admin privs on target to\r\nenumerate its local groups PowerView: Get-NetLocalGroup –ComputerName HOSTNAME Get-NetLocalGroupMemeber –ComputerName HOSTNAME -GroupName GROUP References:\r\nhttp://www.harmj0y.net/blog/redteaming/local-group-enumeration/ 46\r\n47.\r\n49.\r\n50.\r\n52.\r\n53.\r\n54.\r\nhttps://www.slideshare.net/rootedcon/carlos-garca-pentesting-active-directory-forests-rooted2019\r\nPage 5 of 7\n\nciyinet FOREIGN USER MEMBERSHIP Enumerateusers in groups outside of the user’s domain. This can be\r\nused within the same forest PowerView: *Only Universal groups membership will be reflected Get-DomainForeignUser –Domain FOREIGN DOMAIN FQDN 54\r\n56.\r\nciyinet FOREIGN GROUP MEMBERSHIP Enumerategroups in the target domain that contains users that are not\r\nfrom the target domain. This can be used against domain within the same forest or through a external/forest trust\r\nPowerView: Get-DomainForeignGroupMember –Domain FOREIGN DOMAIN FQDN 56\r\n57.\r\nciyinet FOREIGN ACL PRINCIPALS 1.Enumerate DACLs (and their ACE entries) of all objects in domains that\r\ntrusts yours 2. Only analyze ACE entries with foreign security principals This can be used against domain within\r\nthe same forest or through a external/forest trust PowerView to list ACE entries with security principals from our\r\ndomain: Get-DomainObjectAcl –Domain FOREIGN DOMAIN FQDN –ResolveGUIDs | Where-Object\r\n{$_.SecurityIdentifier –like ‘CURRENT_DOMAIN_SID*’} 57\r\n58.\r\nciyinet 3. MAPPING EXPLOITATIONPATH – OBJECT ENUMERATION WITH BLOODHOUND BloodHound\r\ncan enumerate trusts and objects in foreign domains (local and domain groups membership, ACLs, etc.) Invoke-BloodHound –SearchForest Invoke-BloodHound –Domain FOREIGN DOMAIN FQDN 58\r\n59.\r\n62.\r\n64.\r\n66.\r\n67.\r\nciyinet WRAPPING UP –“METHODOLOGY” 1. Enumerate trusts the current domain has and also trusts the\r\nother domains have 2. Is the target within the same forest? Yes: step 3 No: steps 4 and 5 3. Got DA-level\r\nprivileges in the current domain? Yes: use DA-level techniques No: steps 4 and 5 4. Enumerate objects: a. Security\r\nprincipals (i.e. user, groups, computers) in the current domain that have access to resources in another domain b.\r\nGroups that have users from another domain c. Foreign security principals in ACE in foreign domains 5. Map\r\nexploitation path What accounts need to be compromised to move from the current position to the target 67\r\n68.\r\n69.\r\nciyinet CONCLUSIONS - If otherdomain trusts our domain, we can query their AD information - Trusts can\r\nintroduce unintended access paths - Domain trust boundaries are not security boundaries - Losing control of the\r\nKRBTGT account password hash of any domain equates to losing control of the entire forest - You must reset\r\nKRBTGT (twice) in every domain in the forest! 69\r\n70.\r\nhttps://www.slideshare.net/rootedcon/carlos-garca-pentesting-active-directory-forests-rooted2019\r\nPage 6 of 7\n\nciyinet BUSINESS RISK Compromise ofjust one Domain Admin account in the Active Directory forest exposes\r\nthe entire organization to risk. The attacker would have unrestricted access to all resources managed by all\r\ndomains, users, servers, workstations and data. Moreover, the attacker could instantly establish persistence in the\r\nActive Directory environment, which is difficult to notice and cannot be efficiently remediated with guarantees.\r\n“Once Domain Admin, always Domain Admin” “Once any Domain Admin, always Enterprise Admin” 70\r\n71.\r\nciyinet ACKNOWLEDGMENT \u0026 REFERENCES -My brother (Happy B-DAY!!!) - Francisco Tocino - Nikhil\r\nMittal (@nikhil_mitt) - Will Schroeder (@harmj0y) - Andrew Robbins (@_wald0) - Benjamin Delpy\r\n(@gentilkiwi) - Sean Metcalf (@PyroTek3) 71\r\n72.\r\n73.\r\n74.\r\n75.\r\nSource: https://www.slideshare.net/rootedcon/carlos-garca-pentesting-active-directory-forests-rooted2019\r\nhttps://www.slideshare.net/rootedcon/carlos-garca-pentesting-active-directory-forests-rooted2019\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.slideshare.net/rootedcon/carlos-garca-pentesting-active-directory-forests-rooted2019"
	],
	"report_names": [
		"carlos-garca-pentesting-active-directory-forests-rooted2019"
	],
	"threat_actors": [],
	"ts_created_at": 1775434744,
	"ts_updated_at": 1775791224,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d3ea7fadd8578f1b6ac022a2a58e580404c615ca.pdf",
		"text": "https://archive.orkl.eu/d3ea7fadd8578f1b6ac022a2a58e580404c615ca.txt",
		"img": "https://archive.orkl.eu/d3ea7fadd8578f1b6ac022a2a58e580404c615ca.jpg"
	}
}