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 Threat Detection 2024)
View in MITRE ATT&CK®| Capability ID | Capability Description | Mapping Type | ATT&CK ID | ATT&CK Name | Notes |
|---|---|---|---|---|---|
| IAM-16 | Authorization Mechanisms | mitigates | T1484.002 | Trust Modification |
Comments
This control requires both CSP and CSC to independently enforce formal approval processes for user access, implement dynamic and explicit authorization mechanisms. The guidance focuses on implementing technical measures to verify authorization and prevent unauthorized access and execution.
References
|
| IAM-11 | CSCs Approval for Agreed Privileged Access Roles | mitigates | T1484.002 | Trust Modification |
Comments
This control requires both CSP and CSC to collaboratively identify high-risk data and privileged roles, enforce formal CSC approval workflows for CSP user access, use secure PAM systems, and implement comprehensive monitoring and reporting to ensure privileged access to sensitive CSC data is tightly controlled and traceable.
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
account permissions and roles, PAM solutions, or just-In-Time access.
References
|
| IAM-10 | Management of Privileged Access Roles | mitigates | T1484.002 | Trust Modification |
Comments
This control requires both CSP and CSC to independently manage privileged access by enforcing time-bound approvals, formal request and justification processes, automated revocation, session restrictions, credential vaulting and rotation, continuous monitoring, and periodic reviews, ensuring privileged access is tightly controlled, monitored, and limited to only what is necessary for specific roles and timeframes.
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
account permissions and roles, PAM solutions, or just-In-Time access.
References
|
| IAM-09 | Segregation of Privileged Access Roles | mitigates | T1484.002 | Trust Modification |
Comments
This control describes the periodic, risk-based, and reviews of privileged accounts and high-risk access configurations, ensuring these are accounts are managed and scrutinized to prevent unauthorized access or excessive privileges.
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
account permissions and roles, PAM solutions, or just-In-Time access.
References
|
| IAM-06 | User Access Provisioning | mitigates | T1484.002 | Trust Modification |
Comments
This control describes the implementation of a secure and controlled user access provisioning process. Proper user account management reduces the attack surface by limiting unauthorized access to data, assets, and systems. Managing account access authorizations can reduce the risk of privilege escalation by ensuring accounts cannot perform unauthorized actions.
References
|
| IAM-05 | Least Privilege | mitigates | T1484.002 | Trust Modification |
Comments
This control describes the enforcement of the principle of least privilege implementing controls such as regular automated reviews of access permissions, enforcing MFA for high-risk accounts, promptly revoking unused privileges, and by limiting access to sensitive data.
For this technique, adversaries have been known to add a federated identity provider to the victim’s SSO tenant and activates automatic account linking. In terms of mitigation, using the principal of least privilege and protect administrative access to domain trusts and identity tenants. Additionally, in cloud environments, limit permissions to create new identity providers to only those accounts that require them. In AWS environments, consider using Service Control policies to limit the use of API calls such as CreateSAMLProvider or CreateOpenIDConnectProvider.
References
|