Elastic Security Labs' latest research on cloud threat emulation cuts through a problem I've watched plague detection engineering teams for years: organizations fire atomic tests into their cloud environments, watch the alerts (or the silence), and call it validation. That isn't emulation — it's detonation without engineering discipline. The plan-first methodology outlined in this research — scope, victim model, telemetry, coverage, cleanup — is the difference between a detection program that matures and one that churns.
Why does this matter right now? Cloud intrusions continue to accelerate. Adversaries have fully industrialized against AWS, Azure, and GCP: stolen session tokens, IAM privilege escalation, CloudTrail tampering, and living-off-the-cloud techniques using native CLIs are standard tradecraft in 2026 incident response engagements. If your detection coverage for these techniques is assumed rather than validated, you are operating on faith. Emulation done correctly converts assumptions into evidence. This post breaks down the methodology, shows you how to leverage AI for emulation automation without losing engineering rigor, and provides the detection content you need to validate the most commonly emulated cloud behaviors.
Technical Analysis: The Plan-First Emulation Methodology
The core thesis of the research is that cloud threat emulation is a detection engineering discipline, not a red team side quest. Every emulation should be planned against five pillars:
1. Scope
Define precisely what you're emulating and why. Scope is anchored to threat intelligence — the TTPs your threat model actually cares about (mapped to MITRE ATT&CK Cloud matrices), the cloud platforms you operate (AWS, Azure, GCP, or multi-cloud), and the blast radius you're willing to accept in a production-adjacent environment. A scoped emulation answers: "Are we validating detection of IAM credential theft against our AWS organization, or are we just running stratus-red-team modules because they're convenient?"
2. Victim Model
The victim model defines the identity and resource posture the adversary operates against. In cloud terms this means: pre-staged IAM users or roles with realistic permission sets (not admin-everything service accounts), representative workloads, and realistic data classification. A lazy victim model — an over-privileged test principal — produces emulations that overstate attacker capability and generate detection requirements that don't match your real environment's telemetry.
3. Telemetry
This is where most programs fail. Before you detonate anything, you must confirm the telemetry pipeline actually captures the events your emulation will generate. In AWS that means validating CloudTrail is enabled across all regions, management events AND data events (S3, Lambda, EBS) are logged where relevant, GuardDuty findings flow to your SIEM, and VPC Flow Logs exist for network-based techniques. Detonating an emulation into a telemetry void produces a false negative that looks like a detection gap but is actually a collection gap — and engineers will burn days tuning rules that were never the problem.
4. Coverage
Map emulation outcomes to detection coverage explicitly. Each emulated technique gets a coverage verdict: detected (rule fired, fidelity acceptable), telemetry-present-but-undetected (collection works, analytics missing), or telemetry-absent (collection gap). This mapping feeds directly into detection backlog prioritization — the emulation program becomes your coverage measurement system, not a quarterly fire drill.
5. Cleanup
Cloud emulations leave residue: IAM users, access keys, roles, policies, S3 buckets, security groups, Lambda functions. Orphaned emulation artifacts are themselves attack surface — I've investigated incidents where a forgotten test IAM user with an active access key became the adversary's entry point months later. Cleanup must be automated, verifiable, and audited. If your emulation framework can't prove it cleaned up, it didn't.
AI in the Loop — Correctly Leveraged
The research addresses AI-assisted emulation automation, and the framing is right: AI is excellent at generating emulation plans from threat intelligence (translating an adversary campaign report into a sequenced set of ATT&CK-mapped procedures), drafting infrastructure-as-code for victim models, writing detection rule candidates from observed telemetry, and generating cleanup manifests. AI is dangerous when used to autonomously execute against cloud environments without a human-reviewed plan, or when its generated detections are deployed without fidelity testing. The model is copilot-for-engineering, not autopilot-for-execution — despite the headline, context is everything.
Detection & Response
Below is validation-grade detection content for the three cloud behaviors that every emulation program should cover first, because they are the most consistently abused in real intrusions: CloudTrail tampering, IAM credential proliferation, and non-MFA console access. Run your emulations against these, then verify your analytics fire.
Sigma Rules
---
title: AWS CloudTrail Logging Disabled or Trail Deleted
id: 3c9f2a71-8b4d-4e5a-9c1f-7d2e6a8b0f31
status: experimental
description: Detects attempts to stop CloudTrail logging, delete a trail, or modify event selectors — a hallmark defense-evasion technique seen in cloud intrusions and validated by threat emulation.
references:
- https://attack.mitre.org/techniques/T1562/008/
- https://www.elastic.co/security-labs/threat-command/cloud-threat-emulation-methodology
author: Security Arsenal
date: 2026/01/15
tags:
- attack.defense_evasion
- attack.t1562.008
logsource:
product: aws
service: cloudtrail
detection:
selection:
eventSource: cloudtrail.amazonaws.com
eventName:
- StopLogging
- DeleteTrail
- PutEventSelectors
filter_known_automation:
userIdentity.type: AssumedRole
userIdentity.sessionContext.sessionIssuer.userName|contains:
- 'config-rule'
- 'securityhub'
condition: selection and not filter_known_automation
falsepositives:
- AWS Config remediation and Security Hub automated actions
- Infrastructure-as-code pipelines that manage trail configuration
level: high
---
title: AWS IAM Credential and Access Proliferation Burst
id: 8e4b1d62-3f7a-4c9e-b5d2-1a6f9c0e7b42
status: experimental
description: Detects a single IAM principal performing multiple credential creation or privilege modification actions in a session — consistent with post-compromise persistence established via access keys and login profiles.
references:
- https://attack.mitre.org/techniques/T1098/001/
- https://www.elastic.co/security-labs/threat-command/cloud-threat-emulation-methodology
author: Security Arsenal
date: 2026/01/15
tags:
- attack.persistence
- attack.privilege_escalation
- attack.t1098.001
logsource:
product: aws
service: cloudtrail
detection:
selection:
eventSource: iam.amazonaws.com
eventName:
- CreateAccessKey
- CreateLoginProfile
- UpdateLoginProfile
- AttachUserPolicy
- AddUserToGroup
filter_readonly:
errorCode: '*'
condition: selection and not filter_readonly
falsepositives:
- IAM identity lifecycle automation (onboarding pipelines)
- Break-glass account administration
level: high
---
title: AWS Console Login Without MFA
id: 5f2a8c93-6d1b-4e7a-a3f8-9c4d2e1b6a53
status: test
description: Detects successful AWS console sign-ins where MFA was not used. High-value validation target for emulation of stolen-credential access; tune against sanctioned break-glass accounts only.
references:
- https://attack.mitre.org/techniques/T1078/004/
- https://www.elastic.co/security-labs/threat-command/cloud-threat-emulation-methodology
author: Security Arsenal
date: 2026/01/15
tags:
- attack.initial_access
- attack.t1078.004
logsource:
product: aws
service: cloudtrail
detection:
selection:
eventSource: signin.amazonaws.com
eventName: ConsoleLogin
additionalEventData.MFAUsed: 'No'
responseElements.ConsoleLogin: Success
falsepositives:
- Break-glass accounts (allowlist explicitly, never broadly)
- Legacy federated login flows that assert MFA upstream
level: medium
KQL — Microsoft Sentinel Hunt Queries
These queries validate emulation outcomes and hunt for the same behaviors in production. The first targets CloudTrail events ingested via the AWS connector; the second hunts AWS CLI reconnaissance on endpoints, catching the adversary's tooling at the host layer where CloudTrail attribution gets murky.
// CloudTrail tampering and IAM credential bursts — emulation validation + production hunt
// Works against the AWS CloudTrail data connector table in Sentinel
let Lookback = 24h;
AWSCloudTrail
| where TimeGenerated > ago(Lookback)
| where EventName in~ ("StopLogging", "DeleteTrail", "PutEventSelectors",
"CreateAccessKey", "CreateLoginProfile", "UpdateLoginProfile", "AttachUserPolicy")
| where isempty(ErrorCode) // successful calls only — failed attempts are noise here
| extend UserArn = tostring(UserIdentityArn),
SourceIP = tostring(SourceIpAddress)
| summarize Actions = make_set(EventName), ActionCount = dcount(EventName),
FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
by UserArn, SourceIP, AwsRegion, bin(TimeGenerated, 1h)
| where ActionCount >= 2 or Actions has_any ("StopLogging", "DeleteTrail")
| sort by ActionCount desc;
// Endpoint-layer hunt: AWS CLI reconnaissance and credential access patterns
// Catches adversaries operating cloud tooling from compromised hosts
DeviceProcessEvents
| where TimeGenerated > ago(24h)
| where FileName =~ "aws.exe" or ProcessCommandLine has "aws "
| where ProcessCommandLine has_any (
"sts get-caller-identity", // identity recon — nearly always adversary or emulation
"iam create-access-key",
"iam attach-user-policy",
"iam create-login-profile",
"secretsmanager get-secret-value",
"ssm get-parameter"
)
| project TimeGenerated, DeviceName, AccountName, FileName,
ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessAccountName
| sort by TimeGenerated desc;
Tune the endpoint query by excluding your known automation accounts and CI/CD runner identities — sts get-caller-identity is benign in pipelines but almost never runs interactively on a user workstation outside of an engineer's session or an adversary's hands-on-keyboard phase. That distinction is exactly what your emulation program should be testing: does your SOC differentiate the two?
Velociraptor VQL — Endpoint Artifact Hunt
When an emulation or a real intrusion involves endpoint-to-cloud pivot, forensic evidence lands on the host: AWS CLI processes, credentials file access, and session caches. This hunt checks both.
-- Hunt for AWS CLI execution and cloud credential artifacts on endpoints
-- Validates emulation execution and detects real adversary cloud pivots
-- Part 1: Live AWS CLI process execution
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)aws(\.exe)?$'
OR CommandLine =~ '(?i)(sts get-caller-identity|iam create-access-key|iam attach-user-policy|secretsmanager get-secret-value)'
-- Part 2: Cloud credential files touched recently (potential theft staging)
-- Run against user profile .aws / .azure directories
SELECT FullPath, Size, Mtime, Atime
FROM glob(globs=[
'C:/Users/*/.aws/credentials',
'C:/Users/*/.aws/config',
'C:/Users/*/.azure/accessTokens.json',
'/home/*/.aws/credentials',
'/root/.aws/credentials'
])
WHERE Mtime > now() - 86400 // modified in last 24h
Emulation Hygiene and Telemetry Validation Script
Run this before and after every emulation exercise. It validates that your telemetry pipeline is live (so emulations don't detonate into a void) and audits for emulation residue (so your test artifacts don't become the next breach vector).
#!/bin/bash
# cloud-emulation-hygiene.sh — pre/post emulation validation
# Verifies telemetry is flowing and audits for leftover emulation artifacts.
# Requires: aws CLI v2, jq. Read-only by default.
set -euo pipefail
echo "=== [1/4] CloudTrail status across all regions ==="
for trail in $(aws cloudtrail describe-trails --include-shadow-trails \
--query 'trailList[].TrailARN' --output text); do
aws cloudtrail get-trail-status --trail-arn "$trail" \
--query '{Trail: TrailARN, Logging: IsLogging, LatestDelivery: LatestDeliveryTime}'
done
# Any trail with Logging=false or stale LatestDeliveryTime is a telemetry VOID.
# Do not detonate emulations until resolved.
echo "=== [2/4] GuardDuty detector status ==="
for detector in $(aws guardduty list-detectors --query 'DetectorIds[]' --output text); do
aws guardduty get-detector --detector-id "$detector" \
--query '{Detector: '"$detector"', Status: Status}'
done
echo "=== [3/4] Audit: emulation-tagged resources and suspicious access keys ==="
# Find IAM users tagged as emulation artifacts that still exist
echo "--- Emulation-tagged IAM users (should be EMPTY post-exercise) ---"
aws iam list-users --query 'Users[].UserName' --output text | tr '\t' '\n' | while read -r u; do
tags=$(aws iam list-user-tags --user-name "$u" \
--query 'Tags[?Key==`Purpose` && Value==`threat-emulation`]' --output text 2>/dev/null || true)
[ -n "$tags" ] && echo "RESIDUE: emulation user still present: $u"
done
echo "--- Access keys older than 90 days (rotation + residue check) ---"
aws iam list-users --query 'Users[].UserName' --output text | tr '\t' '\n' | while read -r u; do
aws iam list-access-keys --user-name "$u" \
--query "AccessKeyMetadata[?CreateDate<='$(date -d '90 days ago' +%Y-%m-%d)'].{User: UserName, Key: AccessKeyId, Created: CreateDate, Status: Status}" \
--output table
done
echo "=== [4/4] Recent CloudTrail management events (is telemetry flowing NOW?) ==="
aws cloudtrail lookup-events --max-results 5 \
--query 'Events[].{Time: EventTime, Name: EventName, User: Username}' --output table
echo "=== DONE. Review RESIDUE lines and telemetry gaps before detonation. ==="
Remediation: Operationalizing the Methodology
There is no patch for a methodology gap — remediation here means institutionalizing the plan-first discipline. Concretely:
- Codify emulation plans as reviewable artifacts. Every emulation gets a written plan — scope, victim model, expected telemetry, target detections, cleanup manifest — reviewed by both a detection engineer and a cloud platform owner before execution. AI can draft these from threat intelligence reports; humans approve them.
- Gate detonation on telemetry validation. No emulation executes until the hygiene script above (or equivalent) confirms CloudTrail, GuardDuty, and SIEM ingestion are live. Log the validation output alongside the emulation results — your coverage verdicts are only trustworthy if the collection layer was proven healthy.
- Enforce MFA and eliminate long-lived credentials. Non-MFA console access should be detectable (rule above) and then eliminated via SCPs. Prefer IAM Identity Center with short-lived sessions over access keys; where keys are unavoidable, enforce 90-day rotation and tag-based ownership.
- Automate cleanup with verification. Every emulation artifact is created tagged (
Purpose=threat-emulation,ExerciseID=<id>). Cleanup is a post-exercise job that deletes by tag and then re-audits to prove zero residue. Treat any surviving emulation credential as an incident, not an oversight. - Feed coverage verdicts into the detection backlog. Undetected-but-telemetried techniques become detection engineering tickets with the emulation's actual CloudTrail events attached as ground truth — the highest-quality rule development input you can get.
- Constrain AI automation. Use AI for plan generation, IaC drafting, and detection candidate authoring. Never grant AI-generated emulation code execution rights against production-adjacent environments without human review, and never deploy AI-drafted detections without fidelity testing against both the emulation telemetry and baseline noise.
The organizations that get breached through the cloud in 2026 are rarely the ones without tools — they're the ones whose detection coverage was assumed. Plan-first emulation, validated telemetry, and disciplined cleanup is how you replace assumption with evidence.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.