/deploying-cloud-deception-with-decoy-resources

name: deploying-cloud-deception-with-decoy-resources
description: >-
  Deploy cloud-native deception across AWS, Azure, and GCP using decoy (honey) resources
  whose only purpose is to generate a high-fidelity alert the instant an attacker touches
  them: canary IAM access keys, permission-less decoy users/roles/service principals,
  honey object-storage buckets, and decoy secrets in Secrets Manager / Key Vault / Secret
  Manager. Wires detection through CloudTrail + EventBridge, Azure Sentinel honeytoken
  watchlists + Defender, and GCP Cloud Audit Logs, so any use of a decoy is routed to the
  SOC with near-zero false positives. Use when protecting cloud accounts and data stores,
  when an org has only on-prem honeypots and needs cloud coverage, when seeding fake AWS
  keys to catch credential theft and code-leak exposure, or when detecting cloud
  reconnaissance and lateral movement. Keywords: cloud deception, canary token AWS, honey
  S3 bucket, decoy IAM credentials, CloudTrail alert, GuardDuty, Sentinel honeytoken,
  decoy secret, honey service account, cloud honeypot, breach detection.
domain: cybersecurity
subdomain: deception-technology
tags:
- cloud-deception
- aws
- azure
- gcp
- canary-token
- honeytoken
- cloudtrail
- breach-detection
version: "1.0"
author: andrewibrah
license: Apache-2.0
nist_csf:
- DE.CM-01
- DE.CM-06
- DE.AE-02
- ID.RA-01
- RS.MA-01
mitre_attack:
- T1078
- T1552
- T1580
- T1530
- T1619

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   # plant the returned AccessKeyId/Secret

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}]'
# Ensure CloudTrail captures S3 data events for this bucket, then alert on GetObject/ListBucket
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
# Alert on GetSecretValue for this secret via EventBridge -> SNS

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 th