AN0016: Analytic 0016
Adversary uses nltest, PowerShell, or Win32/.NET API to enumerate domain trust relationships (via DSEnumerateDomainTrusts, GetAllTrustRelationships, or LDAP queries), followed by discovery or authentication staging.
Analyst context for executives and security teams
AN0016 describes a Windows-focused detection analytic for attempts to enumerate Active Directory domain trust relationships using tools or APIs such as nltest, PowerShell, Win32/.NET APIs, or LDAP queries. For leaders, this matters because trust discovery can reveal paths between domains that may affect identity risk, incident scope, and resilience of business units connected through AD trust boundaries.
Executive priority
Treat this as an identity security and incident-readiness validation item. Executives and security leaders should ask whether the organization can see domain trust enumeration across Windows environments, whether AD trust relationships are documented and reviewed, and whether SOC/IR teams can use that visibility to assess lateral movement risk during an incident. Because no official detection logic is supplied, priority should be on confirming telemetry coverage and response procedures rather than assuming a specific analytic is already effective.
Technical view
SOC and detection teams should validate visibility into Windows activity associated with domain trust enumeration, including command-line use of nltest, PowerShell-based discovery, LDAP queries, and calls through Win32/.NET APIs where telemetry supports it. Since ATT&CK provides no detection implementation for this analytic and no relationship context, teams should map local logging sources to the described behavior, test benign administrative use cases, and tune detections to distinguish routine domain administration from unusual trust discovery followed by additional discovery or authentication staging.
Likely telemetry
- Windows process creation and command-line telemetry for nltest and PowerShell
- PowerShell logging where enabled, such as script block or module-level evidence relevant to trust discovery
- LDAP query telemetry or directory service logs that can show enumeration of trust relationships
- Endpoint detection telemetry that can surface Win32/.NET API usage or related process behavior
- Active Directory audit data and domain controller logs useful for correlating discovery with subsequent authentication activity
Detection direction
- Confirm whether Windows endpoints and domain controllers collect enough process, PowerShell, LDAP, and directory audit data to observe the behavior described by AN0016.
- Build or validate analytics around domain trust enumeration patterns, then tune against known administrative workflows to reduce false positives.
- Correlate trust enumeration with nearby discovery or authentication staging activity, as described in the official analytic, rather than treating every single query as malicious.
- Review blind spots created by limited PowerShell logging, missing command-line capture, unmanaged Windows hosts, or lack of LDAP visibility on domain controllers.
- Document what the analytic can and cannot prove, since the official ATT&CK object does not provide detection logic or supported relationships.
Mitigation priorities
- Inventory and periodically review Active Directory domain trust relationships so defenders understand expected trust paths before an incident.
- Limit privileged access and administrative tooling use to approved roles and monitored systems where operationally feasible.
- Enable and retain relevant Windows, PowerShell, LDAP, and directory service telemetry needed to investigate trust discovery.
- Create incident response playbooks that treat suspicious trust enumeration as a prompt to assess identity exposure, lateral movement paths, and authentication activity across trusted domains.
- Use the analytic as a validation target for managed detection, identity security reviews, and compliance evidence around monitoring of privileged directory activity.
Analyst notes and limits
This take is based only on the supplied MITRE ATT&CK analytic fields. The object is a detection analytic for Windows and describes domain trust enumeration using nltest, PowerShell, Win32/.NET APIs, or LDAP queries. No tactics, official detection logic, aliases, labels, or relationships were supplied, so local environment telemetry and administrative baselines are required to operationalize it.
The supplied ATT&CK object does not provide detection logic, related techniques, groups, software, mitigations, or confirmed adversary use. Guidance is therefore limited to defensive validation and telemetry planning for the described Windows behavior, not claims of active exploitation, attribution, or guaranteed detection coverage.
Analytic 0016
Adversary uses nltest, PowerShell, or Win32/.NET API to enumerate domain trust relationships (via DSEnumerateDomainTrusts, GetAllTrustRelationships, or LDAP queries), followed by discovery or authentication staging.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 71fd3fbe11fd… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0016Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.