Proactive Cloud Security: Tackling Credential Theft with InstaSecure

Today we will see InstaSecure, a proactive cloud security platform. InstaSecure provides 50+ AWS-native preventive guardrails for AI, data, identity, and cloud infrastructure to prevent misconfigurations and access issues across the entire AWS platform.

Today, we will focus on building an air-gapped environment called data perimeters that tackle the issue of credential theft.

More than 60 percent of cloud breaches are attributed to credential issues. Credentials in the cloud are present everywhere—in your software packages, network shares, GitHub repos, access from your cloud infrastructure, agentic frameworks, or anything deployed on or accessing the cloud.

The source of credentials can be tied to human or workforce access, whether directly through IAM configurations for data access or through long-term session keys, credentials, and access keys. There are many ways credentials appear.

There are also various formats for providing third-party web identity and other forms of access. As you quickly realize, the cloud is complex, and understanding the security posture of credential usage is very difficult.

Let's see how we tackle the issue of credential theft and build preventive protection inside the cloud. To demo the problem, let’s assume there's a company called Equi, which has deployed an application inside a VPC. It has a cloud credential—an IAM role—associated with it, and it is accessing an S3 bucket with data in the same cloud account. In this case, that identity is accessing a trusted resource through an expected network, so this access should be allowed.

The problem arises when this trusted identity gets stolen and is then used by an attacker from a random location to access cloud infrastructure—for example, sensitive data stored in that S3 bucket. This is a very common pattern of credential abuse in the cloud. A well-known case was the Capital One breach of 2019.

Capital One built a solution around this called Data Perimeter, which they have discussed at various cloud conferences.

Let's dive a little deeper and see how we can recognize this problem and solve it. This problem isn’t just for applications—it also impacts workforce access. Workforce users are authenticated through Okta, and that authenticated access then goes through an AWS authorization check before access is granted.

But what happens when that authenticated session is stolen and launched from an internet location? That access should be blocked, but it passes through because post-authentication it is still seen as a valid session token.

Now, let’s look into InstaSecure and how we solve this. In this demo, we start with two terminals: an application terminal with an EC2 instance running, and an attacker terminal we’ve named Page Thompson (after the attacker behind the Capital One breach). In this case, the attacker is able to exfiltrate the session token associated with the IAM role on that EC2 instance and copy it to their own terminal running on the internet.

Once the credentials are copied over, they can be used to access from that attacker terminal. From the EC2 instance, the session token lists all the S3 buckets in that cloud account. From the attacker terminal, the copied credentials enable access to the same S3 buckets—proving that credentials are portable. Once credentials are in an attacker’s hands, there is nothing stopping them from accessing resources.

Now, let’s tackle this with InstaSecure. In InstaSecure, I’ve copied a snapshot of the dashboard where we identify credentials at risk of this problem. In this case, we have 17 IAM users, 17 IAM roles or instance profiles, and two third-party principals at risk of being abused through credential portability.

Here, the dashboard identifies the problem and suggests a remediation control. For example, a service control policy to create a network perimeter. Clicking into the Network Perimeter takes you to the control in our library of controls.

It recommends implementing Trusted Network Access for Cloud Credentials. The control clearly identifies the objective (limit network access), the applicable frameworks, and the expected behavior. This control is a primitive control implemented through an AWS service control policy, impacting IAM roles and users.

It also describes the high-level goals of these credentials, such as data perimeter enforcement, credential theft prevention, and digital sovereignty.

Clicking the control takes you through the process of creating it. End to end, it takes no more than five minutes. Once the control is created and deployed to the cloud, let’s see what happens.

Accessing the same S3 storage in that cloud account from the application terminal still works. But when the attacker attempts access from their personal terminal, the access is denied.

This is essentially what a data perimeter enforces: a trusted identity can only access a trusted resource from an expected network. With this, I conclude the demo.

We are available on AWS Marketplace. If you’d like to see the actual control creation or more demos, please reach out to us.