|
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 CenterDetection
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.
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.