Cloud threat emulation is more than detonation. A plan-first methodology for cloud detection engineering: scope, victim model, telemetry, coverage, cleanup. Learn how to properly leverage AI to automate your emulations.
Cloud threat emulation needs more than detonation
Cloud threat emulation is not firing an API call and calling it done. Public practice already says the quiet part out loud. Intelligence-driven impersonation of real adversary TTPs, in a controlled environment, to test and improve defenses;. The MITRE Center for Threat-Informed Defense Adversary Emulation Library is a clear expression of that plan-first shape. We build on similar pillars, then alter the approach for cloud detection engineering: scope in layers, threat model, execute, verify telemetry, and tear down clean.
In cloud, SaaS, and identity environments, that same discipline matters even more. There is often no malware sample, sandbox, or incident artifact to replay. You research the behavior. Threat models it all, including the victim’s environment. You provision the right resources and identities, execute, and capture the telemetry. Then you ask the only question that matters for detection engineering: "Is this data actually useful for detection?”
Endpoint atomic testing can get away with a host and a payload. Cloud threat emulation for detection engineering cannot. Identities, control-plane APIs, eventual consistency, and logging that ships half-off change what “reproducing the behavior” even means. That is the so what. Cloud threat emulation/detection engineering (TE/DE) needs its own approach, not a port of the endpoint habit.
Plenty of tooling helps you perform the nefarious bits, whether or not it cleanly mimics a red team or a named adversary. Stratus Red Team, Atomic Red Team, CloudGoat, ROADTools, Splunk ATT&CK Range, and a pile of homegrown scripts all get used that way. Anyone who has done this work knows how much planning and testing, and cleanup still sits around the detonation itself. Cloud detection is also not "call an API, alert on that API." That is a fast path to noise and the principal detection engineer’s office. IAM context, prerequisites, expected outcomes, and realistic execution all matter. Poor emulation produces poor data. Poor data produces poor detections.
A daily note from us to you:
Cloud threat emulation is not the act of detonating a technique. It is the process of creating the right model, identity, environment, permissions, resources, and telemetry conditions to reproduce adversary behavior and turn the result into meaningful detection engineering outcomes.
This post is Part 1 of our cloud threat emulation series: our cloud-focused take on that methodology, built on public threat-emulation pillars and altered where cloud and detection engineering force different habits. Part 2 will cover agents, skills, and AI executing it in practice. We know boring stuff first sucks. Do it anyway. Context and breakdown come before an ambitious agent gets anywhere useful.
What cloud threat emulation actually requires
Emulation is plan-first: objectives, threat model, victim model, operational flow, then execution.
Scope in layers: atomic, micro, or full; same lifecycle, different depth.
Start from a compromised identity. Admin sessions and out-of-order API calls produce pretty demos and bad detection data.
Telemetry and coverage are outputs that you verify, not assumptions that you write rules against.
Automation can remove repetitive work. Engineers still own realism and assumptions, in addition to whether a detection is worth shipping.
Where practice usually stalls
In theory it's a short loop: research, plan, run, observe, and improve. Center for Threat-Informed Defense (CTID) plans, atomic tests, and report-derived flows all say that. In cloud the middle gets fuzzy.
Starting point varies. Off-the-shelf tool aimed at a tenant, colorful CLI, cool ASCII art, done. Or a tool that scaffolds infra and chains toward a micro or full plan. Or last quarter's script, half-finished Terraform, manual CLI after a report. The shapes differ, but the stall is the same. Most of the day is still spent on victim and threat modeling, then proving the result was useful for detection.
Tools that stop at detonation leave you with an attack fired off and not enough said about what landed in the logs, whether logging was on. They also don’t tell you whether the behavior is detectable. And that is after the tedious part. A break-glass account, the right compromised identity, assumed network settings from thin blogs, data worth stealing, logging actually configured. A tool might spare you some clicking. It rarely spares you proper planning. Don't get us started on virtual networks where resources talk to each other…successfully.
Then the attack, and it lasts about four minutes. The field name isn't what you remembered, and the coverage board still looks green. Then the detection question arrives with the batteries already flat.
Public practice isn't wrong. Cloud detection engineering just needs the same plan-first discipline that public practice uses, plus extras cloud makes non-optional: victim realism, threat modeling, IAM progression, telemetry verification, coverage triage, and cleanup that can fail closed. Without it, your emulations will either lack actual meaning/context or be in-accurate to the intended behavior you want to capture telemetry for.
A cloud threat emulation methodology
We try to treat useful cloud emulation as one lifecycle:
Define the objective and scope (atomic, micro, or full).
Research and threat-model the behavior.
Model the victim environment and starting IAM.
Build the operational flow.
Provision a controlled lab.
Execute with context.
Verify telemetry against real events.
Evaluate detection coverage.
Document assumptions and findings.
Clean up completely, and then repeat
The cloud-specific work is making the threat and victim modeling, IAM, environment, telemetry, and teardown first-class instead of afterthoughts.
Treat it as a state machine, not a vibe. You cannot execute what you have not deployed. You should not redeploy on top of a half-dead environment. Cleanup has to handle both planned infrastructure and attacker-created leftovers (orphaned resources). After cleanup, redeployment is always valid. Skipping states is how labs get contaminated and findings get soft. Then your telemetry analysis becomes a cauldron of alphanumeric spaghettios with no clear distinction between overlapping emulations.
Start with the question and the scope
Not every emulation starts the same way. Pick the question, then pick the depth:
Mode | Question | Typical input |
|---|---|---|
Intelligence-driven | Can we reproduce behavior described in public research or a CTID-style plan? | Blog, advisory, campaign report, emulation plan |
Rule-driven | Does an existing rule actually fire on the intended behavior? | Detection rule TOML / query |
Coverage-driven | Which known techniques do we not currently detect? | ATT&CK or data-source gap |
Hypothesis-driven | Could an adversary realistically abuse this service or permission? | Threat model of a service / IAM pattern |
We prefer to think in three layers of scope:
Atomic: quick and dirty. One technique, one clear signal question.
Micro: more planned. Still missing a larger scope, but it can pull in other resources, especially when chaining one or two behaviors (for example discover > stage > exfil).
Full: larger scope. End-to-end at times, and it can cover multiple planes and surfaces.
Public libraries map onto this in different ways. Atomic Red Team lives mostly in the first layer, while CTID micro and full plans sit in the other two. We use the three-layer split because it matches how we actually scope cloud work, not because one repo owns the vocabulary.
What changes is the source material and how wide you cast the net; the rest of the lifecycle doesn’t change. Keep it tool-agnostic. The plan is the product, and the tool is optional scaffolding.
Intelligence-driven work should stay faithful to the source. Don’t invent victim details that make the demo easier. Rule-driven work is different. The rule tells you API actions and fields, but you often infer identity type, permissions, and environment. Flag those assumptions. Hypothesis-driven work is where judgment matters most. Model what a real adversary would do, almost always from a stolen identity or compromised instance, not portal clicks. All of this is operations-plane API work.
Model the threat and the environment first
How hard this section is depends on scope.
An atomic run of a red-teamer proof of concept (PoC) is often behavior-driven so one technique, one signal question, thin environment. You still need a plan, but you are not rebuilding a hybrid enterprise to prove CreateAccessKey
lands in CloudTrail.
A micro or full run is different. CTID-style plans, and intelligence-driven writeups of long compromises, force threat modeling and victim accuracy to carry the exercise. If Microsoft or another shop publishes end-to-end research across hybrid Windows, Entra, AD, and M365, skipping environment fidelity is how you get a demo that fires APIs and teaches you almost nothing about detection. The larger the scope, the more variables matter, and the less you can cheat with a god-mode principal that can do everything from step one.
Before executing anything, answer the planning questions:
What is the adversary attempting to achieve?
What does the source actually describe (and what is it silent on)?
What resources and controls exist in the victim environment?
What access path is available at the start, and what has to be earned later?
What assumptions are we making about the scenario?
Would each action realistically succeed here, or only in a cartoon lab?
Technically valid commands can still produce unrealistic emulations when the threat model and victim model do not match such as wrong foothold, wrong permissions, wrong resources, wrong controls, wrong network path.
Access path is one piece of that model, not the whole model. Micro and full runs usually start from a foothold the scenario allows, not a blank admin session:
Foothold type | What it models |
|---|---|
Stolen long-term credentials | IAM user keys, service principal secrets, service account keys |
Assumed / escalated role | STS assumed role, managed identity, IRSA |
Compromised compute | EC2 instance profile, GKE pod SA, Azure VM managed identity |
Do not treat the ATT&CK ladder as a script you recite once either. Micro and full emulations are rarely a clean Discovery > Credential Access > Persistence > Escalation > Objectives parade. Tactics repeat, behaviors loop and when something fails, the operator adjusts, and the next move is opportunistic. That is the hard part, and it is also where the useful telemetry lives.
End-to-end work makes the dependency problem obvious. You cannot jump to the sexy stage with full admin to everything. Certain steps have to complete, produce an artifact, and unlock the next one. It is not always glamorous. Land on an EC2 instance, enumerate the host, pull the instance role, discover the security group, open egress for a callback port, then move. Failures are part of the model too. A denied call, a missing permission, a control that blocks the path. Real adversaries change the toolset and plan when that happens. Your emulation should too, instead of quietly attaching AdministratorAccess
so the blog screenshot stays pretty.
Use only what that stage would have. Do not grant the initial foothold full admin unless the scenario models that. Do not reach for your admin session because it is already open. Same goes for rolling virtual networks with 0.0.0.0/0
everywhere. It is not realistic. Don't do it. At least we hope it is not realistic. If you like to play in traffic, that is on you.
Build a controlled, reproducible lab
Before any apply
, stop for approval. Present the objective, threat model, victim model, identity model, operational flow, infrastructure needs, and a cost estimate if compute or metered services are involved. That is the cloud version of scope, rules of engagement, and permission to execute. We hope you are not a one-person team so feel free to phone-a-friend for a second set of eyes.
Keep the lab disposable on purpose:
Fully owned research tenants / accounts
Consistent provisioning (IaC, frameworks, or scripts)
Admin setup separated from adversary execution
Dedicated identities and resources per run
Everything tracked, including attacker-created leftovers
Easy redeploy, complete destroy
A practical habit is to give every run a unique emulation tag (name + short random id, e.g. void-blizzard-a3f8c1) and put it in resource names, identities, session names, and labels. Not the star of the methodology. Useful for keeping concurrent runs from colliding, pulling the right slice of telemetry when races get messy, and finding orphaned leftovers during cleanup.
When you do filter later (assuming you already spent time setting up the ingestion), a query can be as simple as:
FROM logs-aws.cloudtrail-*
| WHERE @timestamp > NOW() - 1 day
AND aws.cloudtrail.user_identity.arn LIKE "*void-blizzard-a3f8c1*"
That only works if the tag is actually in the ARN string (user name, role name, or STS session name). A resource tag alone will not show up there.
On Azure, resource-group (RG) naming helps for Activity Logs. Identity-plane work still needs sign-in and audit telemetry too. Do not pretend one RG filter covers Entra.
Track two resource classes:
Provisioned by Terraform/Ansible. In state. Destroyed with
terraform destroy
.Orphaned during execution (backdoor users, keys, topics, role assignments). Not in state. Cleaned up first.
Always destroy orphans before provisioned resources. Scope Azure work to one resource group per run. Force-destroy storage. Restrict compute inbound access to the engineer’s IP. Never 0.0.0.0/0
"just for the lab."
We REALLY want to caution orphaned resources on this, especially as we leverage LLMs. Nothing like an expensive AWS bill as a result of unstaged Kubernetes pods or an unpatched Apache Tomcat server which is now part of a crypto-campaign, rather than your emulation efforts.
Execute with context, then trust only the real events
The plan is only as good as the way you run it. You can fire a technique's exact commands and still get an emulation that does not teach you much. Context decides whether it is useful, and it starts upfront with threat modeling and planning. Vague steps produce vague telemetry. Contextual steps produce events you can actually detect against.
Vague: Initial access via user logging in.
Contextual: User opens a link to login.microsoftonline.com
, reaches the portal in a browser, attempts login, and hits MFA with Entra ID as the IdP. They are instructed to share the MFA auth code over Teams. MFA is approved. No Conditional Access policies are broken. The adversary takes the auth code and exchanges it with Entra for a refresh token.
Vague: Exfiltrate data from S3.
Contextual: Foothold is an EC2 instance profile for a batch job, not an admin console session. The role can ListBucket
/ GetObject
on prod-analytics
. Objects are server‑side encryption with AWS Key Management Service (SSE-KMS), and the role has kms:Decrypt
on that customer managed key (CMK). Copy to a same-account staging prefix first, then PutObject
to an external bucket the role was mistakenly granted. CloudTrail data events are on for that bucket. Management events alone would miss the GetObject
volume that makes the behavior visible.
Write the contextual version into the operational flow before you touch a CLI. Call, actor, target, expected result, and what should land in logs. Keep the failures too. A denied permission during recon is often the exact trace a detection should chase.
Cloud timing matters too. IAM is eventually consistent. Fixed sleep 30
makes flaky runs. Poll for new credentials. Use provider waiters. Give logs a settle window before you declare telemetry missing. When you get into the nuances of timing for query language sake, it can be challenging to not only understand but recreate acceptable historic windows.
Treat telemetry as an output of the emulation
Do not assume what the cloud recorded. Verify it.
Before you detonate, decide which log should capture each step and confirm it is on. A lot of data-access logging ships off. Then open the real events raw. The real event beats the docs, your memory and an engineer who built the schema normalization layer several years ago but took a competitor’s offer and left little documentation. Memory invents field names. A rule written against a name that is almost right never fires. A model does the same thing and sounds more sure of itself.
Look for what is missing too: late, partial, or absent telemetry. Sometimes the technique leaves no useful trace. That is a finding! Knowing something is invisible is worth as much as detecting it. Last check should be “does this data distinguish the attacker from normal activity?”
Evaluate coverage against the exercise, not the matrix
An ATT&CK board that is all green is reassuring and often misleading. It counts rules by name and mapping, not by what they do against this telemetry.
Throw the exercise's events at your rules and look at what fires and why:
Rule fires for the right reason. Good.
Rule fires on a different link in the chain. Less good.
A different rule fires by accident and dies if one detail changes. Weak.
A perfectly named, perfectly mapped rule whose query never touches this telemetry. Inventory coverage. Incident silence.
Then decide the next move. Should you create a new rule, tune, request a missing log, hunt, or investigate more before changing anything. Having a rule per action is not the same thing as reliable detection. Whoever gets that alert at three in the morning also cares about what it does not cover.
Document, clean up, and make it repeatable
You can regenerate a command tomorrow. The reasoning does not come back unless you wrote it down.
Capture why that behavior, how you modeled the victim, which identity did what, what worked, what failed, what telemetry appeared, what coverage existed, and what is still open. Assumptions are the part you will need later. When a rule gets noisy, somebody asks what "normal" meant when you wrote it. If nobody wrote that down, the comfortable move is to raise the threshold until it goes quiet. Date environmental claims. Commands age. Reasoning is what you reuse.
A useful write-up looks like a short engagement report, not a command diary:
Objective, scope, and source material
Threat model and ATT&CK mapping
Victim model and assumptions
Operational flow / timeline (action, API call, identity, result)
Observations and credential progression
Detection opportunities and coverage outcomes
Infrastructure summary and cleanup status
Recommendations (new rule, tune, hunt, follow-up emulation)
Cleanup is part of the methodology, not housekeeping. Leftovers can contaminate the next run. Infrastructure in code comes down easily. Attacker-created roles, keys, and grants do not unless you tracked them. Temporary credentials can outlive the role that issued them. Logging you enabled for the exercise has to come back off. Verify by tag, and make sure that check can fail. Keep the plan and the findings. Delete the rest. Worse, you half-ass an emulation with no care about public exposure and security posture, then have to join a call with IR to explain what the purpose of this rogue access point was. Saying “my bad” won’t save you.
Where automation helps, and where judgment stays
This is usually the part people skip to. Which is fair. Once the methodology is clear, a lot of the work is repetitive.
Automation (including agents and skills) can help with drafting threat and victim models from a report, rule, or plan; provisioning and tagging; executing with the right identity; tracking orphans; verifying telemetry against real events; searching coverage; writing up the run; and verifying cleanup.
Engineers still decide whether the scenario is realistic, whether assumptions are sound, whether existing coverage is truly equivalent, which behavior is worth detecting, whether a resulting detection helps customers, and whether the emulation stayed faithful to the original threat. We still strongly believe in human-in-the-loop (HITL) value no matter how much you want to flex new models and tokenmaxxing.
The split between automated work and engineer judgment matters. The goal is not to replace threat-informed practice with vibes, and it is not to remove the practitioner. The goal is to make the methodology repeatable in cloud at the pace the problem demands, so human time goes into realism, judgment, and detection quality.
What's next in Part 2
If you made it this far, here’s the important meat between our memes
Start with the question, not the tool. Define what you are trying to prove first.
Pick the right scope. Atomic, micro, or full depending on the question.
Threat model before execution. Know the adversary objective and source assumptions.
Model the victim too. Resources, controls, identities, and network paths matter.
Start from a believable foothold. Avoid defaulting to admin access.
IAM progression matters. Use only the permissions available at each stage.
Respect dependencies. Earlier actions should realistically unlock later ones.
Failures are useful. Denied or blocked actions can produce valuable telemetry.
Build disposable labs. Make provisioning, isolation, and teardown repeatable.
Tag every run. Unique identifiers simplify telemetry and cleanup.
Track attacker-created resources. IaC will not know about every artifact created during execution.
Cleanup is part of the exercise. Remove leftovers and verify the environment is clean.
Context beats API spam. Define the actor, target, prerequisites, and expected result.
Cloud timing matters. Account for propagation, readiness, and log delays.
Telemetry is an output. Verify what actually lands in the logs.
Missing telemetry is a finding. Invisible or incomplete behavior still teaches you something.
Trust the real event. Do not build detections from remembered field names.
Test coverage against the exercise. ATT&CK mappings alone do not prove detection.
A firing rule can still be weak coverage. Make sure it fired for the intended reason.
Not every gap needs a rule. Sometimes the answer is a tune, hunt, logging change, or more research.
Document the reasoning. Preserve assumptions, identity progression, failures, telemetry, and outcomes.
Treat the lab like a state machine. Run from known-good states and avoid contaminated environments.
Automate the repetitive work. Research, provisioning, execution, telemetry checks, and cleanup can all benefit.
Keep human judgment in the loop. Engineers still own realism, value, and detection quality.
The plan is the durable artifact. Tools change; the methodology and reasoning are what you reuse.
What Part 2 covers: agents running the emulation lifecycle
Part 2 is where this stops being a methodology post. Agents, skills, and concrete runs: turn a research post or rule into a lab, verify what landed in the logs, triage coverage, tear it down. Same lifecycle. Less theory.
Emulate responsibly!