Cross-Domain Authentication: Kerberos Referral and NTLM Pass-Through

Concept

When a user in Domain A accesses a securable resource in Domain B, Windows relies on one of two authentication protocols:

Kerberos Referral (Modern / Primary): Kerberos v5 implements cross-realm routing using referral tickets (Cross-Realm TGTs). The client queries its local KDC, which responds with a referral ticket pointing to the next KDC in the trust hierarchy, repeating until the KDC hosting the target service’s SPN is reached.
NTLM Pass-Through (Legacy / Fallback): When Kerberos cannot be negotiated (e.g., target accessed via IP address instead of FQDN, unmapped SPN, or firewall blocking port 88), Windows falls back to NTLM. Because NTLM does not support client-side referrals, the target server contacts its local DC, which forwards the challenge and response to the user’s home DC via the Netlogon RPC service (ports 445/135).

Why It Matters in DFIR

Understanding protocol mechanics dictates where evidence of access is recorded:

Log Dispersal in Kerberos Referrals: Kerberos referrals generate Event ID 4768 (TGT) on the user’s home DC, Event ID 4769 (Referral TGS) on intermediate DCs and the target domain DC, and Event ID 4624 on the target workload.
NTLM Pass-Through Centralization: In cross-domain NTLM authentications, the target domain DC logs Event ID 8004 (NTLM authentication to domain was forwarded to...) via NTLM Auditing, capturing the exact Netlogon validation path.
Attacker Exploitation Angles: Attackers intentionally force NTLM fallback by targeting IP addresses to facilitate NTLM Relay attacks or capture Netlogon challenge-response exchanges across trusts.

How It Works

1. The Kerberos Referral Chain

Scenario: user@child.corp.local accessing fileserver.partner.local across a Forest Trust:

[Client user@child]
   │ 1. TGS-REQ for cifs/fileserver.partner.local
   ▼
[KDC child.corp.local] ──► Returns Referral TGT for krbtgt/corp.local
   │
   │ 2. TGS-REQ for cifs/fileserver.partner.local (with Referral TGT)
   ▼
[KDC corp.local (Root)] ──► Returns Referral TGT for krbtgt/partner.local
   │
   │ 3. TGS-REQ for cifs/fileserver.partner.local (with Inter-Forest Referral TGT)
   ▼
[KDC partner.local] ──► Returns final TGS for cifs/fileserver.partner.local
   │
   │ 4. AP-REQ (Presents final TGS)
   ▼
[fileserver.partner.local] ──► Validates ticket and grants access

2. NTLM Pass-Through Flow

[Client user@child]
   │ 1. Connects to SMB via IP \10.0.1.50
   │ 2. NTLM Negotiation & Challenge
   ▼
[Target Server (partner.local)]
   │ 3. Forwards Challenge/Response via Netlogon Secure Channel
   ▼
[DC partner.local]
   │ 4. Detects user domain is child.corp.local
   │    Relays request via Netlogon RPC
   ▼
[DC child.corp.local]
   │ 5. Validates response against local NTDS database
   │ 6. Returns STATUS_SUCCESS to DC partner.local
   ▼
[DC partner.local] ──► Returns STATUS_SUCCESS to Target Server

What Is Possible

Tracking Attacker Traversal via Event 4769: Filtering for ServiceName: krbtgt/<REMOTE_DOMAIN> across enterprise DCs enables precise reconstruction of every trust hop traversed during an intrusion.
Forced NTLM Downgrade: An attacker can intentionally force NTLM authentication by connecting via raw IP addresses, bypassing Kerberos FAST protections and facilitating credential relaying.
Granular NTLM Auditing: Enabling NTLM auditing policies (Network security: Restrict NTLM: Audit NTLM authentication in this domain) generates rich forensic events (8001 through 8004).

What Is Not Possible

Completing Kerberos Referrals When Name Suffix Routing Fails: If the source KDC cannot map the requested target SPN to a recognized trusted name suffix, it returns KDC_ERR_S_PRINCIPAL_UNKNOWN and authentication aborts or falls back to NTLM.
Executing Kerberos Referrals Without Network Connectivity to Every KDC: The client must be able to reach port 88 on every intermediate and destination KDC along the trust path.
Concealing Origin SIDs Inside Kerberos Tickets: The Privilege Attribute Certificate (PAC) always encapsulates the originating account SID regardless of referral hop depth.

Common DFIR Confusions

Frequent Confusion	Verifiable Forensic Reality
”The client has no network access to the remote DC, so cross-domain Kerberos works via proxy.”	False. Kerberos client referrals require direct client-to-DC connectivity to every domain’s KDC. Without it, Kerberos fails.
”Event 4769 with ServiceName=krbtgt indicates a Golden Ticket attack.”	No. This is standard, legitimate Kerberos referral behavior: requesting a TGS for `krbtgt/<REMOTE_DOMAIN>` is an ordinary inter-domain referral ticket.
”NTLM Pass-Through works without inter-DC network connectivity.”	NTLM pass-through strictly requires direct RPC Netlogon communications between the DCs of both domains.

Concrete Forensic Example

A ransomware deployment impacts a database server in subsidiary.corp:

Target server log: Event ID 4624, LogonProcessName: NtLmSsp, Workstation Name: PIVOT-WS, TargetUserName: backup_svc, TargetDomainName: PARENT_CORP.
Subsidiary DC log: Event ID 8004 (NTLM Auditing), recording that backup_svc authentication was routed to DC01.parent_corp.local via Netlogon.
Parent DC log: Event ID 4624 (Logon Type 3) initiated by the subsidiary DC computer account.
DFIR Synthesis: The attacker leveraged a parent domain credential over NTLM pass-through to access subsidiary workloads, leaving an unbroken chain of Netlogon telemetry.

Key Forensic Artefacts

DC Security Logs — Kerberos Referrals:
- Event ID 4768: Initial TGT issuance in user home domain.
- Event ID 4769: TGS request with ServiceName: krbtgt/<REMOTE_DOMAIN_NAME> (Referral Ticket).
- Ticket Options: Flag 0x40810010 indicating referral request.
DC Operational Logs — NTLM Pass-Through:
- Event ID 8004 (Microsoft-Windows-NTLM/Operational): Telemetry documenting forwarded Netlogon authentications.
Target Server Security Logs:
- Event ID 4624: Network Logon (Type 3) documenting authentication package (Kerberos vs NtLmSsp) and foreign source domain.

Investigation Methods

Trace the Complete Referral Hop Sequence: Correlate Event ID 4769 entries across all forest DCs filtered by client IP and target service name.
Inspect Netlogon Operational Event Logs: Query Microsoft-Windows-NTLM/Operational on domain controllers to detect forwarded NTLM authentications.
Analyze Endpoint Ticket Caches: Run klist on suspected source machines to review active cached cross-realm referral TGTs.

Investigative Tooling

Klist:
Terminal window
```
klist
klist purge
```

PowerShell Event Log Query:

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4769} |
  Where-Object { $_.Properties[0].Value -like 'krbtgt/*' } |
  Select-Object TimeCreated, @{N='TargetUser';E={$_.Properties[4].Value}}, @{N='Service';E={$_.Properties[0].Value}}, @{N='IPAddress';E={$_.Properties[6].Value}}

Wireshark: Filter: kerberos.msg_type == 12 (TGS-REQ) and kerberos.msg_type == 13 (TGS-REP) displaying referral structures.

Key Takeaways

Kerberos Referral is a client-driven navigation across KDC endpoints.
NTLM Pass-Through is a DC-to-DC relay orchestrated over Netlogon RPC.
Event 4769 entries for krbtgt/<DOMAIN> are the hallmark signature of legitimate Kerberos referrals.
Accessing servers by IP address reliably forces NTLM fallback over Kerberos.