Cloud Threat Hunting: A Guide to Getting Started

Cloud threat hunting is a proactive, hypothesis-driven search for an intruder who never tripped an alert. Its evidence is the AWS CloudTrail events, VPC Flow Logs, and Kubernetes audit events your platform team already ships for debugging. Platform engineers and SREs control how long that telemetry stays and how fast anyone can query it, and those two settings determine whether a hunt still has evidence when an intrusion surfaces months later, sometimes only through an outside tip.

This guide covers what cloud threat hunting is, how it differs from traditional threat hunting, and how you can prepare the data and workflow for your first hunt.

What Is Cloud Threat Hunting?

Cloud threat hunting starts from the assumption that an adversary is already inside the cloud environment and has slipped past automated controls, then searches infrastructure, workloads, and identities for evidence of that adversary. In cloud hunts, the control plane, IAM configuration, API activity, and ephemeral containers and serverless functions replace files on a managed host as the search space.

Threat detection works the other way around. A rule or signature matches a condition and fires an alert, and teams accept false positives as the cost of speed. Hypothesis-driven threat hunting looks for activity no rule covers yet and spends analyst time on the few events that resemble a live intrusion. A hunt ends in incident response when it finds something, or in a new detection rule that alerts on the technique next time.

How Cloud Threat Hunting Differs from Traditional Threat Hunting

Cloud threat hunting differs because the evidence lives in API and identity logs instead of on hosts. In the cloud, an intruder can do damage without dropping malware because a legitimate credential used from the wrong place can reach the same APIs your engineers call. Four differences shape how you hunt:

• Ephemeral workloads: Containers and serverless functions often live for minutes, so forensic evidence comes from audit and flow logs captured while they ran.
• Shared responsibility model: The provider secures the underlying infrastructure, and you secure your data, identities, and configuration. Telemetry follows the same split, and CloudTrail doesn't log data events by default, including Amazon S3 object reads.
• Identity as the attack surface: Adversaries use valid cloud accounts for initial access, persistence, and privilege escalation, which makes IAM credential compromise a primary hunting target in place of host malware.
• Fragmented telemetry: Evidence sits in CloudTrail, VPC Flow Logs, Azure Activity Logs, and Google Cloud Audit Logs with no unified view, while one campaign can span AWS, Azure, GCP, and Okta.

Behavior survives as evidence even when the workload doesn't. A team can identify which identity called which API and from where, then compare it with last month.

Which Cloud Security Threats Are Worth Hunting For?

The cloud threats worth hunting for are misconfiguration, IAM credential compromise, lateral movement, cryptomining, data exfiltration, and CI/CD supply chain attacks, because each one can stay invisible until after data leaves. Two well-documented breaches show how.

At Capital One in 2019, an intruder entered through a misconfigured web application firewall and accessed customer data. The breach came to light only when a GitHub user saw the intruder's post about the theft and alerted the company.

CircleCI's 2023 incident report traces its breach to malware on an engineer's laptop that stole a valid, two-factor-backed single sign-on session on December 16, 2022, and the company alerted customers on January 4, 2023. Each of the six categories leaves its own trace for a hunter to look for:

• Cloud misconfiguration: Public buckets, open security groups, and misconfigured firewalls give attackers entry, as at Capital One.
• IAM credential compromise: Attackers use stolen session tokens and long-lived keys, and the first use from a new IP address or region is the trace a hunter looks for.
• Lateral movement: Hunters watch for administrative policies attached to roles and unusual cross-account role assumptions.
• Cryptomining: Hijacked compute shows up as unexplained billing spikes.
• Data exfiltration: Hunters look for unusual volumes of object reads or snapshots shared with unfamiliar accounts, because attackers can move from access to exfiltration faster than reactive controls respond.
• CI/CD supply chain: Poisoned build actions leak secrets into build logs or to attacker servers.

Credentials run through each of these categories, as the way in or the thing taken, so identity logs anchor the hunts that follow.

What Are the Three Types of Cloud Threat Hunting?

Hunts fall into three types based on what starts them:

• Structured, or hypothesis-driven: Starts from a tactic, technique, or procedure (TTP) in the MITRE ATT&CK cloud matrix. One example hypothesis looks for lambda:CreateFunction followed by cloudtrail:StopLogging or guardduty:DeleteDetector, a backdoor that blinds its own logging.
• Unstructured, or IoC-driven: Starts from a known indicator of compromise (IoC) such as a malicious IP address, domain, or file hash, and searches CloudTrail, Amazon GuardDuty findings, Azure Activity Logs, and Google Cloud Audit Logs for it.
• Situational, or entity-driven: Starts from a risk assessment or a high-value asset such as a privileged role or production data store.

Structured hunting against a finite list of ATT&CK techniques is a workable entry point for a new team.

How Cloud Threat Hunting Works Step by Step

A cloud hunt runs as a loop that starts with a hypothesis and ends with a new detection. Targeted Hunting integrating Threat Intelligence (TaHiTI), a 2018 methodology from the Dutch financial sector, runs Initiate, Hunt, and Finalize phases and treats threat intelligence as a major source of hypotheses.

The PEAK (Prepare, Execute, and Act with Knowledge) framework adds baseline hunts, which surface changes in IP address, region, and API calls, and model-assisted hunts. The cloud working loop has five steps:

1. Form a hypothesis: Write a hypothesis that is specific and falsifiable, such as "a service account's access keys are being used from outside our cloud provider's IP ranges," and tie it to threat intelligence.
2. Collect and normalize telemetry: The team pulls CloudTrail management and data events, VPC Flow Logs, container runtime logs, and identity provider sign-ins into one queryable store.
3. Analyze for anomalies: Hunters use pattern matching and statistical counts to compare behavior against a baseline. They can also apply user and entity behavior analytics (UEBA).
4. Investigate and triage: The hunter correlates across data types until the activity is ruled benign or fully mapped. Responders take over confirmed findings.
5. Document and improve: The team writes up each outcome and converts positive findings into detection rules and runbooks.

Baselines are what make anomalies visible. One baseline technique groups each AWS principal's access-denied CloudTrail events by event name and flags a name that principal has never been denied before, such as CreateUser, which points the investigation at an attempted IAM user creation.

In Coralogix, a cross-stack observability platform, Olly, its autonomous observability agent, runs a hunt from a hypothesis written in plain language. Olly correlates CloudTrail activity with network flows, traces, and error patterns, flags rare events and deviations from normal behavior, and shows the DataPrime queries it ran so the hunter can check its work.

What Tools and Data Sources Does Cloud Threat Hunting Need?

Cloud threat hunting draws on tools from six categories that together cover cloud logs, identities, entitlements, and SaaS activity. Each category contributes a different part of the investigation:

• Security Information and Event Management (SIEM): A SIEM platform stores the logs a hunt queries and analyzes them as they arrive, even as event volume grows.
• Cloud Detection and Response (CDR): CDR tools parse cloud audit and runtime events that SIEM and endpoint tools weren't built for, such as CloudTrail CreateAccessKey calls and Kubernetes audit events.
• Cloud-Native Application Protection Platform (CNAPP): CNAPP tools rank exposures by the attack paths that lead to sensitive data or privileged identities, such as a path that connects a public bucket to a privileged role.
• Cloud Access Security Broker (CASB): A CASB tracks sanctioned and unsanctioned SaaS usage, which lets a hunter distinguish approved services from unexpected SaaS activity.
• Cloud Infrastructure Entitlement Management (CIEM): CIEM maps which role or user holds which permission, which lets a hunter trace a suspicious cross-account role assumption to its identity.
• Threat Intelligence Platforms (TIPs): TIPs supply external feeds that seed structured hunts with TTPs, such as techniques in the MITRE ATT&CK cloud matrix.

Tools that consolidate log ingestion, real-time SIEM detection, and cloud security posture management (CSPM) in one pipeline shrink the data-silo problem that slows hunting. In Coralogix, Cloud SIEM runs 2,500+ out-of-the-box detections in-stream on the same pipeline that ingests logs, metrics, and traces, and CSPM checks cover AWS, Azure, and GCP.

Retention defaults decide how far back a hunt can look, and several are short:

• AWS CloudTrail: Event history covers recent management events and isn't a permanent record, so data events and long-term history need a trail.
• Microsoft Entra ID: Sign-in log retention is seven days on the Free tier and 30 days on P1 and P2, and expired data is gone unless you routed it elsewhere.
• Google Cloud: Admin Activity logs stay longer than Data Access logs, and Data Access logs are off by default except for BigQuery.
• Kubernetes: Upstream audit logging stays disabled until you set an audit log path on the API server, and Amazon EKS doesn't export control plane audit logs by default.

Short defaults won't hold a usable baseline, so route these sources to longer retention before the first hunt.

What Makes Cloud Threat Hunting Hard?

Cloud threat hunting is hard because four problems reinforce one another. In a 2026 threat hunting survey, 32 percent of hunters rated cloud infrastructure the hardest environment to hunt in, and 50 percent named data quality or quantity as their primary barrier, ahead of skilled staffing at 45 percent. The four problems are:

• Volume and noise: A production account emits large event volumes, and filtering has to cut noise without discarding the context a hunter later needs.
• Missing multi-cloud visibility: Providers don't offer a unified view across each other's logs by default, and running several identity providers leaves more activity uncorrelated.
• Cloud hunting skills shortage: Cloud hunting needs cloud architecture knowledge and investigative method in one person, a pairing that is hard to hire.
• Retention cost: Teams cap retention to control spend, yet the 14-day median dwell time reported for 2025 can exceed a short retention policy, and longer-running intrusions can outlast default windows entirely.

Noise and short retention compound each other, because the more alert fatigue pushes a team to drop data, the thinner the baseline a hunter has to compare against. Longer retention preserves that baseline for investigations that begin after default windows close.

How Platform Engineers and SREs Can Start Cloud Threat Hunting

Platform teams can start by making sure the evidence for a hunt exists when someone needs it. CircleCI disclosed its breach almost three weeks after the initial compromise, longer than some identity providers keep sign-in logs by default. Five steps reduce that risk:

• Build the log foundation first: Your log foundation should include CloudTrail data events for S3 and Lambda, VPC Flow Logs, Kubernetes audit logs, and identity provider sign-ins, routed to a log management store with months of retention.
• Prioritize hypotheses with MITRE ATT&CK: MITRE ATT&CK for Cloud covers four platforms in the Enterprise matrix, namely IaaS, SaaS, Office Suite, and Identity Provider. For the first three hypotheses, start with Valid Accounts: Cloud Accounts, then Data from Cloud Storage and Additional Cloud Credentials.
• Define normal first: Your baseline should record which principals create resources, from which IP addresses, and when, because deviation queries depend on that context.
• Start narrow: Your first hunt can use one hypothesis and one data source over one week. For example, you can hunt for CreateAccessKey calls against service-account users.
• Feed findings back into detection: A confirmed finding can become one rule that fires on CreateAccessKey for users tagged service-account and another that correlates new keys with use from countries outside an allowed list.

Security teams own the hypotheses and the response, and the platform team owns whether the evidence to test them exists.

Cloud Threat Hunting Starts with the Data Layer You Already Own

Cloud threat hunting runs on a hypothesis worth testing and on telemetry that lasts long enough to test it, and the second half sits with platform engineers and SREs. Coralogix writes all ingested data to your own cloud bucket in open Parquet format with unlimited retention, and a hunt that starts months after an intrusion still has a baseline to compare against.

Explore the Coralogix platform to run your first CloudTrail hunt against telemetry you keep for as long as you need it.

Frequently Asked Questions About Cloud Threat Hunting

Can AI help with cloud threat hunting?

Yes, an AI agent can turn a plain-language hypothesis into queries, correlate results across log types, and flag rare events, shortening the time from hypothesis to evidence. A human still decides what to hunt for and whether a finding is real.

Do you need a SIEM to start cloud threat hunting?

No, a first hunt needs one queryable store that holds CloudTrail, flow, and identity logs long enough to build a baseline, and a log management platform can provide it. A SIEM adds correlation rules and out-of-the-box detections, which helps once hunts start turning into detections you want to run continuously.

How do you perform threat hunting in the cloud?

A cloud hunt starts with a falsifiable hypothesis, compares relevant logs against a baseline, and investigates deviations. For example, you can query CloudTrail for console sign-ins by a principal that has never signed in from that country before. A negative hunt still helps, because it verifies that a path is closed.

What is the difference between threat hunting and threat detection?

Detection is automated, with rules and models firing when telemetry matches a condition. Hunting is human-led, starts with a hypothesis about adversary behavior, and usually produces a new detection rule for the same technique. A detection rule catches the techniques you already know, while a hunt looks for the ones you don't.

What log sources do you need to start cloud threat hunting?

A practical starting set includes AWS CloudTrail with data events on, VPC Flow Logs, identity provider sign-in logs, and Kubernetes audit logs for container-heavy environments. CloudTrail data events add charges, so turn them on first for the S3 buckets and Lambda functions that touch sensitive data to keep costs proportional. Retention then determines whether you can compare current behavior with a useful baseline.