|
Account Manipulation: Additional Cloud Credentials
Other sub-techniques of Account Manipulation (5)
| ID | Name |
|---|---|
| T1098.001 | Additional Cloud Credentials |
| T1098.003 | Additional Cloud Roles |
Adversaries may add adversary-controlled credentials to a cloud account to maintain persistent access to victim accounts and instances within the environment.
For example, adversaries may add credentials for Service Principals and Applications in addition to existing legitimate credentials in Azure AD. These credentials include both x509 keys and passwords. With sufficient permissions, there are a variety of ways to add credentials including the Azure Portal, Azure command line interface, and Azure or Az PowerShell modules.
In infrastructure-as-a-service (IaaS) environments, after gaining access through
Cloud Accounts [MITRE]
, adversaries may generate or import their own SSH keys using either the CreateKeyPair or ImportKeyPair API in AWS or the gcloud compute os-login ssh-keys add command in GCP. This allows persistent access to instances within the cloud environment without further usage of the compromised cloud accounts.
Adversaries may also use the CreateAccessKey API in AWS or the gcloud iam service-accounts keys create command in GCP to add access keys to an account. If the target account has different permissions from the requesting account, the adversary may also be able to escalate their privileges in the environment (i.e.
Cloud Accounts [MITRE]
). For example, in Azure AD environments, an adversary with the Application Administrator role can add a new set of credentials to their application's service principal. In doing so the adversary would be able to access the service principals roles and permissions, which may be different from those of the Application Administrator.
In AWS environments, adversaries with the appropriate permissions may also use the `sts:GetFederationToken` API call to create a temporary set of credentials to
Forge Web Credentials [MITRE]
tied to the permissions of the original user account. These temporary credentials may remain valid for the duration of their lifetime even if the original accounts API credentials are deactivated.
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.
With access to an AWS identity that has the appropriate permissions, threat actors may add adversary-controlled credentials to maintain persistent access to compromised AWS resources or IAM users, and import or create SSH keys for EC2 instances within the account. Actions that threat actors take against IAM users with this technique include creating an additional access key, or updating an access key. Up to a maximum of two access keys can be configured for an IAM user. Additional IAM user actions include the creation of a login profile to allow a user to connect to an AWS account using the AWS Management Console. Actions that threat actors take against EC2 instances with this technique include the import or the creation of key pairs, as well as the use of the
ec2-instance-connect:SendSSHPublicKey CLI command using EC2 Instance Connect.With the appropriate permissions, threat actors can also use the
sts:GetFederationToken (or sts:GetSessionToken) action to create a temporary set of credentials tied to the permissions of the IAM user invoking the sts:GetFederationToken (or sts:GetSessionToken) command. These temporary credentials remain valid for the specified duration, from 900 seconds (15 minutes) up to a maximum of 129,600 seconds (36 hours). The default session duration is 43,200 seconds (12 hours). The credentials remain valid for the duration of their lifetime even if the original access keys for the IAM user are deactivated or deleted. Temporary credentials can be obtained using sts:GetFederationToken (or sts:GetSessionToken) for the root user, and in this case, the credentials are valid for a maximum duration of 3,600 seconds (1 hour) and cannot be revoked during that time.Detection
Monitor Azure Activity Logs for Service Principal and Application modifications. Monitor for the usage of APIs that create or import SSH keys, particularly by unexpected users or accounts such as the root account. Monitor for use of credentials at unusual times or to unusual systems or services. This may also correlate with other suspicious activity.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:CreateAccessKey or iam:UpdateAccessKey.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.
If Amazon GuardDuty is configured within the AWS account, an IAMUser/AnomalousBehavior finding may be created if this technique is used. This finding is presented in GuardDuty when actions commonly used to maintain unauthorized access to an AWS environment are invoked in an anomalous way.
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.
In the event that a threat actor uses an IAM user to perform the
sts:GetFederationToken or sts:GetSessionToken actions, the temporary credentials that are created remain valid for their specified duration - even if the original compromised credentials that are used to create the temporary credentials are deactivated or deleted. To revoke these temporary credentials, an inline policy denying actions should be applied to the IAM user whose credentials were originally compromised. In the example inline policy below, the value of the aws:TokenIssueTime parameter should be the same value as the eventTime field of the sts:GetFederationToken or sts:GetSessionToken event logged in CloudTrail.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"DateLessThan": {"aws:TokenIssueTime": "2014-05-07T23:47:00Z"}
}
}
}Additional information on the policy is available here. For steps on how to create an inline policy for an IAM user, click here. Take note that an inline policy cannot be applied to an account root user, and if the root user credentials for a standalone AWS account are compromised by a threat actor and used to create temporary credentials using
sts:GetFederationToken or sts:GetSessionToken then the credentials will remain valid for 1 hour (if the AWS account is a member of AWS Organizations, then actions taken by the root user can be denied through the use of a Service Control Policy). Incident responders should delete the compromised root user credentials and actively review the account for unauthorized activity until the temporary credentials expire.References
- mitre-attack
- Crowdstrike AWS User Federation Persistence
- Expel IO Evil in AWS
- SpecterOps Azure Privilege Escalation
- Demystifying Azure AD Service Principals
- GCP SSH Key Add
- Blue Cloud of Death Video
- Blue Cloud of Death
- Microsoft SolarWinds Customer Guidance
- Expel Behind the Scenes
- Sysdig ScarletEel 2.0
- Rhino Security Labs AWS Privilege Escalation