CDR Use Cases: 8 Cloud Threats It Detects

A leaked access key turns into a billing alert three days later: someone spun up forty GPU instances in a region you never use. By then the attacker has already enumerated your IAM, assumed two roles, and copied a storage bucket to an account you do not own. None of it tripped an endpoint alert, because none of it touched an endpoint. It was all API calls and control-plane actions, the kind of activity a posture scanner reports on after the fact and an EDR agent never sees at all.

That gap is what CDR use cases are about. Cloud Detection and Response watches the cloud at runtime, correlating control-plane logs, identity events, workload telemetry, and network flow into a single picture of what an identity or workload is actually doing. This article does not redefine CDR; the sibling page does that. Here the goal is concrete: the eight attacks CDR is built to catch, the telemetry it reads for each, the signal that fires the detection, and the response that closes the loop. Every attack is mapped to its MITRE ATT&CK cloud technique where one applies, because "anomalous behavior" is not a detection and a technique ID is.

A quick recap: what CDR watches

CDR is runtime detection and response for cloud environments. It does not prevent a misconfiguration the way posture management does, and it does not live on the host the way an endpoint agent does. It reads the cloud's own telemetry as events happen and decides whether a sequence of actions is an attack.

Four telemetry sources feed every use case below:

• Control-plane audit logs. AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs. Every API call: who made it, from where, against what resource, allowed or denied.
• Identity and authentication events. Sign-ins, MFA results, role assumptions, token grants, from the cloud IdP and IAM.
• Runtime workload telemetry. Agents or eBPF sensors on VMs, containers, and serverless, reporting process, file, and network activity inside the workload.
• Network flow telemetry. VPC flow logs and equivalents: which workload talked to which address, on which port, how much data moved.

The work is correlation. One CloudTrail event is rarely an incident. The leaked key, the role it assumed, the API calls that role made, the bucket it read, and the external address the data went to are one timeline, and CDR's job is to stitch them into it. The use cases that follow are the timelines worth detecting. For the full architecture and lifecycle, see the cloud detection breakdown.

Use case 1: Compromised cloud credentials and identity abuse

A long-lived access key ends up in a public Git commit, a phished session token, or a scraped CI/CD variable. The attacker authenticates with valid credentials and starts making API calls that the cloud accepts because, as far as IAM is concerned, the legitimate identity is making them. This is the most common way intrusions begin in the cloud, and it maps to ATT&CK T1078 Valid Accounts, specifically T1078.004 Cloud Accounts.

The telemetry is identity and control-plane logs. CDR detects on the deltas a stolen credential cannot hide: a sign-in or API call from a new geography or ASN, an access key used from an IP it has never used before, a sudden burst of Describe and List calls as the attacker maps what the credential can reach, or use at an hour that does not match the identity's history. None of these are malware. They are a known identity behaving unlike itself.

The response runs through the cloud API. Revoke the active session, disable or rotate the compromised key, and force re-authentication. Because the credential is the foothold, cutting it off stops everything downstream before the attacker pivots.

Use case 2: Privilege escalation in IAM

A foothold identity rarely has the access the attacker wants, so the next move is to grant itself more. In the cloud this is not a kernel exploit; it is an API call. The attacker attaches an over-permissive policy, adds itself to a privileged group, creates a second set of credentials on an account they control, or assumes a role that trusts too broadly. These map to T1098 Account Manipulation, including T1098.001 Additional Cloud Credentials and T1098.003 Additional Cloud Roles.

The signal lives in control-plane logs, and it is high fidelity because IAM mutations are rare and loud. CDR watches for AttachUserPolicy, CreateAccessKey on an identity other than the caller's own, CreateRole or UpdateAssumeRolePolicy that widens a trust relationship, and AddUserToGroup targeting an admin group. The tell is an identity modifying the permissions of the very session it is operating in, or minting credentials it will use moments later.

Response quarantines the identity: detach the policy it just added, delete the credentials it created, and isolate the principal pending review. The detection has to fire fast, because escalation is the step that turns a limited foothold into account-wide reach.

Use case 3: Crypto mining on hijacked compute

Compute is the cloud resource an attacker can monetize directly. With enough privilege they launch instances, often large GPU or compute-optimized types, in regions you do not use, and point them at a mining pool. The bill is the eventual symptom; the activity is the detection. This is ATT&CK T1496 Resource Hijacking, and the current sub-technique for mining specifically is T1496.001 Compute Hijacking.

Two telemetry sources catch it. Control-plane logs show the anomaly in provisioning: RunInstances for instance types or regions outside the account's baseline, a spike in concurrent instances, or service quotas being raised right before a launch. Runtime and network telemetry catch the workload behavior: sustained CPU pinned at 100 percent, plus outbound connections to known mining-pool ports and addresses.

Response terminates the unauthorized instances, revokes the launching identity's permissions, and, because mining is downstream of credential or escalation abuse, traces back to how the launch privilege was obtained. Stopping the instances without fixing the access just invites a relaunch.

Use case 4: Data exfiltration from cloud storage

The data an attacker came for usually lives in object storage. Once they have a credential or role that can read it, exfiltration is a sequence of ordinary API calls: enumerate the buckets, read the objects, and either pull them out to an external host or copy them into a storage account the attacker controls. Reading from storage is T1530 Data from Cloud Storage; copying to an attacker-owned account is T1537 Transfer Data to Cloud Account.

CDR reads control-plane and network telemetry together. The control-plane signal is the access pattern: a single identity issuing GetObject across an entire bucket, a volume and rate of reads far above that identity's norm, or a bucket policy suddenly opened to a wider audience. The network signal is the egress: a large outbound transfer from a workload that normally serves internal traffic, or a CopyObject whose destination is an account outside the organization.

Response cuts the path. Revoke the identity's read access, lock or re-scope the bucket policy, and block the egress route. The detection that matters most is volume-over-baseline, because individual GetObject calls are legitimate all day long; the anomaly is the rate and the breadth.

Use case 5: Control-plane and API abuse with logging tampering

A capable attacker knows the control-plane log is the thing that will convict them, so they try to blind it. They stop a CloudTrail trail, delete it, reconfigure it to log to a bucket they control, or disable a Cloud Audit Log sink. This is ATT&CK T1562 Impair Defenses, and the cloud-logging sub-technique is T1562.008 Disable or Modify Cloud Logs.

The detection is almost paradoxical: the last clean event the logging pipeline emits is often the attacker turning it off. CDR watches for StopLogging, DeleteTrail, UpdateTrail pointing a trail at a new destination, and the equivalent disable or delete events for Azure and Google Cloud audit sinks. Because these are administrative actions that legitimate operators almost never perform unannounced, they are high-confidence signals on their own.

Response treats logging tampering as an active intrusion in progress, not a configuration drift. Re-enable the trail, isolate the identity that disabled it, and preserve whatever telemetry survived elsewhere, since the gap in the primary log is itself evidence. This is why CDR should not depend on a single log source: telemetry that an attacker can switch off is telemetry you cannot trust alone.

Use case 6: Lateral movement across accounts and workloads

Cloud environments are rarely one account. They are organizations of accounts, subscriptions, and projects connected by role-assumption trust. An attacker who lands in one place uses that trust to move: assuming a role into a second account, pivoting from a compromised workload to others it can reach, or chaining role hops until they reach the account that holds the prize. Cross-account lateral movement in the cloud leans on T1078 Valid Accounts at each hop and on cloud infrastructure discovery (T1580) to find the next target.

The signal is in identity and control-plane logs, and it is a graph problem more than a single event. CDR correlates AssumeRole chains across account boundaries, identities authenticating in accounts they have never touched, and a workload's credentials suddenly making calls in a different account. One role assumption is routine. A chain of them tracing a path from a low-value entry point toward a sensitive account is the detection.

Response severs the chain at the narrowest point: revoke the role-assumption path, isolate the workloads and identities on it, and constrain the trust relationships that allowed the hop. The investigation value is the path itself, which shows exactly how far the attacker reached.

Use case 7: Container and Kubernetes runtime threats

Containerized workloads add an attack surface that lives below the cloud API and above the host. An attacker who lands in a container tries to break out to the node (T1611 Escape to Host), deploy a malicious container to run their own code (T1610 Deploy Container), or enumerate the cluster to find what else is reachable (T1613 Container and Resource Discovery). Managed Kubernetes such as Azure Kubernetes Service ties this surface back to the cloud control plane, where the cluster is provisioned and its identities are granted.

Runtime workload telemetry is the primary source here, because the control plane cannot see inside a running pod. eBPF or agent sensors catch the tells: a process spawning inside a container that was never in its image, a mount or syscall pattern consistent with a host escape, a new container image pulled from an unexpected registry, or a service account token being used from a pod that should not hold cluster-admin rights. CDR correlates these runtime events with the control-plane record of how the workload and its identity were created.

Response isolates the affected pod or node, kills the rogue container, and revokes the service account or workload identity it abused. The runtime layer is where this attack is visible at all, which is why a CDR deployment without workload sensors is blind to it.

Use case 8: Misconfiguration exploited at runtime

Posture tools find the open security group, the world-readable bucket, or the over-permissive role and tell you it exists. CDR's distinct job is to catch the moment that misconfiguration is used. The classic chain is the instance metadata service: a workload exposed to server-side request forgery lets an attacker reach the metadata endpoint and steal the instance's role credentials, mapped to T1552.005 Unsecured Credentials: Cloud Instance Metadata API. Other AWS misconfigurations, like a publicly exposed admin port or an open bucket, become incidents the instant an external party acts on them.

The telemetry is the combination that posture tools lack: the static weakness plus the runtime event that exploits it. CDR detects the metadata-credential pattern when a role's credentials, normally used only by the instance they belong to, suddenly appear in API calls from a different IP. It detects open-bucket abuse as anonymous or external GetObject against a resource that should be private. The known misconfiguration raises the prior; the runtime access confirms the breach.

Response is both immediate and structural: revoke the leaked role credentials and block the access, then close the misconfiguration that allowed it so the same path cannot be reused. This is the use case where CDR and posture management are complements, posture to find the weakness, CDR to catch its exploitation.

CDR use cases at a glance

Each use case is a chain from telemetry to detection to response. The table maps the eight to the cloud telemetry CDR reads, the signal that fires the detection, the response that closes it, and the ATT&CK technique where one applies.

Two patterns run through the table. First, almost every response acts through the cloud API, revoke, rotate, isolate, terminate, which is what lets CDR respond at the speed the attack moves. Second, the detection that matters is rarely a single event; it is an action that deviates from a baseline or a sequence that forms a path. The full set of cloud techniques these map to lives in the MITRE ATT&CK cloud matrices.

The bottom line

CDR earns its place by catching the attacks that run entirely inside the cloud, where neither a posture scan nor an endpoint agent is looking. The eight use cases are the spine of that value: credential abuse, IAM escalation, crypto mining, storage exfiltration, log tampering, cross-account lateral movement, container and Kubernetes runtime threats, and the runtime exploitation of misconfigurations. Each is a chain from cloud telemetry to a detection signal to a response that runs through the cloud API.

Two things hold across all eight. The telemetry is the cloud's own, control-plane logs, identity events, runtime sensors, and network flow, and the detection almost always comes from correlating several of them rather than trusting one event. And the response acts at API speed: revoke, rotate, isolate, terminate, before the attacker reaches the next hop. Map each use case to its ATT&CK technique, instrument the telemetry it needs, and "we have CDR" becomes a list of specific attacks you can actually prove you detect.