|
Domain or Tenant Policy Modification: Trust Modification
Other sub-techniques of Domain or Tenant Policy Modification (1)
| ID | Name |
|---|---|
| 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. 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 [MITRE]
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.
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 to any user of the tenant. 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.
AWS Specific Content
A prerequisite for this technique is that a threat actor has already gained control of an AWS identity with the permissions to perform the actions in the AWS CloudTrail Event Name(s) section.
A trust relationship between separate domains or tenants within an environment be modified to facilitate access into domains. One way this can be achieved in AWS is through the creation of an Identity Provider. With access to an AWS identity that has the appropriate permissions, threat actors may create an Identity Provider within an AWS account, which allows the threat actor to utilize an alternative means of authenticating into an environment. Additionally, if an AWS Organization with multiple accounts has an Identity Provider configured by a threat actor using this technique, it is possible for a threat actor to federate into, and gain access to, the AWS Organization member accounts without creating identities for each of the member accounts.
Detection
Monitor for modifications to domain trust settings, such as when a user or application modifies the federation settings on the domain or updates domain authentication from Managed to Federated via ActionTypesSet federation settings on domain and Set domain authentication.(Citation: Microsoft - Azure Sentinel ADFSDomainTrustMods) This may also include monitoring for Event ID 307 which can be correlated to relevant Event ID 510 with the same Instance ID for change details.(Citation: Sygnia Golden SAML)(Citation: CISA SolarWinds Cloud Detection)
Monitor for PowerShell commands such as: Update-MSOLFederatedDomain –DomainName: "Federated Domain Name", or Update-MSOLFederatedDomain –DomainName: "Federated Domain Name" –supportmultipledomain.(Citation: Microsoft - Update or Repair Federated domain). AWS Specific Content
When this technique is used by the threat actor, actions taken by the threat actor using the credentials obtained will be logged in CloudTrail. You can use the Event History page in the AWS CloudTrail console to view the last 90 days of management events in an AWS Region for the events listed in the AWS CloudTrail Event Name(s) section, such as
iam:CreateOpenIDConnectProvider or iam:CreateSAMLProvider. In AWS accounts or AWS Organizations that do not already have an identity provider, the presence of the iam:StartSSO API call in CloudTrail indicates evidence of Identity Center being enabled.A separate CloudTrail trail will give you an ongoing record of events in your AWS account past 90 days and can be configured to log events in multiple regions. You can also review events using the console as well as the AWS CLI.
It is also possible to create a CloudWatch metric filter to watch for when specific AWS API calls are used and perform notification actions if logged, and additionally configure CloudWatch to automatically perform an action in response to an alarm.
Additionally, in this scenario where an identity provider was not previously configured, evidence of actions with an event source of
sso.amazonaws.com or sso-directory.amazonaws.com can be considered unauthorized. Create a CloudWatch Events rule to match the AWS API calls specified. For more information on how to monitor CloudTrail log files using CloudWatch, click here.| ID | Data Source | Data Component | Description |
|---|---|---|---|
| DS0015 | Application Log | Application Log Content | Monitor changes to cloud-based directory services and identity tenants, especially regarding the addition of new federated identity providers. In Okta environments, the event system.idp.lifecycle.create will trigger on the creation of an identity provider, while sign-ins from a third-party identity provider will create the event user.authentication.auth_via_IDP. In AWS environments, alert on events such as StartSSO, CreateSAMLProvider, or CreateOIDCProvider. |
Mitigation
AWS Specific Content
You can make sure that principals are scoped with the least-privileged permissions necessary to perform duties, limiting the ability to perform unauthorized actions in an AWS account when not required. One possible method of applying the principle of least-privileged permissions is to use Service Control Policies to restrict the maximum available permissions for the IAM users and IAM roles within your AWS Organizations accounts (note - you should test SCPs in a development environment before deploying them in production).
You can also use IAM Access Analyzer to regularly review and verify access and manage permissions across your AWS environment, which will highlight AWS identities with excessive permissions and the actions performed by those identities.
| ID | Mitigation | Description |
|---|---|---|
| M1018 | User Account Management | 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 StartSSO, CreateSAMLProvider, or CreateOIDCProvider. |