MITRE ATT&CK T1482 Domain Trust Discovery: Spotting Enumeration Early

Listing an organisation's Active Directory trusts takes one built-in command, and in ransomware intrusions it often runs within the first hour, so it is one of the earliest discovery signals a SOC can catch. MITRE ATT&CK T1482 Domain Trust Discovery covers adversaries gathering information on domain trust relationships to find lateral movement opportunities in Windows multi-domain and multi-forest environments. In ATT&CK v20 it belongs to the Discovery tactic (TA0007) and applies to Windows. This guide covers how trust enumeration appears in real intrusions, the v20 detection strategy and its data sources, how to separate attacker enumeration from the many legitimate tools that read trusts, and the two ATT&CK mitigations. It is for detection engineers, SOC analysts and Active Directory owners. How trusts and SID filtering work, and how to harden them, is covered in the Active Directory Trusts and SID Filtering Guide; this page stays on detecting the discovery step.

Key takeaways

• Early and common. ATT&CK v20 lists more than 30 groups, software and campaigns using T1482, from QakBot, TrickBot, Latrodectus and IcedID loaders to Akira, BlackByte, FIN8 and Storm-0501 operators.
• Nltest dominates. Most procedure examples use the built-in nltest utility with its trust options, with AdFind, dsquery, PowerShell and BloodHound as the other common routes.
• Process context beats the command alone. Admin scripts and identity tools also read trusts; the useful signal is trust enumeration from a workstation, a loader, an Office or browser child process, or a newly logged-on account.
• Directory-side visibility needs a SACL. Event ID 4662 for reads of trustedDomain objects appears only if a SACL audits them, under Audit Directory Service Access.
• Prevention is limited; reduction is not. M1047 Audit (map trusts and keep them minimal) and M1030 Network Segmentation shrink what discovery reveals and what it is worth.

What the technique is

ATT&CK explains that domain trusts let one domain grant access to resources based on another domain's authentication, so users of the trusted domain can reach resources in the trusting domain. Learning the trust map tells an adversary which other domains and forests their current foothold can authenticate to, and therefore where SID-History injection, pass the ticket and Kerberoasting across a trust might work. ATT&CK lists the interfaces used: the DSEnumerateDomainTrusts() Win32 API, the .NET GetAllTrustRelationships() method, LDAP queries for trustedDomain objects, and tools such as nltest and PowerShell.

How adversaries use it: cases from ATT&CK v20

The loader cases are the most useful for detection design. QakBot, TrickBot, Latrodectus and IcedID run trust discovery automatically as part of initial host profiling, so an alert here is often the first sign that a phishing payload executed. In the human-operated cases (Akira, BlackByte, Storm-0501) the same step precedes credential theft and movement toward domain controllers. See the QakBot Malware Guide, the Akira Threat Actor Profile and the Storm-0501 Threat Actor Profile Guide.

What to detect and where

ATT&CK v20 maps DET0007 Detection of Domain Trust Discovery via API, Script, and CLI Enumeration, with one Windows analytic, AN0016: use of nltest, PowerShell or Win32 and .NET APIs to enumerate trusts, followed by further discovery or authentication staging. Its log sources are below.

Turning noise into a signal

Trust reads are not rare on their own. Domain-joined clients, identity synchronisation agents, monitoring tools and administrators all query them. Build the rule around context:

1. Where it ran: trust enumeration from a user workstation or a server that is not a management host is a stronger signal than from a privileged access workstation.
2. What started it: a parent of cmd.exe or powershell.exe that itself descends from an Office application, a browser, wscript.exe, rundll32.exe or an unsigned binary in a user-writable path.
3. What surrounds it: ATT&CK's analytic stresses the follow-on step. Combine trust discovery with domain account and group discovery (T1087.002, T1069.002) or remote system discovery (T1018) from the same host within a short window.
4. Who ran it: a first-seen account running directory discovery, or a service account doing so interactively.

Microsoft documents that Event ID 4662 is logged under Audit Directory Service Access only when a SACL on the object matches the operation, records the object's distinguished name and class GUID, and can be filtered by object type. Adding a read-audit SACL on the trustedDomain objects under CN=System gives a directory-side record that does not depend on endpoint coverage; keep the SACL narrow, because domain members read these objects routinely. See the Active Directory Security Monitoring and Event IDs Guide for audit policy and the T1087 and T1069 Account and Permission Group Discovery Defensive Guide for the neighbouring discovery steps.

Deception

Decoy objects work well against discovery. A decoy account or computer that appears in trust and domain enumeration output, and that no legitimate process ever authenticates as, gives a high-confidence alert when an adversary tries to use what they found. See Decoy accounts in Active Directory.

Mitigations

Trust discovery itself cannot be blocked without breaking Windows, because clients legitimately need trust information. The practical goal is that what the adversary discovers is small and well defended: fewer trusts, selective authentication on the ones that remain, and SID filtering left on, all covered in the Active Directory Trusts and SID Filtering Guide. See also M1047 Audit and M1030 Network Segmentation.

Where identity fits

Trusts are an identity boundary, and the accounts that cross them are often non-human. Cross-forest service accounts, synchronisation agents and migration tooling accounts are the identities an adversary looks for once they know a trust exists. Three practical steps:

• Baseline the legitimate readers: identity synchronisation servers, monitoring tools and management hosts that query trusts should be listed so detections can exclude them precisely, by host and account rather than by tool name.
• Inventory cross-trust service accounts: know which accounts from one forest are used on resources in another, and restrict them with selective authentication.
• Treat discovery by a service account as high severity: a service account running interactive enumeration is a sign its credential is being used by a person.

For the attack path view across trusts, see the BloodHound and Active Directory Attack Path Guide.

Rolling out detection

1. Confirm telemetry: Sysmon Event IDs 1, 7 and 10 or EDR process telemetry with command lines on all Windows endpoints, and PowerShell script block logging enabled.
2. Write the base rule in audit: trust enumeration by process name and arguments, and by PowerShell content, logged without alerting for two to four weeks.
3. Baseline: record which hosts, accounts and parents produce it legitimately and turn them into precise exclusions.
4. Add context scoring: raise severity for workstation origin, suspicious parents, first-seen accounts and co-occurring discovery.
5. Add the directory-side source: a narrow 4662 SACL on trustedDomain objects, piloted on one DC to measure volume first.
6. Rollback: rules and SACLs are reversible; keep the pre-change SACL export and rule version so either can be restored in minutes.

How to test

• Endpoint path: from a test workstation with an authorised test account, run a trust listing with the built-in tool and confirm the process event, command line and parent reach the SIEM and score correctly.
• PowerShell path: run a trust query through PowerShell and confirm the script block log is collected.
• Directory path: confirm 4662 records the read on the trustedDomain object from the pilot DC.
• Exclusion check: confirm the identity synchronisation host's routine reads do not alert, and that the same command from a workstation does.

Measuring it

• Coverage: percentage of Windows endpoints sending process creation with command line and PowerShell script block logs.
• Precision: share of trust discovery alerts confirmed as malicious or unauthorised testing, tracked monthly.
• Trust register health: number of trusts with no named owner or past their end date (target zero).
• Time to contain: median time from a trust discovery alert on a workstation to host isolation.
• Emulation pass rate: percentage of purple-team trust discovery tests detected.

Common failure patterns

• Excluding the tool, not the context: whitelisting nltest because administrators use it removes the most common adversary route.
• No command lines: process creation without command line logging cannot tell a trust query from any other nltest use.
• PowerShell logging off: trust discovery through PowerShell or .NET leaves no process signal at all.
• Alerting in isolation: a single trust read without the surrounding discovery and parent context is too noisy and gets tuned out.
• Forgotten trusts: trusts from old projects that nobody owns make the discovery more valuable and are rarely monitored.

Framework mapping

Practitioner checklist

• Collect process creation with command lines and PowerShell script block logs on every Windows endpoint.
• Detect trust enumeration by nltest, dsquery, AdFind and PowerShell, scored by host, parent and account context.
• Correlate trust discovery with account, group and remote system discovery from the same host.
• Pilot a narrow 4662 SACL on trustedDomain objects for a directory-side record.
• List legitimate trust readers by host and account and exclude only those.
• Keep a trust register with owner and end date, and remove orphaned trusts.
• Restrict network paths to other forests' domain controllers to the hosts that need them.
• Seed decoy objects that appear in enumeration and alert on any use.

Standards and references

• MITRE ATT&CK: T1482 Domain Trust Discovery
• MITRE ATT&CK: S0359 Nltest
• Microsoft Learn: Event 4662, an operation was performed on an object
• Microsoft Learn: Get-ADTrust
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: ATT&CK Discovery Tactic (TA0007) Guide · Active Directory Trusts and SID Filtering Guide · Active Directory Security Monitoring and Event IDs Guide · BloodHound and Active Directory Attack Path Guide · T1018 Remote System Discovery