 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Check Point sponsored this post.
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.
Here we will review an attack scenario that utilizes launching an Amazon Web Services‘ Elastic Cloud Compute (EC2) instance without a key pair.
In this attack, the attacker was able to log into the console using a low privilege user’s credentials. The attacker could have obtained these credentials in many ways: brute force, phishing, purchasing stolen credentials on the dark web, and more. However, once they obtained the credentials, it gave them access to the AWS console with no programmatic permissions. Given that the stolen permissions of this user are not excessive, the attacker will attempt to escalate to a higher permission that has access to sensitive assets.
This attacker will look at Amazon Machine Images (AMI) — a template that allows you to launch an instance and which contains a software configuration (such as operating system, application server, and applications). They will choose to launch the AMI most likely to get access to a database.
Since the attacker will not have access to existing key pairs and creating a new one could alert security to their presence in the account, they will launch this AMI without a key pair. They do this by inserting a payload into the user data itself. This is not common behavior for most organizations and not best practice.
Another attack vector that can jeopardize the account is allowing users to pass User Data to the instance. This is in order to perform common automated configuration tasks. However, it can also be used to run scripts after the instance starts, which attackers will take advantage of. In this attack, the attacker uploads a file with payload scripts, which creates a reverse shell to the attacker’s machine once the instance is spun-up.
From here, escalating privileges is simply a matter of finding the right files that contain the credentials to access the database. Once the attacker logs into the database, they will search for sensitive content to exfiltrate.
The key first step to investigating attacks like these is a real-time, relevant, alert. However, 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? So these alerts should be both automated and security-focused. A useful Threat Intelligence solution prioritizes these alerts and provides enough context for an analyst to easily investigate an attack and put the pieces together.
Generated alerts should correspond to different attack techniques that are outlined in the MITRE ATT&CK framework. Ordered by priority (risk level), here is an example of relevant alerts that would generate for this attack using a cloud intelligence and threat hunting capability:
1. The first is Suspicious EC2 Instance without KeyPair was launched but with the UserData attribute. As previously mentioned, this is a known privilege escalation technique utilized by attackers.
2. The second is Anomaly Detection — anomalous network traffic. Using machine learning builds a baseline of normal behaviors. It will alert any deviations from this baseline. This alert gives the context needed to understand that data was extracted from your environment. The logs will show you all of the relevant IP addresses involved and the specific bytes related to the outbound data shift.
3. The next alert is Login to AWS console from a new location. This alert also utilizes machine learning and AI capabilities. If a login occurred from a location that is outside of the normal behavior scope, an alert should be generated to provide information about the login — such as country and IP address.
4. The last alert is Successful login without MFA. This alert has the lowest priority or risk level (Informational). By itself, it would not be alarming; unless there is a strictly enforced company policy of using MFA. However, in parallel with all the other alerts, it helps to complete the picture of the attack that occurred.
Understanding how and when a cloud breach occurred is no small feat. There are many pieces of the puzzle that must be put together. To effectively address these attack types, organizations need to leverage innovations to provide context and the security-oriented alerts needed for cloud intelligence and threat hunting. These measures will assist in understanding how and why a breach took place.
This post was sponsored by Check Point.
Amazon Web Services is a sponsor of The New Stack.
Feature image via Pixabay.
