Detecting T1484 Domain or tenant policy modification

How T1484 domain or tenant policy modification changes the rules of your environment

T1484 Domain or tenant policy modification is the technique in which an adversary changes policy at the scope of a whole Windows domain or identity provider tenant, so that one edit reaches every account, device or application that inherits it. Adversaries use it to weaken controls, such as audit settings or authentication requirements, or to widen their reach by extending trust to infrastructure they control. Because the change is made through administrative paths the environment already trusts, it can look like routine administration. For a SOC lead, the first question is whether an authorized administrator made that exact change and whether an approved change record supports it.

ATT&CK places T1484 under the *Defense Impairment* tactic (MITRE ATT&CK tactic TA0112), which ATT&CK v19 introduced in April 2026 when it split Defense Evasion into Stealth and Defense Impairment. The technique has two sub-techniques, one covering Group Policy changes in Active Directory and one covering trust settings for a domain or identity provider tenant. Confirm the sub-technique names and IDs against the ATT&CK version your detections target, because releases can rename or restructure them. In a typical intrusion, the actor makes these changes after obtaining highly privileged credentials, often while it is establishing persistence or preparing to move laterally, so the change may sit inside a period of otherwise quiet administrative activity.

Act on this by first deciding which policy objects and tenant settings carry the most weight, such as domain-wide Group Policy objects, domain trust configuration and identity provider conditional access or federation settings. For each one, confirm with your Windows and identity provider administrators which audit settings are enabled, because detection depends on that telemetry existing before an incident. Then plan for two cases: an unauthorized change made by a legitimate privileged account, and an authorized change that was made outside the documented process. Both need a response path, and both point back to whether your privileged account controls and change records can be trusted.

Which telemetry reveals T1484 on Windows and identity providers

This table maps each telemetry source to the T1484 signal it can reveal, the open-source collector that gathers it, and the gap to close before relying on it. Read it as a coverage checklist: a source with no collector in your estate gives you no detection, whatever the mapping says. Confirm data component IDs against the enterprise-attack 20.0 bundle before writing rules.

Telemetry source	Signal to look for	Open-source collector	Common gap
Process Creation (DC0032)	Policy-editing tools or scripts launched by accounts outside the expected admin group, especially on domain controllers	Sysmon-style process logging forwarded by Wazuh agents or Windows event forwarding	Command-line auditing is off, so the policy change shows only as a generic process start
File Modification (DC0061)	Changes to policy files in SYSVOL, such as Group Policy templates and scripts, outside the change window	Wazuh file integrity monitoring on domain controller SYSVOL paths, with events shipped to Security Onion	Monitoring covers one domain controller only, so changes replicated from other controllers go unseen
Application Log Content (DC0062)	Directory service audit events for policy object changes, plus identity provider admin audit entries for tenant policy edits	Windows event forwarding to Wazuh or Security Onion, and identity provider audit logs ingested through their API or log export	Directory service auditing is not enabled for policy object access, so the event is never written
Active Directory Object Modification (DC0066)	Changes to policy objects, trust settings or domain-level attributes, with the acting account and the before and after values	Directory replication and object change events collected by Wazuh agents on domain controllers	Object-level auditing is applied to few containers, and the logs roll over before review
Identity provider audit logs	Tenant-level policy edits such as conditional access, password rules or federation settings, made by unexpected administrators	Connector or export feed into Wazuh or Security Onion, with alerts keyed to the policy change event names	Logs are retained in the vendor portal only, and no feed exists for the tenant's admin roles
Baseline of approved policy changes	A reference list of expected change windows and approved administrators, used to tag alerts as expected or unexpected	Change records exported from the ticketing system into the SIEM as a lookup table	The baseline is never updated after staff changes, so every legitimate edit looks suspicious
ATT&CK version and bundle check	Data component and mitigation IDs in your rules match the ATT&CK v20 targeting for this page	Scripted check against the enterprise-attack 20.0 STIX bundle from the attack-stix-data repository	Rules were written against an older version, and IDs were renamed or deprecated without notice

Detection logic for domain and tenant policy changes

Domain and tenant policy changes are rarely malicious on their own, so detection depends on context: who made the change, when, from where, and what changed around it. The four ideas below combine timing, actor, sequence and source, and each one needs thresholds and an approved-change baseline set in your own environment before it produces useful alerts.

Policy object changes outside change windows

Flag creation, modification or linking of Group Policy objects and identity provider policy objects whose timestamps fall outside the approved change calendar. On Windows, correlate directory object modification events on policy containers with your change tickets for the same window. Start with a tolerance of a few minutes around each approved window and tune it after two weeks of baseline data. The main risk is a policy edit made during a quiet period, when fewer people are watching alerts. Confirm with your change management owner which systems are covered by the calendar before you rely on this logic.

Policy changes by non-administrative accounts

Alert when a policy object change is made by an account that is not in your approved policy administrator group, or by a service account that has no documented role in policy management. Compare the acting account against the privileged account inventory maintained under the Privileged Account Management mitigation. Expect false positives from delegated OU administrators and from directory synchronization accounts, so add them to an explicit allowlist with an owner and review date. Keep the allowlist short, because every entry is a path a changed policy can take without review.

Reduced logging after policy edits

Build a sequence rule that fires when a policy change is followed within a short window by a change to audit policy, log retention, or a security setting on the same host or tenant. Typical sources are file modification and application log content for the policy engine, and process creation for audit configuration tools. Set the window from your own change cadence, starting with minutes rather than hours, and test it against approved changes that touch auditing. Approved audit policy updates and configuration management runs are the main sources of false positives, so match on the pipeline identity and the change ticket reference.

Tenant policy edits from unusual sources

For identity provider tenant policy, alert on administrative edits to conditional access, authentication methods or trusted location settings that originate from an unfamiliar IP range, an unmanaged device, or a session without the expected multi-factor step. Baseline the normal source networks for administrators and build an exclusion list for known management hosts. Scheduled tenant reviews and infrastructure-as-code deployments will appear as edits from automation sources, so tag them separately and require their pipeline identity in the rule. Confirm with your identity provider which audit events expose source address and device state in your plan.

Policy changes from configuration pipelines

Treat policy changes pushed by configuration management or infrastructure-as-code runs as a separate class. Require each approved pipeline run to carry a commit or change reference, then alert on any policy modification whose identity or reference does not match a recent merged change. Review the pipeline service account permissions, because a compromised pipeline can make policy changes that look routine. Expect false positives during manual hotfixes that bypass the pipeline, so route those to a fast review queue rather than suppressing them.

How to baseline policy change activity before alerting

Before any T1484 Domain or tenant policy modification alert goes live, build a written inventory of every legitimate source that changes Group Policy Objects, domain trusts, federation settings or tenant-wide authentication and conditional access policies. Start with the change management system, because each approved change should map to a ticket, an owner and a time window that your detection can join against. Then list the automation service accounts used by configuration management, deployment pipelines and identity lifecycle tools, along with the hosts they run from. Finally, record the administrator groups allowed to make these changes, such as Domain Admins, Enterprise Admins or the equivalent tenant roles, and confirm with each group owner which of them still need write access to policy objects. Expect the first inventory to be incomplete. Review it against a sample of the last several months of directory audit events and treat every unexplained actor as an open question, not a finding.

Once the inventory exists, decide how policy events reach people. Not every change deserves the same response, so route events into tiers. A change that matches an approved ticket, a known automation account and an expected host can go to a low-priority log review queue. A change by a privileged human account outside a change window, or a change to a domain trust, federation relationship or authentication policy, should go to an analyst queue with a short response target that you set and document yourself. Reserve the top tier for changes that touch tenant-wide authentication or domain-wide enforcement and have no matching ticket. Tune suppression rules deliberately, record who approved each one, and review them at a fixed interval so that exclusions do not quietly widen. Illustrative example: a scheduled GPO refresh from a named automation account is suppressed, but the same account making the change from an unfamiliar workstation is not.

Revisit the baseline whenever you adopt a new ATT&CK version, because mappings and detection guidance can change between releases. Targeting a specific version is essential here: the pages in this series use Enterprise ATT&CK 20.0, and MITRE's update notes record that v18 and v19 changed detection content and introduced the Defense Impairment tactic (TA0112). Compare your detection rules against the technique and sub-technique entries in the version you target, and check whether any sub-technique identifiers, detection strategies or data component references have changed. Confirm each release date and content change against MITRE's ATT&CK updates page rather than relying on secondary summaries. Record which version each rule was tuned against, so an analyst can tell whether a gap is a coverage problem or a mapping change.

How to validate a T1484 detection in a lab before trusting it

This sequence proves that a T1484 detection sees a controlled policy change, raises the right alert and reaches the right people, and it leaves dated evidence that the detection was tested before anyone relied on it. Run it in an isolated lab domain or test tenant, never in production.

Agree the emulation plan with change owners
The detection engineer, the identity team owning Group Policy or the identity provider tenant, and the SOC lead agree in writing which policy objects or tenant settings will be modified, which lab environment is used, who approves the change window and who is told when the test starts and stops. The plan names the ATT&CK version targeted (for example, the version your detection mapping records) and the expected event types for both the Windows and identity provider paths. It is done when every named owner has signed off and the plan is stored with the detection record.
Prepare an isolated lab domain or test tenant
Build or confirm a lab domain or identity provider test tenant that holds no production users, trusts, federation relationships or synced objects. Confirm that the audit settings you plan to test are enabled in the lab the same way they are in production, because a detection cannot fire on events the platform never records. The output is a short configuration record listing audit policy, log forwarding agents and the time source, so reviewers can see the test conditions.
Run a controlled policy change
The tester makes one pre-agreed, reversible change to a domain or tenant policy that the plan lists, such as a policy object or authentication-related setting in the test environment. The change is logged with its start time, the account used, the exact object changed and the intended end state. The step closes when the change is recorded in the test log and the test environment has been returned to its baseline or the reversion is scheduled and logged.
Confirm the event reaches the SIEM with expected fields
The SIEM analyst searches for the originating event in the platform, for example in Wazuh or the Security Onion stack, and checks that it arrived with the fields the detection depends on, including the actor, the target object, the action, the timestamp and the source host or tenant. Missing or renamed fields are recorded as defects against the log pipeline, not patched silently in the rule. The step is done when each required field is present in a screenshot or exported record for the test run.
Confirm the rule fires and the alert routes correctly
The detection engineer checks that the rule matching the change produced an alert, that the severity matches the agreed plan, and that the alert reached the intended queue, ticketing integration or on-call channel. The tester also confirms that an alert was not generated for a benign change used as a negative control, so noise is measured as well as detection. The step closes with the alert identifier, the routing destination and both the positive and negative test results recorded.
Measure detection latency and record gaps
The team compares the time of the policy change with the time the event was indexed and the time the alert was created and acknowledged, then records each interval. Any gap, such as a fired rule with no ticket, a missing field under certain conditions or an attribution error, is logged with an owner and a remediation item. The output is a gap register attached to the detection, with the measured intervals and the decision on whether the detection is accepted, accepted with conditions or returned for rework.
Retain evidence for audit readiness
The team packages the emulation plan, configuration record, raw event excerpts, alert records, routing evidence, latency measurements, gap register and sign-off into one dated folder linked to the detection identifier and the ATT&CK version. The record is reviewed again whenever the rule, log source or ATT&CK mapping changes. It is complete when an assessor or internal auditor could follow the chain from the planned change to the accepted detection without asking the team to reconstruct it.

Preventive controls that limit T1484 impact

T1484 becomes damaging when an attacker can change domain or tenant policy without anyone noticing. The controls below work in two directions: they make unauthorized policy edits harder to perform, and they make any edit that does happen visible quickly. Review them together, since a restricted editor population without audit coverage still leaves a blind spot.

Restrict who can edit policy

Privileged Account Management (M1026) is the ATT&CK mitigation that limits which accounts can modify domain or tenant policy at all. Start by listing every group and role that can change Group Policy, directory-wide settings, or tenant-level policy objects, then remove standing membership that the business does not need. Use just-in-time elevation or privileged access workflows for the remaining edits, and confirm that break-glass accounts are documented and monitored. Ask your identity team to produce this list as a written inventory.

Separate policy administration from daily use

Policy editors should not use the same accounts for email, browsing, or routine workstation tasks. Dedicated administrative accounts, kept on hardened administrative workstations, reduce the chance that a phished or compromised user session can reach policy objects. Check whether your directory separates tier-0 assets such as domain controllers and identity providers from lower tiers, and whether any service account holds policy edit rights it does not strictly need.

Enable policy change auditing

Audit (M1047) is the mitigation that makes policy edits visible. Turn on auditing for changes to directory objects, Group Policy objects, and tenant configuration settings, so that each modification records who made it, when, and from where. Confirm that these events reach your central log platform, such as a Wazuh or Security Onion deployment, with enough retention to investigate a change that is discovered weeks later. Audit settings that are enabled on one domain controller but not others create gaps that attackers can exploit.

Shorten detection time through audit coverage

Auditing shortens the time between a policy change and a response, which matters because a modified policy often persists long after the initial action. Test whether an alert fires within your target window when a test change is made in a non-production domain or tenant. Measure the gap between the change timestamp and the moment an analyst sees it. Record the results so you can show auditors and leadership how the control performs, not only that it is configured.

Protect audit configuration itself

An attacker who changes policy may also try to change the audit settings that would reveal the change. Restrict who can modify audit policy and log forwarding configuration, and alert on any change to those settings. Keep a baseline of expected audit settings and compare it on a schedule. This control is closely tied to Audit (M1047), because audit coverage that can be silently disabled provides little assurance.

Account for adjacent user account controls

User Account Management (M1018) is commonly mapped to related techniques and is worth reviewing alongside the two primary mitigations. Its relevance to T1484 lies in how accounts are created, disabled, and reviewed, since a dormant or over-provisioned account can be used to edit policy. Confirm with your identity provider documentation which account lifecycle controls are available in your environment, and schedule periodic access reviews for accounts holding policy edit rights.

What to do in the first hour after a policy change alert

The first hour after a domain or tenant policy change alert is about deciding quickly whether the change was authorized, and preserving the evidence needed to answer that question before anything is reverted. Start by matching the alerted change against the change record: the ticket, approver, maintenance window and named engineer. If no approved change explains it, treat the event as a potential T1484 incident and open an incident record immediately. Then identify the account that made the change, the source host or session it came from, and whether that identity was expected to hold policy-editing rights. On Windows, the account and source workstation usually come from the Security log events tied to the Group Policy or directory object change. On a cloud identity provider, use the audit and sign-in records for the same actor and session, and confirm which administrator roles that identity held at the time.

Next, compare the current policy state with your last known good baseline. For Group Policy, this means the GPO version, linked scopes, and the settings in the affected objects, checked against the most recent backup or exported report. For a tenant, compare conditional access policies, authentication methods, federation or trust settings, and directory-wide security defaults against your configuration-as-code or exported baseline. Record the differences exactly as found before changing anything. Then scope the blast radius: check whether the same change replicated to other domain controllers, whether other tenants, subscriptions or organizational units received it, and whether the change touched policy that controls logging, audit subcategories or privileged access. Any change that reduces audit coverage should be treated as a higher priority than a change to user experience settings.

Only after logs and the baseline diff are preserved should you decide on containment. Reasonable first-hour options include suspending the actor's privileged role or session, restricting who can edit the affected policy objects, and pausing further changes through your change freeze process. Rollback is a decision to make with the incident lead, because reverting a policy before the evidence is exported can erase the record of who changed what and when. Export the relevant event logs, policy versions and directory audit records to write-once storage, and note the hash or timestamp of each export. Document every decision, including who authorized the containment step, what was checked, and what remains unknown, in the incident record. Confirm with your internal policy owners and your incident response procedure which steps require sign-off, since those obligations vary by organization.

How to rehearse T1484 detection in a private cyber range

The Windows range should contain test domain controllers, a small set of workstations and a log pipeline built on Wazuh or Security Onion, so that policy changes on the domain are observable from the same place defenders already work. Rehearsals should use a dedicated test forest that is isolated from production networks and from any shared identity services. Injects are described in words: a test operator changes a domain-wide policy setting through a sanctioned administrative path, then a second inject changes the same policy through a path that bypasses the usual change workflow. Expected outcomes are that the directory change appears as an Active Directory Object Modification event, that the originating process is captured under Process Creation, and that any related file changes to policy storage are recorded under File Modification. Good looks like an alert that names the object, the actor and the time, reaches the analyst queue within the agreed triage window, and triggers a documented response step such as reviewing the change ticket and reverting the setting in the test domain. Confirm log forwarding coverage on every domain controller in the range before the first exercise, since a missing source makes the result meaningless.

Injects: one sanctioned change, one out-of-process change and one change made outside business hours.
Telemetry checks: confirm that directory audit settings are enabled on the test domain controllers before the exercise begins.
Expected alerts: a correlated alert that ties the policy object to the process and account that made the change.
Response: analysts record the change, compare it to a ticket and roll back in the test domain.
Good looks like: every inject produces a timestamped record in the pipeline with no unexplained gaps.

Check that each inject produced evidence in the log pipeline before scoring the analyst response.

The identity provider range uses a non-production tenant or a sandbox directory that mirrors the production configuration of conditional access, authentication and tenant-level policy. Its purpose is to test whether tenant policy changes produce audit records that the security team can read, attribute and act on, without relying on the Windows domain telemetry. Injects should be described to the testers in plain language: an administrator changes a tenant-wide authentication requirement, a service principal with delegated rights changes a policy used by a group of applications, and a privileged role assignment is granted and then removed. Expected outcomes are that each change appears in the identity provider audit log with the actor, the target policy and the outcome, and that the log is forwarded into the same analytics platform used for the Windows range. Good looks like a detection that distinguishes a change made by a named administrator from one made by an automation account, and a response runbook that includes checking whether the change was approved and whether any sign-ins occurred under the altered policy. Confirm with the identity provider vendor which audit events cover tenant policy changes, what retention applies to them and whether they are available through an export or streaming option in your plan.

Injects: a tenant-wide policy change, a delegated service principal change and a privileged role grant followed by removal.
Log coverage: verify that the sandbox tenant audit log is exported to the analytics platform and that timestamps align with the Windows range.
Attribution: the detection should separate human administrators from automation accounts.
Response: analysts confirm change approval, review related sign-in events and restore the sandbox policy.
Good looks like: each change is attributed within the triage window and the rollback is documented.

Record any event type the identity provider did not emit, since that gap belongs in the detection backlog.

Questions SOC leads and detection engineers ask about T1484

How does T1484 differ from T1556 modify authentication process?

T1484 covers changes to the policy that governs a domain or cloud tenant, such as Group Policy objects on Windows or trust, federation and tenant-wide configuration in an identity provider. T1556 covers changes to the authentication mechanism itself, such as components that validate credentials or the logic that issues authentication decisions. The two overlap in practice because a policy change can enable an authentication change, so many teams map both to the same identity telemetry. Keep them as separate detection strategies with separate analytics, so an alert states which control plane was altered. Use the ATT&CK technique pages for the authoritative definitions and confirm your mapping against the version you target.

Do Sigma rules cover both Windows and identity provider sources for T1484?

Public Sigma rules exist for both Windows event sources and identity provider audit logs, but coverage differs by platform and by log source, so do not assume parity. Check each rule's logsource block against the sources you actually collect, such as Windows security and directory service auditing, and your identity provider's administrative audit feed. Where a rule has no equivalent for your platform, write a local rule and test it in your range before promoting it. Record which rules you adopted, modified or rejected, because that record is what an auditor or peer reviewer will ask for.

How should teams handle legitimate GPO automation noise?

Start by inventorying every automated process that changes policy, including configuration management, deployment pipelines, backup or compliance tooling and scheduled scripts. Give each one a named service identity, a documented change window and an expected set of modified objects. Then tune detections to alert on deviations from that baseline, such as a known identity changing an object outside its approved scope, or any change from an unrecognized host or account. Avoid suppressing whole event IDs or service accounts, because that removes the signal you need. Review suppressions on a schedule, and have the change owner confirm each exception in writing.

How do we version T1484 detections against ATT&CK v20?

Pin every detection to the ATT&CK version it targets, and record that version in the rule metadata and in your detection register. ATT&CK v20 is the release MITRE published on 2026-10-13, and earlier releases, including v18 on October 28, 2025 and v19 on April 28, 2026, changed tactics, detection content and data components. Between releases, check the MITRE updates page for renamed, deprecated or revoked techniques and sub-techniques. Use the enterprise STIX bundle for the matching version to diff technique and mitigation mappings, and re-validate any detection whose data components changed. Schedule that comparison at each release so mappings do not drift silently.

What logging coverage should we confirm first for T1484?

Confirm that the events that record policy and tenant configuration changes are generated, forwarded and retained before writing any rule. On Windows, that means auditing of directory service object changes and Group Policy object modification, plus process creation with command line logging where your policy allows it. For the identity provider, confirm the administrative audit log is enabled, exported to your SIEM and retained for the period your compliance program requires. Verify time synchronization across sources, because correlation fails when clocks disagree. Finally, test each source with a benign, documented change and confirm it appears in the SIEM with the expected fields.

How do we measure T1484 detection after a cyber range exercise?

Measure detection against the exercise plan, not against the number of alerts. For each scripted policy change in the range, record whether a detection fired, how long it took to reach an analyst, whether the alert contained enough context to act on, and whether the response runbook was followed. Compare results across runs to see whether tuning improved coverage without raising false positives during the legitimate automation you simulated. Track gaps as tickets with owners and retest them in the next exercise. Keep the raw logs and timeline so the results can be reproduced and shown to auditors or leadership.

How DeployOpen builds T1484 detections and range exercises

DeployOpen approaches T1484 Domain or tenant policy modification as a fixed-scope engagement inside the client's own environment, starting from the Windows and identity provider telemetry the client already collects. Each step is written down so the detection, the range exercise and the evidence can be reviewed by the client's own team.

How we scope

Confirm which domains, tenants and identity provider configurations are in scope for T1484 and its two sub-techniques.
Inventory which Process Creation, File Modification and Application Log Content sources reach the SIEM, and where gaps exist.
Agree in writing which ATT&CK version the detection mapping targets, so later releases do not silently change the logic.

How we build

Write detection logic in Sigma and map it to Wazuh or Security Onion rules that run against the client's own log pipeline.
Tune alerts against the client's normal administrative change activity so policy edits by approved operators are documented, not noisy.
Test each analytic against replayed telemetry from a private cyber range before it is promoted to production.

How we hand over

Deliver the detection logic, data source mapping and tuning notes as versioned files in the client's repository.
Document the response runbook for a suspected policy change, including who is notified and which audit records to preserve.
Walk the client's security operations and identity teams through a range exercise so they can repeat it without DeployOpen.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
A retainer can re-validate T1484 analytics when ATT&CK releases change techniques, detection strategies or data components.
Ask any provider to confirm in writing which audit evidence they prepare and which parts an independent auditor must assess.

T1484 Domain or tenant policy modification