Detecting T1482 Domain trust discovery

How T1482 domain trust discovery shows up in your Windows estate

T1482 Domain Trust Discovery is an intruder enumerating the trust relationships between Active Directory domains in your Windows estate, so they can decide which domains are reachable from the one they already control. MITRE ATT&CK files this under the Discovery tactic, TA0007, whose stated purpose is that the adversary is trying to figure out your environment. For a SOC lead, the practical question is whether your telemetry would show someone mapping those trusts, and whether anyone would act on it. The activity usually appears early in an intrusion, after an attacker has a foothold on a domain-joined host and before any movement into another domain.

Trust mapping matters because it turns a single compromised domain into a plan. An attacker who learns which domains trust each other, in which direction, and whether trusts are transitive can judge where a stolen credential or an inherited privilege might work next. That is why trust discovery sits upstream of lateral movement and privilege escalation in many intrusions. Your environment may contain forest and external trusts that were created for mergers, vendors or legacy applications, and those are often the trusts nobody has reviewed recently. Confirm with your Active Directory administrators which trusts exist, their direction and their purpose, so that any unexpected enumeration can be compared against a known baseline.

The detection work starts from logs you may already collect. Windows process creation events, command execution records and process access events from endpoints and domain controllers are the telemetry most often referenced for this technique, and they let you see which processes and accounts ran directory queries against trust objects. Ask your team whether command line auditing is enabled on the hosts that administrators and servers use, because without it the same activity looks like ordinary administration. Document which accounts are expected to query trusts, so an alert on an unusual account or host has a clear comparison point.

Which telemetry reveals domain trust discovery and which open-source tool collects it

This table maps each data component that ATT&CK references for T1482 to the signal it gives on Windows, the collector that feeds it, and its role in the detection. Read the rows as layers: process and command evidence usually comes first, while process access and secondary sources help confirm context and reduce false positives. The main takeaway is that the detection depends on collecting these sources centrally before any rule is tuned.

Data component	Signal on Windows	Open-source collector	Role in detection
Process Creation (DC0032)	Records the launch of trust-related enumeration utilities and their parent process, including the account context	Sysmon process creation events forwarded through Windows event forwarding to Wazuh or Security Onion	Primary source for first-pass alerts; confirm the event IDs and fields your collector actually emits
Command Execution (DC0064)	Captures command line arguments used to query domain trust relationships	Sysmon command line capture, PowerShell script block logging and Windows event forwarding into Wazuh or Security Onion	Primary source for intent; command line content is often the strongest differentiator but can be disabled or truncated, so verify coverage
Process Access (DC0035)	Shows one process opening another, which can reveal tooling that reads directory or trust data from memory or a service	Sysmon process access events forwarded to Security Onion or Wazuh, filtered to relevant target processes	Secondary source; volume is high, so scope it to sensitive processes and tune against administrative tooling
File Access (DC0055)	Reveals reads or writes to files that hold trust or domain configuration exports	Windows object access auditing forwarded to Wazuh or Security Onion, limited to chosen paths	Secondary source for context; requires deliberate audit policy and path selection to be useful
OS API Execution (DC0021)	Shows calls to directory or trust-related Windows APIs by a process	Endpoint telemetry from an EDR or instrumentation that the organization already runs, forwarded to the SIEM	Secondary source; open-source coverage depends on the collector chosen, so confirm what your stack can see
ATT&CK version	Detection strategies and analytics replaced detections in technique pages from v18 onward	Mapping documents in the SIEM rule repository, stored with the targeted version	Name the targeted version in every mapping, for example v20, because releases can rename or deprecate content

Detection ideas for domain trust discovery that SOC teams can tune

T1482 Domain Trust Discovery is hard to separate from routine directory administration, so no single signal is enough. The four cards below combine process creation, command execution context, process access against directory-related processes, and identity correlation, and each one is meant to be tuned against the baseline of your own domain controllers and admin hosts.

Trust enumeration process creation logic

Alert on process creation events on Windows hosts where a trust-enumeration utility runs, particularly when it is launched by a parent process that is not a known administrative console or management agent. Start with a short allowlist of approved parents and a per-host count of trust-enumeration launches within a rolling window. Tune the window and count to what your administrators actually do; a domain controller running a scheduled health check will look different from a workstation. Review the parent process lineage first, because lineage often separates an analyst from a script that has been dropped in a user profile. Watch for trust queries from hosts that have no reason to query trusts.

Command execution context checks

Command execution telemetry adds the arguments and working context that process creation alone does not show. Check whether trust-related queries are issued from interactive sessions, from remote management sessions, or from service accounts that normally run only scheduled jobs. Compare the execution time against change windows and the user's usual working hours. Expect false positives from inventory scripts, backup agents and migration tooling that enumerate trusts on a schedule; record their accounts and hosts in a suppression list with an owner and a review date rather than suppressing by pattern alone.

Process access against directory processes

Process access telemetry on domain controllers and directory-facing servers can show a process reading the memory or handles of directory service processes while it gathers trust information. Scope the rule to the directory service processes on your own build and to access rights that your monitoring tool can reliably report. Establish a baseline of which security products, backup agents and monitoring agents legitimately open these processes, and alert on any access source outside that list. Confirm the exact access fields your collection agent produces before writing the rule, because the fields differ across agent versions and vendors.

Correlating account and host activity

A single trust query is weak evidence, but a trust query followed by other discovery activity from the same account and host is a stronger pattern. Correlate T1482 signals with logon session creation, account enumeration and remote system discovery on the same host within a time window you set from your own baseline. Record which accounts are expected to perform domain reconnaissance, such as identity engineers and tier-zero administrators, and route their alerts to a different queue. Ask your SOC to confirm how identity context is joined in the SIEM, because account names, domain prefixes and host names are often inconsistent across log sources.

Tuning thresholds and false positives

Tuning is a repeated process, not a one-time setting. Begin in detection-only mode, measure how often each rule fires for each host group over several weeks, and set thresholds per group rather than globally. Common false positive sources include directory inventory scripts, scheduled compliance scans, migration and trust-creation projects, and new monitoring agents. Document each suppression with the owner, the reason and the expiry date, and review the list after every change to the domain. ATT&CK mappings change between versions, so record the ATT&CK version your rules target, for example v20, when you review them.

How to validate that the detection fires before you trust it

This sequence proves that a T1482 Domain Trust Discovery detection receives the right telemetry, fires on an approved emulation, and produces evidence an auditor can review. It turns a rule that looks correct on paper into one whose behavior the team has measured.

Agree emulation scope with the system owner
Before any emulation runs, the detection engineer, the owner of the Windows domain or lab forest, and the cyber range lead agree in writing which hosts, accounts and time window are in scope, who can stop the exercise, and where the logs will be kept. The system owner signs off on the scope document. The step is complete when the signed scope is stored with the detection record and the range team confirms that the emulation account and target hosts are isolated from production trust relationships.
Select an approved emulation plan mapped to T1482
The team chooses an emulation plan that is documented, reviewed and explicitly mapped to T1482 Domain Trust Discovery in the ATT&CK version the detection targets. The plan should state the expected observable behavior on the endpoint, such as which Process Creation and Command Execution events and which process access events should appear, so the result can be judged against a written expectation rather than a memory of the test. Confirm the ATT&CK version in the plan header against the version recorded in the detection metadata. The step closes when the plan is approved by the detection owner and the expected telemetry list is attached to the test ticket.
Confirm telemetry reaches the SIEM
Before judging the rule, the team checks that the source events arrive. On Windows, this means confirming that process creation auditing and command line capture are enabled on the test hosts, that the Wazuh agent or log forwarder is shipping the relevant channels, and that the events are indexed in the SIEM with the expected timestamps and host names. Ingestion delay is measured from the emulation timestamp to the first indexed event. If required events are missing, the step fails and the gap goes to the owner of the logging configuration, not into the rule. The step closes when a record of event presence and indexing time is saved for each test host.
Check the rule fires with the expected fields
The detection engineer runs the emulation and checks that the Sigma-derived or native SIEM rule produces an alert whose fields match the plan, including host, user context, process and command line values, and the ATT&CK technique and data component tags. An alert that fires for the wrong reason, or that fires with empty fields, is a failed test even if it looks like a hit. Results are compared against the expected telemetry list from the earlier step. The step closes when each expected field is confirmed in the alert record, with any mismatch logged as a defect against the rule.
Measure time to alert and false positive rate
The team records how long the path takes from emulation to alert, using the event timestamp and the alert creation timestamp, and reviews benign administrative activity in the same window to estimate the false positive rate. Benign activity should be drawn from the same environment, such as scheduled inventory or administrator sessions that legitimately query domain trusts. Both measurements are compared with the tolerance the SOC has agreed for this rule. The step closes when the figures and the sample size behind them are written into the validation record, with the period reviewed and the reviewer named.
Record evidence for audit and tuning
The validation record is stored in a location the audit and compliance team can access, and it holds the scope agreement, the emulation plan version, the telemetry check, the alert samples, the timing and false positive figures, and the reviewer sign-off. Each record names the detection version and the ATT&CK version it targets so later changes can be traced. Findings lead to tuning tickets, and the rule is retested after any change. Confirm with your auditor which evidence format they accept. The step is complete when the record is versioned and linked to the detection in the rule repository.

Mitigations that limit where trust information can be queried

Domain trust discovery depends on which hosts can reach directory services and whether those queries are logged. The two ATT&CK mitigations below address those conditions directly, and each card names a check to run in your own environment. Confirm fit with your directory architecture before changing any policy.

Restrict directory service reachability

Network Segmentation (M1030) limits which hosts can open connections to domain controllers and other directory endpoints. For T1482, the question is which workstation subnets, server zones and management networks can reach domain controllers over the ports used for trust queries. Map those paths, then confirm that user workstations and non-administrative server segments cannot query directory services across zones they have no business reason to reach. Document exceptions, such as backup or monitoring hosts, with owners and review dates.

Generate the telemetry detection needs

Audit (M1047) covers the audit policy that produces the events detection depends on. For T1482 on Windows, confirm that process creation auditing is enabled with command line capture, and that directory service access auditing is configured for the domain controllers. Without these settings, Process Creation and Command Execution data components may have gaps that no analytic can close. Check the policy on a sample of domain controllers and member servers, not only on the reference build.

Forward audit data off the host

Audit settings only help if the events leave the source system. Confirm that domain controller and endpoint logs are forwarded to a collector such as Wazuh or a Security Onion sensor, and that forwarding survives a reboot or a stopped agent. Test whether an alert fires when a log source goes silent, since a missing trust query is only visible if the absence of data is itself monitored.

Scope administrator tooling access

Discovery of trust relationships often runs from administrative tooling on hosts that are otherwise trusted. Review which management workstations and jump hosts can reach domain controllers, and whether their use is logged. Segmenting these hosts into a dedicated administrative zone makes unusual trust queries stand out, because legitimate use comes from a small, known set of sources.

Confirm other mitigations apply

Segmentation and audit are not the full set of mitigations for this technique. Review the ATT&CK technique page for T1482 in the version you target, and check whether account-level controls or other mitigations fit your environment. Confirm each applicable mitigation with your directory and security teams, and record which ATT&CK version your mapping uses, since releases can rename or revise mitigation links.

Triage and response when a domain trust discovery alert fires

The first decision on a domain trust discovery alert is whether the activity came from a person or process with a legitimate reason to map trust relationships. Start by confirming the source host and the account that ran the enumeration: the host name, its asset owner, whether it is a domain controller, an administrative workstation or an ordinary endpoint, and whether the account is a named administrator, a service account or a standard user. An enumeration of trusts from a general-purpose workstation under a standard user account is a much stronger signal than the same activity from a managed admin jump host. Pull the process lineage and the logon session for the alert window so the reviewer can see what launched the activity and from where.

Next, test the activity against authorized work. Check the change calendar, the privileged access request record and any ticket that covers the account or host for the alert window. Ask the owning team to confirm in writing whether they ran trust discovery, and record who answered and when. Then widen the view: correlate the alert with other Discovery events from the same host or account, such as group membership enumeration, account listing, or network share and remote system discovery, along with authentication events for that account over the preceding hours. A sequence of several discovery steps followed by unusual logons or failed authentications against other domains is the pattern that justifies containment. Confirm the exact detection strategy and analytic you are running against the ATT&CK version your rules target, because the analytic wording and data component mapping may differ between releases.

Containment should be proportionate to what is confirmed. If the activity is unexplained, isolate the source host from the network while keeping it powered on, and ask the identity team to restrict or temporarily disable the account pending review. Before changing anything, preserve evidence: export the relevant Windows event logs, collect the process and command execution records from your telemetry platform, and hash and retain any collected artifacts under your chain of custody procedure. Escalate to the identity and domain administrators, who should review trust configuration changes and recent authentication across trusted domains, and notify the incident commander if the account is privileged. Finally, document the decision in the incident record: the alert, the evidence reviewed, who was consulted, the containment action and the reasoning, so that the outcome can be audited and used to tune the rule.

How to rehearse domain trust discovery detection in a private cyber range

A useful range for T1482 starts with a segmented Windows Active Directory environment that resembles the client's own estate in structure, though not necessarily in scale. Include at least two domains joined by a trust, a management segment for administrators, and a workstation segment that sits behind a boundary you can monitor. Forward Windows Security and Sysmon telemetry from every domain controller and administrative host to a central collector, such as a Wazuh manager or a Security Onion deployment, so that process creation and command execution events are searchable before the exercise begins. Confirm that the collector keeps these events long enough for the review window, and that time synchronization is consistent across hosts so timelines line up.

Segmentation first: Place domain controllers, administrative workstations and user segments in separate zones with logged flows between them.
Telemetry proof: Run a benign process on each segment and confirm the event appears in the collector with the expected fields.
Baseline capture: Record normal administrative activity for a fixed period so the blue team has a realistic noise floor to tune against.
Access control: Keep the range isolated from production, with named operators and a documented reset procedure.
Vendor confirmation: Confirm with your platform team which Windows audit subcategories and Sysmon configuration are enabled, since default settings often miss trust-related activity.

Before the first inject, check that every host in scope reports to the collector and that the blue team can answer a basic question about each segment within minutes.

How to keep T1482 mappings current across ATT&CK releases

Every detection rule for T1482 Domain trust discovery should name the ATT&CK version it targets, and that version should appear in the rule's metadata, the Wazuh or Sigma rule description and the change record that introduced it. ATT&CK releases can rename, deprecate or revoke techniques and sub-techniques, and the most recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. A mapping that tags a rule as T1482 without a version can silently drift out of alignment with the knowledge base, so the security engineering team should decide which version is the reference for the current rule set and record that decision once.

At each ATT&CK release, the detection owner should check whether the technique ID, its name, its tactic list and its data component references still match what the rule claims to cover. The authoritative source is the Enterprise STIX 2.1 bundle published in the attack-stix-data repository, which MITRE publishes per domain and version, so reviewers can query the technique object and its relationships directly rather than relying on a summary. The MITRE ATT&CK updates page lists what changed in each release, and it is the natural starting point for deciding which T1482 mappings need review. Confirm the exact release notes for any version before acting on them, since this page does not restate their contents.

Keep the review itself short and recorded: note the version compared, the date, the rules touched and any analytic or data component changes that affect telemetry already collected for Windows domain trust queries. Ask whether the chosen SIEM or rule converter can carry ATT&CK version metadata, and whether a change in a detection strategy requires new logging, such as additional Process Creation fields or Command Execution capture, before the rule is trusted again. Agree in advance who signs off a mapping change and where the evidence is stored, because auditors and internal reviewers will ask how the detection coverage was kept accurate over time.

Questions SOC leads and detection engineers ask about T1482

What is the minimum telemetry needed to detect T1482 on Windows?

At minimum, collect Process Creation events with the full command line and parent process fields, plus Command Execution logging from the hosts where administrators and servers run enumeration tools. Process Access adds value because it can show one process reading state from another, which helps when activity hides inside a legitimate binary. Map each source to the data components ATT&CK lists for this technique, then confirm which ones your endpoint platform actually records. Without command line capture, a rule can only see that a binary ran, not what it was asked to query, and most trust enumeration then looks like routine administration. Forward domain controller and member server logs to the same SIEM so events can be correlated by host and time. Confirm sensor coverage on every domain controller and jump host first, because those are where high-value trust queries usually occur.

How do you separate trust enumeration from authorized admin tooling?

Separate them by context, because administrators use the same utilities an intruder would use, so the tool name alone is a weak signal. Build an allowlist of accounts, source hosts and change windows that legitimately query domain trusts, such as the identity team's management workstations and scheduled health checks. Treat a trust query from a workstation that normally runs no administrative tooling, by an account with no recent privileged activity, or at an unusual hour as the high-priority case. Enrich each alert with the parent process, the logon session and the host's role in your asset inventory. Review the allowlist on a fixed schedule and require a ticket reference for every exception, so the exclusions do not quietly grow until they hide the signal. Record the rationale in the rule metadata so auditors can follow the logic.

How can you test T1482 detections without disrupting production?

Rehearse the detection in a private cyber range that mirrors your domain layout, using a lab forest and trust relationships that exist only for testing, so no production domain controller is touched. Use the ATT&CK technique page as the reference for the behaviors to simulate, and have a named operator run a controlled set of trust queries from a range workstation while the SOC watches the alerts. Record the exact timestamps, hosts and accounts for each action so every alert can be matched to a known event. For any test that must touch a production-adjacent system, agree the window, the operator and the rollback steps in writing first. Rerun the same scenario after each rule change to catch regressions. DeployOpen runs private cyber ranges and security testing, so this rehearsal can be scoped as a fixed-scope engagement with written rules of engagement.

How do you map a T1482 rule to the ATT&CK version you run?

Record the ATT&CK version and the Enterprise STIX bundle version in the rule metadata so the mapping can be checked later. MITRE publishes ATT&CK content in STIX 2.1 format, with one bundle per domain and version, so you can script a check of your technique and sub-technique IDs against the exact bundle, such as the enterprise-attack 20.0 bundle. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and releases can rename, deprecate or revoke techniques. Since v18 replaced detections with detection strategies and analytics identified by DET IDs, anchor your rule to those IDs and treat the page prose as commentary. Review the mapping each time a new version ships, and confirm that every ID still resolves in the bundle you target.

How do you measure whether a T1482 detection works?

Measure it with range results first and treat raw alert volume as a secondary number. For each rehearsed scenario, record whether an alert fired, how long it took from the action to the alert, and whether the alert carried enough enrichment for an analyst to triage it without extra lookups. Track the false positive rate from production allowlist reviews, because a rule that fires constantly on administrators will be ignored in practice. Agree the target values with the SOC before testing and record them alongside the results, so the trend is meaningful over time. Add a scheduled canary action so a silent rule can be told apart from a broken log source. Store each run's results with the ATT&CK version and rule version it tested.

Which ATT&CK mitigations should support the T1482 detection?

The mitigations this page covers are Network Segmentation (M1030) and Audit (M1047), and each supports detection in a different way. Network Segmentation limits which hosts can reach domain controllers and trust-related services, so an enumeration attempt from an ordinary workstation has fewer paths to succeed and a clearer boundary to alert on. Audit (M1047) means the logging the detection depends on is actually configured, including process creation with command line, consistent time synchronization and forwarding to central storage. Verify both by testing: confirm that a workstation cannot reach directory services it has no business reaching, and confirm that log events arrive within a delay your team has agreed. Ask your internal team or implementation partner to confirm how these mitigations map in the ATT&CK version you target.

Official ATT&CK sources for T1482 detection work

Start every T1482 Domain trust discovery detection from the official MITRE ATT&CK material, not from secondary summaries. The Discovery tactic page (TA0007) is the place to confirm how MITRE frames the goal of this technique: an adversary working out how your environment is connected. Use that page to check the tactic context before you write or review a rule, then move to the technique page for T1482 to confirm its current description, sub-technique status and the detection strategies and analytics MITRE currently attaches to it. Those are the pages your detection owner should cite when a rule is challenged in an audit or a purple team review.

For mappings and data components, the authoritative machine-readable source is the enterprise-attack STIX 2.1 bundle in the attack-stix-data repository. MITRE publishes one bundle per domain and version, so the bundle you query should match the ATT&CK version your detection library targets. Pull the relationship objects for T1482 and check which data components (Process Creation, Command Execution and Process Access are the ones most often referenced for Discovery techniques) and which mitigations (including Network Segmentation and Audit) are linked to it. Record the version number in your detection catalog, and confirm the mapping again whenever MITRE publishes a new release.

Versioning matters for this technique. Recent releases have replaced detections on technique pages with detection strategies and analytics, updated data components and deprecated some data sources. Release notes for each version are listed on the ATT&CK updates pages, and they are the place to check whether a data component your rules depend on has changed. Ask the team that maintains your Wazuh, Sigma or Security Onion content to name the ATT&CK version each rule targets, and to schedule a mapping review after every release so that coverage claims for T1482 stay accurate.

How DeployOpen builds T1482 detections and range scenarios

DeployOpen works on T1482 Domain trust discovery as a fixed-scope engagement inside the client's own environment, with detection logic, range exercises and documentation agreed in writing before work starts. The method follows the same arc for every client: define what is in scope, build and test the detections, hand over the results and keep them current.

How we scope

Confirm which Windows domains, forests and trust relationships are in scope for T1482 monitoring and which are excluded.
Name the Enterprise ATT&CK version the detection mapping targets, since releases can rename or deprecate techniques.
List the telemetry sources available, such as Process Creation, Command Execution and Process Access, and where they are collected.

How we build

Write Sigma-format detection logic for trust enumeration activity and tune it against the client's normal domain administration patterns.
Configure Wazuh or Security Onion collection so the required Windows events reach the analytics layer with known coverage gaps documented.
Map each rule to the ATT&CK detection strategy and data components it relies on, so reviewers can trace every alert to its basis.

How we hand over

Deliver a written detection record covering rule logic, data dependencies, known false positives and the response steps for analysts.
Run a cyber range exercise in a private environment that replays benign and adversary-like trust discovery, and record what the team saw.
Walk the operations and security teams through the mitigations for Network Segmentation and Audit, with evidence for compliance readiness work.

How we support

Review detection performance after the handover and adjust rules when the domain topology or administration model changes.
Re-map detections when a new ATT&CK version changes T1482 or its related detection strategies, and document the change.
Offer ongoing support, upgrades and continuous testing as a retainer, priced from the written scope rather than a published list.

T1482 Domain trust discovery