Active Directory domain trust object attribute modified

Siemphony@siemphonymediumT1484.002unverified

Matches AN1259's core observable directly: a directory-service object modification (Security 5136) whose ObjectClass is trustedDomain and whose changed attribute is one that defines the trust relationship itself — trustPartner (the far-side domain or tenant), trustDirection and trustType (which way authentication flows and what kind of trust it is), trustAttributes (forest-trust and SID-filtering flags), or msDS-TrustForestTrustInfo (the namespace list a forest trust honours). Creating a new trust or repointing an existing one always rewrites at least one of these five, which is what MITRE's ObjectType and AttributeModified knobs name; the attribute list itself is authored here, not supplied by MITRE beyond the two example names it gives. The brief's other two logsources are deliberately not used: Security 4704 (user right assignment) fires whenever any right is granted to any account, not only SeEnableDelegationPrivilege on a trust-related principal, so folding it in as an OR would turn a trust-object rule into a generic privilege-grant rule and lose the technique-specific signal; and AN1259's process-side evidence (netdom.exe, nltest.exe or a PowerShell trust cmdlet) is the tool that makes the change, not the change itself, and a command-line selection for it would duplicate rather than add to the object-level signal 5136 already carries. MITRE's TimeWindow knob — correlating the trust edit with a nearby logon or certificate modification — is a cross-event join lib/sigma cannot express, so this fires on the object modification alone. Prerequisite: 5136 needs the *Audit Directory Service Changes* subcategory enabled on domain controllers and an auditing SACL covering the Configuration partition's trust objects; neither is on in a default install or in the Microsoft and CIS baselines, so an empty result means blind rather than quiet. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0458, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

SecurityEvent| where ((EventID == 5136 and ObjectClass =~ "trustedDomain") and (AttributeLDAPDisplayName =~ "trustPartner" or AttributeLDAPDisplayName =~ "trustDirection" or AttributeLDAPDisplayName =~ "trustType" or AttributeLDAPDisplayName =~ "trustAttributes" or AttributeLDAPDisplayName =~ "msDS-TrustForestTrustInfo"))

Splunk · SPL

Run this as a search.

index=* ((EventID="5136" AND ObjectClass="trustedDomain") AND (AttributeLDAPDisplayName="trustPartner" OR AttributeLDAPDisplayName="trustDirection" OR AttributeLDAPDisplayName="trustType" OR AttributeLDAPDisplayName="trustAttributes" OR AttributeLDAPDisplayName="msDS-TrustForestTrustInfo"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((event.code == 5136 AND TO_LOWER(ObjectClass) == "trusteddomain") AND (TO_LOWER(AttributeLDAPDisplayName) == "trustpartner" OR TO_LOWER(AttributeLDAPDisplayName) == "trustdirection" OR TO_LOWER(AttributeLDAPDisplayName) == "trusttype" OR TO_LOWER(AttributeLDAPDisplayName) == "trustattributes" OR TO_LOWER(AttributeLDAPDisplayName) == "msds-trustforesttrustinfo"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)^5136$</field>    <field name="ObjectClass" type="pcre2">(?i)^trustedDomain$</field>    <field name="AttributeLDAPDisplayName" type="pcre2">(?i)(^trustPartner$|^trustDirection$|^trustType$|^trustAttributes$|^msDS-TrustForestTrustInfo$)</field>    <description>Active Directory domain trust object attribute modified</description>    <mitre>      <id>T1484.002</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: medium
Category: directory_object_tampering
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 54044358-0fac-49f5-b521-5eb9c9e72670

ATT&CKT1484.002

T1484.002Trust Modification

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessondirectory object tampering

directory object tamperingAI draft — unreviewed

01 · What this rule detects

This rule matches AN1259's core observable directly: a directory-service object modification (Security 5136) whose ObjectClass is trustedDomain and whose changed attribute is one that defines the trust relationship itself. Creating a new AD trust or repointing an existing one always rewrites at least one of five attributes named in MITRE's ObjectType and AttributeModified knobs, so catching any write to those attributes catches the technique at its most direct point — the object, not the tool that edited it.

02 · Telemetry you need

Security 5136 (Directory Service Changes) on domain controllers. This needs the Audit Directory Service Changes subcategory enabled plus an auditing SACL covering the Configuration partition's trust objects — neither is on in a default install or the Microsoft/CIS baselines. An empty result here means blind, not quiet; confirm the audit policy and SACL are actually in place before trusting a silent rule.

03 · How the logic works

selection_object requires EventID: 5136 with ObjectClass: 'trustedDomain'. selection_attribute requires AttributeLDAPDisplayName to be one of five values: trustPartner (the far-side domain or tenant), trustDirection and trustType (which way authentication flows and what kind of trust it is), trustAttributes (forest-trust and SID-filtering flags), or msDS-TrustForestTrustInfo (the namespace list a forest trust honours). The condition is selection_object and selection_attribute — both must match on the same event. Review corrected an overclaim in an earlier draft: all five attribute names are traceable somewhere in the brief (four in AN1259's own description, the fifth two in the AttributeModified knob), so none were actually invented beyond MITRE's text — the description now says the list is assembled from both fields rather than authored past them. Two other logsources in the brief are deliberately skipped. Security 4704 (user right assignment) fires for any right granted to any account, not only SeEnableDelegationPrivilege on a trust-related principal — folding it in as an OR would turn a trust-object rule into a generic privilege-grant rule and lose the technique-specific signal. And AN1259's process-side evidence (netdom.exe, nltest.exe, or a PowerShell trust cmdlet) is the tool that makes the change, not the change itself; a command-line selection for it would duplicate rather than add to the object-level signal 5136 already carries. MITRE's TimeWindow knob — correlating the trust edit with a nearby logon or certificate modification — is a cross-event join this rule cannot express, so it fires on the object modification alone.

04 · Common false positives

Legitimate creation of a new external, forest, or shortcut trust during
Scheduled trust maintenance such as resetting the trust password
Azure AD Connect or AD FS federation tooling provisioning or updating a

05 · Detection maturity

tier_1: Unverified — never executed against real directory-service logs. This is a scaffold at the lowest DeBMM tier; validate against your own AD audit stream, and confirm the SACL prerequisite, before treating any match as signal rather than noise.

Tuning & false positivesexperimental · 3 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Correlate matches with a change-management ticket or a known maintenance window before escalating. If your environment runs scheduled trust-password resets, allowlist the service account that performs them. Track which domain controller emitted the event — trust objects should only change from expected admin workstations.

Declared by the author

Legitimate creation of a new external, forest or shortcut trust by AD administrators during domain consolidation, a merger or acquisition onboarding, or a new federation build-out, which rewrites all five attributes at once on the new trustedDomain object.
Scheduled trust maintenance such as resetting the trust password (netdom trust /resetsecuritypassword) or adjusting SID-filtering and quarantine settings, which rewrites trustAttributes without changing the trust's direction or partner.
Azure AD Connect or AD FS federation configuration tooling that provisions or updates a federation trust object as part of a scheduled sync job or an administrator-run federation setup wizard.

Noise check0 of 6 fired

Fires on none of the 6 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 6 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1484.002, evaluated against their — events.

Share this rule

/u/siemphony/54044358-0fac-49f5-b521-5eb9c9e72670

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Active Directory domain trust object attribute modified

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it