Cloud-Native Threat Hunting

Why Cloud Hunting Needs a Different Hypothesis Model

If you've worked through the Threat Hunting module, the ABLE framework (Actor, Behavior, Location, Evidence) is probably already how you structure a hunt: who might be doing this, what would they do, where would it show up, and what evidence would confirm or kill the hypothesis. That structure still works in the cloud. What breaks is the assumption baked into two of its four components, and if you carry those assumptions in unexamined, your hunts will point at the wrong logs and come back empty for the wrong reasons.

On-prem, "Location" usually means a network segment, a subnet, a specific host, or a piece of the topology you can draw on a diagram. In a cloud environment, that diagram mostly doesn't exist, and even where it does, it isn't where the interesting activity happens. Location in a cloud hunt is an identity: a specific user, a service principal, an IAM role, a tenant boundary, or an API caller. Chapter 1 made the case that identity replaces the network as the primary perimeter. Here, that same shift means identity replaces the network as the primary location construct a hunter reasons about. Asking "where would this behavior show up" now means asking "which identity or API surface would this behavior show up under," not "which subnet."

"Evidence" shifts just as directly. An on-prem hunt leans on host artifacts: process trees, registry keys, file system timestamps, memory. A cloud hunt leans on the telemetry Chapter 4 covered in depth: identity sign-in and audit logs, control-plane logs like CloudTrail, and network flow and DNS logs. That's not a smaller evidence set, it's a differently shaped one, and it means a hunt hypothesis that can't be phrased in terms of a query against one of those log sources isn't ready to run yet. Actor and Behavior carry over largely unchanged; you're still reasoning about who might attack you and what they'd plausibly do given their goals and access. This chapter is about rebuilding Location and Evidence for cloud terrain, then walking through concrete hunt hypotheses layer by layer.

Hunting Across the Identity Layer

Identity is where most cloud hunts should start, because it's where the widest range of attacker goals converge: initial access, persistence, and privilege escalation all leave a trace somewhere in identity telemetry, even when the rest of the attack plays out in a service the identity layer doesn't directly instrument.

Impossible travel is the most familiar identity hunt hypothesis and a good starting point precisely because it's easy to state precisely: a single identity signs in from two locations geographically distant enough that the gap between the sign-in timestamps rules out physical travel between them. As a hypothesis, that's directly testable against sign-in logs. Pull successful sign-ins for a given identity, sort by timestamp, and compute the implied travel speed between consecutive geolocated sign-ins. Anything that would require travel faster than a commercial flight allows is worth a closer look, though this hypothesis has known false-positive sources worth ruling out before escalating: VPN egress points, cloud-hosted mail clients that authenticate on the user's behalf from a data center IP, and multi-national organizations with legitimate follow-the-sun access patterns.

Anomalous consent grants target a different attacker goal: persistent, MFA-independent access via a malicious or over-permissioned OAuth application. The hypothesis here is that a user approved an application requesting unusually broad delegated permissions, from a publisher not previously seen in the tenant, outside the hours that user normally works. Each of those three conditions narrows the search independently and they compound well together. Audit logs record the consent event, the requesting application, the permission scopes granted, and the granting user, which is enough to build a query that flags any grant where the requested scope includes mail read, file access, or directory-wide permissions and the publisher has no prior grant history in the tenant.

Privilege escalation chains are the hypothesis that ties the first two together into an attack narrative rather than an isolated event: an identity receives a new high-privilege role assignment shortly after a sign-in that already looked suspicious on its own, whether that's an impossible-travel sign-in, a sign-in that survived risky-sign-in flagging, or a sign-in immediately following a password reset the identity didn't seem to expect. The query pattern is a join across two log sources rather than one: sign-in events flagged as risky or anomalous, correlated by identity and a tight time window against role or policy assignment events in the audit log. A privilege grant in isolation is unremarkable; a privilege grant landing inside minutes of a suspicious authentication event is the kind of temporal correlation that turns a weak signal into a strong one.

Hunting Across the Resource and Control-Plane Layer

Once an identity has meaningful access, the next place attacker activity shows up is in what that identity does with it, and in a cloud environment that means the control plane: the API surface that creates, modifies, and deletes resources rather than the resources themselves.

The strongest hypothesis in this layer is also the simplest to state: a resource was created outside the organization's known infrastructure-as-code pipeline. In a mature cloud environment, the overwhelming majority of legitimate infrastructure changes flow through a CI/CD pipeline or a specific set of automation service principals, not through a human clicking through the console. That means the identity attribute on a resource-creation event is a strong discriminator on its own. A hunt query built around this hypothesis filters CloudTrail or the Azure Activity Log for resource-creation events, then excludes anything performed by the known pipeline identities, leaving a short list of console-driven or unrecognized-principal creations that deserve individual review. This won't catch an attacker who has compromised the pipeline identity itself, but it catches the far more common case of an attacker operating through a compromised human or a stolen access key, since that access rarely includes pipeline credentials.

Reconnaissance inside the cloud API surface tends to look different from network scanning, but it leaves its own pattern: a burst of List, Describe, or Get calls spanning many different services in a short window, from an identity that doesn't normally touch that many services. A developer working a normal day calls a handful of APIs relevant to their project. An attacker who has landed in an environment and doesn't yet know what's there enumerates broadly, because they're building a map. The hypothesis translates into a query that counts distinct API operations and distinct services called per identity per short time window, and flags outliers against that identity's own historical baseline rather than a fixed threshold, since normal breadth varies enormously between an individual developer and an automation account.

The third hypothesis targets an attacker covering their tracks or widening their access rather than exploring it: changes to security-relevant configuration. Disabling a CloudTrail log stream, turning off an Entra diagnostic setting, loosening a security group to allow broader inbound access, or modifying an IAM trust policy to add a new trusted principal are all individually rare events in a stable environment, which makes them well suited to a low-volume, high-fidelity alert rather than a broad hunt query. Because these changes are also things legitimate administrators do occasionally, the useful hunting question isn't just "did this happen" but "did this happen and was it followed by activity consistent with the access it enabled."

Hunting Across the Network Layer

Network telemetry matters less in the cloud than it did on-prem, for the reasons Chapter 1 laid out, but it hasn't dropped out of the picture entirely. Flow logs and DNS logs still catch things identity and control-plane logs miss, particularly around data movement and command-and-control, and they're worth hunting even in an identity-first program.

The first hypothesis is egress to a newly-seen external destination from a resource that has no legitimate reason to make outbound connections at all. A database instance, an internal API backend, or a worker node that only ever talks to other resources inside the environment shouldn't suddenly initiate a connection to an external IP it's never contacted before. Building this hunt requires a baseline of each resource's normal egress destinations, which flow logs accumulate naturally over time, and then flagging any new destination that falls outside that baseline for resources tagged as having no legitimate external egress requirement. The value of this hypothesis is that it doesn't depend on the destination being a known-bad indicator; a brand-new, entirely unremarkable-looking IP is still worth a look if the calling resource has never had a reason to talk outbound before.

Data transfer volume anomalies test for exfiltration directly rather than inferring it from the destination. A resource that typically moves a few megabytes a day suddenly transferring gigabytes is a volume signal independent of where the traffic went, which makes it a useful complement to the destination-based hypothesis above; an attacker staging exfiltration through an otherwise unremarkable or even legitimate-looking endpoint will still show up on a volume baseline even when the destination itself gives no other signal.

DNS query patterns round out the network layer with a hypothesis aimed specifically at tunneling and beaconing. High-entropy subdomains, meaning subdomain labels that look like random or algorithmically generated strings rather than something a human or a normal application would construct, are a recognizable signature of DNS tunneling, since the tunnel encodes data into the query itself. A high frequency of queries to a single domain over a short window, particularly at regular intervals, is a signature more associated with beaconing command-and-control checking in on a schedule. Both patterns are detectable directly from DNS query logs without needing to inspect payload content, which makes DNS one of the more tractable network log sources to hunt against even in an environment where full packet capture isn't available.

Pivoting When Infrastructure Is Ephemeral

Here's the problem that separates cloud hunting from on-prem hunting more than any single hypothesis category above: the compute resource, container, or serverless function you want to investigate may simply no longer exist by the time you go looking at it. An auto-scaling instance that ran for eleven minutes and got torn down by the scaling policy isn't sitting there waiting for you to image it. A container that spun up, executed, and exited has no persistent disk to examine. A serverless function invocation lasted milliseconds and left behind nothing you can log into. On-prem hunting assumes the system under investigation is still reachable, or at minimum that a forensic image was taken before it changed state. Cloud hunting can't assume either.

The practical mitigation is to stop anchoring investigations on the resource and start anchoring them on identity and API-caller fields instead, because those persist in logs regardless of whether the resource they relate to still exists. The IAM role, service principal, or user identity that launched a compute resource, that resource's short-lived instance ID, container ID, or function invocation ID, and the API calls made under that identity's credentials are all recorded at the moment they happen, independent of the resource's lifecycle. A hunt that starts with "what did this instance do" runs into a dead end the moment the instance is gone. A hunt that starts with "what did this identity do, and what resources did it touch across their full lifecycle" keeps working long after any individual resource has been recycled.

Correlating short-lived resource identifiers across log sources is what lets you reconstruct a timeline without ever touching a live system. An instance ID appears in the resource-creation event in the control-plane log, in the flow logs for network activity while it was running, and potentially in application logs if the workload emitted any. None of those log sources require the instance to still exist; they were written at the time the activity happened and persist independently. Stitching them together by the shared identifier, and by the identity that owned the resource across its lifetime, produces a reconstructed timeline that's often just as useful as live access would have been, and sometimes more complete, since it captures the full window rather than a single point-in-time snapshot.

Documenting Cloud Hunts

If you know PEAK from the Threat Hunting module (Prepare, Execute, Act with Knowledge), the lifecycle itself doesn't need reinventing for cloud hunts. What needs adapting is what you capture at each stage, because the evidence a cloud hunt relies on is often less durable than what an on-prem investigation would produce.

A cloud hunt record should capture, at minimum, the exact query used, the log source it ran against, the time range covered, and the specific identity and resource identifiers involved in any findings, whether that's a user principal name, a service principal object ID, an instance ID, or a function invocation ID. That level of specificity matters more here than it might in an on-prem writeup, because reproducing the investigation later isn't guaranteed to be possible. A findings section should also record what was ruled out and why, not just what was confirmed, since a hunt that returns no findings still tells you something about coverage and should be documented as thoroughly as one that does.

Documentation matters more in cloud hunting specifically because the underlying evidence frequently isn't reproducible the way an on-prem forensic artifact is. An on-prem investigation can fall back on a disk image, a memory capture, or a physical machine that's still sitting in a rack if a question comes up three months later. A cloud hunt often can't fall back on anything: the resource that mattered was destroyed on schedule, the credential involved was rotated as a matter of routine hygiene, and the only surviving record of what happened is whatever was captured in logs during the retention window and whatever the hunter wrote down. Treat the hunt record itself as the artifact, because in a real sense, it's the only one that's going to still exist next quarter.