Cloud Deception Technology: Catching Stolen Credentials

An attacker in your cloud does not need malware, a foothold, or a protocol exploit. They need one credential, and from that point every action they take is an authorized API call that the provider logs in the same shape as every legitimate call your organization made that day. Deception works here because a credential attached to no workload, and a resource used by no service, have no legitimate calls to hide among.

Cloud gave security teams something on-prem never had, which is a complete record of every administrative action. It did not give them a way to read it.

Total visibility, no adjudication

The on-prem detection problem is coverage. You cannot see the subnet, the appliance has no agent, the switch does not span. The cloud detection problem is the opposite and it is less widely admitted: coverage is essentially total, and specificity is close to zero.

Your control-plane audit log has the call, the identity, the source address, the user agent, and the result. It also has every deployment, every autoscaling event, every backup job, every CI/CD pipeline run, every developer running a list command because they forgot a bucket name, and every one of your own security tools enumerating the account on a schedule. The events that make up an attack are sts:GetCallerIdentity, s3:ListBuckets, iam:ListAttachedUserPolicies, ec2:DescribeInstances. Those are the same events that make up a Tuesday.

So teams write detections against identity, geography, and rate. Those break in predictable ways. Identity breaks because the credential is valid and belongs to someone real. Geography breaks because half your workloads already call from hosting ranges and your staff travel. Rate breaks because automation calls these APIs harder than any attacker would dare.

CISA's August 2026 red team advisory, A Tale of Two SOCs, is the cleanest public illustration. At the first organization the red team pulled long-lived static AWS IAM user credentials out of configuration files sitting in users' home directories, credentials that had never been configured to expire or rotate. The SOC then failed to detect the lateral movement, persistence, and command and control that followed. Part of the cause was structural rather than technical: the organization ran multiple SOCs and multiple endpoint products, and the staff in one did not have visibility into the detection tools of the others. The second organization caught the initial access and quarantined it.

Same techniques, two outcomes. What separated them was whether anything in the pipeline produced a signal a human would act on.

A decoy credential produces that signal by construction, because it has no innocent explanation. In cloud it also has a property it has nowhere else.

The provider is already the sensor

On-prem, a decoy needs somewhere to live. A host, an IP from a validated pool, a service listening on a port. In cloud the identity itself is the decoy, and the thing watching it is the provider's own control plane. You did not have to deploy that, and an attacker working through the provider API has no way to act without it recording them.

This matters because of how authorization works. Build a decoy IAM user or service principal that genuinely exists in the same account or tenant as your real ones, give it a plausible name and key age, and attach nothing but an explicit deny. Every call made with that credential now authenticates successfully and then fails authorization, and the audit log records the failure with the calling identity, the source address, the user agent, and the API that was attempted. The attacker learns the key is useless. You learn who has it, where they are calling from, what tooling they are using, and what they wanted first.

A decoy that can do nothing beats a decoy with real permissions, and it is worth being precise about why. Give the decoy working access and you now have to sandbox it, watch it for abuse, and make a judgement call the moment the attacker uses it for something. A decoy under a blanket deny is inert, so the only question it can answer is the one you planted it to answer.

Two engineering details decide whether this works. The principal has to exist rather than be a deactivated or deleted one, because a credential the provider cannot resolve at all fails earlier in the request path and leaves you a thinner record. And it must not be named like a decoy. An attacker who has reached your IAM listing is reading those names carefully.

The cloud attack chain, by technique

The IDs are here so you can line this against your coverage map. Where an attack crosses into on-prem identity, that ground is covered in Active Directory deception; hybrid identity is the seam between the two.

Finding the credential (T1552). This is where cloud intrusions start and it is mostly a file-search problem. Credentials in files (T1552.001) means CLI credential profiles, Terraform state, notebook configs, .env files, and database connection strings. The instance metadata API (T1552.005) is the other major path, reachable either from a workload the attacker already controls or from outside through a server-side request forgery in a public-facing application, since the de facto address for it is the same across providers. The container API (T1552.007) covers the Docker and Kubernetes case, where an adversary with a pod's service account can ask the API server for secrets. Each of these locations is a breadcrumb placement, because an inert line of text in a credential file is indistinguishable from a real one until someone tries it.

Stealing tokens (T1528). Application access tokens and managed identity tokens are the cloud-native version of pass-the-hash. A compromised resource with an attached managed identity can request short-lived tokens through the metadata service, which means the attacker never touches a password and nothing about the authentication looks wrong.

Using a valid account (T1078.004). A cloud account used by its owner and the same account used by an intruder produce identical events. This is the whole baseline problem compressed into one technique ID, and decoy principals are the only subset of your accounts where it does not apply.

Enumerating (T1580, T1526, T1619, T1613). Cloud infrastructure discovery reads the components, service discovery reads which services are even in use, cloud storage object discovery lists what is inside a bucket, and container and resource discovery does the same for a cluster. Unlike reading an on-prem directory, every one of these is an API call against a named resource, which is the structural reason cloud deception can detect reconnaissance when on-prem deception mostly cannot. A list call against a decoy bucket is recorded, attributed, and has no legitimate cause.

Persisting (T1098.001, T1098.003, T1136.003). Adding credentials to a service principal or application, adding roles or policies to an account already under control, or creating a new cloud account outright. These survive password resets and they are how a short intrusion becomes a long one.

Breaking the authentication process (T1556.007). Modifying the hybrid identity authentication path, in some cases from the cloud side, so that the trust between your directory and your tenant produces tokens the attacker chose. This is the case where decoys in both environments earn their place, because the attacker eventually has to use what they minted.

Operating where nobody is watching (T1535). Creating instances in geographic regions you do not use, and therefore do not monitor, or in regions where the provider's advanced detection services are not available. A decoy resource in an unused region is one of the cheapest tripwires there is, because nobody who belongs in your account has a reason to look there.

Escaping the container (T1611). Breaking out of a container to the host, and from there to the other containers or to the host's own identity. Deception is not the control for this one. It is a workload-hardening problem, and the most a decoy contributes is catching what the attacker does with the identity they land on.

Taking the data (T1530, T1537). Reading from cloud storage, and transferring it to another account on the same provider rather than out to the internet, which blends into the provider's internal address space and bypasses anything watching the egress path.

Placement table

If you build two rows, build the credential-file breadcrumb and the IAM decoy principal it points at. Together they cover the path the CISA advisory describes, and they fire while the attacker is still deciding what to do. They also have no runtime cost at all, because an identity with no permissions and a line of text in a config file are not resources anyone bills you for. The decoy buckets and the dead-region resources further down the table do cost money, which is the next section.

What the SOC receives

The test is whether an analyst can act without first writing a query across the control-plane log. A decoy alert names the credential, the calls attempted, where the credential was planted, and who spent it:

severity    : high
decoy       : fin-reporting-svc  (decoy IAM user, explicit deny, no attached workload)
event       : sts:GetCallerIdentity (success), s3:ListBuckets (AccessDenied)
breadcrumb  : ~/.aws/credentials profile "fin-reporting" on WS-DEV-0211
source      : 203.0.113.46  (outside all corporate and workload ranges)
user agent  : aws-cli/2  on Linux
note        : credential planted 2026-08-14, never used by anything until now

The breadcrumb and source lines carry the investigation. That credential was readable from exactly one workstation, so the compromise is scoped before anyone opens a ticket. And the source address belongs to the attacker rather than to you, because a planted credential is the one thing in your environment that only moves when someone steals it. Alerts arrive enriched and deduplicated in the tooling the SOC already runs, including Splunk, Microsoft Sentinel, IBM QRadar, and Google Chronicle.

Deployment constraints worth knowing before you ask for approval

Cloud decoys are cheap. They are not free of consequences, and the objections will come from platform engineering rather than from security.

They appear in the bill and in the inventory. A decoy bucket, a decoy principal, and a handful of decoy resources in unused regions show up on the cost report and in whatever asset inventory your auditors read. Tell the owner of that inventory before the audit, not during it.

They have to survive infrastructure as code. If your account is reconciled from a repository, anything created outside it gets deleted on the next apply, and a decoy that vanishes every Thursday detects nothing. Decide early whether the decoys live in the same pipeline as production, with the blending and naming handled there, or in a separate path that the reconciliation excludes.

Your own tools will touch them. Secret scanners find the breadcrumb credential and try it. Posture management and entitlement tooling enumerate every principal, and some of them will test what a principal can do. Backup agents and data classification scanners read the decoy bucket. Write the expected benign triggers down, name who owns each one, and route them before an on-call analyst meets them at 3 AM. Skip this and the alerts get muted, and a muted deception deployment is the same as not having one.

Nothing is installed on production workloads. The breadcrumb is a line of text in a file or a variable, and it only matters if someone steals it.

Next to CSPM, identity tooling and SIEM

Deception adds a layer. The boundaries are what make it worth buying.

Cloud posture and entitlement management (CSPM and CIEM) are better at the problem deception does not address at all, which is that somewhere in your account is a real over-permissioned principal with a five-year-old access key and nobody knows which workload uses it. That is exposure, and the right answer is to remove it. A decoy does not reduce your attack surface by one byte. If you have to choose between finding your real standing credentials and planting fake ones, find the real ones first.

Endpoint products own the host. They see the process that read the credential file, what ran before it and what ran after, and they can block. They are strongest exactly where cloud deception is blind, and weakest once the activity is an API call from an address you have never seen.

Identity threat detection covers every account rather than the handful you planted. That breadth is its real advantage over deception, and the cost of it is that the output is a probability, which is where it stops being something you can page on without a judgement call.

SIEM is where this lands. Deception does not reduce your log volume; it adds one source with an unusually high signal-to-noise ratio, which makes it the rare cloud event where automated escalation and automated key revocation are defensible.

The honest limits. A decoy credential detects use, not theft, so an attacker who copies your credential files and never spends what they took will not trip anything. A careful adversary may try to work out whether a key has ever been used before using it, and your decoy's plausibility is what decides how that goes. Cross-account exfiltration to another tenant on the same provider is barely helped by decoys, because the attacker is moving real data they already found. Container escape and workload compromise are endpoint problems. And an alert nobody owns is decoration, which is a process failure rather than a product one, and is most of what the CISA advisory was actually about.

Where to start

The honest test takes one principal and one file. Create a decoy IAM user with a name that fits your conventions and an explicit deny, write its access key into a credentials profile on one developer workstation and one build agent, and leave both alone for a month. Then have someone run aws sts get-caller-identity against that profile and check two things: whether the alert fires, and whether it arrives naming the workstation the credential was planted on rather than as an AccessDenied line you have to go find in the control-plane log.

Decoy Management provisions, blends and retires those assets from one control plane, with coverage planned against MITRE ATT&CK so placement follows the techniques you are exposed to. For the on-prem identity material that hybrid attacks cross into, see Active Directory deception; for the movement step between hosts, lateral movement detection; and if encryption at scale is the outcome you are defending against, ransomware early detection. For why credential-and-native-tooling attacks are the hardest ones to catch, scaling living off the land engagement, and for deception as a detection layer in general, a practical guide to modern cyber deception.

See it running in your cloud account.