Intercept Threat Actors in AWS Cloud Services with Confluera’s Touchless Continuous Storyboarding
Cloud Security Team, Confluera
Cloud-native environments are crowded marketplaces. Recent breaches exemplify that threat actors have evolved to being stealthy, multi-step and multi-stage, blending in the noise of the marketplace. Today’s cloud-native solutions provide disconnected security observability leaving the burden of connecting the dots from the noise on the human analysts. The lack of an autonomous storyboarding fabric results in most cloud-native attacks remaining un-intercepted, with root cause and impact analyses taking months. Confluera provides that missing autonomous cloud-native storyboarding fabric; connecting the dots in real-time, thereby singling out threat actors in their tracks.
AWS Cloud-Native Services Are Increasingly Becoming Soft Targets for Modern Threat Actors
AWS Cloud-Native Services such as Identity and Access Management, EC2, ECS, Lambda Functions, S3, RDS, and EMR are quickly becoming staple elements in cloud architectures. Recent breach events such as Okta exemplify how multi-stage attacks are extensively exploiting risks such as misconfigured EC2 security groups, over-provisioned IAM policies and loosely configured S3 buckets as points of entry, lateral movements (both cross-role and cross-account) and active exfiltration.
Cloud Services Threat Model
Threat models have evolved across all layers of the cloud and cloud services layer is not an exception. Threats in the cloud service plane are not single isolated events, but have emerged as being more multi-step and multi-stage. For example, when a malicious threat actor attempts a ransom attack that targets high-value data in an AWS S3 bucket, it is not a singular event but a culmination of multiple steps spread across various parts of the cloud services in a varying time window. Here are some examples of seemingly benign AWS activities that could be leveraged by adversaries to get entrenched in your environment:
- AWS IAM activities in the form of account enumeration, disabling multi-factor authentication (MFA), account hijacking, privilege escalation, within-account role assumption, cross-account role assumptions, etc.
- AWS EC2 activities such as instance profile privilege escalation, file exchange tool installs, etc.
- Amazon S3 activities such as bucket and object enumeration; impair bucket encryption and versioning; bucket policy manipulation, etc.
The Battle
Detecting a cloud-native attack in progress is a major challenge. The primary reasons are as follows
- Cloud environments are like crowded marketplaces. Once threat actors make initial footholds, they blend into the noise of the environment (amidst the millions of API calls between different services).
- Siloed security solutions generate too many isolated security alerts which are impossible to triage through
- Security alerts generated are mostly unactionable suspicions, weak in nature
- It is left to a human analyst to perform top down investigation for every signal to figure out whether or not a multi-step threat is brewing underneath the noise
- This manual approach does not scale in a cloud environment
As a result of the lack of connected security observability,
- Most cloud-native attacks remain un-intercepted until they cause damage
- Figuring out the root cause and the impact takes months as human analysts are burdened with connecting the dots
A New Paradigm: Real-Time Cloud-Native Threat Storyboarding Fabric
Detecting cloud-native attacks needs a fundamentally new approach. Confluera’s unique Real-time Threat Storyboarding fabric is built on patented Continuous Attack Graph technology where every actor and its activities are continuously monitored and stitched to quickly single out actors who seem to have malicious intent.
Here is how it works, in four key stages:
Test Drive: A real-life attack scenario
Act 1 — A malicious insider logs in into an EC2 instance that serves as a bastion host in the organization’s development account. The instance has a restricted dev role assigned to it. The insider executes a weak step of changing default of an AWS policy. The insider then uses ‘aws list role policies’ and sees that the restricted role can assume into or privilege escalate into a privileged dev role
Confluera in Action:
Act 2 — The insider assumes the privileged dev role. He succeeds as the privileged dev role did not require any external id or MFA. He finds the role more open and executes the following triggers. 1) Default version changes for IAM policy, 2) New access key creation is triggered, 3) Snapshot being shared to another user. He also finds out that the dev admin role allows him to move into the organization’s production account through a prod role.
Confluera in Action:
Act 3 — Insider takes advantage and assumes the prod role. He then tries to brute force into external corporate accounts, but fails as the external corporate accounts have added an extra layer of protection in the roles using external ids. Just imagine if that had not been the case
Confluera in Action:
Last But Not The Least, It is All Touch-less
Deployment of the end-to-end pipeline is as touchless as it can be. A few AWS event bridge rules targeted to AWS Simple Queue Services plus an IAM role to allow access to these services are all that are needed to register an organization’s AWS accounts with Confluera
