How do you detect a new domain trust being created in Active Directory?

Detect a new domain trust by monitoring directory change activity on the domain objects that represent trust relationships and by reviewing administrative actions that create or modify them. Alert on trust creation outside approved change windows, especially where the new trust expands access across forests or domains. Confirm the business justification and the trust direction before treating it as legitimate.

What counts as a new domain trust in Active Directory?

A new trust is not just a connectivity change, it is an authorization boundary change. In Active Directory, the trust object determines which directory can validate identities across a domain or forest, so creation or modification of that object should be treated as a security-relevant administrative event. The practical question is whether the change was intentional, approved, and scoped as expected.

That matters because trust objects can expand the blast radius of a compromise, even when no passwords change. If a trust is created or altered to allow broader name resolution, authentication, or transitive access, it can change how identities move between directories and how far an attacker can travel after initial access.

Where to monitor for trust creation activity

The most reliable signal is change activity on the directory objects that represent trust relationships, combined with the administrative actions that create or modify them. Watch for object creation and attribute modification events on trust-related directory entries, then correlate those events with directory admin activity, change tickets, and maintenance windows.

For defenders who want a broader Active Directory view, the Active Directory and Entra ID Hardening Guide is useful because trust changes should be interpreted alongside privileged group changes, delegation, and other control-plane events. The same applies to the Federation and Trust Relationships Guide, which covers domain and forest trusts, selective authentication, and trust abuse patterns that help you separate routine administration from dangerous expansion.

In practice, the event stream is only the starting point. A trust object change is more credible when the source host, actor account, and change context align with approved administration. It becomes suspicious when the change originates from an unusual admin workstation, a service account not normally used for directory design, or an account that should not be creating new inter-domain reach.

How to tell a legitimate trust from a suspicious one

Legitimate trust creation should line up with a documented business need, an approved direction of trust, and a known boundary between the two directories. Suspicion increases when the new trust appears outside a change window, connects environments that should remain separate, or introduces cross-forest reach without a clear operational owner.

Trust direction is especially important because one-way and two-way trusts do not have the same exposure profile. A one-way trust can still be dangerous, but a two-way or transitive trust often creates broader identity reach than teams expect. Confirming direction, scope, and any selective authentication settings is the fastest way to decide whether the change is normal or a potential path for lateral movement.

For a practical control perspective, Top 10 Active Directory Security Risks helps place trust changes in the larger set of AD misconfigurations that often widen attack paths. If the trust also changes how privileged users or tier-zero systems can be reached, the Tiered Administration and Enterprise Access Model Guide is the right lens for deciding whether the trust violates your administrative isolation model.

Risk and Threat Considerations

A new trust can quietly enlarge the attack surface by linking identities, authentication paths, and administrative reach between directories. That makes trust creation attractive to attackers who already have administrative access, and it also makes an approved but poorly scoped trust a latent exposure if the other side is later compromised.

Failure mechanism: The trust object is created or modified without equivalent monitoring of its intended scope, so a legitimate administrative change becomes a durable cross-directory access path that defenders do not notice until misuse appears.

Impact: An attacker can use the trust to move between domains or forests, extend identity compromise, or reach additional privileged systems, which increases the cost and complexity of containment.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack surface, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1484.002 — Domain Trust Modification	Trust creation is a directory trust modification that can expand attacker reach.
Recommendation — Monitor trust object changes and hunt for unauthorized cross-domain access expansion.
NIST CSF 2.0	DE.CM-09 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software	Detecting new trusts depends on monitoring unauthorized directory connections and changes.
Recommendation — Alert on unexpected directory trust creation and related administrative changes.
NIST SP 800-53 Rev 5	AU-6 — Audit Review, Analysis, and Reporting	Trust creation is a high-value administrative change that should be reviewed and correlated.
	AC-4 — Information Flow Enforcement	Trusts alter allowed information flow between domains and forests.
Recommendation — Review trust-related audit events and correlate them with approved change records. Restrict and validate inter-domain trust paths to the minimum required scope.
ISO/IEC 27001:2022	A.5.15 — Access control	Trusts directly affect cross-domain access control decisions and boundaries.
Recommendation — Require formal authorization before any new trust boundary is established.

Practitioner Guidance

What to verify: Treat every trust creation event as incomplete until you verify the change ticket, the initiating admin identity, the trust direction, and whether selective authentication or other limiting controls were part of the design. If those details are missing, do not accept the trust as routine.

What to prioritize: Build alerts around trust object creation and modification before you try to over-tune to specific administrator accounts. The most useful detection is often the one that catches the first boundary-expanding change, not the one that tries to infer attacker intent after the fact.

Practitioner takeaway: A new trust is best treated as a change in trust boundary first and an administrative event second, because the security question is not whether the object exists, but whether it legitimately extends reach across directories.