By Maya Levine, Technical Marketing Engineer, and Lior Sonntag, Security Analyst A sign of a truly sophisticated attack in the cloud is the ability to move laterally undetected. Doing so successfully requires knowledge of many techniques. In this latest installation of the : Attack and Investigation Series, we present the most involved attack flow yet. We will break down all of the steps a threat actor took to successfully exfiltrate data out of an AWS account. Cloud Threat Hunting This attack began with a compromised pair of AWS access keys. The first thing the threat actor does is obtain temporary credentials using the command. This is a form of defense evasion – if the permanent credentials the threat actor started with are deleted or disabled, they will still have access to the environment. get-session-token Next, the threat actor gets the user name associated with the credentials: Low-Priv. In order to understand what the permissions of this user will allow them to do, they run the command. Turns out, they do not have permissions to run that command. This is true for the two other commands they attempt: and which shows them managed policies for the user. list-user-policies list-attached-user-policies list groups for users At this point, they could resort to a brute force attack to obtain the permissions. This will require a lot of time and effort. So instead, they check for access to the account’s event history. Using the credentials they already obtained, they run the command to check for access to CloudTrail logs. The output shows them that the user has read-only permissions to CloudTrail logs. lookup-events This will give the threat actor the ability to understand what they can accomplish with this compromised user. They begin by searching CloudTrail events for that username. The results show that the user ran the command to the role. They also learn the default region of the user, the role session name, and most importantly – the role ARN. They copy the ARN to later assume the role. AssumeRole LambdaCreator The threat actor will check what events the role did in that session. Once they assume the role and move laterally, they will be able to execute those same commands. The first event was on a function called . The second event was on that same function. LambdaCreator UpdateFunctionConfiguration Automation-UpdateSSMParam UpdateFunctionCode Finishing up the reconnaissance from the CloudTrail logs, they will now run the command to escalate their privileges to this role. sts assume role LambdaCreator Once in the new role – they try the command but get an Access Denied error. Meaning, they cannot access the function’s code or environmental variables. So, they will turn to a form of social engineering: googling the function name. They find an AWS walkthrough which tells them that the role attached to this lambda function has permissions for . The name implies that if the threat actor is able to gain access to this role, they can easily abuse it, move laterally, and escalate their privileges. Additionally, the actor learns that the function uses boto3 library. get-function AmazonSSMFullAccess The walkthrough also tells them that the AWS name for this function ( ) is identical to the name in the victim’s account. This is a common mistake users make—defining resource names exactly as AWS defines them in their examples. It makes the jobs of threat actors infinitely easier. A simple Google search gave them all of the information they needed to continue in the attack. Automation-UpdateSSMParam Remember there were two permissions the LambdaCreator role used in the CloudTrail logs. Abusing involves changing the function’s code to be malicious and retrieving environmental variables through a reverse shell. This could break the functionality of the function and alert the victim of an attacker’s presence. So, the better alternative is using the permission to inject a malicious lambda layer to the function. This does not affect the functionality of the function whatsoever. UpdateFunctionCode UpdateFunctionConfiguration The code of Lambda layers is stored separately from the rest of the function. These layers can be shared cross-account. First, the actor creates the malicious layer in their own AWS account.  They insert malicious code into a boto3 library. When the lambda function is invoked, it will use this altered boto3 library instead of the default one. This malicious code will result in the lambda sending all it’s environments variables to the attackers IP, including the STS token of the function’s role. The actor makes this malicious layer publically available. Then, switching to the victim’s account, they run the command to insert the malicious backdoor layer. UpdateFunctionConfiguration They wait for the function to be invoked and set up a listener on port 4433. Once invoked, the function sends over all of it’s environmental parameters including: access key ID, secret access key, and session token. Together, these comprise the STS token of the function’s role. Once again, the threat actor can impersonate this, move laterally, and escalate their privileges. In this new role, they have permission. They will now repeat their previous technique of looking at CloudTrail to list the history events – this time related to the SSM service. SSMFullAccess One of the events is API call. This will start a connection to an EC2 instance. The actor copies the instance target ID. Using the STS token from before, they start a session to that target ID and login to that EC2 instance. SSM start session From there, they search for metadata service which by default is found under the IP 169.254.169.254. They now extract the EC2 instance’s role name: Users often name roles based on their permissions, which indicates to threat actors the scope of that role. The name clearly states that the role has full access to DynamoDB. DynamoDBFullAccess. The role name is added to the query, and the metadata service will output it’s STS token. From within the EC2 instance, they list the DynamoDB tables. The actor knows that the EC2 has DynamoDB full access, so they can scan the table. This reveals sensitive customer information like name, phone number, email, and last 4 digits of credit card numbers. Now how will the attacker exfiltrate this information? One option is to use the EC2 role STS token outside of the instance environment – but this can be easily detected as suspicious behavior. A more covert option is NTP or . The attacker uses NTP, which AWS frequently uses to sync the clocks of instances over the network. This allows the attacker to exfiltrate the data relatively silently and under the radar. DNS tunneling Investigation Even with an attack as sophisticated as this, CloudGuard will generate multiple relevant alerts for an investigation within the time frame of the attack. The first alert is . Permissions scan attempt executed by CLI This will show all the commands executed by the attacker from the CLI… , , , , and . The is indicating when the threat actor moved from the original role to the role. ListUserPolicies ListGroupsForUser ListAttachedUserPolicies GetSessionToken AssumeRole AssumeRole LowPriv LambdaCreator The command also prompts this alert: GetSessionToken Temporary Creds created from permanent user creds. The next logical step in an investigation is to take all the tokens from this event and create a new query that searches for CloudTrail logs with these tokens. Note that the command’s response has another token that was added to this query. AssumeRole This reveals more actions taken by the attacker once they moved laterally to a new role. Specifically, the call which was run on the function. UpdateFunctionConfiguration Automation-UpdateSSMParam Back in the alerts list, we see that there are 2 alerts related to the function. The first is . Automation-UpdateSSMParam Lambda configuration update The second is . Lambda Layer was added from an external account The logs show that the event has no known identity. They also show that a backdoor layer was inserted from a completely different AWS account. UpdateFunctionConfiguration From this same view we also see an command…the attacker escalated their privileges to the role. As part of the investigative process of “following the token”, we copy the access key ID of the role and insert it into the same query that has been built out slowly. AssumeRole LambdaSSM There were several alerts generated for the role as well…the first is . LambdaSSM Abuse of access token generated by STS dedicated for lambda The logs show a call from an external source with a Kali Linux user agent, therefore, this was not initiated from the lambda function itself. Most importantly, the call requests an ID. StartSession StartSession Searching for this ID reveals two alerts. First, is an alert called . This shows the malformed NTP traffic that was the attacker exfiltrating the data. Suspicious NTP packets volume per session The Statistics tab clearly shows the uptick in the traffic. The other alert is As the name suggests, it utilizes machine learning to do anomaly detection of network traffic. Anomaly Detection – Anomalous Network Traffic. The Statistics tab shows a pretty active traffic trend with ups and downs. However, the action caused a significant enough uptick to be deemed an anomaly. StartSession Altogether, all of these events indicate an incident. Throughout the course of the investigation, we followed the token. This allowed us to see the entire attack from beginning to end. From the , the move to , to with the . low-priv-user automation-updateSsmParam StartSession SSM role

Flow

Google

Target

Visit us

Too Long; Didn't Read

ML Practitioners - Ready to Level Up your Skills?

Cloud Threat Hunting: Investigating Lateral Movement

Too Long; Didn't Read

Companies Mentioned

Coin Mentioned

@checkpoint

RELATED STORIES