Deploying Cloud Deception with Decoy Resources
When to Use
- When cloud accounts (AWS/Azure/GCP) hold crown-jewel data or infrastructure and you need a tripwire that fires the moment an attacker who has gained access starts to operate.
- When the only deception in place is on-prem honeypots, leaving the cloud control plane uninstrumented.
- When seeding fake credentials to catch credential theft, accidental code-repo leaks, or secrets exposed in build pipelines.
- When detecting cloud reconnaissance (enumeration of IAM, storage, or secrets) and lateral movement that legitimate users would never perform.
- When you want detections that survive into incident response with strong fidelity — a touch on a decoy resource almost always means malicious or unauthorized activity.
This is the cloud counterpart to on-prem honeypot/honeytoken/canary-token deployment skills. For program strategy and how these Activities map to adversary engagement goals, use designing-adversary-engagement-with-mitre-engage.
Prerequisites
- Cloud admin/IAM permissions to create decoy principals, storage, secrets, and detection wiring, ideally in a dedicated deployment role with least privilege.
- Cloud audit logging already enabled: AWS CloudTrail (multi-region, with management and relevant data events), Azure Activity log + Microsoft Entra audit/sign-in logs, GCP Cloud Audit Logs (Admin Activity always on; Data Access enabled where needed).
- A SIEM/alert sink: SNS topic, Microsoft Sentinel workspace, or GCP Pub/Sub + Monitoring, with routing to the SOC.
- A naming and tagging convention that is plausible to an attacker but unambiguous to defenders internally (e.g., realistic names, plus an internal
deception=true tag/label kept out of attacker-visible metadata).
- Decoy principals must be permission-less (explicit deny-all). The value is the alert, never the access. A decoy that grants real privilege is a liability, not a control.
Workflow
1. Decide what to mimic
Pick decoys that match how your attackers operate: leaked AWS keys (credential theft), an "admin" S3 bucket (data discovery), a prod-db-password secret (secrets harvesting), a privileged-looking service account (cloud lateral movement). Place credential decoys where harvesting tools look: env files, CI variables, code comments, an internal wiki.
2A. AWS — canary access keys on a permission-less user
Create a decoy IAM user with an explicit deny-all policy, then issue an access key to plant:
aws iam create-user --user-name svc-backup-prod --tags Key=deception,Value=true
aws iam put-user-policy --user-name svc-backup-prod \
--policy-name deny-all \
--policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"*","Resource":"*"}]}'
aws iam create-access-key --user-name svc-backup-prod
Any use of this key appears in CloudTrail (even denied calls, which still log AccessDenied). Wire an EventBridge rule on CloudTrail to alert:
aws events put-rule --name decoy-key-used \
--event-pattern '{"detail":{"userIdentity":{"userName":["svc-backup-prod"]}}}'
aws events put-targets --rule decoy-key-used \
--targets "Id"="1","Arn"="arn:aws:sns:us-east-1:111111111111:soc-deception-alerts"
2B. AWS — honey S3 bucket
Create a believable bucket, enable object-level data events, and alert on any read/list:
aws s3api create-bucket --bucket acme-prod-db-backups-2026 --region us-east-1
aws s3api put-bucket-tagging --bucket acme-prod-db-backups-2026 \
--tagging 'TagSet=[{Key=deception,Value=true}]'
aws events put-rule --name decoy-bucket-access \
--event-pattern '{"detail":{"eventSource":["s3.amazonaws.com"],"requestParameters":{"bucketName":["acme-prod-db-backups-2026"]}}}'
2C. AWS — decoy secret
aws secretsmanager create-secret --name prod/db/master-password \
--secret-string '{"username":"dbadmin","password":"DECOY-DO-NOT-USE"}' \
--tags Key=deception,Value=true
3A. Azure — honeytoken watchlist + decoy service principal
Microsoft Sentinel natively supports honeytokens via a Watchlist of the HoneyTokens template; tagged decoy accounts/secrets raise analytics alerts on use. Create a permission-less decoy app registration / service principal, then add its identifiers to the HoneyTokens watchlist and enable the related analytics rules. Microsoft Defender for Cloud and Entra ID Protection surface anomalous sign-ins to the decoy identity.
3B. Azure — honey storage + Key Vault decoy secret
Create a decoy Storage account and Key Vault, enable diagnostic logging to the Sentinel workspace, store a decoy secret, and write an analytics rule that fires on any data-plane read of the decoy resources.
4A. GCP — decoy service account + honey GCS bucket
Create a service account with no role bindings (permission-less), generate a key to plant, and alert on its use via Cloud Audit Logs:
gcloud iam service-accounts create svc-billing-export \
--display-name="billing-export"
gcloud iam service-accounts keys create decoy-key.json \
--iam-account=svc-billing-export@PROJECT.iam.gserviceaccount.com
gsutil mb -b on gs://acme-finance-exports-2026
Create a log-based metric + alerting policy in Cloud Monitoring that triggers on any audit-log entry where the principal is the decoy service account or the resource is the honey bucket.
5. Centralize and de-duplicate
Route all clouds' decoy alerts to one SOC pipeline. Tag each alert as DECEPTION/high-fidelity so it bypasses normal noise filtering and triggers an IR playbook rather than a triage queue.
6. Validate (red-team the decoys)
Have an authorized tester use each decoy (read the bucket, call with the key, fetch the secret) and confirm an alert lands end-to-end within target latency. A decoy you have not tested is assumed broken.
7. Maintain realism and rotate
Refresh decoy names, secrets, and pocket-litter periodically so they age with the real environment. Track every decoy in an inventory so they are never mistaken for real assets during audits or cleanups.
Key Concepts
| Concept | Definition |
|---|
| Decoy / honey resource | A cloud object created solely to be touched by an attacker; no legitimate user has any reason to use it. |
| Canary access key | A planted credential whose use generates an audit-log event; carries deny-all permissions. |
| High-fidelity alert | A near-zero-false-positive signal because legitimate workflows never reference the decoy. |
| Permission-less principal | A decoy IAM user/role/service principal/service account with explicit deny-all or no role bindings. |
| Data event | Cloud audit logging of object/data-plane access (e.g., S3 GetObject), required to detect storage decoys. |
| Pocket litter | Plausible supporting artifacts (fake configs, env files, wiki entries) that make a decoy credible. |
| Decoy inventory | The authoritative internal record distinguishing decoys from real assets. |
Tools & Systems
- AWS — IAM (decoy users/roles), S3 (honey buckets, data events), Secrets Manager / SSM Parameter Store (decoy secrets), CloudTrail, EventBridge, SNS/Lambda, GuardDuty (correlate anomalous use).
- Azure — Microsoft Entra ID (decoy app registrations / service principals), Storage / Key Vault decoys, Microsoft Sentinel HoneyTokens watchlist and analytics rules, Microsoft Defender for Cloud, Entra ID Protection.
- GCP — IAM service accounts (decoys), Cloud Storage (honey buckets), Secret Manager (decoy secrets), Cloud Audit Logs, log-based metrics + Cloud Monitoring alerting, Pub/Sub.
- Open-source / managed honeytoken systems — Canarytokens (https://canarytokens.org offers AWS API key tokens), Thinkst Canary, SpaceSiren / SpaceCrab (self-hosted AWS honey-token frameworks).
- SIEM/SOAR — to centralize alerts across clouds and drive an IR playbook on any decoy hit.
Common Scenarios
- Credential-theft / code-leak detection. Plant a canary AWS key in CI variables, an env file, and a private repo. Any external use (even from a leaked public push) fires within minutes.
- Crown-jewel data store. Stand up a honey "backups" bucket next to the real one; attackers enumerating storage hit the decoy first and reveal themselves.
- Cloud lateral movement. A permission-less decoy service principal that "looks" privileged catches adversaries assuming roles during pivoting.
- Secrets harvesting. Decoy entries in Secrets Manager / Key Vault / Secret Manager detect tools scraping the secrets store.
- Migrating from on-prem-only deception. Mirror the existing on-prem decoy strategy into the cloud control plane so coverage follows workloads.
Output Format
Produce a Cloud Deception Deployment Record using assets/template.md, containing:
- Decoy inventory — per decoy: cloud, type, plausible name, real placement location of any planted credential, internal
deception tag/label, owner.
- Detection wiring — per decoy: audit-log source → rule/pattern → alert sink → IR playbook reference, with the target alert latency.
- Least-privilege proof — evidence each decoy principal is deny-all / no-role-binding.
- Validation results — date tested, who tested, end-to-end latency observed, pass/fail.
- Maintenance plan — rotation cadence and review owner.
Use scripts/process.py to render the deployment record and a per-decoy detection checklist from a decoy-inventory JSON, and to flag decoys missing detection wiring or validation.
