Stop an attack in AWS!

Let's see how a SecOps analyst using Vectra can detect and respond to attackers targeting AWS.

Account compromise in AWS

Start by clicking Expand All to review the prioritized Azure AD, M365, and AWS account details to understand if any accounts have been compromised and need to be remediated.

Click the AWS identity to investigate the compromise.

‍

You can see that chris@corp.ai is prioritized as an active compromise with several different Vectra detections correlated to the user.

Let's investigate chris@corp.ai to understand what might be happening.

You can see the user performed several actions that triggered alerts, including:

• Enumerating EC2 instances, S3 Buckets, and user permissions
• Reading network configurations
• Modifying user permissions
• Hijacking Lambda functions

Let's take a deeper look at these alerts by clicking Expand All.

The expanded detections reveal more details about this identity's potentially malicious activities.

AWS Lambda Hijacking

The AWS LambdaHijacking alert could indicate that an attacker has gained persistence in the environment. Let's investigate that alert first.

You can see details of the Lambda change that could have given the attacker persistence.

This detection uses AI to monitor the time series of AWS API calls and request parameters to detect the behavior related to malicious modifications to an AWS Lambda function. 

To understand more about this type of Vectra detection, click ? to review the in-app explanation page.

Now that we understand how this detection works.

Let's investigate and understand

• What API calls were made, and with what parameters?
• What role was used?
• From where were the changes made?

Our investigation reveals that this was a malicious change that provided the attacker backdoor access to the environment.

The attacker assumed the role of lambdaManager-role, created a new Lambda function, and used the API call PutRule to create a backdoor.

Malicious activity through backdoor in AWS

Before we remediate, let's understand what else the attacker has been doing with their access.

‍

‍

Let's investigate the logs to see what else the attacker has done.

Click Instant Investigation for query-less access to the account's historical activity in AWS.

The attacker accessed several different services across multiple regions.

Multiple role assumptions occurred during the attack, potentially hiding the attacker's activities. Vectra correlates all role assumptions back to the user for easy investigations.

Stop the attacker in AWS 

We now have enough information to stop the attacker with the data collected by revoking the identity's access and removing the Lambda backdoor.

Attack Stopped!

‍