Detection engineering teams that have spent years building robust on-premise detection capabilities often encounter a disorienting problem when their organizations migrate to the cloud. The mental models, data sources, detection patterns, and adversary behaviors that have accumulated over years of on-premise work do not translate cleanly. Network packets behave differently. Identity and access operate under different paradigms. Compute resources appear and vanish within minutes. And the attacker techniques most likely to be used against a cloud environment are often entirely absent from an on-premise-oriented detection library. Rebuilding detection capability for cloud-native environments is not an incremental improvement on existing practice. It is a substantive re-architecture of how defenders think about visibility, adversary behavior, and detection logic.
Why the Cloud Changes Everything for Detection
In traditional on-premise environments, detection engineering operates within a relatively stable data model. Endpoints generate process creation events, network devices generate flow data, domain controllers produce authentication logs, and all of this telemetry flows into a centralized SIEM. The environment is physically bounded, the assets are persistent, and the attack surface is well-defined.
Cloud environments invert most of these assumptions. Infrastructure is defined in code and provisioned on demand. A container workload that executes a suspicious process may be destroyed before an analyst ever reviews the alert. An attacker who compromises an IAM access key can operate entirely through API calls without ever touching a running compute instance. Lateral movement in a cloud environment may look nothing like lateral movement in a Windows domain. And the most common initial access vector in cloud environments—credential theft or misconfiguration exploitation—leaves evidence in API logs rather than on endpoints.
An attacker who compromises an IAM access key can operate entirely through API calls, conducting reconnaissance, privilege escalation, and data exfiltration without ever touching a running compute instance.
This shift demands that detection engineers rethink three foundational questions: where does meaningful telemetry come from, what does attacker behavior actually look like in this environment, and how do detections remain effective against infrastructure that changes continuously?
Primary Log Sources Across Cloud Providers
Each major cloud provider exposes a distinct telemetry architecture. Detection engineers working in multi-cloud environments must develop fluency in all three, as the log source naming, event schema, and available fields differ substantially across platforms. [1]
Beyond the control plane logs, network telemetry remains important but behaves differently in cloud environments. AWS VPC Flow Logs, Azure NSG Flow Logs, and GCP VPC Flow Logs all capture metadata about network connections but do not capture packet payloads. DNS query logs from AWS Route 53, Azure DNS, and GCP Cloud DNS add an important detection dimension for identifying command-and-control communication and data exfiltration over DNS. [2]
Cloud-Specific Attacker Techniques and Detection Logic
IAM Abuse and Credential Exploitation
Credential compromise is the dominant initial access vector in cloud environments. Unlike on-premise credential theft, which typically targets interactive user sessions, cloud credential theft often targets programmatic access keys, service account keys, or instance metadata service (IMDS) endpoints that expose temporary credentials to running workloads. Detection engineers should build detection logic for API calls made from unusual source IPs, calls to the IMDS endpoint from unexpected processes, and sudden changes in the volume or type of API calls issued by a given principal. [4]
The following example illustrates a detection query targeting anomalous IAM enumeration from a new source location, expressed in a generalized query pattern applicable to CloudTrail data ingested into a SIEM:
-- Detect IAM enumeration from a previously unseen source IP SELECT userIdentity.arn AS principal, sourceIPAddress AS src_ip, COUNT(eventName) AS api_call_count, COUNT_DISTINCT(eventName) AS unique_actions FROM cloudtrail_logs WHERE eventSource = 'iam.amazonaws.com' AND eventName IN ( 'ListUsers', 'ListRoles', 'ListPolicies', 'GetAccountAuthorizationDetails', 'ListAttachedRolePolicies' ) AND sourceIPAddress NOT IN (-- known admin IPs) AND DATE_DIFF('day', MIN(eventTime), NOW()) < 1 GROUP BY principal, src_ip HAVING unique_actions > 4 ORDER BY api_call_count DESC;
Privilege Escalation Via IAM Policy Manipulation
Cloud privilege escalation frequently involves attaching permissive policies to compromised principals, creating new administrative users, or assuming high-privilege roles. MITRE ATT&CK for Cloud documents over a dozen IAM-based privilege escalation paths in AWS alone, each of which leaves a specific trail of API events. [5] Detection engineers should build individual detections for high-risk API combinations: for example, a principal that calls iam:CreateAccessKey for a user other than themselves, or any call to iam:AttachUserPolicy with an administrative policy ARN.
-- Flag creation of access keys for other users by non-admin principals SELECT eventTime, userIdentity.arn AS actor, requestParameters.userName AS target_user, sourceIPAddress, userAgent FROM cloudtrail_logs WHERE eventName = 'CreateAccessKey' AND requestParameters.userName != userIdentity.userName -- actor creating key for different user AND errorCode IS NULL -- successful call only ORDER BY eventTime DESC;
Defense Evasion Through Logging Disruption
Sophisticated cloud attackers frequently attempt to disable or modify logging services before conducting their primary objectives. In AWS, this manifests as API calls to delete or modify CloudTrail trails, disable GuardDuty detectors, or update GuardDuty trusted IP sets to whitelist attacker infrastructure. Splunk’s Security Content research team documents a composite detection that monitors for deletion operations across GuardDuty, CloudWatch, WAF, and Route 53 logging configurations by pairing each eventName with its corresponding eventSource to reduce false positives significantly. [6]
Handling Ephemeral Infrastructure
One of the most fundamental detection engineering challenges in cloud-native environments is the ephemeral nature of compute resources. A container that runs for ninety seconds and is then destroyed may generate process execution events that are never analyzed because the workload no longer exists by the time the alert fires. Detection engineers must design with this constraint explicitly in mind.
The practical response involves two complementary strategies. First, detection logic must operate at the data plane as close to real time as possible. Streaming architectures that ingest and evaluate cloud logs within seconds of generation, rather than batching them for periodic analysis, are the appropriate model for cloud-native detection. Second, forensic data that would normally reside on an endpoint must be captured proactively during execution. Runtime security tools such as Falco for Kubernetes environments capture system call data from running containers and can produce alerts and event records before the underlying compute resource is terminated. This shifts the detection window from post-hoc log analysis to real-time behavioral monitoring.
Detection Coverage Mapping for Cloud
MITRE ATT&CK now maintains a dedicated Cloud matrix covering IaaS, SaaS, and container environments, with techniques and sub-techniques mapped specifically to the tactics and behaviors relevant to cloud adversaries. Detection engineers should use this matrix as the organizing framework for their cloud detection library, tracking coverage explicitly and identifying gaps before adversaries exploit them. [5]
Key tactic areas that frequently have underdeveloped detection coverage in cloud environments include Collection (specifically S3 object enumeration and bulk download), Exfiltration Over Web Service (data leaving via legitimate cloud service APIs), and Resource Development (attackers spinning up compute resources within the victim account for cryptomining or infrastructure staging). Each of these has a distinct API event signature that can be detected with targeted query logic, provided the relevant log sources are enabled and ingested.
Detection engineering in cloud-native environments is not a solved problem and should not be treated as one. The attack surface evolves as cloud providers release new services, as organizations adopt increasingly complex multi-cloud architectures, and as adversaries develop cloud-specific tradecraft with the same speed and creativity they have always applied to on-premise environments. The detection engineering teams best positioned to keep pace are those that have built a systematic, log-source-aware, ATT&CK-mapped detection library, understand the specific ways that cloud attackers differ from their on-premise counterparts, and maintain the technical discipline to validate that their detections actually fire when the behaviors they model occur. The cloud does not make detection engineering easier. It makes it more important that the fundamentals are done right.
Sources & Further Reading
- Microsoft. Microsoft Cloud Security Benchmark: Logging and Threat Detection. Microsoft Learn Documentation. https://learn.microsoft.com/en-us/security/benchmark/azure/mcsb-logging-threat-detection
- Sysdig. AWS vs. Azure vs. Google Cloud: Security Comparison — GuardDuty, Defender, and Security Command Center. https://www.sysdig.com/learn-cloud-native/threat-detection-in-the-cloud-defender-vs-guardduty-vs-security-command-center
- Sekoia.io TDR Team. AWS Detection Engineering. Sekoia.io Blog, March 2025. https://blog.sekoia.io/aws-detection-engineering/
- AWS Documentation. Threat Detection — AWS Cloud Adoption Framework: Security Perspective. https://docs.aws.amazon.com/whitepapers/latest/aws-caf-security-perspective/threat-detection.html
- MITRE Corporation. ATT&CK for Cloud — Enterprise Matrix. MITRE ATT&CK Knowledge Base. https://attack.mitre.org/matrices/enterprise/cloud/
- Splunk Security Content. Detection: AWS Defense Evasion — Impair Security Services. Splunk Security Research, updated August 2025. https://research.splunk.com/cloud/b28c4957-96a6-47e0-a965-6c767aac1458/
- Permiso Security. Unmasking Adversary Cloud Defense Evasion Strategies: Modify Cloud Compute Infrastructure, Part 2. May 2024. https://permiso.io/blog/unmasking-adversary-cloud-defense-evasion-strategies-modify-cloud-compute-infrastructure-part-2-detections-and-mitigations
- Binary Defense. Threat Hunting AWS CloudTrail with Sentinel: Part 1. https://binarydefense.com/resources/blog/threat-hunting-aws-cloudtrail-with-sentinel-part-1
- CloudOptimo. AWS GuardDuty: Advanced Threat Detection for Cloud Security. February 2025. https://www.cloudoptimo.com/blog/aws-guardduty-advanced-threat-detection-for-cloud-security/
