- Home
- SIEM use cases
- Domain Trust Abuse
How to detect domain trust abuse
In this page
Threat snapshot
Domain trusts are the bridges between Active Directory environments. They allow users in one domain to authenticate and access resources in another, enabling cross-domain collaboration in multi-domain forests and cross-forest partnerships between organizations. In most enterprises, these trusts are set up once during infrastructure deployment and then largely forgotten. That is precisely what makes them attractive to attackers.
An attacker who has compromised one domain in a forest does not stop at that domain's boundary. If trust relationships exist to other domains, particularly transitive trusts or forest trusts with SID history enabled, a compromised domain can become a stepping stone to domains with significantly higher sensitivity or privilege. In multi-forest environments common in large enterprises and across mergers and acquisitions, a single compromised subsidiary domain can be the entry point to the parent organization's entire AD infrastructure.
Trust discovery is the intelligence phase that makes this possible. Before an attacker can exploit a trust relationship, they need to enumerate which trusts exist, which direction they flow, whether they are transitive, and what SID filtering settings are in place. Tools like TruffleSnout, dsquery trust commands, and LDAP queries targeting the trustedDomain object class systematically map the trust landscape and identify exploitable paths between domains.
This page covers the trust discovery and exploitation chain, maps each phase to Log360's detection rules, and provides the investigation workflow for responding when trust-related activity is detected.
Domain trust abuse, at a glance
| Severity | Critical |
| Category | Identity & Access |
| Attack variants covered | Trust relationship discovery and enumeration, cross-domain token impersonation, SID history abuse, forest trust exploitation, access token manipulation for cross-domain lateral movement |
| MITRE ATT&CK tactics | TA0007 - Discovery, TA0006 - Credential Access, TA0005 - Defense Evasion, TA0004 - Privilege Escalation |
| MITRE techniques | T1482 - Domain Trust Discovery, T1134 - Access Token Manipulation, T1134.001 - Token Impersonation/Theft, T1134.002 - Create Process with Token |
| Platforms covered | Active Directory, Windows |
| Log360 detection rules |
|
| SOC maturity level | Level 3 - Incident Response |
| Compliance mapping | NIST CSF PR.AC-3, PCI-DSS 7.2, HIPAA Section 164.312(a)(1), ISO 27001 A.9.1.2 |
How domain trust abuse works
Domain trust abuse follows a two-phase pattern. In the first phase, the attacker enumerates the trust landscape to understand which domains are reachable and what trust properties could be exploited. In the second phase, they exploit those trusts using token manipulation, SID history injection, or forged inter-realm tickets to authenticate across domain boundaries as a privileged user.
Phase 1: Trust discovery (T1482)
Before exploiting a trust, the attacker must understand it. Trust discovery is performed using three main approaches. The first is dsquery commands: dsquery * -filter "(objectClass=trustedDomain)" enumerates all trust objects in the domain partition, returning the trust name, direction, and type. The second is TruffleSnout, a dedicated .NET tool that specifically enumerates Active Directory trust relationships, including forest trusts, external trusts, shortcut trusts, and their transitivity properties. The third is LDAP queries targeting the trustedDomain object class and DNS server discovery, which helps the attacker map domain controller locations in trusted domains for subsequent Kerberos authentication attempts.
The information gathered in this phase is operationally critical: it tells the attacker which domains are reachable via trust, whether those trusts are transitive (allowing multi-hop traversal), whether SID filtering is enabled (which blocks SID history abuse), and which domain controllers in the trusted domain handle cross-realm Kerberos authentication. Without this map, cross-domain exploitation is largely blind.
Log signals: Sysmon Event 1 for TruffleSnout process creation. Windows Security Event 4661 (handle requested for SAM object) or LDAP query logs for dsquery trust commands. LDAP queries targeting objectClass=trustedDomain from non-DC sources.
Phase 2: Trust exploitation via token manipulation (T1134)
With trust relationships mapped, the attacker exploits them through one of three mechanisms. Token impersonation (T1134.001) is the most common: tools like Koh, SharpImpersonation, and Impersonate capture access tokens from processes running under cross-domain user sessions and allow the attacker to impersonate those users. Koh specifically targets named pipes to intercept Kerberos token negotiation, making it particularly effective in environments where cross-domain service accounts are in use.
SID history injection is a more sophisticated technique that requires SID filtering to be disabled on the trust relationship. When SID filtering is off, an attacker who can modify SID history attributes (typically requiring Mimikatz with domain admin access) can add the SID of a privileged account from the target domain to a compromised account in the source domain. When that compromised account authenticates across the trust, the target domain's KDC includes the injected SID in the Kerberos PAC, granting the attacker the privileges of the target domain account.
Inter-realm ticket forgery is the highest-privilege variant and requires that the attacker has already compromised the inter-realm trust key (a shared secret between the two domains' KDCs). With this key, the attacker can forge inter-realm TGTs that grant access to the target domain as any user, including Domain Admin. This is closely related to the Golden Ticket technique but operates across domain boundaries rather than within a single domain.
Log signals: Sysmon Event 1 for Koh, SharpImpersonation, and Impersonate tool execution. Named pipe creation events (Sysmon Event 17) for Koh's named pipe-based token interception. Windows Security Event 4769 (Kerberos TGS request) for inter-realm ticket requests, particularly those requesting tickets for resources in trusted domains from accounts not normally performing cross-domain authentication.
Real-world campaigns
APT29 and Midnight Blizzard: forest trust exploitation for cross-organization access
APT29 has been documented exploiting inter-forest trust relationships as a lateral movement path during intrusions targeting organizations with complex multi-forest AD environments. After compromising an initial domain, the group maps trust relationships to identify partner organizations or subsidiaries connected via forest trusts. If those trusts have SID filtering disabled or have been configured with excessive permissions, the compromised domain becomes an entry point to the partner organization's AD environment. This technique was particularly relevant in supply chain attack scenarios where a managed service provider's domain had trust relationships to multiple customer environments.
Ransomware operators: trust discovery as pre-encryption reconnaissance
Multiple ransomware operators including Black Basta and Akira affiliates have incorporated trust discovery into their standard pre-encryption reconnaissance workflow in multi-domain enterprise environments. After achieving initial domain compromise, the operators enumerate trust relationships to identify additional domains that can be encrypted. In organizations with parent-child domain structures, a compromise of a subsidiary domain followed by trust-based lateral movement to the root domain significantly multiplies the ransomware blast radius. The Trust Discovery Via Dsquery and TruffleSnout rules provide early detection of this reconnaissance phase before cross-domain movement begins.
Attack technique reference table
| Technique | Prerequisites | What it enables | Log360 primary detection |
|---|---|---|---|
| Trust discovery via dsquery (T1482) | Any domain account | Maps all trust relationships: direction, type, transitivity, SID filtering status | Domain Trust Discovery Via Dsquery |
| Trust discovery via TruffleSnout (T1482) | Any domain account | Comprehensive trust enumeration including forest trusts and trust attributes | HackTool - TruffleSnout Execution |
| DNS server discovery for trust mapping (T1482) | Any domain account | Identifies DC locations in trusted domains for cross-realm Kerberos targeting | DNS Server Discovery Via LDAP Query |
| Token impersonation via Koh (T1134.001) | Local admin on machine with cross-domain user sessions | Captures cross-domain tokens from active sessions for impersonation | HackTool - Koh Default Named Pipe |
| Token impersonation via SharpImpersonation / Impersonate (T1134.001) | Local admin or SYSTEM on target machine | Steals or duplicates access tokens for cross-domain account impersonation | HackTool - SharpImpersonation Execution, HackTool - Impersonate Execution |
| SID history injection | Domain Admin in source domain, SID filtering disabled on trust | Grants attacker account privileges of target domain account across trust boundary | Suspicious parent spawning lsass (Mimikatz execution pattern) |
Business impact
- Trust boundaries multiply compromise scope. In multi-domain or multi-forest environments, a single domain compromise that goes undetected during the trust discovery phase can cascade to every connected domain. An attacker who maps and exploits trust relationships in a hub-and-spoke forest topology achieves what is effectively a full enterprise compromise from a single initial foothold.
- Trust relationships are rarely reviewed. Trust configurations established during infrastructure deployment or mergers and acquisitions frequently persist unchanged for years. Overly permissive trust settings such as disabled SID filtering, bidirectional trusts where unidirectional would suffice, or forest-wide transitive trusts to partner organizations are common audit findings that organizations do not discover until after a trust-based compromise.
- Cross-domain movement is harder to detect. Authentication events for cross-domain access often generate logs in the target domain rather than the source domain, creating a monitoring gap when the source and target domains forward logs to different SIEM instances or when the target domain's logs are not centrally collected. An attacker moving laterally across a trust boundary may be invisible to the SOC monitoring the source domain.
- Merger and acquisition risk. Organizations that acquire companies with separate AD environments often establish trust relationships to enable integration. If the acquired organization has weaker security controls, its domain becomes the path of least resistance for attackers targeting the parent organization's more valuable assets.
Detecting domain trust abuse with Log360
Log360's 19 detection rules for this use case cover three distinct layers of the attack: trust discovery tools and LDAP-based enumeration, dedicated token impersonation tool execution, and anomalous process parent-child relationships that indicate token manipulation or injection is occurring at the Windows process level. For process-creation-based rules, Sysmon must be deployed on domain-joined endpoints with Event 1 forwarding to Log360. For LDAP-based trust discovery rules, Active Directory audit logs from domain controllers must be collected.
Trust discovery detection
| Rule name | Severity | Platform | MITRE technique | What it detects |
|---|---|---|---|---|
| Domain Trust Discovery Via Dsquery | Trouble | Active Directory | T1482 | dsquery.exe executed with arguments targeting trust objects, specifically the trustedDomain object class or trust-related LDAP filters. Dsquery trust enumeration is the most common first step in cross-domain reconnaissance and is performed by both manual attackers and automated tools. Fires on Sysmon Event 1 with dsquery process creation and trust-targeting argument patterns. |
| HackTool - TruffleSnout Execution | Trouble | Active Directory | T1482 | TruffleSnout binary execution detected via Sysmon process creation. TruffleSnout is a dedicated .NET Active Directory trust enumeration tool designed specifically to map trust relationships, their attributes, and exploitation potential. Its execution is high-confidence malicious in any production environment outside of an authorized security assessment. |
| DNS Server Discovery Via LDAP Query | Attention | Active Directory | T1482 | LDAP queries targeting DNS server objects in Active Directory, a technique used to identify domain controller locations in trusted domains. Attackers enumerate DNS server records to locate KDCs in target trusted domains before initiating cross-realm Kerberos authentication. Attention severity because DNS server LDAP queries can occur in legitimate infrastructure management contexts. |
Token impersonation tool detection
| Rule name | Severity | Platform | MITRE technique | What it detects |
|---|---|---|---|---|
| HackTool - Koh Default Named Pipe | Critical | Windows | T1134.001 | Koh tool execution detected via its default named pipe creation pattern. Koh intercepts Kerberos token negotiation via named pipes to capture authentication tokens from processes authenticating across domain or forest boundaries. Its named pipe signature is distinctive and has no legitimate use in production environments. Critical severity because successful Koh execution yields cross-domain tokens that enable immediate lateral movement. |
| HackTool - Impersonate Execution | Trouble | Windows | T1134.001 | Impersonate tool execution detected via Sysmon process creation. Impersonate is a Windows token manipulation tool that duplicates or steals access tokens from running processes, enabling the attacker to execute code in the security context of any user with an active session on the machine, including cross-domain accounts. |
| HackTool - SharpImpersonation Execution | Trouble | Windows | T1134.001 | SharpImpersonation binary execution detected via Sysmon process creation. SharpImpersonation is a .NET token impersonation tool that provides named pipe-based impersonation, token stealing from existing processes, and process creation under an impersonated token. Particularly relevant in trust abuse scenarios where cross-domain service accounts have sessions on the compromised machine. |
| HackTool - SharpDPAPI Execution | Trouble | Windows | T1134.001 | SharpDPAPI execution detected via Sysmon process creation. SharpDPAPI decrypts DPAPI-protected credentials and secrets, which can include cached cross-domain credentials stored in the Windows credential manager or browser credential stores. In trust abuse contexts, SharpDPAPI is used to extract stored credentials for accounts in trusted domains that have been cached on the compromised machine. |
| PUA - AdvancedRun Suspicious Execution | Trouble | Windows | T1134.002 | AdvancedRun executed in a suspicious context. AdvancedRun is a tool that can launch processes under different user tokens, including TrustedInstaller and SYSTEM, enabling privilege escalation and cross-domain token-based process creation. In trust abuse chains, it is used to create processes under impersonated cross-domain tokens. |
| Potential Meterpreter/CobaltStrike Activity | Trouble | Windows | T1134.001 | Process behavior patterns consistent with Meterpreter or Cobalt Strike C2 frameworks, both of which include built-in token impersonation capabilities (getsystem, impersonate_token, steal_token commands). These frameworks are commonly used in trust abuse campaigns to perform token manipulation and cross-domain lateral movement from a C2-controlled implant. |
Suspicious process execution patterns
The following rules detect anomalous parent-child process relationships that are characteristic of token manipulation and injection attacks. In a trust abuse context, these patterns indicate that an attacker is using token-based techniques to spawn processes under impersonated identities, potentially including cross-domain accounts. Each rule fires when a Windows system process appears as the parent of an unexpected child process, which is the signature of process injection or token duplication attacks that hijack system process contexts.
| Rule name | Severity | Platform | MITRE technique | What it detects |
|---|---|---|---|---|
| Suspicious parent spawning Consent | Critical | Windows | T1134 | consent.exe spawning an unexpected child process. Consent.exe handles UAC prompts; a process spawned from it outside of normal UAC elevation flows indicates token manipulation to abuse the elevated context created during consent handling. |
| Suspicious parent spawning searchprotocolhost | Critical | Windows | T1134 | searchprotocolhost.exe spawning unexpected child processes. This process runs under the LOCAL SYSTEM account and is a target for token theft to obtain SYSTEM-level tokens for privilege escalation within or across domain boundaries. |
| Suspicious parent spawning LogonUI | Critical | Windows | T1134 | LogonUI.exe spawning unexpected child processes. LogonUI runs in a privileged context during logon sessions; process spawning from it is characteristic of credential interception attacks that target the logon process to capture tokens from authenticating users, including cross-domain logons. |
| Suspicious parent spawning lsass | Critical | Windows | T1134 | lsass.exe spawning unexpected child processes. LSASS manages authentication and holds all authentication tokens on the system. Process injection into LSASS or spawning from it is a hallmark of advanced token theft and credential access attacks, including SID history manipulation for cross-domain trust abuse. |
| Suspicious parent spawning runtimebroker | Critical | Windows | T1134 | RuntimeBroker.exe spawning unexpected child processes. RuntimeBroker runs under the user's token and is targeted for token duplication attacks to obtain user-context tokens for lateral movement. |
| Suspicious parent spawning searchindexer | Critical | Windows | T1134 | SearchIndexer.exe spawning unexpected child processes. SearchIndexer runs as SYSTEM and is targeted for privilege escalation via token impersonation to obtain SYSTEM-level execution context. |
| Suspicious parent spawning svchost | Critical | Windows | T1134 | svchost.exe spawning unexpected child processes outside of its normal service hosting function. Service host processes run under various privilege levels including SYSTEM and NETWORK SERVICE, making them high-value targets for token theft in cross-domain attack chains. |
| Suspicious parent spawning tiworker | Critical | Windows | T1134 | TiWorker.exe (Windows Modules Installer Worker) spawning unexpected child processes. TiWorker runs as SYSTEM and is targeted for token impersonation to obtain SYSTEM-level tokens for privilege escalation. |
| Suspicious parent spawning winlogon | Critical | Windows | T1134 | winlogon.exe spawning unexpected child processes. Winlogon handles user session creation and runs under SYSTEM; process spawning from it outside of normal session management flows indicates token manipulation attacks targeting the logon subsystem. |
| Unauthorized Sophos Firewall Rule Deletion Detected | Critical | SonicWall | T1134 | Unauthorized deletion of firewall rules on Sophos-managed network devices, mapped to T1134 in the context of defense evasion that accompanies cross-domain lateral movement. Attackers who have achieved cross-domain access frequently modify network security controls to remove barriers to their expanded access. |
Attack chain visibility
Trust abuse is always embedded in a larger attack chain. The sequences below show the full progression from trust discovery to cross-domain privilege escalation.
Sequence A: TruffleSnout discovery to token impersonation cross-domain movement
| Step | Log source and event | What it indicates | Time offset |
|---|---|---|---|
| 1 | Sysmon Event 1 (Process Creation) | TruffleSnout.exe executes on the compromised machine. HackTool - TruffleSnout Execution rule fires. The attacker is mapping the trust landscape from the compromised domain, identifying which trusted domains exist and their properties. | T+0 |
| 2 | Sysmon Event 1 (Process Creation) | dsquery.exe executes with trust-targeting arguments. Domain Trust Discovery Via Dsquery rule fires. The attacker is corroborating the TruffleSnout findings and querying specific trust attributes such as SID filtering status. | T+5 min |
| 3 | Sysmon Event 1 (Process Creation) | SharpImpersonation or Koh executes on a machine that has active sessions from cross-domain users. HackTool - SharpImpersonation Execution or HackTool - Koh Default Named Pipe rule fires. The attacker is targeting tokens from cross-domain accounts with active sessions on the machine. | T+30 min to T+2h |
| 4 | Windows Security Event 4624 (logon Type 9 or Type 3) | A new logon event appears for an account from the trusted domain, sourced from the attacker's machine. Type 9 (NewCredentials) indicates impersonation-based logon. The attacker is now authenticated in Domain B using a stolen token from Domain A. | T+2h to T+4h |
Sequence B: dsquery trust discovery to cross-domain C2 lateral movement
| Step | Log source and event | What it indicates | Time offset |
|---|---|---|---|
| 1 | AD audit logs (LDAP query) | LDAP query for DNS server objects in the domain naming context, followed by a dsquery trust enumeration. DNS Server Discovery Via LDAP Query rule fires alongside Domain Trust Discovery Via Dsquery. The attacker is building a complete picture of the trusted domain's DC infrastructure. | T+0 |
| 2 | Sysmon Event 1 (Process Creation) | Meterpreter or Cobalt Strike implant spawns a new process. Potential Meterpreter/CobaltStrike Activity rule fires. The C2 framework's built-in token impersonation commands are being used to perform cross-domain authentication from the C2 session. | T+30 min |
| 3 | Windows Security Event 4769 (Kerberos TGS) on DC of trusted domain | TGS request for a resource in the trusted domain originates from the attacker's source IP using an inter-realm TGT. This is the Kerberos cross-domain authentication event. If the trusted domain's DC logs are forwarded to Log360, this event is visible and links the trust exploitation to a specific resource access attempt. | T+35 min |
Investigation playbook
Trust abuse investigations have two dimensions that must be investigated simultaneously: the source domain (where the attacker is operating) and the target domain (where cross-domain access may have occurred). If both domains forward logs to the same Log360 instance, cross-domain correlation is possible within a single investigation. If not, the investigation requires coordination between the teams responsible for each domain.
Step 1: Triage - identify the phase and domain scope
| Rule that fired | Attack phase | Domain scope | First action |
|---|---|---|---|
| Domain Trust Discovery Via Dsquery or HackTool - TruffleSnout Execution | Trust discovery - reconnaissance phase | Source domain only at this point | Identify which trusts exist and their properties. Determine whether any trusts have SID filtering disabled or are configured as bidirectional when unidirectional would suffice. Alert the security teams of all trusted domains immediately. |
| HackTool - Koh Default Named Pipe or HackTool - SharpImpersonation Execution | Token impersonation - active cross-domain movement attempt | Source domain; check target domain for authentication events | Identify all user sessions on the host where the tool ran. Check whether any cross-domain accounts had active sessions on that machine. Query Event 4624 (Type 9) in the target domain for logons from the source machine IP. |
| Suspicious parent spawning rules (lsass, winlogon, svchost, etc.) | Token manipulation - process injection or token theft in progress | Source domain host | Identify the unexpected child process from the Sysmon Event 1 record. Determine what the child process executed and under whose token. Check UEBA scores for the accounts involved. |
| Potential Meterpreter/CobaltStrike Activity | C2-based token manipulation | Source domain; C2 may be directing cross-domain activity | Identify the C2 implant process. Check outbound network connections from that process for C2 beaconing. Isolate the host. Investigate all token manipulation activities from the C2 session. |
Step 2: Determine whether cross-domain access has occurred
- Query Windows Security Event 4624 in the source domain for logon Type 9 (NewCredentials) events from the machine where token impersonation tools were detected. Type 9 logons indicate impersonation-based credential use and are the key forensic indicator of successful token-based cross-domain access.
- Query Windows Security Event 4769 (Kerberos TGS request) on domain controllers in both the source and target domains. Look for inter-realm TGS requests: these appear in the Kerberos logs with a realm different from the local domain in the client address or service name fields.
- Check whether any accounts from the trusted domain appear in Event 4624 logs on machines in the source domain. Cross-domain accounts authenticating to machines in the source domain from the attacker's source IP indicates successful impersonation.
- If the target domain forwards logs to the same Log360 instance: query for logon events in the target domain from the source machine's IP or from the compromised account. Any successful authentication in the target domain from the attack source is a confirmed cross-domain compromise.
Step 3: Investigate using the Incident Workbench
- Click on the source hostname or compromised account username in the alert to open the Incident Workbench. Use the Process analytics tab to inspect the full process tree on the host where trust discovery or token impersonation tools were detected. The process tree shows what spawned the discovery or impersonation tool, providing context on the prior compromise chain that gave the attacker access to this host.
- Use the User analytics tab for any cross-domain accounts identified in the investigation. If a cross-domain account was impersonated, its UEBA profile in Log360 will show whether its recent activity deviates from its established baseline, which helps confirm whether the account's activity represents the legitimate user or the attacker.
- Use Advanced Threat Analytics on any external IPs involved in the C2 activity (if Meterpreter or Cobalt Strike was detected) to pull threat feed risk scores and confirm the C2 infrastructure is associated with known threat actor tooling.
- Save the Incident Workbench session to an incident and flag it for the security teams responsible for all trusted domains. Cross-domain incidents require coordination across domain boundaries, and the saved session provides the evidence record for that coordination.
Step 4: Assess trust relationship risk and scope
- Document all trust relationships in the source domain: their direction, type, transitivity, and SID filtering status. Any trust with SID filtering disabled is immediately exploitable for SID history injection if the source domain is compromised. This information should be shared with the security team of every trusted domain.
- Determine whether any inter-realm trust keys may have been accessed or extracted. If Mimikatz or similar tools ran on a domain controller, the inter-realm trust keys stored in the LSASS process may have been dumped. Compromised trust keys require trust relationship reset (regenerating the inter-realm trust key) between affected domains.
- Check whether any new trust relationships were created during the intrusion period. Windows Security Event 4706 (new trust created) on domain controllers indicates the attacker may have established a new trust to a domain they control, creating a persistent cross-domain access path that survives normal incident response actions.
- Assess whether the target domain needs to be treated as compromised. If cross-domain authentication was confirmed, the incident scope extends to the target domain and the target domain's security team must be engaged for their own compromise assessment.
Step 5: Collect evidence and build the timeline
- Export Sysmon Event 1 logs from the source host for the attack window. Preserve the full command-line field for all trust discovery and token impersonation tool invocations.
- Export Windows Security Event 4769 logs from domain controllers in both the source and target domains, filtered for inter-realm TGS requests. These logs document the Kerberos-layer evidence of cross-domain authentication.
- Export Event 4624 (Type 9 logons) from the source domain machines in the attack window. These are the primary forensic records for impersonation-based cross-domain logons.
- Export the Incident Workbench session timeline as the compliance artifact for NIST CSF DE.AE-5, and share with the security teams of all affected domains for their own incident documentation.
Response and remediation
Immediate containment
- Isolate the source host where trust discovery or token impersonation tools were detected. This prevents the attacker from using that machine to perform further cross-domain authentication or enumerate additional trust targets.
- Alert the security teams of all trusted domains immediately. If cross-domain access has occurred or is suspected, the trusted domains must be treated as potentially compromised and begin their own investigation. Do not wait for confirmation before notifying; the notification itself is time-sensitive.
- Revoke cross-domain Kerberos tickets. If inter-realm ticket abuse is suspected, perform a double krbtgt password reset in the source domain (to invalidate all Kerberos tickets issued from that domain) and request that the target domain's team perform the same. Two resets within the Kerberos ticket lifetime window are required to invalidate in-flight tickets.
- Disable any accounts confirmed to have been impersonated in cross-domain authentication events until the scope of access using those credentials is determined.
Response actions by trigger
| Trigger | Immediate action | Owner |
|---|---|---|
| HackTool - TruffleSnout Execution or Domain Trust Discovery Via Dsquery | Isolate source host. Identify what trusts were mapped. Alert trusted domain teams. Check for subsequent token impersonation tool execution on same host. | SOC L2 |
| HackTool - Koh Default Named Pipe or SharpImpersonation Execution | Isolate host immediately. Identify all active cross-domain sessions on that machine. Check target domain for Type 9 logons from source IP. Treat as active cross-domain compromise. | SOC L3 + Incident Response |
| Confirmed cross-domain Type 9 logon following impersonation tool detection | Full incident declared. Notify target domain teams. Begin double krbtgt reset in source domain. Disable impersonated accounts. Engage IR for both domains. | CISO + Incident Response + AD Team |
| Suspicious parent spawning rules (lsass, winlogon, svchost) | Isolate host. Identify the unexpected child process and its subsequent actions. Check UEBA scores for accounts active on that machine. Treat as active token manipulation. | SOC L2 + Incident Response |
Trust relationship hardening
- Enable SID filtering on all trust relationships where it is not strictly required for a documented business need. SID filtering prevents SID history injection attacks by stripping SID history attributes from cross-domain authentication tokens. It is disabled by default on certain trust types and must be explicitly enabled.
- Audit all trust relationships for necessity and configuration. Review each trust: is it still needed for a current business purpose? Is the trust direction correct (unidirectional vs. bidirectional)? Is transitivity scoped appropriately? Trusts that are no longer needed should be removed, not just documented.
- Restrict inter-domain authentication using Selective Authentication on forest trusts where possible. Selective Authentication requires that accounts in the trusted forest be explicitly granted access to specific resources in the trusting forest, preventing any account in the trusted forest from authenticating to resources in the trusting forest by default.
- Deploy log forwarding from all trusted domain controllers to Log360 to enable cross-domain authentication correlation. Without logs from trusted domain DCs, Event 4769 inter-realm TGS requests and Event 4624 cross-domain logons in the target domain are invisible to the SOC monitoring the source domain.
False positive tuning
| False positive source | Rules affected | Tuning strategy |
|---|---|---|
| IT administrators performing trust relationship audits | Domain Trust Discovery Via Dsquery, DNS Server Discovery Via LDAP Query | Create an allowlist of authorized AD administrators who perform trust management and auditing. Scope the exception to those accounts AND their designated management workstations. Any trust discovery from a non-admin account or non-management workstation should always alert. |
| Authorized penetration testing and red team exercises | All 19 detection rules | Create time-bounded exceptions scoped to the authorized assessment source IP range and tied to the approved change ticket. TruffleSnout, Koh, SharpImpersonation, and Impersonate detection rules should never have permanent exclusions in production environments. |
| Legitimate cross-domain service accounts with active sessions | Suspicious parent spawning rules (Type 9 logon context) | Cross-domain service accounts that legitimately run services across domain boundaries will generate Type 9 logon events that may trigger process-based rules in certain configurations. Document all authorized cross-domain service accounts and their expected source machines. Alert on cross-domain logons from any other source. |
| Windows Update and maintenance processes | Suspicious parent spawning tiworker, Suspicious parent spawning svchost | TiWorker.exe and svchost.exe spawn legitimate child processes during Windows Update cycles. Correlate these rule firings against Windows Update event logs (Event ID 19 in the Windows Update log). Firings during known update windows from expected update-related processes can be tuned to reduce noise. |
