Inside An AWS Cloud Threat Detection SOC Lab: Simulating and Detecting Real Cloud Attacks

Malware News
1

Introduction

Cloud computing has become the backbone over time of how modern systems are built and run. As I started diving deeper into cloud security, I began to see just how much organizations and various industries depend on it, not just for convenience, but for scalability, speed, and the ability to support technologies like artificial intelligence and big data.

But the deeper I get into cloud security, the more I realize something that changed how I look at everything:

The cloud has not just changed how we build systems, but it has completely changed how attackers break into them.

What makes this shift dangerous is how subtle these attacks have become. In many cases, nothing looks obviously malicious. There’s no traditional malware, no clear red flags, just normal-looking activity. An API call here, a permission change there, a login that does not seem out of place. But underneath that normal behavior, attackers are exploiting weak identities, misconfigurations, and over-permissioned roles to quietly gain control.

And what makes this even more challenging is how attackers are evolving.

With the rise of AI, threat actors are no longer limited by time or scale. They can automate discovery, identify weak points faster, and execute attacks more efficiently than ever before. What used to take hours or even days can now happen in minutes.

That realization is what led me to build this lab.

Rather than only studying cloud attacks in theory, I wanted to understand what they actually look like in a real environment, how they happen, how they appear in logs, and how they can be detected before they cause serious damage.

The goal of this lab is simple:

To turn cloud security from theory into practice by understanding how real attacks happen and how to detect them effectively.
Feel free to explore the GitHub repository: cyberjuss/aws-threat-detection-soc-lab.

Table of Contents

  1. Understanding the Lab Architecture — Learn how data flows from start to finish before interacting with any tools.
  2. What This Lab Builds — Overview of components: CloudTrail, Config, VPC Flow Logs, Splunk, and IAM.
  3. Starting Splunk Locally with Docker — Launch Splunk in a container using Docker and confirm you can log in.
  4. Creating Splunk Indexes — Run a simple script to create the three lab-specific indexes.
  5. Installing the Splunk Add-on for AWS — Download and set up the add-on from Splunkbase.
  6. Building AWS Infrastructure with Terraform — Use build.sh to create S3 buckets, SQS queues, CloudTrail, Config, VPC Flow Logs, and IAM roles.
  7. Connecting Splunk to AWS — Add credentials, set up SQS-based S3 inputs, and verify that data is being collected.
  8. Running Attack Simulations with Stratus Red Team — Configure Stratus, trigger an attack, and confirm it appears in Splunk.
  9. Writing Detections and Building Dashboards — Create SPL searches, build dashboards, and save detections.
  10. Teardown — Safely empty S3 buckets and remove all AWS resources.
  11. Key Takeaways — Learn lessons about IAM, Terraform, debugging data pipelines, and keeping environments isolated.
  12. Challenges — Common issues you may encounter and tips for overcoming them.
Feel free to skip to phases 8 and 9, focusing on the investigation process and building relevant dashboards based on the activity that was executed.

Understanding the Lab Architecture

At a high level, this lab is built around one goal: getting AWS telemetry into Splunk in a way that’s reliable, traceable, and near real-time.

Here’s how it works in practice:

1. Telemetry is generated in AWS
Everything starts with AWS-native logging services generating telemetry across the environment:

  • CloudTrail captures API activity (IAM changes, role assumptions, key usage)
  • VPC Flow Logs record network traffic from EC2 Instance

These are your core detection data sources. If something happens, it shows up here.

2. Logs land in S3 (source of truth)
Each telemetry source writes to its own S3 bucket:

  • soc-lab-cloudtrail
  • soc-lab-config
  • soc-lab-vpcflow

S3 becomes your central storage layer where raw logs are preserved. It gives you replay capability and cleanly separates log generation from ingestion.

3. S3 triggers SQS (ingestion sig

nal)
When new logs hit S3, an event is pushed to SQS, a managed message queue that acts as a reliable ingestion signal. Each message contains metadata pointing to the exact object Splunk needs to retrieve.

This shifts you from polling to signal-based ingestion, which is far more reliable.

4. Splunk ingests via SQS
From the local Docker environment:

  • Splunk (AWS Add-on) polls SQS for new messages
  • Each message points to the exact S3 object
  • Splunk pulls, parses, and indexes the data

Result: a clean pipeline
S3 → SQS → Splunk

Data flows predictably, and every event is traceable from source to detection.

Starting Splunk Enterprise Locally with Docker

Before configuring Splunk as our SIEM, make sure the prerequisites are in place. You can find everything needed in the guides/step-by-step.md file in the repository.

At this stage, we’re bringing up Splunk locally using Docker.

Docker lets us run Splunk in an isolated container without worrying about manual installation, dependency issues, or system conflicts. It’s fast, repeatable, and easy to tear down when you’re done.

The docker-compose.yml configuration defines exactly how that container should run:

  • Pulls the official Splunk image
  • Sets default credentials (Username: admin | Password: Changeme123!)
  • Exposes ports for the UI (8000) and management API (8089)
  • Persists data using volumes so nothing is lost between restarts

For the Docker Compose configuration, refer to the soc/docker-compose.yml file in the GitHub repository.

docker compose up -d

Once executed, Docker pulls the image (if needed) and starts the container in the background.

At this point, Splunk should be available locally at http://localhost:8000 and ready to begin ingesting data.
Left: Command to start Docker. Right: Splunk container up and operational.

Creating Splunk Indexes

Now that Splunk is up and running, the next step is defining where incoming AWS data will live.

In this lab, we create three dedicated indexes where data is stored and organized:

  • aws_cloudtrail
  • aws_config
  • aws_vpcflow

To keep things simple and repeatable, index creation is automated using a small Python script. It connects to the local Splunk instance (localhost:8089) and creates each index if it doesn’t already exist.

Run the script from the scripts folder:

pip install splunk-sdk
python setup_splunk.py

Once completed, Splunk is ready to receive AWS telemetry.

Left: Indexes created via script. Right: Verified in Splunk and ready for ingestion.

Installing the Splunk Add-on for AWS

To bring AWS telemetry into Splunk, we need the Splunk Add-on for AWS.

This add-on acts as the bridge between AWS and Splunk, handling ingestion, parsing, and normalization of logs so they can be used for detection.

Once installed, it allows Splunk to pull data from services like S3 and SQS, turning raw CloudTrail, Config, and VPC Flow Logs into structured, searchable events.

Steps:

  1. Navigate to Find more apps in Splunk
  2. Search for Splunk Add-on for AWS
  3. Install and open the add-on
  4. Go to the Inputs tab to begin configuring AWS data ingestion
Installing the Splunk Add-on for AWS to enable ingestion of CloudTrail, Config, and VPC Flow Logs.

Building AWS Infrastructure with Terraform

Once Splunk is ready, the next step is building the AWS environment that will actually generate the telemetry.

Instead of manually configuring services, everything is deployed using Infrastructure as Code with Terraform. This makes the lab consistent, repeatable, and easy to tear down after testing.

The Terraform configuration provisions the core components needed for both visibility and simulation:

  • CloudTrail to capture API activity across the account
  • VPC Flow Logs to monitor network-level traffic
  • S3 buckets to store all telemetry (source of truth)
  • SQS queues to enable signal-based ingestion into Splunk
  • IAM roles and policies to support logging and simulations

This is where the lab becomes realistic. You’re no longer working with sample data; you’re generating real cloud activity that mirrors what you would see in production.

To deploy the environment, run from the infra:

./build.sh
Side note: Make sure to grab your AWS access key and secret access key, as they’ll be used later for authentication and configuration.
The setup script also installs any required dependencies and will install and configure AWS CLI and Terraform if they are not already present on your machine.

Behind the scenes, this initializes and applies the Terraform configuration, standing up the full environment in minutes.

What the Terraform Files Do (Quick Breakdown)

The Terraform configuration is split into focused files, each responsible for a specific part of the environment:

  • cloudtrail.tf — Enables CloudTrail, configures the CloudTrail bucket policy, and delivers API activity logs to S3
  • vpc_flow_logs.tf — Enables VPC Flow Logs for the default VPC and delivers network traffic logs to S3
  • s3.tf — Creates the telemetry S3 buckets for CloudTrail and VPC Flow Logs, including lifecycle rules and public access blocks
  • sqs_s3_ingestion.tf — Creates SQS queues, DLQs, queue policies, and S3 ObjectCreated notifications for SQS-based ingestion
  • iam_splunk.tf — Creates the Splunk ingestion IAM user, access key, and policies for reading S3 logs and polling SQS
  • iam_stratus.tf — Creates the Stratus IAM user, access key, and permissions used to generate simulated attack activity
  • ec2_target.tf — Creates the optional EC2 Stratus target instance, security group, IAM role, instance profile, and related outputs
  • versions.tf — Defines Terraform/provider version requirements and the AWS provider configuration
  • variables.tf — Defines reusable input variables such as region, project name, VPC Flow Logs, SQS ingestion, IAM user creation, and EC2 target settings
  • outputs.tf — Exposes core outputs such as bucket names, IAM credentials, CloudTrail details, and Stratus/Splunk identity information
  • outputs_sqs.tf — Exposes SQS queue URLs and ARNs used when configuring Splunk ingestion
For the full implementation, refer to the infra/ directory in the GitHub repository.

Ingesting logs into Splunk from AWS

With the infrastructure in place, the next step is wiring Splunk to the ingestion pipeline.

At a high level, this is where everything comes together. When a new object lands in S3, SQS sends a notification, and the Splunk Add-on for AWS uses that signal to fetch and index the data.

Add AWS Credentials

Start by adding your AWS credentials to the add-on:

  • Open the Splunk Add-on for AWS
  • Navigate to Configuration → AWS Account
  • Add the soc-lab-splunk-addon access key and secret

This allows Splunk to interact with SQS and S3 securely.

Create Data Inputs

Next, configure inputs so Splunk knows what to ingest.

Go to: Inputs → Create New Input → SQS-based S3

Each input tells Splunk:

  • Which queue to monitor
  • Which S3 objects to pull
  • Where to store the data
  • Ensure the SQS Queue Name matches the CloudTrail S3 event notification queue created in AWS (not DLQ), so Splunk can receive alerts when new log files arrive.
  • DLQ (Dead Letter Queue) is important because failed or unreadable messages are sent there instead of being lost, allowing retry and troubleshooting.
  • Ensure the AWS Region matches where the S3 bucket and SQS queue were deployed.

Should see the appropriate inputs.

Validate Ingestion

After a few minutes, verify that data is flowing:

index=aws_cloudtrail earliest=-30

Repeat for:

  • aws_vpcflow

Initial delivery can take a minute or two, so retry if results are empty.

For more details: aws-threat-detection-soc-lab/guides/step-by-step.md at main · cyberjuss/aws-threat-detection-soc-lab · GitHub

Running Attack Simulations with Stratus Red Team

Now, this is where all the fun begins! Where we get to run some tests and detect them in Splunk

For context, Stratus Red Team is an open-source tool used to safely simulate real-world cloud attacks in AWS environments, helping security teams test detections and validate their monitoring capabilities.

Let’s talk about the configure-stratus.sh script and what it does.

  • Verifies required tools like aws, awk, and sed are installed
  • Loads AWS credentials from .env.stratus (generated during lab setup)
  • Determines the correct AWS region (or defaults to us-east-1 if not found)
  • Creates a stratus-lab AWS CLI profile
  • Exports AWS_PROFILE and AWS_REGION for your session

To get this up and running:

cd attacks/
./configure-stratus.sh 
stratus list --platform aws
For more details: aws-threat-detection-soc-lab/guides/step-by-step.md at main · cyberjuss/aws-threat-detection-soc-lab

Threats

This section highlights key attack scenarios simulated in the lab to demonstrate how different threat types appear across AWS telemetry.

Ensure to run these after executing stratus list --platform aws.
  • Privilege Escalation (CloudTrail)
    Simulates unauthorized creation of an administrative IAM user.
# Run the attack: creates a new IAM user with admin privileges
stratus detonate aws.persistence.iam-create-admin-user

# Clean up: removes the created IAM user and attached policies
stratus cleanup aws.persistence.iam-create-admin-user
  • S3 Data Exposure (CloudTrail)
    Simulates modifying a bucket policy to allow external access.
# Run the attack: updates S3 bucket policy to allow public/external access
stratus detonate aws.exfiltration.s3-backdoor-bucket-policy

# Clean up: restores/removes the malicious bucket policy
stratus cleanup aws.exfiltration.s3-backdoor-bucket-policy
  • Network Visibility Evasion (VPC Flow Logs)
    Simulates removing VPC Flow Logs to reduce network visibility.
# Run the attack: removes or disables VPC Flow Logs
stratus detonate aws.defense-evasion.vpc-remove-flow-logs

# Clean up: re-enables or restores VPC Flow Logs configuration
stratus cleanup aws.defense-evasion.vpc-remove-flow-logs

Writing Detections and Building Dashboards

Now that we’ve run these threat simulations, let’s see how they show up in our logs and build a dashboard to track and understand them.

Privilege Escalation: New Admin User Created (CloudTrail)

Before investigating, we must understand the threat. Privilege escalation occurs when an insider or attacker gains higher levels of access than they are authorized to have. In this scenario, the attacker created a new administrator IAM user to obtain elevated control over the Amazon Web Services environment.
This now allows them to access sensitive data, disrupt cloud services, assign backdoor roles or policies, and delete critical workloads.

Fields

In Splunk Enterprise or any SIEM platform, these are commonly known as searchable fields:

  • src_user — user or identity performing the action
  • src_ip — source IP address of the request
  • eventName — AWS API action that occurred
  • userAgent — method/tool used (Console, CLI, SDK, Terraform, etc.)
  • _time — timestamp of the event

Key Value Pairs of Interest

Since we are reviewing Amazon Web Services CloudTrail logs regarding the creation of an admin IAM user, these event values are high priority for privilege escalation investigations:

  • CreateAccessKey — creation of new programmatic credentials
  • CreateUser — creation of a new IAM user
  • AttachUserPolicy — attaching permissions directly to a user
  • PutUserPolicy — adding inline permissions to a user
  • AddUserToGroup — placing a user into a privileged IAM group

These values are important because they may indicate an attacker attempting to establish persistence, elevate privileges, or gain unauthorized long-term access.

Now, let's put the query together:

index="aws_cloudtrail"
(eventName IN ("AddUserToGroup","PutUserPolicy","AttachUserPolicy","AttachRolePolicy",
"CreateUser","CreateAccessKey")
| bin _time span=5m
| stats count values(eventName) as actions values(userAgent) as userAgent by _time src_user src_ip user
| sort - _time

What it does:

  • index="aws_cloudtrail" searches CloudTrail logs
  • eventName IN (...) filters for IAM privilege escalation and persistence activity
  • bin _time span=5m groups events into 5-minute windows
  • stats count ... by _time src_user src_ip user summarizes suspicious activity by time, user, and source IP
  • sort - _time Shows the newest activity first

Dashboards for Suspicious IAM Activity

Now, let’s focus specifically on suspicious IAM activity and privilege escalation. I decided to run several attack methods and successfully detected the following:

  • Unauthorized IAM user creation
  • Administrator privilege assignment
  • Access key creation for persistence
  • Suspicious role policy changes
  • AssumeRole trust policy abuse
  • Console logins without MFA
  • Identity creation and cleanup activity after execution
Suspicious IAM Identity Creation & Persistence Dashboard

Check out the report: aws-threat-detection-soc-lab/reports/identity-access-security-2026–04–21.pdf at main · cyberjuss/aws-threat-detection-soc-lab

To investigate additional activity, including potential S3 data exposure and network visibility evasion that we ran earlier, you can use the following query:

index="aws_cloudtrail" (eventName IN ("DeleteTrail","DeleteFlowLogs","AttachUserPolicy","AttachRolePolicy",
"CreateUser","CreateAccessKey","PutPublicAccessBlock","PutBucketPolicy","GetBucketPolicy"))
| bin _time span=5m
| stats count values(eventName) as actions values(userAgent) as userAgent by _time src_user src_ip user
| sort - count

Should now be exposed to other interesting cloud activities.

Feel free to build on the examples above and create your own queries to investigate other suspicious activity generated using Stratus Red Team.
To continue expanding the project, I will be working on Part II, which will focus on cloud threats targeting VPC Flow Logs and how to investigate network traffic in the Cloud.

Teardown

Great! After simulating both the attacker and building detections as a threat detection security engineer, it’s time to clean up the environment.

One of the benefits of this lab is that everything can be easily torn down using a single script.

From the infra directory, run:

./destroy.sh
You will be prompted with the option to keep IAM user keys to avoid recreating them in future runs.

Just like that, your environment is all cleaned up!

Key Takeaways

So in a nutshell, what did we do? Let’s break it down so we can clearly understand and speak to it:

  • Infrastructure as Code keeps everything repeatable.
    With a single ./infra/build.shtTerraform sets up CloudTrail, VPC Flow Logs, S3, SQS, IAM, and the Stratus EC2 target. This mirrors how real SOC teams can build environments that can be recreated, tested, and audited on demand.
  • Two pipelines, clear separation.
    CloudTrail and VPC Flow Logs each have their own bucket, queue, and Splunk index (aws_cloudtrail, aws_vpcflow). This keeps permissions, retention, and detections isolated and easier to manage.
  • Splunk Add-on handles ingestion reliably.
    Using SQS notifications tied to S3 (GetObject) keeps ingestion separate and resilient. It’s a common production pattern that helps prevent data loss during spikes or delays.
  • Stratus Red Team makes testing real.
    By running configure-stratus.sh and running attacks, we can simulate real TTPs and build detections for better insight. From attack to telemetry to detection, all in a safe environment.
  • Teardown reinforces good habits.
    Lastly, running ./infra/destroy.sh cleans up resources and lets us choose whether to keep IAM keys, reinforcing the importance of cost control and proper cleanup in real-world cloud environments.

Conclusion

Ladies and gentlemen, thank you for making it this far! That brings us to the end of the AWS Threat Detection SOC Lab.

I had a great time building this and hope you found it valuable as well. I’ll definitely continue to expand on this lab and deepen my understanding of cloud security.

Feel free to share any comments, ideas, or questions — your feedback truly means a lot. Thank you!

References

Inside An AWS Cloud Threat Detection SOC Lab: Simulating and Detecting Real Cloud Attacks was originally published in Detect FYI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction to Malware Binary Triage (IMBT) Course

Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.

Enroll Now and Save 10%: Coupon Code MWNEWS10

Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.

Article Link: https://detect.fyi/inside-an-aws-cloud-threat-detection-soc-lab-simulating-and-detecting-real-cloud-attacks-a11e0ea98430?source=rss----d5fd8f494f6a---4