Loading AttackTrace...
Loading AttackTrace...
Trust Modification (T1484.002) is a MITRE ATT&CK technique associated with Defense Impairment, Privilege Escalation . Adversaries may add new domain trusts, modify the properties of existing domain trusts, or otherwise change the configuration of trust relationships between do…
Trust Modification (T1484.002) is a MITRE ATT&CK technique associated with Defense Impairment, Privilege Escalation. 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.(Citation: Microsoft - Azure AD Federation) These trust objects may include accounts, credentials, and other authentication material applied to servers, tokens, and domains.
Attackers use Trust Modification because it provides a reliable way to advance their objective within the Defense Impairment, Privilege Escalation tactic, often with a favorable balance of impact versus detectability on Identity Provider, Windows environments. Defenders should assess this behavior in the context of the affected platform and adjacent activity rather than treating it as a standalone indicator.
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.(Citation: Microsoft - Azure AD Federation) 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.(Citation: AADInternals zure AD Federated Domain)
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.(Citation: Okta Cross-Tenant Impersonation 2023) 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.(Citation: AWS re Inforce Trust Mod)
No universal command represents Trust Modification. Capture the exact command line, arguments, parent process, account, host, and execution time from the investigated environment; do not operationalize unverified examples.
| Event ID | Log Channel | What It Indicates |
|---|---|---|
| Environment-specific | Relevant Windows channel(s) | Correlate authentication, process, object-access, and configuration events with the observed execution context. |
| Sysmon Event ID | Name | Why It's Relevant Here |
|---|---|---|
| Environment-specific | Validate configured telemetry | Use process, network, file, registry, DNS, or image-load telemetry only when relevant and enabled. |
No MITRE detection guidance published for this technique.
Relevant ATT&CK Data Sources: N/A
A universal Sigma rule would create unreliable results because this technique has no single guaranteed observable. Build detection logic from a documented behavior and supported data source, scope it to the affected platform, and validate it against benign administrative activity before deployment.
Start with the data sources named in the detection section. Scope searches by asset, identity, and time window; correlate the primary behavior with preceding access and subsequent actions. A portable query is intentionally not provided where the technique lacks a universal schema or observable.