Technique T1482
Domain Trust Discovery
The majority of Domain Trust Discovery activity we observe results from TrickBot using nltest.exe to gather domain trust information from Active Directory for the purpose of lateral movement.
Editors’ note: While the analysis and detection opportunities remain applicable, this page has not been updated since 2020.
Analysis
Why do adversaries use Domain Trust Discovery?
Added in February 2019, Domain Trust Discovery is a relatively new discovery technique in MITRE’s ATT&CK matrix. In Windows environments, trust relationships play a critical role in determining who can access what resources. Domain Trust Discovery more directly relates to the ways that one domain in a given network environment can either inherit trust from—or grant it to—other domains, endpoints, and users in that environment.
In order to determine which user accounts have access to what systems, an adversary has to understand the user accounts that exist within a given domain and the trust relationships between that domain and others. As such, discovering domain trust information is tremendously useful for an adversary or malware that is intent on moving laterally between systems in a compromised environment.
How do adversaries use Domain Trust Discovery?
In our dataset, the prevalence of Domain Trust Discovery is due entirely to TrickBot outbreaks in a relatively small number of customer environments. The detection logic that alerts our detection engineering team to this aspect of TrickBot is designed to trigger when nltest.exe executes with certain command-line options. A couple of those options include:
/domain_trusts/all_trusts
Nltest is a native Microsoft command-line tool that administrators often use to enumerate domain controllers (DC) and determine trust status between domains, to name a few important features.
Outside of TrickBot, several popular post-exploitation frameworks have the ability to perform Domain Trust Discovery, either through Windows APIs or Lightweight Directory Access Protocol (LDAP) queries:
- Empire and PowerSploit use the
DsEnumerateDomainTrustsAPI calls, LDAP queries for(objectClass=trustedDomain)when enumerating domain trusts, and the .NET methodForest.GetAllTrustRelationships()when enumerating forest trusts. - PoshC2 uses Forest.GetAllTrustRelationships() from the
System.DirectoryServicesassembly as well.
Other tools that can enumerate domain trusts are the native Microsoft command-line tool dsquery and Adfind.exe, which has been used by FIN6 and Ryuk before to discover AD users and groups as well.
You can read about some additional methods and explanations of Domain Trust Discovery on Will Schroeder’s blog.
Sighted with
Like many of the other techniques that owe their prominence on this list to TrickBot, this technique is frequently seen in tandem with:
- Scheduled Task (T1053)
- Process Injection (T1055)
- Windows Admin Shares (T1077)
- Disabling Security Tools (T1089)
- Remote File Copy (T1105)
Definition
Detection
MITRE’s data sources
- Azure activity logs
- Office 365 account logs
- API monitoring
- Process monitoring
- Process command-line parameters
Collection requirements
While MITRE does not include it among its data sources, network logs for LDAP queries (typically port 389 over TCP/UDP) are another good collection source for defenders seeking to observe Domain Trust Discovery activity. Security teams seeking to observe malicious instances of Domain Trust Discovery will also want to collect logs relating to process monitoring and process command-line parameters.
Detection suggestions
The analytics that will uncover Domain Trust Discovery attempts are relatively simple, but they vary in feasibility as your environment scales. Most organizations can work to detect nltest.exe with these command lines:
/domain_trusts/all_trusts
In a similar vein to nltest.exe, dsquery.exe can be used to enumerate domain trusts with the following command line:
- dsquery *
-filter "(objectClass=trustedDomain)" -attr*
The ADFind tool can also be used to query domain trusts with the following command lines:
- adfind.exe
-f objectclass=trusteddomain - adfind.exe
-sc trustdmp
If you are able to collect and analyze LDAP queries, you’ll want to scrutinize any that originate from non-DCs with the substring (objectClass=trustedDomain), especially if other suspicious reconnaissance actions are identified.
Weeding out false positives
Looking for generic detection of nltest.exe without specific command-line options will lead you down some high-volume paths. The best route with this technique is to be specific.
Testing
Start testing your defenses against Domain Trust Discovery using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
Getting started
View Atomic tests for T1482: Domain Trust Discovery. In most environments, these should be sufficient to generate a useful signal for defenders.
Run this test on a Windows system using Command Prompt:
nltest /domain_trustsUseful telemetry will include:
| Data source | Telemetry |
|---|---|
| Data source: Process monitoring | Telemetry: nltest.exe |
| Data source: Process command line | Telemetry: “/domain_trusts” |
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.