Cloud Threat Hunting: Attack & Investigation Series- Privilege Escalation via Lambda

Author: Maya Levine, Technical Marketing Engineer

Lior Sonntag, Security Analyst

Cloud breaches are becoming increasingly prevalent in this modern digital era. One of the more dangerous strategies attackers deploy during a cloud breach is Privilege escalation. They use this to move laterally within a cloud environment and access sensitive assets.

This blog, the third of the Cloud Threat Hunting: Attack & Investigation Series, reviews an attack scenario that utilizes Lambda functions to gain entry to sensitive data within a cloud account.

Watch this video for an in depth overview of the attack and investigation:

THE ATTACK

This attack began with a hacker who gained credentials for an AWS user with low privileges and no S3 access. In order to execute privilege escalation, they must first understand what this low privilege user can access. To do this, they will run a list-functions command on different regions to find Lambda functions they can utilize for an attack.

In one of these regions, the hacker found they had access to a lambda function whose runtime uses python. In their own AWS account, they will put a compromised layer with a backdoor and make it public. In the victim’s account, they utilize the low privilege user to update the configuration of the function they could access. In this way, they are able to insert their compromised layer from their own account.

The compromised layer contains a payload that when the lambda is invoked, it will send the data the attacker wants to their own machine. The attacker starts up a listener machine with a public IP in order to accept that data. This machine waits for the Lambda to be invoked, listening on port 4444 to accept a packet from the Lambda function.

When the Lambda function gets invoked, it sends a packet to the attacker’s listener machine with critical sensitive information such as Access Key ID, Secret Access Key, and the Session Token. In this way, the attacker steals the token of the Lambda. They will decode and export it to their own environment.

Now they can run the command aws s3 ls to find sensitive data. They will look for files with names such as customer-credentials-sensitive. Anything that could potentially contain credentials or sensitive data. Once they locate such a file, they will exfiltrate the contents.

THE INVESTIGATION

The key first step to investigating an attack like this is a real-time, relevant, alert. Alert fatigue is a serious problem for those tasked with analyzing and identifying potential breaches within a cloud environment, after all, what good is a Threat Intelligence solution if the relevant alerts are buried or hidden by sheer numbers? Alerts should be both automated and security focused. A useful Threat Intelligence solution will prioritize the alerts and provide enough context for an analyst to easily investigate an attack and put the pieces together.

CloudGuard’s generated alerts correspond to different attack techniques that are outlined in the MITRE ATT&CK^® framework. Ordered by priority (risk level), here are the relevant alerts CloudGuard would generate for this attack using its cloud intelligence and threat hunting capability:

The first relevant alert is Abuse of access token generated by STS dedicated for Lambda. This notifies of an abuse of Lambda. Someone used the Lambda’s Token from an external IP which should never happen. This is a clear indicator that the cloud account was breached and a starting point for the investigation.

The second relevant alert is Series of enumeration API calls executed in several regions. In this attack scenario, the attacker ran the list-functions call in several regions to find where they had access to a function. That action would have triggered this alert. This alert can be a red flag that someone gained access to your account and is trying to move laterally and escalate their privileges.

The next alert is Lambda Layer was Added from an External Account. This will notify if someone inserted a Lambda Layer from a different AWS account that is external from your own account. Whether this is indicative of an attack depends on the normal development practices of a company. However, if the external account is not recognizable, this is a big indication that you should investigate further. With CloudGuard Intelligence, you can drill down to see the layer, and in the case of this attack, the actual payload inserted.

An informational alert will be generated to show there was a Lambda Configuration Update. In conjunction with the other alerts presented, this helps to complete the picture of how an attacker was able to exfiltrate the sensitive credentials.

All of these alerts together paint a clear picture of a data exfiltration attack in which an attacker utilized privilege escalation via Lambda. Putting these alerts together help to understand how and when a cloud breach occurred. CloudGuard provides the context and security oriented alerts needed for proper cloud intelligence and threat hunting.

For more information and to request a demo, please visit https://pages.checkpoint.com/cloudguard-logic-demo.html