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.