Elastic Outlines a Plan-First Method for Cloud Threat Emulation

· Original article ↗

Summary

Elastic outlines a cloud threat-emulation lifecycle: define scope, model the threat and victim environment, execute with realistic identities, verify real telemetry and detection coverage, document findings, and clean up resources.

Key points

  • The methodology starts with objectives and a threat model, then models the victim environment, starting identity, permissions, and operational flow before execution.
  • Emulations can use atomic, micro, or full scope, depending on whether the goal is to test one technique, a short chain, or end-to-end behavior.
  • Cloud testing must account for IAM progression, control-plane APIs, eventual consistency, and logging delays; endpoint-style tests may not capture these factors.
  • Use controlled, disposable labs and unique run tags; track both provisioned resources and attacker-created leftovers for complete cleanup.
  • Verify expected events in actual logs rather than relying on assumptions about telemetry or field names; missing or partial logs can reveal detection gaps.
  • Test rules against the exercise’s events and check whether they fire for the intended reason; ATT&CK mappings alone do not demonstrate effective coverage.
  • Automation can handle repetitive tasks, but engineers remain responsible for realism, assumptions, detection value, and cleanup verification.

Article Details

Defense Focus
Use realistic, plan-first cloud threat emulation to validate detection coverage against actual telemetry, identify logging gaps, and improve detection engineering.
Detection Methods
  • Define an objective and atomic, micro, or full scope; threat-model the activity and victim environment before execution.
  • Use a realistic starting identity and model IAM progression, permissions, prerequisites, and expected outcomes for each step.
  • Verify that relevant logging is enabled, then inspect raw events and compare observed fields and timing with expectations.
  • Run the exercise's events against existing rules and assess whether alerts fire for the intended behavior and telemetry.
  • Investigate missing, late, or partial telemetry as potential detection gaps; decide whether to add or tune a rule, hunt, request logging, or investigate further.
  • Tag each run and use the tag to correlate telemetry and locate resources during cleanup.
Data Sources
  • AWS CloudTrail management events
  • AWS CloudTrail data events, including S3 object-access events
  • Azure Activity Logs
  • Entra ID sign-in and audit telemetry
  • Raw cloud events observed during the emulation
Rule Types
  • Detection-rule TOML and query-based rules
  • ES|QL queries for filtering CloudTrail logs and correlating run tags
Platforms
  • AWS cloud control plane
  • Azure cloud control plane and identity plane
Defensive Actions
  • Confirm expected logging is configured before execution, particularly for data-access events.
  • Allow for IAM propagation and log-ingestion delays; poll for credentials and give logs time to settle before concluding telemetry is absent.
  • Use dedicated identities and resources in controlled, disposable labs; restrict inbound access and avoid broad 0.0.0.0/0 access.
  • Track and remove attacker-created resources, including orphaned users, keys, and role assignments, before destroying provisioned infrastructure.
  • Verify cleanup by run tag, remove temporary credentials and exercise-enabled logging, and document assumptions, failures, telemetry, and coverage results.

MITRE ATT&CK

Vendors

Products

Tools

Related Articles