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.

#9

Overall rank

13%

Organizations affected

784

Confirmed threats

Analysis

Domain Trust Discovery was only added to ATT&CK in 2019. We retroactively re-mapped two discovery techniques, which collectively ranked 30th in 2018, to T1482 while creating this report.

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 DsEnumerateDomainTrusts API calls, LDAP queries for (objectClass=trustedDomain) when enumerating domain trusts, and the .NET method Forest.GetAllTrustRelationships() when enumerating forest trusts.
  • PoshC2 uses Forest.GetAllTrustRelationships() from the System.DirectoryServices assembly 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

Getting Started With Atomic Red Team

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_trusts
Useful telemetry will include:
Data sourceTelemetry
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.

Thomas Gardner
Detection Engineer
The detection strategies in this section were brought to you by Thomas Gardner! At Red Canary, he splits his time investigating threats to customers and developing new methods of finding them. Previously, Thomas worked at CenturyLink in various roles spanning incident response, threat hunting, and threat intelligence.
The detection strategies in this section were brought to you by Thomas Gardner! At Red Canary, he splits his time investigating threats to customers and developing new methods of finding them. Previously, Thomas worked at CenturyLink in various roles spanning incident response, threat hunting, and threat intelligence.