Connecting the Dots across OS, Containers, Network, and Cloud API Planes

Vinay Prabhu, Niloy Mukherjee

Cloud is a Marketplace

The cloud is evolving as a marketplace of diverse components ranging from infrastructure, platforms, and cloud-native services. You can visualize your cloud as a casino or a shopping mall. However unlike a casino or a shopping mall, the cloud is perimeter-less and zero trust. Threat actors will keep evading perimeters, blend in the environment hiding in the noise overload, while navigating towards the Crown Jewels (your RDS or S3 artifacts). So how do you connect the dots automatically and intercept cloud data security threat actors in their tracks?

The Solution Fabric

• Put a tracking device on every actor right from the point it makes an initial entry.
• Continue tracking them as they navigate across various components (host OS, container, K8S, network, Identity and Access Management Role).
• Record suspicious behaviors executed on the trail, weak or strong; behaviors such as reconnaissance, IAM privilege escalation, cloud discompliance and misconfigurations
• A threat actor gets automatically surfaced from the pack way before it reaches the crown jewels when it has exhibited enough risk on its trail
• Having full knowledge of the exact entities impacted by the threat actor, surgically clean it up

(More details at https://bit.ly/3OfXNgR)

Test Drive

Check out how Confluera reacts in real-time to a malicious insider as he makes an initial access, navigates from one VM to another, uses an IAM role associated with a VM to assume a more open role, and finally hops into a cross account IAM role towards production crown jewels.

Act 1 — The malicious insider logs in to an EC2 instance and performs a few ‘netstat’ commands for reconnaissance.

Act 2 — He moves in into another EC2 instance that serves as a bastion host in his organization’s AWS development account. The instance has a very restricted IAM role assigned to it. The restricted role only allows him to change the default version for the IAM policy associated with the role. However, the insider uses ‘aws list role policies’ to figure out that the restricted role can assume into a more open privileged dev role

Act 3 — 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

• Default version changes for IAM policy
• New access key creation is triggered
• Shares a snapshot with 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. His organization’s production account hosts services that interface with a lot of external corporate accounts.

Act 4 — He 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