Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1484.002: Trust Modification

Adversaries may add new domain trusts, modify the properties of existing domain trusts, or otherwise change the configuration of trust relationships between domains and tenants to evade defenses and/or elevate privileges.Trust details, such as whether or not user identities are federated, allow authentication and authorization properties to apply between domains or tenants for the purpose of accessing shared resources.[1] These trust objects may include accounts, credentials, and other authentication material applied to servers, tokens, and domains.

Manipulating these trusts may allow an adversary to escalate privileges and/or evade defenses by modifying settings to add objects which they control. For example, in Microsoft Active Directory (AD) environments, this may be used to forge SAML Tokens without the need to compromise the signing certificate to forge new credentials. Instead, an adversary can manipulate domain trusts to add their own signing certificate. An adversary may also convert an AD domain to a federated domain using Active Directory Federation Services (AD FS), which may enable malicious trust modifications such as altering the claim issuance rules to log in any valid set of credentials as a specified user.[2]

An adversary may also add a new federated identity provider to an identity tenant such as Okta or AWS IAM Identity Center, which may enable the adversary to authenticate as any user of the tenant.[3] This may enable the threat actor to gain broad access into a variety of cloud-based services that leverage the identity tenant. For example, in AWS environments, an adversary that creates a new identity provider for an AWS Organization will be able to federate into all of the AWS Organization member accounts without creating identities for each of the member accounts.[4]

EnterpriseT1484.002Sub-techniqueObject v3.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Trust Modification matters because it targets the rules that let identities move between domains, tenants, and federated providers. If those trust relationships are changed without authorization, an adversary may bypass normal identity boundaries, impersonate users, or gain broader access to cloud and Windows-connected resources. For leaders, this is not just an identity configuration issue; it is a control-plane risk that can affect business continuity, incident containment, and confidence in audit evidence.

Executive priority

Prioritize this as a high-value identity and cloud security governance concern where the organization uses Active Directory, federation, identity providers, or multi-account cloud environments. Executives should ask who can create or modify trusts, who reviews federation and claim-rule changes, whether privileged identity actions are logged centrally, and whether incident response plans include rapid validation of tenant/domain trust integrity. Budget and control decisions should emphasize privileged account management, user account lifecycle discipline, and detection of trust relationship changes.

Technical view

This sub-technique sits under Domain or Tenant Policy Modification and applies to Identity Provider and Windows platforms, with defense-impairment and privilege-escalation relevance. SOC and IR teams should validate visibility into changes to domain trusts, federation settings, identity provider additions, signing certificate or authentication material changes, and claim issuance rule modifications. Relationship context includes DET0458, a detection strategy for trust relationship modifications in domain or tenant policies, and mitigations M1018 User Account Management and M1026 Privileged Account Management. Known ATT&CK relationships also associate this behavior with AADInternals software and with campaign/group usage references, which should inform threat-informed testing without assuming local exposure.

Likely telemetry

  • Identity provider administrative audit logs
  • Windows/Active Directory directory service and domain trust change logs
  • Federation service configuration and claim rule change records
  • Cloud tenant or organization-level identity provider creation and modification events
  • Privileged account activity logs for users or roles able to modify trust relationships

Detection direction

  • Baseline authorized domain, tenant, and federation trust relationships, then alert on additions, removals, or property changes outside approved change windows.
  • Validate whether DET0458-style detection logic is implemented for domain or tenant policy trust modifications across both Windows and identity provider environments.
  • Correlate trust changes with privileged account usage, recent account lifecycle events, and administrative role assignments to separate approved administration from suspicious control-plane changes.
  • Tune for expected identity engineering activity, mergers, tenant migrations, and federation projects, which can generate legitimate trust changes.
  • Check blind spots around cloud identity provider audit retention, decentralized tenant administration, AD FS or federation configuration logging, and logs that are not forwarded to the SOC.

Mitigation priorities

  • Restrict who can create or modify trusts, federation settings, identity providers, claim rules, and related authentication material using least privilege.
  • Apply privileged account management for roles that can alter domain or tenant trust configuration, including monitoring and accountability for administrative actions.
  • Maintain an authoritative inventory of approved trusts, federated domains, identity providers, and claim configurations.
  • Require change approval and post-change validation for trust and federation modifications.
  • Include trust integrity checks in incident response playbooks for suspected identity compromise or cloud control-plane abuse.
Analyst notes and limits

ATT&CK provides no official detection text for this object, but the relationship to DET0458 gives a clear detection direction: monitor trust relationship modifications in domain or tenant policies. The supplied description highlights Active Directory, AD FS, Azure AD federation, Okta, AWS IAM Identity Center, and AWS Organizations as examples from references; local applicability depends on which identity and federation architectures are actually in use.

This take is limited to the supplied ATT&CK STIX fields, references, and relationships. It does not establish active exploitation, customer exposure, or guaranteed detectability. Exact event IDs, provider-specific log names, and response procedures require environment-specific validation.

Official MITRE ATT&CK definition

Trust Modification

Adversaries may add new domain trusts, modify the properties of existing domain trusts, or otherwise change the configuration of trust relationships between domains and tenants to evade defenses and/or elevate privileges.Trust details, such as whether or not user identities are federated, allow authentication and authorization properties to apply between domains or tenants for the purpose of accessing shared resources.[1] These trust objects may include accounts, credentials, and other authentication material applied to servers, tokens, and domains.

Manipulating these trusts may allow an adversary to escalate privileges and/or evade defenses by modifying settings to add objects which they control. For example, in Microsoft Active Directory (AD) environments, this may be used to forge SAML Tokens without the need to compromise the signing certificate to forge new credentials. Instead, an adversary can manipulate domain trusts to add their own signing certificate. An adversary may also convert an AD domain to a federated domain using Active Directory Federation Services (AD FS), which may enable malicious trust modifications such as altering the claim issuance rules to log in any valid set of credentials as a specified user.[2]

An adversary may also add a new federated identity provider to an identity tenant such as Okta or AWS IAM Identity Center, which may enable the adversary to authenticate as any user of the tenant.[3] This may enable the threat actor to gain broad access into a variety of cloud-based services that leverage the identity tenant. For example, in AWS environments, an adversary that creates a new identity provider for an AWS Organization will be able to federate into all of the AWS Organization member accounts without creating identities for each of the member accounts.[4]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1484 Domain or Tenant Policy Modification This object subtechnique of Domain or Tenant Policy Modification.
Associated objects

Groups, software, and campaigns

Group Enterprise

G1015: Scattered Spider

Scattered Spider is a native English-speaking cybercriminal group active since at least 2022. [1] [2] The group initially targeted customer relationship management (CRM) providers, business process outsourcing (BPO) firms, and telecommunications and technology companies before expanding in 2023 to gaming, hospitality, retail, managed service provider (MSP), manufacturing, and financial sectors. [2] Scattered Spider relies heavily on social engineering, including impersonating IT and help-desk staff, to gain initial access, bypass multi-factor authentication (MFA), and compromise enterprise networks. The group has adapted its tooling to evade endpoint detection and response (EDR) defenses and used ransomware for financial gain. [3] [4] [5] Scattered Spider had expanded into hybrid cloud and identity environments, using help-desk impersonation and MFA bypass to obtain administrator access in Okta, AWS, and Office 365. [6]

Group Enterprise

G1053: Storm-0501

Storm-0501 is a financially motivated cyber criminal group that uses commodity and open-source tools to conduct ransomware operations. Storm-0501 has been active since 2021 and has previously been affiliated with Sabbath Ransomware and other Ransomware-as-a-Service (RaaS) variants such as Hive, BlackCat, Hunters International, LockBit 3.0, and Embargo ransomware.[1][2][3][4]

Tool Enterprise

S0677: AADInternals

AADInternals is a PowerShell-based framework for administering, enumerating, and exploiting Azure Active Directory. The tool is publicly available on GitHub.[1][2]

WindowsOffice SuiteIdentity Provider
Campaign Enterprise

C0024: SolarWinds Compromise

The SolarWinds Compromise was a sophisticated supply chain cyber operation conducted by APT29 that was discovered in mid-December 2020. APT29 used customized malware to inject malicious code into the SolarWinds Orion software build process that was later distributed through a normal software update; they also used password spraying, token theft, API abuse, spear phishing, and other supply chain attacks to compromise user accounts and leverage their associated access. Victims of this campaign included government, consulting, technology, telecom, and other organizations in North America, Europe, Asia, and the Middle East. This activity has been labled the StellarParticle campaign in industry reporting.[1] Industry reporting also initially referred to the actors involved in this campaign as UNC2452, NOBELIUM, Dark Halo, and SolarStorm.[2][3][4][5][1][6][7][8]

In April 2021, the US and UK governments attributed the SolarWinds Compromise to Russia's Foreign Intelligence Service (SVR); public statements included citations to APT29, Cozy Bear, and The Dukes.[9][10][11] The US government assessed that of the approximately 18,000 affected public and private sector customers of Solar Winds’ Orion product, a much smaller number were compromised by follow-on APT29 activity on their systems.[12]

Relationship explorer

All related ATT&CK context

uses · Group G1015: Scattered Spider Enterprise mitigates · Mitigation M1026: Privileged Account Management Enterprise subtechnique of · Technique T1484: Domain or Tenant Policy Modification Enterprise uses · Tool S0677: AADInternals Enterprise mitigates · Mitigation M1018: User Account Management Enterprise detects · Detection Strategy DET0458: Detection of Trust Relationship Modifications in Domain or Tenant Policies Enterprise uses · Group G1053: Storm-0501 Enterprise uses · Campaign C0024: SolarWinds Compromise Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1026: Privileged Account Management

Privileged Account Management focuses on implementing policies, controls, and tools to securely manage privileged accounts (e.g., SYSTEM, root, or administrative accounts). This includes restricting access, limiting the scope of permissions, monitoring privileged account usage, and ensuring accountability through logging and auditing.This mitigation can be implemented through the following measures:

Account Permissions and Roles:

- Implement RBAC and least privilege principles to allocate permissions securely. - Use tools like Active Directory Group Policies to enforce access restrictions.

Credential Security:

- Deploy password vaulting tools like CyberArk, HashiCorp Vault, or KeePass for secure storage and rotation of credentials. - Enforce password policies for complexity, uniqueness, and expiration using tools like Microsoft Group Policy Objects (GPO).

Multi-Factor Authentication (MFA):

- Enforce MFA for all privileged accounts using Duo Security, Okta, or Microsoft Azure AD MFA.

Privileged Access Management (PAM):

- Use PAM solutions like CyberArk, BeyondTrust, or Thycotic to manage, monitor, and audit privileged access.

Auditing and Monitoring:

- Integrate activity monitoring into your SIEM (e.g., Splunk or QRadar) to detect and alert on anomalous privileged account usage.

Just-In-Time Access:

- Deploy JIT solutions like Azure Privileged Identity Management (PIM) or configure ephemeral roles in AWS and GCP to grant time-limited elevated permissions.

*Tools for Implementation*

Privileged Access Management (PAM):

- CyberArk, BeyondTrust, Thycotic, HashiCorp Vault.

Credential Management:

- Microsoft LAPS (Local Admin Password Solution), Password Safe, HashiCorp Vault, KeePass.

Multi-Factor Authentication:

- Duo Security, Okta, Microsoft Azure MFA, Google Authenticator.

Linux Privilege Management:

- sudo configuration, SELinux, AppArmor.

Just-In-Time Access:

- Azure Privileged Identity Management (PIM), AWS IAM Roles with session constraints, GCP Identity-Aware Proxy.

Mitigation Enterprise

M1018: User Account Management

User Account Management involves implementing and enforcing policies for the lifecycle of user accounts, including creation, modification, and deactivation. Proper account management reduces the attack surface by limiting unauthorized access, managing account privileges, and ensuring accounts are used according to organizational policies. This mitigation can be implemented through the following measures:

Enforcing the Principle of Least Privilege

- Implementation: Assign users only the minimum permissions required to perform their job functions. Regularly audit accounts to ensure no excess permissions are granted. - Use Case: Reduces the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.

Implementing Strong Password Policies

- Implementation: Enforce password complexity requirements (e.g., length, character types). Require password expiration every 90 days and disallow password reuse. - Use Case: Prevents adversaries from gaining unauthorized access through password guessing or brute force attacks.

Managing Dormant and Orphaned Accounts

- Implementation: Implement automated workflows to disable accounts after a set period of inactivity (e.g., 30 days). Remove orphaned accounts (e.g., accounts without an assigned owner) during regular account audits. - Use Case: Eliminates dormant accounts that could be exploited by attackers.

Account Lockout Policies

- Implementation: Configure account lockout thresholds (e.g., lock accounts after five failed login attempts). Set lockout durations to a minimum of 15 minutes. - Use Case: Mitigates automated attack techniques that rely on repeated login attempts.

Multi-Factor Authentication (MFA) for High-Risk Accounts

- Implementation: Require MFA for all administrative accounts and high-risk users. Use MFA mechanisms like hardware tokens, authenticator apps, or biometrics. - Use Case: Prevents unauthorized access, even if credentials are stolen.

Restricting Interactive Logins

- Implementation: Restrict interactive logins for privileged accounts to specific secure systems or management consoles. Use group policies to enforce logon restrictions. - Use Case: Protects sensitive accounts from misuse or exploitation.

*Tools for Implementation*

Built-in Tools:

- Microsoft Active Directory (AD): Centralized account management and RBAC enforcement. - Group Policy Object (GPO): Enforce password policies, logon restrictions, and account lockout policies.

Identity and Access Management (IAM) Tools:

- Okta: Centralized user provisioning, MFA, and SSO integration. - Microsoft Azure Active Directory: Provides advanced account lifecycle management, role-based access, and conditional access policies.

Privileged Account Management (PAM): - CyberArk, BeyondTrust, Thycotic: Manage and monitor privileged account usage, enforce session recording, and JIT access.

Change history

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 .

ATT&CK release
19.1
Object version
3.0
Created
Modified
Raw hash
59feb84169c141a5...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 3.0 Current bundle 59feb84169c1…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Microsoft - Azure AD Federation

    Microsoft. (2018, November 28). What is federation with Azure AD?. Retrieved December 30, 2020.

    Open source URL
  2. [2]
    AADInternals zure AD Federated Domain

    Dr. Nestori Syynimaa. (2017, November 16). Security vulnerability in Azure AD & Office 365 identity federation. Retrieved September 28, 2022.

    Open source URL
  3. [3]
    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
  4. [4]
    AWS re Inforce Trust Mod

    AWS re Inforce. (2024, June). Retrieved April 15, 2026.

    Open source URL
  5. [5]
    mitre-attack T1484.002
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use