T1484: Domain or Tenant Policy Modification
Adversaries may modify the configuration settings of a domain or identity tenant to evade defenses and/or escalate privileges in centrally managed environments. Such services provide a centralized means of managing identity resources such as devices and accounts, and often include configuration settings that may apply between domains or tenants such as trust relationships, identity syncing, or identity federation.
Modifications to domain or tenant settings may include altering domain Group Policy Objects (GPOs) in Microsoft Active Directory (AD) or changing trust settings for domains, including federation trusts relationships between domains or tenants.
With sufficient permissions, adversaries can modify domain or tenant policy settings. Since configuration settings for these services apply to a large number of identity resources, there are a great number of potential attacks malicious outcomes that can stem from this abuse. Examples of such abuse include:
* modifying GPOs to push a malicious Scheduled Task to computers throughout the domain environment[1][2][3] * modifying domain trusts to include an adversary-controlled domain, allowing adversaries to forge access tokens that will subsequently be accepted by victim domain resources[4] * changing configuration settings within the AD environment to implement a Rogue Domain Controller. * adding new, adversary-controlled federated identity providers to identity tenants, allowing adversaries to authenticate as any user managed by the victim tenant [5]
Adversaries may temporarily modify domain or tenant policy, carry out a malicious action(s), and then revert the change to remove suspicious indicators.
Analyst context for executives and security teams
Domain or Tenant Policy Modification matters because a single change in Active Directory or an identity provider tenant can affect many users, devices, and applications at once. If an adversary has enough permission to alter GPOs, domain trusts, federation settings, or identity provider configuration, they may be able to weaken defenses, expand access, or make malicious authentication appear legitimate. For leaders, this is an identity control-plane risk, not just an endpoint issue.
Executive priority
Prioritize this as a high-value identity and resilience control area. Executives should ask who can change domain, tenant, GPO, trust, synchronization, and federation settings; whether those changes are logged and reviewed; and whether incident responders can quickly identify and reverse unauthorized changes. This technique is especially relevant to audit evidence, privileged access governance, cloud/identity security, and business continuity because misconfiguration or abuse can propagate broadly across centrally managed environments.
Technical view
SOC, detection engineering, and IR teams should validate monitoring for Windows Active Directory and identity provider administrative changes associated with domain or tenant policy. The ATT&CK object has no official detection text, but the relationship to DET0270 indicates a detection strategy focused on domain or tenant policy modifications via AD and identity provider telemetry. Teams should specifically review coverage for the related sub-techniques: T1484.001 Group Policy Modification and T1484.002 Trust Modification. Investigation should account for temporary changes that may be reverted after a malicious action, so point-in-time configuration snapshots and change history are important.
Likely telemetry
- Active Directory administrative change logs for GPO, domain, and trust configuration changes
- Identity provider administrative audit logs for tenant, federation, trust, and identity provider configuration changes
- Privileged account activity associated with policy, GPO, domain trust, synchronization, or federation administration
- Configuration baselines or snapshots for domain, GPO, trust, and tenant settings
- Change management records to compare approved versus observed administrative changes
Detection direction
- Validate that DET0270-style coverage is implemented for both Active Directory and identity provider administrative changes where applicable.
- Correlate policy or trust modifications with the privileged account, source system, time, approval record, and subsequent authentication or access activity.
- Tune for high-risk changes rather than every routine administrative update: new or modified trusts, federation changes, GPO changes affecting many systems, and additions of federated identity providers are especially important based on the supplied ATT&CK description.
- Account for false positives from legitimate identity administration, migrations, federation updates, and planned GPO maintenance by integrating change-management context.
- Address blind spots where logs are not retained long enough, identity provider audit events are not ingested into the SIEM, or reverted configuration changes are not captured.
Mitigation priorities
- Enforce user account management controls so ordinary accounts cannot modify domain, tenant, GPO, trust, or federation policy settings unless explicitly required.
- Apply privileged account management for all roles that can alter centralized identity or policy configuration, including least privilege, role scoping, accountability, and monitoring.
- Implement and regularly review auditing for domain, tenant, GPO, trust, and federation configuration changes to support detection, compliance evidence, and incident reconstruction.
- Maintain known-good configuration baselines for high-impact identity and policy settings so responders can identify and reverse unauthorized changes.
- Periodically review delegated permissions over GPOs, trusts, federation, synchronization, and identity provider configuration, especially after administrative projects or organizational changes.
Analyst notes and limits
This technique sits under defense impairment and privilege escalation for Windows and Identity Provider platforms. The supplied relationships identify User Account Management, Privileged Account Management, and Audit as relevant mitigations, and identify Group Policy Modification and Trust Modification as sub-techniques. The most important local validation question is whether the organization can reliably prove who changed centralized identity policy, what changed, whether it was authorized, and whether it was later reverted.
The official ATT&CK object does not provide detection guidance, so detection recommendations are derived from the technique description, platforms, tactics, relationship to DET0270, and related mitigations/sub-techniques. Local identity architecture, logging configuration, retention, and change-management maturity determine actual coverage.
Domain or Tenant Policy Modification
Adversaries may modify the configuration settings of a domain or identity tenant to evade defenses and/or escalate privileges in centrally managed environments. Such services provide a centralized means of managing identity resources such as devices and accounts, and often include configuration settings that may apply between domains or tenants such as trust relationships, identity syncing, or identity federation.
Modifications to domain or tenant settings may include altering domain Group Policy Objects (GPOs) in Microsoft Active Directory (AD) or changing trust settings for domains, including federation trusts relationships between domains or tenants.
With sufficient permissions, adversaries can modify domain or tenant policy settings. Since configuration settings for these services apply to a large number of identity resources, there are a great number of potential attacks malicious outcomes that can stem from this abuse. Examples of such abuse include:
* modifying GPOs to push a malicious Scheduled Task to computers throughout the domain environment[1][2][3] * modifying domain trusts to include an adversary-controlled domain, allowing adversaries to forge access tokens that will subsequently be accepted by victim domain resources[4] * changing configuration settings within the AD environment to implement a Rogue Domain Controller. * adding new, adversary-controlled federated identity providers to identity tenants, allowing adversaries to authenticate as any user managed by the victim tenant [5]
Adversaries may temporarily modify domain or tenant policy, carry out a malicious action(s), and then revert the change to remove suspicious indicators.
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1484.002 | Trust Modification Sub-technique | Trust Modification subtechnique of this object. |
| Enterprise | T1484.001 | Group Policy Modification Sub-technique | Group Policy Modification subtechnique of this object. |
All related ATT&CK context
Mitigation direction
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 | 4.0 | Current bundle | 6245d26c8aaf… |
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]
ADSecurity GPO Persistence 2016
Metcalf, S. (2016, March 14). Sneaky Active Directory Persistence #17: Group Policy. Retrieved March 5, 2019.
Open source URL -
[2]
Wald0 Guide to GPOs
Robbins, A. (2018, April 2). A Red Teamer’s Guide to GPOs and OUs. Retrieved March 5, 2019.
Open source URL -
[3]
Harmj0y Abusing GPO Permissions
Schroeder, W. (2016, March 17). Abusing GPO Permissions. Retrieved September 23, 2024.
Open source URL -
[4]
Microsoft - Customer Guidance on Recent Nation-State Cyber Attacks
MSRC. (2020, December 13). Customer Guidance on Recent Nation-State Cyber Attacks. Retrieved December 30, 2020.
Open source URL -
[5]
Okta Cross-Tenant Impersonation 2023
Okta Defensive Cyber Operations. (2023, August 31). Cross-Tenant Impersonation: Prevention and Detection. Retrieved February 15, 2024.
Open source URL -
[6]
mitre-attack T1484Open 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.