What Is Cloud Detection Engineering?

How Cloud Detection Engineering Differs from Traditional Threat Detection

On-premises detection largely revolves around network telemetry, endpoint logs, and host-based indicators. Cloud detection engineering operates in a fundamentally different environment. There are no packet captures from a network tap. There is no EDR agent on a Lambda function. The primary telemetry is API call logs, and the attack surface is the control plane itself: the management APIs that provision, configure, and govern cloud resources.

This shift changes everything about how detections are authored. A detection for lateral movement in a traditional network might look for anomalous SMB connections between workstations. The cloud equivalent might look for an IAM role assumption from an unexpected source account followed by S3 object enumeration, an entirely different data model requiring entirely different query logic.

Platforms and Query Languages

Each major SIEM and cloud-native analytics platform has its own detection language. Microsoft Sentinel uses Kusto Query Language (KQL) against tables like SigninLogs, AuditLogs, and AzureActivity. Splunk uses Search Processing Language (SPL) and increasingly relies on data models that normalize cloud log formats. AWS-native detection runs through CloudWatch Logs Insights, Amazon Detective, and GuardDuty custom threat lists. Google Chronicle uses YARA-L 2.0, a purpose-built detection language that supports multi-event correlation across Google Cloud and third-party log sources.

Effective cloud detection engineers are polyglot, comfortable writing KQL for one client's Sentinel deployment and SPL for another's Splunk Cloud instance, with an understanding of where each platform's strengths and blind spots lie.

The Detection Engineering Lifecycle

Mature cloud detection engineering runs as a repeatable lifecycle rather than a one-time rule-writing exercise. It starts with research: understanding a technique well enough to know what it leaves behind in the logs. From there, engineers develop a detection, test it against known-good and known-bad samples to measure false positives, deploy it through a pipeline, and then tune it continuously as the environment and the attacker tradecraft change. The strongest teams close the loop by validating detections against real attacks, either through purple-team exercises or by replaying the telemetry from a genuine intrusion, so coverage is proven rather than assumed.

Detection-as-Code

Modern cloud detection engineering treats detections as software artifacts. Detections are written in structured formats (YAML, TOML, or native platform syntax), stored in version-controlled repositories, validated through CI/CD pipelines, and deployed programmatically. Frameworks like Sigma provide a vendor-agnostic detection format that can be compiled into platform-specific queries. Panther and Matano take this further with Python-based detection logic that runs directly against cloud log data in S3.

The detection-as-code approach brings software engineering rigor: peer review for detection logic, unit tests with known-good and known-bad log samples, automated deployment, and rollback capability. This is critical in cloud environments where the volume of API telemetry means a poorly written detection can generate thousands of false positives per hour.

The MITRE ATT&CK Cloud Matrix

The MITRE ATT&CK Cloud matrix provides the taxonomic backbone for cloud detection engineering. It maps adversary techniques specific to IaaS, SaaS, and identity providers into a structured framework. Key technique areas include Initial Access (such as T1078.004, Valid Accounts: Cloud Accounts), Persistence (T1098, Account Manipulation), Privilege Escalation (T1548, Abuse Elevation Control Mechanism), and Exfiltration (T1537, Transfer Data to Cloud Account).

Mapping detections to ATT&CK techniques provides coverage visibility. Detection engineers can identify gaps. For instance, an organization might have strong detections for credential-based initial access but no coverage for T1535 (Unused/Unsupported Cloud Regions), where attackers spin up cryptomining infrastructure in regions the organization does not monitor.

Common Cloud Detections

Several detection patterns recur across cloud environments. Impossible travel detections flag when a single identity authenticates from geographically distant locations within a timeframe that makes physical travel impossible, though these require tuning for VPN usage and corporate proxies. API abuse detections look for high-velocity enumeration patterns: an IAM principal calling ListBuckets, GetBucketAcl, and GetBucketPolicy across dozens of buckets in seconds is likely running a tool like Pacu or ScoutSuite rather than performing legitimate administration. Privilege escalation indicators monitor for dangerous IAM API calls such as CreatePolicyVersion, AttachUserPolicy with overly permissive policies, and PutRolePolicy, especially when the calling principal does not normally perform IAM administration.

More sophisticated detections correlate across log sources: a new OAuth application consent in Entra ID followed by Mail.Read API calls to Microsoft Graph, for instance, can indicate a consent phishing attack even when each individual event appears benign.

Real-World Cloud Attacks Worth Detecting

The techniques below are drawn from documented intrusions and map directly to detections a cloud team should have.

Midnight Blizzard, 2024

The group behind the 2024 Microsoft corporate email compromise password-sprayed a legacy test tenant, then abused OAuth applications to grant themselves access to mailboxes. The detectable signals include sign-in risk on the sprayed account and, critically, a new application consent followed by Microsoft Graph mail access, correlated in AuditLogs and AADServicePrincipalSignInLogs.

Scattered Spider

This financially motivated group, also tracked as UNC3944 and Octo Tempest, is known for social-engineering help desks, defeating MFA, and pivoting quickly into cloud consoles and identity providers. Detections focus on anomalous administrative sign-ins, MFA method changes, and rapid enumeration of cloud resources from a newly authenticated session.

Codecov, 2021

A compromised CI/CD tool exfiltrated credentials from build environments, which were then used against cloud accounts. The lesson for detection engineers is to watch for cloud credentials being used from unexpected networks or in ways that break from a service account's normal behavior.

Detection Engineering vs. Traditional SOC Monitoring

Traditional SOC monitoring often relies on vendor-supplied rules and alert triage. Detection engineering treats detections as owned, tested, version-controlled software tuned to the specific environment. The difference shows up in quality: a generic "impossible travel" rule generates noise, while an engineered detection accounts for the organization's VPNs, service accounts, and travel patterns. In cloud, where a single misconfigured detection can fire thousands of times an hour against high-volume API telemetry, that engineering discipline is the difference between actionable signal and an ignored alert queue.

Related Labs

Pwned Labs scenarios pair attack with detection, so you write rules from firsthand knowledge of what the attack looks like in the logs. Scenarios such as Investigate a Ransomware Attack in AWS using Splunk and Breach in the Cloud walk through spotting malicious activity in CloudTrail and SIEM data. Browse the full set at pwnedlabs.io/explore.

Build Cloud Detections with Pwned Labs

Every Pwned Labs bootcamp (MCRTP, ACRTP, GCRTP, and MCRTE) follows an attacker-informed defender model: practitioners execute real attack techniques in live cloud environments, then build detections for exactly those techniques. This means you are not writing detections from documentation. You are writing them from firsthand knowledge of what the attack actually looks like in CloudTrail, Sentinel, or GCP logs. Explore all bootcamps at pwnedlabs.io/bootcamps.

Frequently Asked Questions

What is cloud detection engineering?

The practice of building, testing, and maintaining detections for attacks against cloud environments, working primarily from API and identity logs rather than network and endpoint telemetry.

How does it differ from on-premises detection?

There are no packet captures or endpoint agents on serverless and managed services. The primary telemetry is API call logs, and the attack surface is the control plane, so detections are written against control-plane events.

What query languages are used?

Kusto Query Language for Microsoft Sentinel, Search Processing Language for Splunk, CloudWatch Logs Insights for AWS, and YARA-L for Google Chronicle, among others. Vendor-agnostic formats like Sigma compile to several of these.

What is detection-as-code?

Treating detections as software: written in structured formats, stored in version control, tested in CI/CD with known-good and known-bad samples, and deployed programmatically, which brings peer review and rollback to detection logic.

How does MITRE ATT&CK help?

The ATT&CK Cloud matrix maps adversary techniques for IaaS, SaaS, and identity providers, letting teams map detections to techniques, measure coverage, and find gaps where they have no detection at all.