|
Trusted Relationship: Role Assumption and Federated Access
AWS Specific Sub-Technique
Other sub-techniques of Trusted Relationship (1)
| ID | Name |
|---|---|
| T1199.A002 | Role Assumption and Federated Access |
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, and that the AWS identity is permitted by the role it is attempting to assume.
A role is an IAM identity that you can create in your account that has specific permissions. Roles and users are both AWS identities with permissions policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumed by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.
With access to an AWS identity that has the appropriate permissions, threat actors can use the
sts:AssumeRole action to get credentials in another AWS account if cross account roles are present. When using AWS Organizations, the management account creates one of these cross account roles in the member account by default. The AssumeRole action is also performed when an identity is provided federated access into an AWS account, for example, through AWS Identity CenterThreat actors may also leverage compromised third-party credentials that have been granted access to Amazon EKS clusters through Kubernetes RBAC, AWS IAM roles, or EKS access entries. Third-party access to EKS clusters is often granted with broader permissions than necessary and may not be subject to the same monitoring and access review processes as internal credentials. Compromised third-party credentials have been used to delete critical cluster workloads and modify cluster configurations, causing service disruption.
Detection
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
sts:AssumeRole or sts:AssumeRoleWithSAML indicating that a role has been assumed within the AWS account or federated access has been obtained. Be aware that the sts:AssumeRole* events in CloudTrail are quite common and detection strategies would need to consider additional context to help you isolate unauthorized activity from authorized activity.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.
When looking through Event history for events related to this technique, you should note that the actions are non-mutable and are therefore listed as
readOnly, which means that the Events will not be visible if there are filters set to show only mutable actions.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.
Amazon EKS control plane audit logs will show Kubernetes API activity from the compromised third-party identity. Monitor for destructive operations such as delete on deployments, statefulsets, services, and namespaces, particularly from service accounts or IAM roles associated with third-party access. Key indicators of compromise include Kubernetes API activity from third-party identities outside of expected maintenance windows and access from IP addresses not associated with the third party's known infrastructure.
Mitigation
AWS Specific Content
While it may be possible to use Resource Control Policies to restrict the ability to assume roles within the AWS account, this may be counter-productive to an organization’s goals. You can also make sure that roles are scoped with the least-privileged permissions necessary to perform duties, limiting the ability for principals that assume the role to perform unauthorized actions within the AWS account when the role is assumed.
You can 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.
Additionally, to restrict the use of IAM roles to trusted IP networks, you can apply the Service Control Policy available here.
Apply least-privilege RBAC policies for third-party EKS cluster access and scope permissions to the specific namespaces and resources the third party needs to manage. Avoid granting cluster-admin to third-party identities. Use time-bound access through temporary credentials or just-in-time access mechanisms rather than persistent credentials. Implement IP-based restrictions on IAM roles used for third-party access using IAM policy conditions (
aws:SourceIp). Enable EKS control plane logging and configure alerts for destructive operations from third-party identities.