Threat Hunting in the Cloud, Part 1: From Logs to Behavior

Cloud threat hunting is not traditional endpoint hunting with new log names. The cloud changes the operating model. Identity becomes the first perimeter. APIs become the command line. Infrastructure changes are security events. Data movement can happen without malware. A single compromised token can create compute, enumerate secrets, disable logging, copy storage, modify firewall rules, and destroy backups faster than a human responder can click through a console.

That does not make cloud hunting mystical. It makes it more disciplined. A mature cloud hunt program starts with one question: what behaviors would an adversary need to perform in order to turn access into impact? The answer is usually not provider-specific at first. Across AWS, Azure, and Google Cloud, cloud intrusion paths tend to move through five repeatable layers: identity, control plane, data plane, workload runtime, and recovery/impact systems.

The Cloud Security Alliance's 2024 Top Threats report is useful because its top issues are not just product weaknesses. They are hunt prompts. Misconfiguration and inadequate change control, identity and access management, insecure interfaces and APIs, insecure third-party resources, accidental disclosure, limited visibility, unauthenticated resource sharing, and advanced persistent threats all describe conditions defenders can search for before an incident becomes obvious. CSA's broader Security Guidance v5 also explicitly calls out security monitoring, cloud telemetry, security analytics, resilience, and data lakes as part of modern cloud security practice. In other words, cloud defense is not only posture management. It is continuous behavioral review.

Why Cloud Hunting Needs a Behavioral Map

Most cloud programs begin with hygiene: MFA, least privilege, encryption, logging, policy enforcement, network segmentation, and backup protection. Hygiene matters, but hunting starts after the baseline. A hunt asks whether the environment is being used in a way that is unusual, risky, or consistent with adversary objectives.

MITRE ATT&CK's Enterprise Cloud matrix gives teams a shared language for this. The Cloud matrix includes techniques such as Cloud Accounts, Cloud Infrastructure Discovery, Cloud Service Dashboard, Cloud Storage Object Discovery, Cloud Services for remote access, Application Access Token abuse, Data from Cloud Storage, Remote Email Collection, Transfer Data to Cloud Account, Account Access Removal, Lifecycle-Triggered Deletion, Data Encrypted for Impact, and Resource Hijacking. These techniques turn cloud telemetry into a structured hunt backlog.

A good cloud hunt is not "look for bad IPs in CloudTrail" or "review all admin actions." Those searches may be useful, but they are not sufficient. A better hunt starts with an ATT&CK-backed hypothesis:

• An adversary with stolen credentials may enumerate cloud accounts, storage, and IAM relationships before attempting privilege escalation.
• An adversary with control-plane access may create alternate authentication material, modify conditional access or MFA settings, or add credentials to an application identity.
• An adversary targeting data may stage and transfer objects to an external account or service.
• An adversary seeking impact may delete backups, reduce retention, disable protections, or encrypt data using cloud-native services.
• An adversary abusing compute may create unusual instances, serverless functions, containers, or high-cost resources for cryptomining or staging.

This is where a platform-specific console and a behavior-specific hunt platform should complement each other. Cloud-native tools can surface alerts and provider-specific context. Threat Foundry can help teams translate those signals into ATT&CK-aligned hunts, reusable detection ideas, case notes, and cross-platform investigation packages.

The Five Cloud Hunting Planes

1. Identity Plane

Cloud identity is bigger than users. It includes human users, service principals, service accounts, workload identities, federated identities, application registrations, API keys, access tokens, SAML assertions, OAuth grants, and temporary credentials. In many incidents, identity abuse is the intrusion path and the persistence mechanism.

Core hunts include:

• New privileged role assignments outside change windows.
• Privileged access from new countries, ASNs, devices, or automation clients.
• Service accounts or application identities granted broad permissions.
• New credentials added to existing identities.
• MFA disabled, reset, bypassed, or weakened for privileged accounts.
• Conditional access or policy changes that reduce enforcement.
• Token use after suspicious sign-in or impossible travel events.

Threat Foundry tie-in: use the Cloud ATT&CK matrix in Hunt Builder to anchor identity hunts to techniques such as Valid Accounts, Cloud Accounts, Modify Authentication Process, Multi-Factor Authentication, Hybrid Identity, Application Access Token, and SAML Tokens. The output can become a saved hunt, a triage item, or the first node in an Attack Path Builder sequence.

2. Control Plane

The control plane is where cloud infrastructure is created, changed, and deleted. It is also where attackers often operate because every provider exposes powerful APIs. Control-plane telemetry tells defenders who did what, from where, using which identity, against which resource, and whether it succeeded.

Core hunts include:

• Logging, monitoring, or security services disabled.
• IAM policy changes followed by discovery or data access.
• New public exposure for storage, databases, load balancers, or management ports.
• New compute, serverless, container, or pipeline resources created by unusual identities.
• Secrets accessed soon after new privileges are granted.
• New regions used for the first time by an account or project.
• High-risk API calls chained together in short windows.

Threat Foundry tie-in: Attack Path Builder is valuable here because control-plane abuse is rarely one event. A realistic path might be Cloud Account discovery, Permission Groups Discovery, Cloud Infrastructure Discovery, Cloud Storage Object Discovery, then Data from Cloud Storage. Turning that sequence into a reusable hunt helps analysts avoid one-event thinking.

3. Data Plane

The data plane covers the object, database, warehouse, file, email, and SaaS content that adversaries actually want. Cloud data exfiltration may not require malware or traditional command and control. It may look like a legitimate API copying a bucket, exporting a table, granting external access, creating a snapshot, or using a managed transfer feature.

Core hunts include:

• Large reads or exports by identities that do not normally access the data.
• Storage access from new geographies or automation clients.
• Public sharing, external account grants, or cross-tenant access changes.
• Sensitive data accessed shortly after IAM changes.
• Snapshots, backups, or exports created and shared externally.
• Data access followed by deletion or retention changes.

Threat Foundry tie-in: CTI intake and Auto Triage can prioritize cloud data-theft reporting, map observed behaviors to ATT&CK, and help generate Sigma candidates or cloud query packages for review. CTI Modeling can then show which ATT&CK techniques, vendors, products, and cloud services are recurring in the intelligence queue.

4. Workload Runtime

Runtime still matters. Containers, VMs, serverless functions, Kubernetes clusters, CI/CD runners, and managed databases create execution surfaces. Cloud adversaries often combine identity abuse with runtime execution: steal credentials from metadata services, run discovery tools in containers, add startup scripts, deploy malicious images, or abuse serverless functions for staging.

Core hunts include:

• Metadata service access followed by cloud API calls.
• Startup scripts, user data, extensions, or run commands added to compute.
• Suspicious container exec, Kubernetes secret access, or privileged pod creation.
• Serverless functions created or modified by unusual identities.
• Cryptomining indicators, high-cost compute spikes, or unusual GPU creation.
• Reverse shell, tunneling, or remote copy utilities in cloud workloads.

Threat Foundry tie-in: Sigma and YARA workflows split the problem cleanly. Sigma is useful for log behavior: API calls, identity events, Kubernetes audit logs, process telemetry, and network events. YARA is useful when CTI contains malware traits, scripts, payload strings, or file content. Case Workspace keeps the two evidence types together.

5. Resilience and Impact Plane

Cloud impact is often native. Attackers can delete backups, reduce retention, remove recovery points, disable versioning, encrypt data with attacker-controlled keys, exhaust resources, or remove access. A cloud hunt program should look for pre-impact shaping as much as final impact.

Core hunts include:

• Backup vault, snapshot, lifecycle, immutability, or retention policy changes.
• Logging retention reduced before suspicious activity.
• Mass delete or encryption operations against storage or databases.
• Security service tampering followed by data movement.
• Resource quota spikes, unusual regions, or high-cost services created.
• Account access removal targeting administrators or incident responders.

Threat Foundry tie-in: saved hunts and Case Workspace let teams preserve the hypothesis, evidence, impacted assets, ATT&CK mapping, and validation steps. That is important because resilience hunts often become board-level narratives: what did we see, when did we see it, what controls worked, and what would we change?

A Practical Cloud Hunt Operating Model

The most effective cloud hunt teams run a weekly loop:

1. Pick one Cloud ATT&CK technique or one short attack path.
2. Confirm required telemetry exists.
3. Generate or adapt a hypothesis-driven hunt.
4. Run the hunt in the relevant cloud-native or SIEM platform.
5. Save useful findings, false positives, and tuning notes.
6. Convert strong logic into a reviewed detection rule.
7. Open or update a case when the hunt produces evidence.
8. Feed lessons back into CTI source priority, field normalization, and query overrides.

Threat Foundry is built for that loop. The Cloud ATT&CK matrix gives the behavioral anchor. Hunt Builder and Attack Path Builder generate structured investigation packages. Field Normalization helps align customer telemetry to expected entity fields. Query Overrides let teams preserve local cloud-query adaptations. Sigma and YARA rule builders create review-first detection content. CTI intake turns external reporting into prioritized hunt opportunities. Case Workspace captures the operational narrative.

The Strategic Shift

The strategic shift is simple: cloud hunting should move from alert follow-up to behavior confirmation. Alerts are useful, but they are not the program. The program is the disciplined practice of asking whether the environment shows evidence of adversary behavior across identity, control plane, data plane, runtime, and resilience systems.

The teams that win in cloud security are not the ones with the longest list of alerts. They are the ones that can repeatedly answer: which ATT&CK behavior are we testing, what telemetry proves or disproves it, what changed in our environment, and what detection or response improvement did we create?

Threat Foundry gives that work a place to live.

Sources

• Cloud Security Alliance, Security Guidance for Critical Areas of Focus in Cloud Computing v5.
• Cloud Security Alliance, Top Threats to Cloud Computing 2024.
• MITRE ATT&CK, Enterprise Cloud Matrix.
• Microsoft Learn, Hunting capabilities in Microsoft Sentinel.
• AWS Documentation, What is Amazon Security Lake?.
• Google Cloud Documentation, Investigating and responding to threats in Security Command Center.