By, Maya Levine, Technical Marketing Engineer and Lior Sonntag, Security Analyst
Probably the most infamous breach of this past year against a major financial institution did not utilize the most advanced hacking techniques. In fact, it all boiled down to a misconfiguration in a cloud environment – by far the most common reason for cloud breaches in the modern era.
This blog, the second of the Cloud Threat Hunting: Attack & Investigation Series, walks through an attack technique similar to the one used in a major attack against a major financial institution.
Watch this video for an in depth overview of the attack and investigation:
THE ATTACK
The attack began by taking advantage of a misconfiguration on the application layer. This allowed the attacker to do a Server side request forgery attack – which basically let the attacker tell the server to execute a HTTP request on their behalf. This vulnerability was used to query the metadata service on the EC2 to get the desired information: credentials for a role with access to the EC2. The attacker obtained an Access Key and Token, exported it to their own environment, and assumed the role.
Now the role which the attacker assumed did not have S3 permissions. In order to escalate their permissions, the attacker used enumeration techniques to discover different role names within that account. This involves using dictionaries of most common role names that exist in the wild, known as Enumerable Role Names. Attackers are able to easily check if those role names exist in your account. Using this technique, the attacker found and then assumed a role with full access to S3.
Once they escalated their privileges from the original EC2 role they assumed, to the S3FullAccess role, the attacker was able to steal the entire storage from the account. They used Tor to exfiltrate the data out.
THE INVESTIGATION
The key first step to investigating an attack like this is real-time, relevant, alerts. 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 alert for this investigation is Successful API request originated from a Tor exit node, which is a huge red flag for any environment. Attackers are notorious for using Tor, as it anonymizes their internet activity.
The second alert is Abuse of Access Token, generated by STS dedicated for EC2. Basically, this says that an STS token, which was supposed to be used just for the EC2, was used by an external IP. STS tokens should be used only for internal purposes.
The next alert is Abuse of Unsuccessful AssumeRole. This identifies the enumeration technique used by the attacker to find a role with privileged access to the S3 bucket. The attacker guessed multiple different variations of the role name S3 Full Access until they managed to guess the right one and could assume the role of S3FullAccess. This alert notifies users of a potential compromise where an attacker is attempting to escalate privileges.
The alerts outlined here paint a clear picture of malicious activity on a cloud account. They serve as a starting point – a clear indication that an investigation must occur. CloudGuard makes such an investigation seamless. For example, within a few clicks from the alerts, one can see that data was actually exfiltrated out.
CloudGuard provides the context and security oriented alerts needed for cloud intelligence and threat hunting, to assist in understanding the how and why a breach took place.
For more information and to request a demo, please visit: https://pages.checkpoint.com/cloudguard-logic-demo.html