Stratus Red Team — Cloud Attack Emulation

Endpoint adversary emulation (Atomic Red Team, CALDERA) doesn’t cover cloud attacks. A threat actor who compromises an AWS IAM key or exploits an Azure app consent vulnerability doesn’t generate Sysmon events — they generate CloudTrail entries, Azure Activity Log records, and GCP audit logs. Stratus Red Team was built to validate those detections.

Why Cloud Emulation Is Different

Dimension	Endpoint (Atomic RT)	Cloud (Stratus)
Attack surface	Windows/Linux processes	Cloud APIs (IAM, storage, compute)
Primary telemetry	Sysmon, Windows Events	CloudTrail, Activity Log, GCP Audit
Log delivery delay	Near-real-time	5–15 minutes (CloudTrail)
Event structure	ProcessCreate, FileCreate	API calls (eventName, userIdentity)
Test environment	Lab VM	Real cloud account (sandbox)
Cleanup complexity	Delete files/registry keys	Destroy IAM users, S3 buckets, etc.

Important: Stratus requires a real cloud account (AWS free tier works). It creates and destroys cloud resources during tests. Use a dedicated sandbox account — never a production account.

Installation

# Install Stratus Red Team
brew install datadog/stratus-red-team/stratus-red-team   # macOS
# or
go install github.com/DataDog/stratus-red-team/v2/cmd/stratus@latest

# For AWS — configure credentials
export AWS_DEFAULT_REGION=us-east-1
aws configure  # or use AWS CLI profile

# List available attack techniques
stratus list

# List only AWS techniques
stratus list --platform aws

The Stratus Workflow

Phase 1: Warmup

# Prepare infrastructure for the attack scenario
stratus warmup aws.credential-access.secretsmanager-retrieve-secrets

# Stratus creates:
# → IAM user with GetSecretValue permissions
# → Sample secret in AWS Secrets Manager
# Output: "Warmed up attack technique"

Phase 2: Detonate

# Execute the attack
stratus detonate aws.credential-access.secretsmanager-retrieve-secrets

# Stratus executes:
# → IAM user calls secretsmanager:GetSecretValue
# → CloudTrail logs: eventName=GetSecretValue, userIdentity=malicious-iam-user

# Output:
# Retrieving secret 'stratus-red-team-secret'
# Successfully retrieved secret value

Phase 3: Cleanup

# Destroy all created resources
stratus cleanup aws.credential-access.secretsmanager-retrieve-secrets

# Deletes:
# → IAM user
# → Secret in Secrets Manager
# → Any generated credentials

Key Attack Scenarios by Cloud

AWS

# IAM credential exfiltration via console access
aws.credential-access.console-login-without-mfa

# Backdoor IAM user creation
aws.persistence.backdoor-iam-user

# S3 data exfiltration
aws.exfiltration.s3-backdoor-bucket-policy

# CloudTrail tampering (disable logging)
aws.defense-evasion.cloudtrail-stop

# Lambda execution for persistence  
aws.persistence.malicious-lambda-extension

Azure

# OAuth app consent grant (T1550.001)
azure.credential-access.azure-ad-oauth-phishing

# Service Principal credentials added
azure.persistence.add-service-principal-credentials

# VM run command (lateral movement)
azure.lateral-movement.vm-run-command

GCP

# Custom IAM role with escalated privileges
gcp.privilege-escalation.create-custom-iam-role

# Service account key exfiltration
gcp.credential-access.service-account-key-exfil

# GCS bucket access
gcp.exfiltration.gcs-object-access

Validating Cloud Detections

After detonating a scenario, validate in your cloud SIEM:

-- AWS Athena query for CloudTrail (if using Athena+S3)
SELECT eventtime, eventname, useridentity.arn, sourceipaddress
FROM cloudtrail_logs
WHERE eventname = 'GetSecretValue'
  AND eventtime BETWEEN '2026-05-20T10:00:00Z' AND '2026-05-20T11:00:00Z'
ORDER BY eventtime DESC
LIMIT 10;

Or in a SIEM receiving CloudTrail:

# Splunk - check CloudTrail for Secrets Manager access
index=cloudtrail eventName=GetSecretValue
  earliest="-30m"
| table _time, eventName, userIdentity.arn, sourceIPAddress

Expected detection rule (Sigma):

title: AWS Secrets Manager GetSecretValue from Anomalous Principal
logsource:
  product: aws
  service: cloudtrail
detection:
  selection:
    eventName: GetSecretValue
    eventSource: secretsmanager.amazonaws.com
  filter_known:
    userIdentity.arn|contains: 'arn:aws:iam::123456789:role/app-production'
  condition: selection and not filter_known

Stratus with Other Cloud Tools

For deeper cloud detection validation, combine Stratus with:

Tool	Purpose
pacu	AWS post-exploitation framework — more realistic attack chains
ROADtools	Azure AD attack scenarios (consent phishing, token theft)
gcp-goat	Intentionally vulnerable GCP environment for practice
CloudGoat	Vulnerable AWS environments for attacker simulation

Stratus is focused on clean, documented scenarios with proper cleanup. Pacu and ROADtools simulate more complex, realistic attacks.

Stratus Red Team— DataDog Stratus Red Team GitHub— GitHub

Retrieval Practice

You run `stratus detonate aws.defense-evasion.cloudtrail-stop` and wait 20 minutes. You check CloudTrail — but there are no events logged after the detonate time. Why might this be, and how do you investigate?

Reveal answer

If CloudTrail was stopped by the attack (StopLogging API call), CloudTrail stops recording events — including evidence of the attack itself. This is the detection paradox of CloudTrail tampering: the attack that disables CloudTrail leaves no CloudTrail trace after the StopLogging event. What you should find: a StopLogging event IN CloudTrail just before the gap. If even that is absent, the trail itself may have been deleted. Investigation: check if the CloudTrail trail still exists and is enabled (AWS Console → CloudTrail → Trails). Check S3 bucket for the last delivered log file — the timestamp of the last file tells you when logging stopped. The detection for this should fire on the StopLogging event itself (the last event before the gap), not on the absence of subsequent events.

Retrieval Practice

A Stratus test for AWS IAM privilege escalation (`aws.privilege-escalation.create-admin-policy`) completes. Your Sigma rule for IAM policy creation (eventName: CreatePolicy AND policyDocument contains '*') doesn't fire. CloudTrail has the CreatePolicy event. What are the two most likely causes in a cloud detection context?

Reveal answer

(1) Field extraction difference: Sigma cloud rules often need to match nested JSON fields. The policyDocument field in CloudTrail is stored as a URL-encoded or escaped JSON string within the requestParameters. Your rule may be checking `policyDocument|contains: '*'` but the actual CloudTrail field is `requestParameters.policyDocument` (or just `requestParameters` as a string blob). Check the exact field path in your SIEM against what the rule expects. (2) Logsource mismatch: the Sigma rule may target `service: cloudtrail` but your SIEM indexes CloudTrail events under a different sourcetype or index pattern than the pipeline maps. Run the raw CloudTrail event query manually and check which index/sourcetype it landed in, then compare to what the converted Sigma rule queries.