Detecting Unusual AWS Sessions Utilizing Temporary Credentials (2/2)

In our previous blog post, we discussed some common scenarios in which temporary credentials in AWS can be compromised and abused by malicious actors. In this blog, we will introduce the Uptycs’ Identity Threat Detection and Response (ITDR) solution for the cloud that will detect and provide a means to remediate the likely compromised temporary credentials.

Without a capability like ITDR for the cloud, it is very difficult to parse AWS CloudTrail logs to discover which credentials are abused or used in an abnormal fashion compared to the rest of the user population. Unless you’re paying for GuardDuty, detecting when temporary credentials are being used outside of the EC2 instance they’re created for is also difficult. Our ITDR offering for the cloud continuously analyzes CloudTrail logs and makes it easier for our customers to detect temporary credential abnormalities and know how to remediate them.

Let’s dive into how Uptycs does this …

Scenario 1: Detecting Role Chaining to Establish Persistence

In the diagram below, the threat actor used long-term credentials to assume a role to acquire temporary credentials. Those temporary credentials then go on to assume another role for a different set of temporary credentials, and so on. Three roles in total have been assumed which has led to the threat actor creating a new user Bob and a long-term credential (AKIAY) for persistence.

Uptycs will detect this series of role chaining and surface it in a graphical format to highlight someone (user or machine) is trying to persist in your account. Based on our research and talking to advanced customers about their strategy of using roles, a second role chain (highlighted in orange) could be anomalous activity, whereas three or more role chains (highlighted in red) is most likely anomalous activity.

Figure 1 - Uptycs ITDR for the cloud will detect role chaining to establish persistence

Scenario 2: Compromising Short-term Credentials From an EC2 Instance

In the diagram below, an EC2 instance that has a role attached has been compromised by a Server-Side Request Forgery (SSRF) attack. The threat actor has been able to curl the metadata and steal the temporary credentials. Those temporary credentials then go on to assume another role for a different set of temporary credentials, and so on.

The difference between this scenario and the first scenario is that there are no long-term credentials at play in scenario two. Uptycs will continue to detect and visualize when a threat actor tries to persist through several role chains when the source of the role chain is a temporary credential. We will also provide the context of the source of the role chaining (in this example it originates from the EC2 instance) so that you’re able to narrow down where to begin your investigation.

Figure 2 - Uptycs will provide contextual information as part of the detection to help you investigate the EC2 instance in question, for example

Scenario 3: Compromising Short-term Credentials From an EC2 Instance … Then Using Them Outside of That EC2 Instance

In the diagram below, an EC2 instance (IP: 2.2.2.2) that has a role attached has been compromised by an SSRF attack. The threat actor has been able to curl the metadata and steal the temporary credentials. But this time they use the credentials on a different machine (IP: 8.8.8.8) running the AWS CLI to make programmatic calls into the victim’s account.

Sometimes threat actors steal credentials and use them on a different machine with a different source IP. Uptycs will be able to surface when a temporary token has been used outside of the machine it was intended for. By design, the EC2 instance the role is attached to should be the only machine using those credentials.

Figure 3: Uptycs will detect when temporary credentials are used outside the machine where they were intended for

Remediating Anomalous Temporary Sessions

While visualizing these anomalous tokens is great, the next logical step is to remediate any that shouldn’t be active. The way this is done is by revoking all permissions to the role's credentials by attaching a new inline policy to the role that denies all permissions to all actions.

Put simply, anyone who tries to use the credentials after this policy has been added will not be able to do so. The Uptycs ITDR solution for the cloud will provide you with step-by-step instructions on how to apply this remediation (via the AWS console or CLI) to be able to mitigate the ongoing persistence created by using role chaining.

Figure 4: Uptycs provides remediation guidance for detections of anomalous temporary tokens

The Uptycs ITDR for the cloud functionality is available for Uptycs customers now. This capability will immediately improve your security posture in the cloud and help your security team more quickly detect and respond to this frequently used attack vector. We would love to discuss and answer questions.

Click here to schedule a demo.