Lateral Movement Across Active Directory Domains: Methods, Paths, and Constraints

Boundary Traversal Axiom

Adversary traversal from Domain A to Domain B is never unconstrained: it strictly relies on one of three architectural vectors:

1. A cryptographic trust pathway (Kerberos Referral ticketing or NTLM Pass-Through).
2. A pre-existing authorization bridge (Foreign Security Principals nested in local groups).
3. Credential harvesting from memory (LSASS dumping of a Domain B user logged into a Domain A workload).

Concept

Cross-Domain Lateral Movement describes the techniques through which an adversary with a foothold in a source domain (DOMAIN_A) expands administrative authority and operational reach into securable workloads, data stores, or domain controllers of a distinct domain (DOMAIN_B).

These movements occur across two primary topologies:

• Intra-Forest: Between domains residing within the same forest (Parent-Child, Tree-Root). Trusts are transitive and bidirectional.
• Inter-Forest: Between separate forests linked via a Forest Trust or External Trust.

---

Why It Matters in DFIR

Understanding cross-domain pivot mechanics allows investigators to:

• Pinpoint Patient Zero in Multi-Domain Outbreaks: Ransomware deployed across a primary production domain frequently originates days or weeks prior on an unmonitored subsidiary or dev workstation in a secondary domain.
• Expose Stealth Ingress Paths: Adversaries prioritize high-leverage indirect routes (e.g., compromising a delegated service account in a child domain that holds local admin rights on a jump server in the parent domain).
• Identify Network and Architectural Bypass Points: Established trusts require opening RPC, SMB, and Kerberos ports through internal firewalls, creating permitted traversal conduits.

---

How It Works

Cross-Domain Lateral Movement Attack Matrix

┌────────────────────────────────────────────────────────────────────────────┐
│              CROSS-DOMAIN LATERAL MOVEMENT VECTORS IN DFIR                 │
├────────────────────────────────────────────────────────────────────────────┤
│ 1. sIDHistory Abuse (Intra-Forest or Quarantine-Disabled Trusts)           │
│    -> Forging Inter-Realm TGTs with RID 512/519 injected into sIDHistory.  │
├────────────────────────────────────────────────────────────────────────────┤
│ 2. Foreign Security Principal (FSP) Nesting Abuse                          │
│    -> A Domain A account/group is nested into a Domain B local group.      │
├────────────────────────────────────────────────────────────────────────────┤
│ 3. Memory Credential Harvesting (LSASS Pivot)                              │
│    -> A Domain B admin authenticated to a compromised Domain A machine.    │
├────────────────────────────────────────────────────────────────────────────┤
│ 4. Kerberos Delegation Abuse (Unconstrained Delegation / RBCD)             │
│    -> Harvesting TGTs of Domain B accounts visiting Domain A workloads.    │
├────────────────────────────────────────────────────────────────────────────┤
│ 5. Cross-Domain Kerberoasting                                              │
│    -> Requesting TGS tickets for Domain B SPNs and cracking offline.       │
└────────────────────────────────────────────────────────────────────────────┘

---

What Is Possible

• Instant Intra-Forest Escalation: Armed with a child domain krbtgt key, forging an inter-realm ticket with sIDHistory guarantees mathematical takeover of the forest root (absent manual non-standard hardening).
• Cross-Domain Pivoting Without Any Trust via Memory Theft: If a Domain B administrator connects via RDP to a Domain A workstation (even with zero trust between domains), their credentials can be dumped from LSASS to attack Domain B.
• Resource-Based Constrained Delegation (RBCD) Across Domains: Controlling a computer account in Domain A and possessing write rights over msDS-AllowedToActOnBehalfOfOtherIdentity on a Domain B server enables full server takeover.

---

What Is Not Possible

• Traversing Forest Trusts via sIDHistory Under Active SID Filtering: Target KDCs sanitize foreign SIDs from PAC payloads prior to service ticket issuance.
• Executing DCSync on Domain B Using Domain A Domain Admin Credentials: Directory replication rights are bound to specific domain naming contexts; the identity must explicitly hold DS-Replication-Get-Changes-All on Domain B.
• Operating NTLM Pass-Through When Inter-DC Netlogon Channels Are Blocked at Network Firewalls.

---

Common DFIR Confusions

Frequent Confusion	Verifiable Forensic Reality
”The attacker could not traverse from A to B because no trust exists between them.”	Lack of trust blocks automated Kerberos/NTLM referrals, but does not prevent harvesting Domain B credentials cached in memory on Domain A hosts.
”Cross-domain lateral movement leaves traces on a single DC.”	False. The hop produces telemetry on the source DC (Event 4768/4769), target DC (Event 4769 / Netlogon 4776), and target workload (Logon 4624).
”Isolating Domain A DCs eliminates all inbound attacks against Domain B.”	If the attacker cached valid tickets or harvested plaintext Domain B credentials, they can hit Domain B endpoints directly without touching Domain A DCs.

---

Concrete Forensic Example

In an international enterprise, a ransomware outbreak begins in a regional subsidiary (apac.corp.local):

1. The adversary secures local administrative rights on an endpoint in Sydney.
2. BloodHound path analysis reveals:
   • APAC\Domain Users is nested into a local group CORP\Regional-Admins via an FSP on the root domain.
   • Regional-Admins holds local administrator privileges on an infrastructure jumpbox JUMP-SRV in corp.local.
3. The attacker connects to JUMP-SRV via SMB using a Kerberos referral.
4. On JUMP-SRV, an LSASS memory dump extracts plaintext credentials of a CORP\Enterprise Admins account logged into an active RDP session.
5. Outcome: The attacker achieves full forest dominance within 3 hours by chaining FSP group nesting with memory credential theft.

---

Key Forensic Artefacts

1. Source Domain DC Event Logs:
   • Event ID 4769: TGS request with ServiceName: krbtgt/TARGET_DOMAIN (referral ticket).
2. Target Domain DC Event Logs:
   • Event ID 4769: Service ticket issued for local SPN upon presentation of referral TGT.
   • Event ID 4675: SID filtering violation logged if foreign SID injection was attempted.
3. Target Workload Event Logs:
   • Event ID 4624 (Logon Type 3): Network logon recording remote domain in TargetDomainName.
   • Event ID 4672: Privileges assigned during logon.

---

Investigation Methods

1. Map Cross-Domain Attack Pathways: Use BloodHound to audit TrustedBy, cross-domain MemberOf group edges, and active user sessions.
2. Analyze Referral TGS Issuances: Query Event ID 4769 across all enterprise DCs for requests targeting inter-domain trust accounts (krbtgt/*).
3. Audit Cross-Domain Network Logons: Identify Event ID 4624 (Type 3) on sensitive servers where TargetDomainName differs from the local machine’s domain.

---

Investigative Tooling

• BloodHound / SharpHound:

  # Collect multi-domain attack paths
  Invoke-BloodHound -CollectionMethod All,Trusts -Domain "corp.local"

• PowerShell / Get-WinEvent:

  Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} |
    Where-Object { $_.Properties[7].Value -eq 3 -and $_.Properties[5].Value -ne $env:USERDOMAIN } |
    Select-Object TimeCreated, @{N='Domain';E={$_.Properties[5].Value}}, @{N='User';E={$_.Properties[4].Value}}, @{N='IP';E={$_.Properties[18].Value}}

---

Key Takeaways

• Cross-domain pivots rely on: Kerberos/NTLM trusts, nested FSPs, or memory credential theft.
• sIDHistory injection succeeds by default intra-forest, but is blocked by inter-forest SID Filtering.
• Detection requires multi-tier correlation of KDC Event 4769 referral requests and endpoint Event 4624 logons.

---

References & Further Reading

• Microsoft Learn: Kerberos Authentication across Domains
• Card 16 — Cross-Domain Authentication: Kerberos Referral and NTLM Pass-Through
• Card 17 — SID Filtering and Name Suffix Routing
• Card 18 — Cross-Domain Group Membership and Foreign Security Principals
• Card 23 — NetExec (nxc): What Do the Results Actually Prove?