[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AE7CM953J96HVTGR6X2H58":3,"skill-same:01M6AE7CM953J96HVTGR6X2H58":112},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":65,"commitSha":66,"skillDirectory":67,"forksCount":68,"repositoryHtmlUrl":69,"repositoryHomepageUrl":70,"ownerHtmlUrl":71,"ownerBlogUrl":72,"ownerDescription":73,"updatedAt":74,"install":75,"resources":88},"01M6AE7CM953J96HVTGR6X2H58","deploying-cloud-deception-with-decoy-resources",null,"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\u002Froles\u002Fservice principals, honey object-storage buckets, and decoy secrets in Secrets Manager \u002F Key Vault \u002F 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.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",36078,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdeploying-cloud-deception-with-decoy-resources\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"deploying cloud deception with decoy resources","deception","cloud","cloudtrail","reconnaissance","sentinel","iam","gcp","data","ZeRO","soc","cybersecurity","s3","logs","audit","code","generate","azure","defender","storage","2026-11-10 10:12:30",false,"---\nname: deploying-cloud-deception-with-decoy-resources\ndescription: >-\n  Deploy cloud-native deception across AWS, Azure, and GCP using decoy (honey) resources\n  whose only purpose is to generate a high-fidelity alert the instant an attacker touches\n  them: canary IAM access keys, permission-less decoy users\u002Froles\u002Fservice principals,\n  honey object-storage buckets, and decoy secrets in Secrets Manager \u002F Key Vault \u002F Secret\n  Manager. Wires detection through CloudTrail + EventBridge, Azure Sentinel honeytoken\n  watchlists + Defender, and GCP Cloud Audit Logs, so any use of a decoy is routed to the\n  SOC with near-zero false positives. Use when protecting cloud accounts and data stores,\n  when an org has only on-prem honeypots and needs cloud coverage, when seeding fake AWS\n  keys to catch credential theft and code-leak exposure, or when detecting cloud\n  reconnaissance and lateral movement. Keywords: cloud deception, canary token AWS, honey\n  S3 bucket, decoy IAM credentials, CloudTrail alert, GuardDuty, Sentinel honeytoken,\n  decoy secret, honey service account, cloud honeypot, breach detection.\ndomain: cybersecurity\nsubdomain: deception-technology\ntags:\n- cloud-deception\n- aws\n- azure\n- gcp\n- canary-token\n- honeytoken\n- cloudtrail\n- breach-detection\nversion: \"1.0\"\nauthor: andrewibrah\nlicense: Apache-2.0\nnist_csf:\n- DE.CM-01\n- DE.CM-06\n- DE.AE-02\n- ID.RA-01\n- RS.MA-01\nmitre_attack:\n- T1078\n- T1552\n- T1580\n- T1530\n- T1619\n---\n\n# Deploying Cloud Deception with Decoy Resources\n\n## When to Use\n\n- When cloud accounts (AWS\u002FAzure\u002FGCP) hold crown-jewel data or infrastructure and you need a tripwire that fires the moment an attacker who has gained access starts to operate.\n- When the only deception in place is on-prem honeypots, leaving the cloud control plane uninstrumented.\n- When seeding fake credentials to catch credential theft, accidental code-repo leaks, or secrets exposed in build pipelines.\n- When detecting cloud reconnaissance (enumeration of IAM, storage, or secrets) and lateral movement that legitimate users would never perform.\n- 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.\n\nThis is the cloud counterpart to on-prem honeypot\u002Fhoneytoken\u002Fcanary-token deployment skills. For program strategy and how these Activities map to adversary engagement goals, use `designing-adversary-engagement-with-mitre-engage`.\n\n## Prerequisites\n\n- Cloud admin\u002FIAM permissions to create decoy principals, storage, secrets, and detection wiring, ideally in a dedicated deployment role with least privilege.\n- Cloud audit logging already enabled: **AWS CloudTrail** (multi-region, with management and relevant data events), **Azure Activity log + Microsoft Entra audit\u002Fsign-in logs**, **GCP Cloud Audit Logs (Admin Activity always on; Data Access enabled where needed)**.\n- A SIEM\u002Falert sink: SNS topic, Microsoft Sentinel workspace, or GCP Pub\u002FSub + Monitoring, with routing to the SOC.\n- 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\u002Flabel kept out of attacker-visible metadata).\n- **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.\n\n## Workflow\n\n### 1. Decide what to mimic\nPick 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.\n\n### 2A. AWS — canary access keys on a permission-less user\nCreate a decoy IAM user with an explicit deny-all policy, then issue an access key to plant:\n```bash\naws iam create-user --user-name svc-backup-prod --tags Key=deception,Value=true\naws iam put-user-policy --user-name svc-backup-prod \\\n  --policy-name deny-all \\\n  --policy-document '{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Deny\",\"Action\":\"*\",\"Resource\":\"*\"}]}'\naws iam create-access-key --user-name svc-backup-prod   # plant the returned AccessKeyId\u002FSecret\n```\nAny use of this key appears in CloudTrail (even denied calls, which still log `AccessDenied`). Wire an EventBridge rule on CloudTrail to alert:\n```bash\naws events put-rule --name decoy-key-used \\\n  --event-pattern '{\"detail\":{\"userIdentity\":{\"userName\":[\"svc-backup-prod\"]}}}'\naws events put-targets --rule decoy-key-used \\\n  --targets \"Id\"=\"1\",\"Arn\"=\"arn:aws:sns:us-east-1:111111111111:soc-deception-alerts\"\n```\n\n### 2B. AWS — honey S3 bucket\nCreate a believable bucket, enable object-level data events, and alert on any read\u002Flist:\n```bash\naws s3api create-bucket --bucket acme-prod-db-backups-2026 --region us-east-1\naws s3api put-bucket-tagging --bucket acme-prod-db-backups-2026 \\\n  --tagging 'TagSet=[{Key=deception,Value=true}]'\n# Ensure CloudTrail captures S3 data events for this bucket, then alert on GetObject\u002FListBucket\naws events put-rule --name decoy-bucket-access \\\n  --event-pattern '{\"detail\":{\"eventSource\":[\"s3.amazonaws.com\"],\"requestParameters\":{\"bucketName\":[\"acme-prod-db-backups-2026\"]}}}'\n```\n\n### 2C. AWS — decoy secret\n```bash\naws secretsmanager create-secret --name prod\u002Fdb\u002Fmaster-password \\\n  --secret-string '{\"username\":\"dbadmin\",\"password\":\"DECOY-DO-NOT-USE\"}' \\\n  --tags Key=deception,Value=true\n# Alert on GetSecretValue for this secret via EventBridge -> SNS\n```\n\n### 3A. Azure — honeytoken watchlist + decoy service principal\nMicrosoft Sentinel natively supports honeytokens via a **Watchlist** of the `HoneyTokens` template; tagged decoy accounts\u002Fsecrets raise analytics alerts on use. Create a permission-less decoy app registration \u002F 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.\n\n### 3B. Azure — honey storage + Key Vault decoy secret\nCreate 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.\n\n### 4A. GCP — decoy service account + honey GCS bucket\nCreate a service account with no role bindings (permission-less), generate a key to plant, and alert on its use via Cloud Audit Logs:\n```bash\ngcloud iam service-accounts create svc-billing-export \\\n  --display-name=\"billing-export\"\ngcloud iam service-accounts keys create decoy-key.json \\\n  --iam-account=svc-billing-export@PROJECT.iam.gserviceaccount.com   # plant this key\ngsutil mb -b on gs:\u002F\u002Facme-finance-exports-2026\n```\nCreate 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.\n\n### 5. Centralize and de-duplicate\nRoute all clouds' decoy alerts to one SOC pipeline. Tag each alert as DECEPTION\u002Fhigh-fidelity so it bypasses normal noise filtering and triggers an IR playbook rather than a triage queue.\n\n### 6. Validate (red-team the decoys)\nHave 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.\n\n### 7. Maintain realism and rotate\nRefresh 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.\n\n## Key Concepts\n\n| Concept | Definition |\n|---|---|\n| Decoy \u002F honey resource | A cloud object created solely to be touched by an attacker; no legitimate user has any reason to use it. |\n| Canary access key | A planted credential whose use generates an audit-log event; carries deny-all permissions. |\n| High-fidelity alert | A near-zero-false-positive signal because legitimate workflows never reference the decoy. |\n| Permission-less principal | A decoy IAM user\u002Frole\u002Fservice principal\u002Fservice account with explicit deny-all or no role bindings. |\n| Data event | Cloud audit logging of object\u002Fdata-plane access (e.g., S3 GetObject), required to detect storage decoys. |\n| Pocket litter | Plausible supporting artifacts (fake configs, env files, wiki entries) that make a decoy credible. |\n| Decoy inventory | The authoritative internal record distinguishing decoys from real assets. |\n\n## Tools & Systems\n\n- **AWS** — IAM (decoy users\u002Froles), S3 (honey buckets, data events), Secrets Manager \u002F SSM Parameter Store (decoy secrets), CloudTrail, EventBridge, SNS\u002FLambda, GuardDuty (correlate anomalous use).\n- **Azure** — Microsoft Entra ID (decoy app registrations \u002F service principals), Storage \u002F Key Vault decoys, **Microsoft Sentinel HoneyTokens watchlist** and analytics rules, Microsoft Defender for Cloud, Entra ID Protection.\n- **GCP** — IAM service accounts (decoys), Cloud Storage (honey buckets), Secret Manager (decoy secrets), Cloud Audit Logs, log-based metrics + Cloud Monitoring alerting, Pub\u002FSub.\n- **Open-source \u002F managed honeytoken systems** — Canarytokens (https:\u002F\u002Fcanarytokens.org offers AWS API key tokens), Thinkst Canary, SpaceSiren \u002F SpaceCrab (self-hosted AWS honey-token frameworks).\n- **SIEM\u002FSOAR** — to centralize alerts across clouds and drive an IR playbook on any decoy hit.\n\n## Common Scenarios\n\n- **Credential-theft \u002F 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.\n- **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.\n- **Cloud lateral movement.** A permission-less decoy service principal that \"looks\" privileged catches adversaries assuming roles during pivoting.\n- **Secrets harvesting.** Decoy entries in Secrets Manager \u002F Key Vault \u002F Secret Manager detect tools scraping the secrets store.\n- **Migrating from on-prem-only deception.** Mirror the existing on-prem decoy strategy into the cloud control plane so coverage follows workloads.\n\n## Output Format\n\nProduce a **Cloud Deception Deployment Record** using `assets\u002Ftemplate.md`, containing:\n\n1. **Decoy inventory** — per decoy: cloud, type, plausible name, real placement location of any planted credential, internal `deception` tag\u002Flabel, owner.\n2. **Detection wiring** — per decoy: audit-log source → rule\u002Fpattern → alert sink → IR playbook reference, with the target alert latency.\n3. **Least-privilege proof** — evidence each decoy principal is deny-all \u002F no-role-binding.\n4. **Validation results** — date tested, who tested, end-to-end latency observed, pass\u002Ffail.\n5. **Maintenance plan** — rotation cadence and review owner.\n\nUse `scripts\u002Fprocess.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.\n","# Deploying Cloud Deception with Decoy Resources\n\n## When to Use\n\n- When cloud accounts (AWS\u002FAzure\u002FGCP) hold crown-jewel data or infrastructure and you need a tripwire that fires the moment an attacker who has gained access starts to operate.\n- When the only deception in place is on-prem honeypots, leaving the cloud control plane uninstrumented.\n- When seeding fake credentials to catch credential theft, accidental code-repo leaks, or secrets exposed in build pipelines.\n- When detecting cloud reconnaissance (enumeration of IAM, storage, or secrets) and lateral movement that legitimate users would never perform.\n- 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.\n\nThis is the cloud counterpart to on-prem honeypot\u002Fhoneytoken\u002Fcanary-token deployment skills. For program strategy and how these Activities map to adversary engagement goals, use `designing-adversary-engagement-with-mitre-engage`.\n\n## Prerequisites\n\n- Cloud admin\u002FIAM permissions to create decoy principals, storage, secrets, and detection wiring, ideally in a dedicated deployment role with least privilege.\n- Cloud audit logging already enabled: **AWS CloudTrail** (multi-region, with management and relevant data events), **Azure Activity log + Microsoft Entra audit\u002Fsign-in logs**, **GCP Cloud Audit Logs (Admin Activity always on; Data Access enabled where needed)**.\n- A SIEM\u002Falert sink: SNS topic, Microsoft Sentinel workspace, or GCP Pub\u002FSub + Monitoring, with routing to the SOC.\n- 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\u002Flabel kept out of attacker-visible metadata).\n- **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.\n\n## Workflow\n\n### 1. Decide what to mimic\nPick 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.\n\n### 2A. AWS — canary access keys on a permission-less user\nCreate a decoy IAM user with an explicit deny-all policy, then issue an access key to plant:\n```bash\naws iam create-user --user-name svc-backup-prod --tags Key=deception,Value=true\naws iam put-user-policy --user-name svc-backup-prod \\\n  --policy-name deny-all \\\n  --policy-document '{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Deny\",\"Action\":\"*\",\"Resource\":\"*\"}]}'\naws iam create-access-key --user-name svc-backup-prod   # plant the returned AccessKeyId\u002FSecret\n```\nAny use of this key appears in CloudTrail (even denied calls, which still log `AccessDenied`). Wire an EventBridge rule on CloudTrail to alert:\n```bash\naws events put-rule --name decoy-key-used \\\n  --event-pattern '{\"detail\":{\"userIdentity\":{\"userName\":[\"svc-backup-prod\"]}}}'\naws events put-targets --rule decoy-key-used \\\n  --targets \"Id\"=\"1\",\"Arn\"=\"arn:aws:sns:us-east-1:111111111111:soc-deception-alerts\"\n```\n\n### 2B. AWS — honey S3 bucket\nCreate a believable bucket, enable object-level data events, and alert on any read\u002Flist:\n```bash\naws s3api create-bucket --bucket acme-prod-db-backups-2026 --region us-east-1\naws s3api put-bucket-tagging --bucket acme-prod-db-backups-2026 \\\n  --tagging 'TagSet=[{Key=deception,Value=true}]'\n# Ensure CloudTrail captures S3 data events for this bucket, then alert on GetObject\u002FListBucket\naws events put-rule --name decoy-bucket-access \\\n  --event-pattern '{\"detail\":{\"eventSource\":[\"s3.amazonaws.com\"],\"requestParameters\":{\"bucketName\":[\"acme-prod-db-backups-2026\"]}}}'\n```\n\n### 2C. AWS — decoy secret\n```bash\naws secretsmanager create-secret --name prod\u002Fdb\u002Fmaster-password \\\n  --secret-string '{\"username\":\"dbadmin\",\"password\":\"DECOY-DO-NOT-USE\"}' \\\n  --tags Key=deception,Value=true\n# Alert on GetSecretValue for this secret via EventBridge -> SNS\n```\n\n### 3A. Azure — honeytoken watchlist + decoy service principal\nMicrosoft Sentinel natively supports honeytokens via a **Watchlist** of the `HoneyTokens` template; tagged decoy accounts\u002Fsecrets raise analytics alerts on use. Create a permission-less decoy app registration \u002F 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.\n\n### 3B. Azure — honey storage + Key Vault decoy secret\nCreate 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.\n\n### 4A. GCP — decoy service account + honey GCS bucket\nCreate a service account with no role bindings (permission-less), generate a key to plant, and alert on its use via Cloud Audit Logs:\n```bash\ngcloud iam service-accounts create svc-billing-export \\\n  --display-name=\"billing-export\"\ngcloud iam service-accounts keys create decoy-key.json \\\n  --iam-account=svc-billing-export@PROJECT.iam.gserviceaccount.com   # plant this key\ngsutil mb -b on gs:\u002F\u002Facme-finance-exports-2026\n```\nCreate 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.\n\n### 5. Centralize and de-duplicate\nRoute all clouds' decoy alerts to one SOC pipeline. Tag each alert as DECEPTION\u002Fhigh-fidelity so it bypasses normal noise filtering and triggers an IR playbook rather than a triage queue.\n\n### 6. Validate (red-team the decoys)\nHave 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.\n\n### 7. Maintain realism and rotate\nRefresh 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.\n\n## Key Concepts\n\n| Concept | Definition |\n|---|---|\n| Decoy \u002F honey resource | A cloud object created solely to be touched by an attacker; no legitimate user has any reason to use it. |\n| Canary access key | A planted credential whose use generates an audit-log event; carries deny-all permissions. |\n| High-fidelity alert | A near-zero-false-positive signal because legitimate workflows never reference the decoy. |\n| Permission-less principal | A decoy IAM user\u002Frole\u002Fservice principal\u002Fservice account with explicit deny-all or no role bindings. |\n| Data event | Cloud audit logging of object\u002Fdata-plane access (e.g., S3 GetObject), required to detect storage decoys. |\n| Pocket litter | Plausible supporting artifacts (fake configs, env files, wiki entries) that make a decoy credible. |\n| Decoy inventory | The authoritative internal record distinguishing decoys from real assets. |\n\n## Tools & Systems\n\n- **AWS** — IAM (decoy users\u002Froles), S3 (honey buckets, data events), Secrets Manager \u002F SSM Parameter Store (decoy secrets), CloudTrail, EventBridge, SNS\u002FLambda, GuardDuty (correlate anomalous use).\n- **Azure** — Microsoft Entra ID (decoy app registrations \u002F service principals), Storage \u002F Key Vault decoys, **Microsoft Sentinel HoneyTokens watchlist** and analytics rules, Microsoft Defender for Cloud, Entra ID Protection.\n- **GCP** — IAM service accounts (decoys), Cloud Storage (honey buckets), Secret Manager (decoy secrets), Cloud Audit Logs, log-based metrics + Cloud Monitoring alerting, Pub\u002FSub.\n- **Open-source \u002F managed honeytoken systems** — Canarytokens (https:\u002F\u002Fcanarytokens.org offers AWS API key tokens), Thinkst Canary, SpaceSiren \u002F SpaceCrab (self-hosted AWS honey-token frameworks).\n- **SIEM\u002FSOAR** — to centralize alerts across clouds and drive an IR playbook on any decoy hit.\n\n## Common Scenarios\n\n- **Credential-theft \u002F 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.\n- **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.\n- **Cloud lateral movement.** A permission-less decoy service principal that \"looks\" privileged catches adversaries assuming roles during pivoting.\n- **Secrets harvesting.** Decoy entries in Secrets Manager \u002F Key Vault \u002F Secret Manager detect tools scraping the secrets store.\n- **Migrating from on-prem-only deception.** Mirror the existing on-prem decoy strategy into the cloud control plane so coverage follows workloads.\n\n## Output Format\n\nProduce a **Cloud Deception Deployment Record** using `assets\u002Ftemplate.md`, containing:\n\n1. **Decoy inventory** — per decoy: cloud, type, plausible name, real placement location of any planted credential, internal `deception` tag\u002Flabel, owner.\n2. **Detection wiring** — per decoy: audit-log source → rule\u002Fpattern → alert sink → IR playbook reference, with the target alert latency.\n3. **Least-privilege proof** — evidence each decoy principal is deny-all \u002F no-role-binding.\n4. **Validation results** — date tested, who tested, end-to-end latency observed, pass\u002Ffail.\n5. **Maintenance plan** — rotation cadence and review owner.\n\nUse `scripts\u002Fprocess.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.\n",{"name":5,"tags":44,"author":50,"domain":30,"license":15,"version":51,"nist_csf":52,"subdomain":58,"description":7,"mitre_attack":59},[45,46,36,26,47,48,22,49],"cloud-deception","aws","canary-token","honeytoken","breach-detection","andrewibrah","1.0",[53,54,55,56,57],"DE.CM-01","DE.CM-06","DE.AE-02","ID.RA-01","RS.MA-01","deception-technology",[60,61,62,63,64],"T1078","T1552","T1580","T1530","T1619","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fdeploying-cloud-deception-with-decoy-resources",4414,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":76,"prompt":86,"zipAvailable":87},[77,80,83],{"tool":78,"command":79},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill deploying-cloud-deception-with-decoy-resources",{"tool":81,"command":82},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill deploying-cloud-deception-with-decoy-resources",{"tool":84,"command":85},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill deploying-cloud-deception-with-decoy-resources","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdeploying-cloud-deception-with-decoy-resources\u002FSKILL.md",true,[89,95,100,106],{"path":90,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":93,"sourceHtmlUrl":94},"assets\u002Ftemplate.md","ASSET","资产文件",2380,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdeploying-cloud-deception-with-decoy-resources\u002Fassets\u002Ftemplate.md",{"path":96,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdeploying-cloud-deception-with-decoy-resources\u002FLICENSE",{"path":101,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Fstandards.md","REFERENCE","参考文档",4187,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdeploying-cloud-deception-with-decoy-resources\u002Freferences\u002Fstandards.md",{"path":107,"resourceType":108,"resourceTypeDesc":109,"sizeBytes":110,"sourceHtmlUrl":111},"scripts\u002Fprocess.py","SCRIPT","脚本",5099,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdeploying-cloud-deception-with-decoy-resources\u002Fscripts\u002Fprocess.py",[113,143,166,194,218,245],{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":124,"publishedAt":39},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[119],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[125,126,127,128,129,30,130,131,132,34,133,134,135,136,137,138,139,140,141,142],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","security","incident response","identity","pr","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":150,"publishedAt":39},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[149],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},[151,139,152,153,129,154,30,132,155,28,156,157,158,159,160,161,162,163,164,165],"boot","TPM","validating tpm measured boot attestation","policy","verification","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":176,"publishedAt":39},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[172,175],{"categoryNo":173,"categoryName":174,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},[160,177,178,179,180,30,181,182,155,183,184,185,186,187,188,189,190,191,192,193],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1078","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":201,"publishedAt":39},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[200],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},[202,203,204,30,205,206,32,207,208,209,210,27,211,212,213,214,157,215,216,217],"windows","kape","triaging windows with kape","registry","browser","windows-forensics","dfir","mft","mftecmd","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":219,"name":220,"nameZh":6,"description":221,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":222,"categories":223,"keywords":225,"publishedAt":39},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[224],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},[226,227,228,30,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":246,"name":247,"nameZh":6,"description":248,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":249,"categories":250,"keywords":252,"publishedAt":39},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[251],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},[129,253,30,254,255,256,29,257,258,259,260,189,261,190,262,263,264,265,266,267],"triaging security incident","siem","file","ioc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]