What Is a Cloud Compromise Assessment?

A cloud security assessment asks whether your S3 bucket is set to public. A cloud compromise assessment asks whether someone already walked through it. The difference is the whole job. One grades configuration against a benchmark; the other assumes the configuration already failed somewhere and goes looking for the intruder who used it. You run a compromise assessment when you have no specific alert but a real reason to doubt that "no alerts" means "no attacker": after a vendor breach that touched your tenant, before an acquisition closes, when an account you trusted turns out to have leaked credentials, or simply because nothing in cloud telemetry guarantees that quiet equals clean.

A cloud compromise assessment is a structured, evidence-driven hunt across a cloud environment for signs of past or present unauthorized access. It collects the telemetry that records what actually happened (control-plane audit logs, identity events, network flows, workload activity), then searches it for indicators of compromise and attacker behavior that monitoring missed or never had a rule for. This guide covers what the assessment inspects, the three-phase process from collection to action, the cloud-specific attacker behaviors it hunts for, how it differs from a posture assessment and an incident response engagement, and what the deliverable tells a defender. It is written for the SOC analysts, threat hunters, and DFIR teams who run these and inherit their findings.

What is a cloud compromise assessment?

A cloud compromise assessment is a point-in-time investigation that assumes breach and looks for proof, rather than assuming safety and looking for misconfiguration. Its question is narrow and uncomfortable: is there evidence that an unauthorized actor has accessed, persisted in, or moved through this cloud environment, now or in the recent past? It does not grade your controls. It reads the record those controls left behind and decides whether that record shows an intruder.

The distinction from a posture review is the point. A posture assessment is forward-looking and preventive: it finds the open door. A compromise assessment is backward-looking and investigative: it checks whether anyone already used the open door, and what they did once inside. The two are complementary, and a mature program runs both, but they answer different questions and produce different deliverables.

The scope is the evidence, not the architecture diagram. That means the cloud provider's control-plane audit trail (AWS CloudTrail, Azure Activity and sign-in logs, Google Cloud Audit Logs), identity and access events, network flow records, workload and container telemetry, and any indicators of compromise already in hand from threat intelligence or a prior incident. The assessment lives or dies on that telemetry: an environment that never enabled its audit log gives a compromise assessment almost nothing to read, which is itself a finding worth reporting.

What a cloud compromise assessment inspects

The value is in correlating sources, not in any single log. A cloud intrusion rarely shows up as one obvious event; it shows up as an unusual login followed by a permission change followed by an API call no one in that role has ever made. So the assessment pulls every relevant telemetry source and looks for the story they tell together.

Control-plane audit logs. The system of record for who did what to the cloud account itself. CloudTrail, Azure Activity Log, and Google Cloud Audit Logs capture API calls: who created a role, who attached a policy, who disabled logging, who launched an instance in a region the company never uses. This is the single richest source for a cloud hunt, because almost every attacker action against the control plane leaves an entry here.

Identity and authentication events. Where most cloud compromise begins. Sign-in logs, federation events, and token activity reveal logins from unfamiliar geographies or autonomous systems, impossible-travel patterns, MFA fatigue and prompt bombing, new device registrations, and the creation of access keys or service principals that grant an attacker durable entry. Stolen credentials and abused tokens are the cloud's front door, so identity telemetry gets read closely.

Network flow records. What talked to what. VPC and VNet flow logs expose connections to known-bad infrastructure, data egress to unexpected destinations, and internal traffic patterns that suggest lateral movement between workloads that have no business communicating.

Workload and container telemetry. The compute layer. Process and runtime data from instances, containers, and serverless functions surfaces unexpected processes, miners, reverse shells, and images pulled from registries no one approved. This is where an attacker who got past identity actually executes.

Configuration and change history. Not the current configuration (that is the posture assessment's job) but the history of changes: a logging rule disabled at 3 a.m., a security group opened then quietly closed, a snapshot shared to an external account. Attackers modify configuration to persist and to cover tracks, and the change trail is where that shows.

The cloud compromise assessment process

A compromise assessment is a defined investigation, not a scan. CrowdStrike frames it as three phases, and that arc holds regardless of vendor: collect and assess the evidence, analyze it to confirm or rule out compromise, then act on what you found. Most engagements move through these three stages.

1. Assess (collect and triage). Pull the telemetry that records the environment's recent history: control-plane logs across all regions and accounts, identity and sign-in events, flow logs, workload activity, and any indicators already in hand. Triage it against known indicators of compromise and known-bad infrastructure to surface the events worth a human's attention. This stage is only as good as the data retention behind it: thirty days of logs answers a different question than a year of logs.

1. Analyze (confirm and scope). Investigate the surfaced events to decide whether they are an intrusion or noise, and if they are an intrusion, how far it reached. This is the threat-hunting core of the work: pivoting from one suspicious sign-in to the access key it created, to the role that key assumed, to the data that role touched. Analysis confirms whether a compromise happened, when it started, what the attacker did, and what they reached, separating "this login looks odd" from "this login created a persistence mechanism that is still active."

1. Act (remediate and harden). Turn the findings into action. If the assessment confirms an active compromise, it hands off to incident response for containment and eviction. Either way it produces hardening steps: revoke and rotate exposed credentials, remove attacker-created identities and access keys, close the configuration gaps that allowed entry, tighten monitoring on the blind spots the hunt exposed, and schedule continuous monitoring so the next intrusion is caught by an alert rather than by the next assessment.

What it hunts for: cloud attacker behavior

A compromise assessment is only useful if it knows what cloud intrusion actually looks like, which is different from on-premises intrusion. The hunt is organized around the behaviors attackers repeatedly use against cloud accounts.

Initial access through identity. Valid stolen credentials, phished session tokens, exposed access keys committed to a public repository, and abused OAuth or federation trust. Cloud attackers rarely break in; they log in.

Privilege escalation in IAM. An attacker with a low-privilege foothold looking for the policy misconfiguration, the assumable admin role, or the iam:PassRole chain that turns a toehold into account control.

Persistence. New IAM users, long-lived access keys, additional service principals, modified trust policies, and Lambda or automation backdoors, all the ways an attacker keeps a way back in even after the original credential is rotated.

Defense evasion. Disabling or deleting CloudTrail, stopping a logging pipeline, deleting flow logs, operating from regions the organization does not monitor, all aimed at making sure the assessment finds nothing.

Collection and exfiltration. Enumerating and copying storage buckets, snapshotting and sharing databases to attacker-controlled accounts, and egress to external destinations, the actions that turn an intrusion into a data breach.

Compromise assessment vs posture assessment vs incident response

These three get conflated, and treating them as interchangeable leads to running the wrong one. They differ on their starting assumption, their trigger, and their output.

The relationships matter more than the table. A posture assessment finds the weaknesses an attacker could use; a compromise assessment finds out whether an attacker already used them; incident response takes over once the answer is yes and the intrusion is live. A compromise assessment sits between proactive hygiene and active firefighting: it is more adversarial and evidence-driven than a posture review, but it is not the full containment-and-recovery effort of an incident. When a compromise assessment confirms an active breach, it does not replace incident response, it triggers it. Run periodically and after any event that raises suspicion, the compromise assessment is the check that closes the gap between "we have no alerts" and "we have no intruders," which are not the same statement.

Why cloud environments need their own compromise assessment

The reason a cloud compromise assessment is its own discipline, and not just an on-premises hunt pointed at the cloud, comes down to where the evidence lives and how fast it moves.

The control plane is the new battleground. In the cloud, an attacker does not need to touch a single operating system to do real damage; an API call against the control plane can enumerate every bucket, assume a role, snapshot a database, and share it out. That means the audit log, not the endpoint, is often the primary evidence, and a hunt built only around endpoint detection misses the attacks that never reach an endpoint.

Identity is the perimeter. With no network edge to defend, a valid credential is access, and the line between a legitimate admin and an attacker using the admin's stolen token is drawn entirely in the identity telemetry. Ephemerality erases evidence: an instance or container that ran for an hour and was torn down leaves nothing to image unless its telemetry was captured while it lived, so cloud forensics depends on logging that was already on before the incident. And the shared responsibility model means the provider secures the infrastructure but the customer owns the configuration, the identities, and the data, which is exactly the layer a compromise assessment investigates.

Deliverables

The deliverable is what the engagement is bought for, and for a compromise assessment it has to answer the question that prompted it. A useful report has a few non-negotiable parts.

A clear verdict: was there evidence of compromise, yes or no, stated plainly and qualified by the data that was available to reach it. A timeline and scope if the answer is yes: when the intrusion started, what the attacker accessed, which identities and resources are implicated, and whether the access is still active. The evidence behind each conclusion, tied to specific log events, so a defender can verify the finding rather than trust it. A remediation and hardening plan: credentials to rotate, attacker artifacts to remove, configuration gaps to close, and monitoring to add. And a frank telemetry gap statement: where the assessment could not see, because that gap is both a limit on the verdict and the most important thing to fix before the next one.

For a defender, the report doubles as a map of the environment's blind spots. Every place the hunt went dark for lack of logging is a place the next attacker operates unseen, which is why a compromise assessment so often ends with a logging and retention overhaul rather than a clean bill of health.

Frequently Asked Questions

What is a cloud compromise assessment?

A cloud compromise assessment is a point-in-time, evidence-driven investigation of a cloud environment for signs that an unauthorized actor has accessed, persisted in, or moved through it. It collects control-plane audit logs, identity events, network flows, and workload telemetry, then hunts them for indicators of compromise and attacker behavior. It assumes breach and looks for proof, rather than grading configuration.

How is a compromise assessment different from a cloud security assessment?

A cloud security (posture) assessment is preventive and forward-looking: it grades configuration against benchmarks to find weaknesses an attacker could use. A compromise assessment is investigative and backward-looking: it checks whether an attacker already used those weaknesses and what they did inside. One finds the open door; the other checks whether anyone walked through it. Mature programs run both.

When should you run a cloud compromise assessment?

Run one proactively on a periodic basis, and reactively whenever something raises suspicion without a confirmed incident: a vendor or supply-chain breach that touched your tenant, leaked or exposed credentials, an upcoming acquisition that needs the target's environment vetted, or unexplained activity that monitoring flagged but could not resolve. It is the check for when "no alerts" is not the same as "no attacker."

What does a cloud compromise assessment inspect?

It inspects control-plane audit logs (CloudTrail, Azure Activity Log, Google Cloud Audit Logs), identity and sign-in events, network flow logs, workload and container telemetry, and configuration change history. The value comes from correlating these sources, because a cloud intrusion usually appears as a chain across them, an unusual login leading to a permission change leading to an unfamiliar API call, rather than a single obvious event.

Is a compromise assessment the same as incident response?

No. A compromise assessment determines whether a breach occurred when none is confirmed; incident response is what happens once a breach is confirmed and active. The assessment is the investigation that produces the verdict; if that verdict is a live intrusion, it hands off to incident response for containment, eviction, and recovery. The assessment triggers incident response, it does not replace it.

Why do cloud environments need a dedicated compromise assessment?

Because the evidence and the attack surface differ from on-premises. In the cloud the control-plane audit log is often the primary evidence, since an attacker can do extensive damage through API calls without touching an operating system. Identity is the perimeter, ephemeral workloads erase evidence unless telemetry was captured while they ran, and the shared responsibility model puts configuration, identity, and data, the exact targets of a hunt, on the customer.

What is in a cloud compromise assessment report?

A plain verdict on whether compromise was found, a timeline and scope if it was, the specific log evidence behind each conclusion, a remediation and hardening plan (credentials to rotate, attacker artifacts to remove, gaps to close), and a statement of where the assessment could not see for lack of telemetry. That telemetry-gap section is often the most actionable part, because it maps where the next intrusion would go unseen.

The bottom line

A cloud compromise assessment is an evidence-driven hunt that assumes an attacker is already inside and goes looking for proof, reading the control-plane logs, identity events, network flows, and workload telemetry that record what actually happened. It moves through three phases, assess the evidence, analyze it to confirm or rule out compromise, then act on the result, and it ends in a verdict rather than a configuration grade.

It is not a posture assessment and it is not incident response, though it sits between them: the posture review finds the weaknesses, the compromise assessment finds out whether they were used, and incident response takes over when the answer is yes. For a defender, the report is the most direct artifact you will get of whether your cloud is clean and, just as usefully, of where you cannot tell. Run it after anything that raises doubt, pair it with continuous monitoring, and treat every telemetry gap it finds as the place the next intruder will hide.