[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AE7VJHZ04S9HR97KGMPDS1":3,"skill-same:01M6AE7VJHZ04S9HR97KGMPDS1":108},{"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":29,"publishedAt":50,"linkOnly":51,"markdownContent":52,"markdownBody":53,"frontMatter":54,"refName":63,"commitSha":64,"skillDirectory":65,"forksCount":66,"repositoryHtmlUrl":67,"repositoryHomepageUrl":68,"ownerHtmlUrl":69,"ownerBlogUrl":70,"ownerDescription":71,"updatedAt":72,"install":73,"resources":86},"01M6AE7VJHZ04S9HR97KGMPDS1","deploying-honeytokens-and-canarytokens",null,"Plants Canarytokens-based decoy artifacts (honey credentials, DNS tokens, web-bug URLs, AWS keys, documents, kubeconfigs) using Thinkst's open-source Canarytokens project and alerts via email or webhook when a token is touched. Use for high-fidelity intrusion detection in low-telemetry areas like file shares or credential stores, or to catch credential dumping and data-theft staging.","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-honeytokens-and-canarytokens\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000005","邮件与沟通",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49],"deploying honeytokens and canarytokens","honeytokens","data","decoy-credentials","d3fend","canarytokens","deception-technology","detection","deception","aws","cybersecurity","intrusion-detection","threat-detection","dns","email","file","artifacts","documents","telemetry","web","2026-11-10 10:12:30",false,"---\nname: deploying-honeytokens-and-canarytokens\ndescription: Plants Canarytokens-based decoy artifacts (honey credentials, DNS tokens, web-bug URLs, AWS keys, documents, kubeconfigs) using Thinkst's open-source Canarytokens project and alerts via email or webhook when a token is touched. Use for high-fidelity intrusion detection in low-telemetry areas like file shares or credential stores, or to catch credential dumping and data-theft staging.\ndomain: cybersecurity\nsubdomain: deception-technology\ntags:\n- deception-technology\n- canarytokens\n- honeytokens\n- breach-detection\n- threat-detection\n- d3fend\n- decoy-credentials\n- intrusion-detection\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- DE.CM-01\nmitre_attack:\n- T1556\n---\n# Deploying Honeytokens and Canarytokens\n\n> **Authorized Use Only:** Deception assets described here are defensive controls deployed inside your own environment. Deploying tokens, decoy credentials, or honeypots on infrastructure you do not own or administer, or using them to entrap third parties, may violate computer-misuse and privacy law. Deploy only on assets you own or are explicitly authorized to instrument, and route all alert data through approved monitoring channels.\n\n## Overview\n\nHoneytokens (a.k.a. canarytokens) are decoy artifacts — credentials, files, URLs, API keys, DNS names, database connection strings, documents — that have no legitimate operational use. Because no authorized user or process should ever touch them, **any** interaction is a high-fidelity signal of an intrusion, insider misuse, or reconnaissance. Unlike signature- or anomaly-based detection, honeytokens generate near-zero false positives: the alert *is* the compromise.\n\nThinkst's open-source **Canarytokens** project (https:\u002F\u002Fcanarytokens.org and the self-hostable `thinkst\u002Fcanarytokens-docker`) generates dozens of token types that \"phone home\" when triggered: an HTTP\u002Fweb-bug URL that fires on GET, an AWS API key that fires when used against AWS, an MS Word\u002FPDF document that fires on open, a DNS token that fires on resolution, a Slack API token, a Kubernetes `kubeconfig`, an Azure login certificate, a `log4shell` payload, and more. Each token is bound to a unique `memo` (so you know *where* it was planted) plus an alert channel (email and\u002For webhook).\n\nThis skill maps to MITRE D3FEND's **Decoy File (D3-DF)**, **Decoy User Credential (D3-DUC)**, and **Honeytoken** techniques. From an ATT&CK perspective, a triggered honey credential most commonly evidences adversary attempts to abuse or modify authentication material (**T1556 – Modify Authentication Process** and related credential-access activity), giving the SOC an early, unambiguous tripwire deep inside the kill chain — typically after initial access but before lateral movement completes.\n\n## When to Use\n\n- When you need high-fidelity intrusion detection in segments where traditional telemetry is sparse (file shares, password vaults, code repos, cloud accounts).\n- When validating that an attacker who reaches a \"crown-jewel\" host or document store is detected, not just blocked at the perimeter.\n- When seeding decoy credentials into LSASS-reachable memory, browser stores, `.aws\u002Fcredentials`, or password managers to catch credential dumping and reuse.\n- When instrumenting documents, repos, or wikis to catch data theft and ransomware staging.\n- When building a MITRE D3FEND-aligned deception layer as part of a defense-in-depth or zero-trust program.\n\n## Prerequisites\n\n- Docker Engine and Docker Compose v2 for self-hosting (`docker compose version`).\n- A registered domain you control plus DNS delegation for DNS-based tokens (NS records pointing at your switchboard host).\n- A public IPv4 address reachable on 80\u002F443 (HTTP tokens) and 53\u002Fudp (DNS tokens).\n- An SMTP relay or Mailgun account, and\u002For a Slack\u002FTeams\u002Fgeneric webhook URL for alert delivery.\n- Python 3.8+ for the helper script:\n  ```bash\n  python3 -m pip install requests\n  ```\n- For quick use with no hosting, an account-free token from the public service at https:\u002F\u002Fcanarytokens.org.\n\n## Objectives\n\n- Stand up a self-hosted Canarytokens instance (or use the public service) with working alerting.\n- Generate the major token types (HTTP, DNS, AWS key, MS Word\u002FPDF, Slack, kubeconfig) with descriptive memos.\n- Plant decoy credentials and decoy files in realistic, monitored locations.\n- Validate that each token fires and that alerts reach the SOC channel.\n- Catalogue deployed tokens and map them to MITRE D3FEND\u002FATT&CK for coverage tracking.\n\n## MITRE ATT&CK Mapping\n\n| ID | Official Technique Name | Relevance |\n|----|------------------------|-----------|\n| T1556 | Modify Authentication Process | A triggered honey credential reveals an adversary harvesting\u002Fabusing authentication material; the decoy provides a detection tripwire for credential abuse activity. |\n\n**Related MITRE D3FEND defensive techniques** (the offensive counter-mapping for this control):\n\n| D3FEND ID | Technique | Role |\n|-----------|-----------|------|\n| D3-DF | Decoy File | Canary documents, fake configs, decoy archives placed and monitored. |\n| D3-DUC | Decoy User Credential | Honey credentials (AWS keys, AD accounts, kubeconfig) integrated with a monitored decoy asset. |\n| D3-DO | Decoy Object | Umbrella for honeytokens\u002Fcanarytokens as monitored decoy artifacts. |\n\n## Workflow\n\n### 1. Deploy a self-hosted Canarytokens switchboard\nClone the official Docker repo and create the two environment files from their distributed templates:\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fthinkst\u002Fcanarytokens-docker\ncd canarytokens-docker\ncp switchboard.env.dist switchboard.env\ncp frontend.env.dist frontend.env\n```\nSet the core variables. In `frontend.env`:\n```ini\nCANARY_DOMAINS=canary.example.com          # general-purpose token domains (comma-separated)\nCANARY_NXDOMAINS=nx.example.com            # domains reserved for PDF\u002FDNS tokens\nCANARY_PUBLIC_IP=203.0.113.10              # public IP of this host\n```\nIn `switchboard.env`:\n```ini\nCANARY_PUBLIC_DOMAIN=canary.example.com\nCANARY_MAILGUN_DOMAIN_NAME=mg.example.com\nCANARY_MAILGUN_API_KEY=key-xxxxxxxxxxxxxxxx\nCANARY_ALERT_EMAIL_FROM_ADDRESS=canary@example.com\nCANARY_ALERT_EMAIL_FROM_DISPLAY=Canarytokens\nCANARY_ALERT_EMAIL_SUBJECT=Canarytoken Triggered\n# WireGuard token seed:\n# dd bs=32 count=1 if=\u002Fdev\u002Furandom 2>\u002Fdev\u002Fnull | base64\nCANARY_WG_PRIVATE_KEY_SEED=\u003Cbase64-seed>\n```\n\n### 2. Bring the stack up\n```bash\ndocker compose up -d\n# HTTPS with automatic Let's Encrypt certs (after editing certbot.env):\n# docker compose -f docker-compose-letsencrypt.yml up -d\ndocker compose ps\ndocker compose logs -f frontend\n```\nThe frontend (token generator UI) is now served on your `CANARY_PUBLIC_DOMAIN`; the switchboard listens on 80\u002F443 and 53\u002Fudp to receive triggers.\n\n### 3. Generate an HTTP (web-bug) token via the API\nBoth the public service and a self-hosted frontend expose a `POST \u002Fgenerate` endpoint. Create an HTTP token that fires on any GET:\n```bash\ncurl -s https:\u002F\u002Fcanarytokens.org\u002Fgenerate \\\n  -F 'type=http' \\\n  -F 'email=soc@example.com' \\\n  -F 'memo=Internal wiki - IT admin passwords page' \\\n  -F 'webhook_url=https:\u002F\u002Fhooks.slack.com\u002Fservices\u002FT000\u002FB000\u002FXXXX'\n# Response JSON includes: token, auth, hostname, url, url_components\n```\nThe returned `url` is the trip-wire link; place it where only an intruder would find it (a fake bookmark, a hidden link in a wiki page, an email signature).\n\n### 4. Generate a cloud credential (AWS API key) honeytoken\n```bash\ncurl -s https:\u002F\u002Fcanarytokens.org\u002Fgenerate \\\n  -F 'type=aws_keys' \\\n  -F 'email=soc@example.com' \\\n  -F 'memo=Decoy AWS keys - jenkins build host \u002Froot\u002F.aws\u002Fcredentials'\n# Response contains access_key_id and secret_access_key plus a downloadable\n# credentials file via \u002Fdownload?token=\u003Ctoken>&auth=\u003Cauth>&fmt=aws_keys\n```\nDrop the keys into a plausible `~\u002F.aws\u002Fcredentials` on a monitored host. Any `sts:GetCallerIdentity` or other AWS call using them triggers an alert with the source IP and user agent.\n\n### 5. Generate a document token (MS Word \u002F PDF) for data-theft detection\n```bash\n# MS Word\ncurl -s https:\u002F\u002Fcanarytokens.org\u002Fgenerate \\\n  -F 'type=msword' \\\n  -F 'email=soc@example.com' \\\n  -F 'memo=Q4-Layoffs-DRAFT.docx on FILESERVER01\\\\HR$' \\\n  -o token-meta.json\n# Download the weaponized document:\ncurl -s \"https:\u002F\u002Fcanarytokens.org\u002Fdownload?fmt=msword&token=\u003Ctoken>&auth=\u003Cauth>\" -o Q4-Layoffs-DRAFT.docx\n```\nFor PDFs use `type=adobe_pdf`. The document phones home when opened (DNS\u002FHTTP callback), exposing the reader's IP.\n\n### 6. Plant a DNS token for resolver-level tripwires\n```bash\ncurl -s https:\u002F\u002Fcanarytokens.org\u002Fgenerate \\\n  -F 'type=dns' \\\n  -F 'email=soc@example.com' \\\n  -F 'memo=DNS canary referenced in backup script comments'\n# Response 'hostname' is a unique FQDN; any resolution of it fires an alert.\n```\nEmbed the hostname in scripts, configs, or `\u002Fetc\u002Fhosts` comments. Because resolution alone triggers it, DNS tokens catch reconnaissance even when egress HTTP is blocked.\n\n### 7. Generate infrastructure tokens (Slack, kubeconfig, Azure)\n```bash\n# Slack API token canary (fires when the fake token is used against Slack)\ncurl -s https:\u002F\u002Fcanarytokens.org\u002Fgenerate -F 'type=slack_api' \\\n  -F 'email=soc@example.com' -F 'memo=Decoy Slack bot token in repo .env'\n\n# Kubeconfig canary (fires when used against the kube API)\ncurl -s https:\u002F\u002Fcanarytokens.org\u002Fgenerate -F 'type=kubeconfig' \\\n  -F 'email=soc@example.com' -F 'memo=Decoy kubeconfig in \u002Fhome\u002Fdeploy\u002F.kube\u002Fconfig'\n```\nCommit decoy `.env` \u002F `kubeconfig` files only to repos and hosts you instrument, never to public repos.\n\n### 8. Plant Active Directory honey credentials (decoy user)\nCreate a non-privileged-looking but never-used AD account whose authentication is alerted on. Set a SPN so it appears Kerberoastable bait, and forward Event ID 4768\u002F4769\u002F4625 for it to your SIEM:\n```powershell\nNew-ADUser -Name \"svc_backup_legacy\" -SamAccountName \"svc_backup_legacy\" `\n  -AccountPassword (ConvertTo-SecureString 'C0mpl3xDecoy!2026' -AsPlainText -Force) `\n  -Enabled $true -Description \"Legacy backup service (do not use)\"\nSet-ADUser svc_backup_legacy -ServicePrincipalNames @{Add=\"MSSQLSvc\u002Fdecoy.example.com:1433\"}\n```\nAdd a Windows audit ACL\u002FSACL or a SIEM correlation rule so any 4768\u002F4769 for `svc_backup_legacy` pages the SOC — no legitimate logon should ever occur.\n\n### 9. Validate and catalogue\nTrigger each token from a controlled host and confirm the alert lands:\n```bash\n# HTTP token\ncurl -s \"https:\u002F\u002Fcanary.example.com\u002F\u003Ctoken-url>\" >\u002Fdev\u002Fnull\n# DNS token\ndig +short \u003Cunique-hostname>\n# AWS key token\nAWS_ACCESS_KEY_ID=\u003Cid> AWS_SECRET_ACCESS_KEY=\u003Csecret> aws sts get-caller-identity\n```\nRecord each deployed token (type, memo, location, alert channel, D3FEND mapping) in an inventory. Use the helper script below to bulk-generate and export this inventory as JSON.\n\n## Tools and Resources\n\n| Tool \u002F Resource | Purpose | Link |\n|-----------------|---------|------|\n| Canarytokens (public) | Free hosted token generation | https:\u002F\u002Fcanarytokens.org |\n| canarytokens-docker | Self-hosted switchboard + frontend | https:\u002F\u002Fgithub.com\u002Fthinkst\u002Fcanarytokens-docker |\n| canarytokens (core) | Source for the token engine | https:\u002F\u002Fgithub.com\u002Fthinkst\u002Fcanarytokens |\n| Canarytokens docs | Per-token-type usage guides | https:\u002F\u002Fdocs.canarytokens.org |\n| MITRE D3FEND | Defensive technique taxonomy (D3-DF, D3-DUC) | https:\u002F\u002Fd3fend.mitre.org |\n| MITRE ATT&CK T1556 | Modify Authentication Process | https:\u002F\u002Fattack.mitre.org\u002Ftechniques\u002FT1556\u002F |\n\n## Token Type Reference\n\n| `type` value | Token | Fires when |\n|--------------|-------|-----------|\n| `http` | Web-bug URL | URL is requested (GET) |\n| `dns` | DNS name | Hostname is resolved |\n| `aws_keys` | AWS API key | Keys used against AWS |\n| `msword` \u002F `adobe_pdf` | Office\u002FPDF document | Document is opened |\n| `slack_api` | Slack API token | Token used against Slack |\n| `kubeconfig` | Kubernetes config | Used against the kube API |\n| `azure_id` | Azure login certificate | Cert used to authenticate to Azure |\n| `qr_code` | QR code | Encoded URL is requested |\n| `web_image` | Image web-bug | Image is loaded |\n| `log4shell` | Log4j JNDI string | Vulnerable logger evaluates it |\n| `cmd` | Sensitive command (Windows) | Process\u002Fcommand is executed |\n\n## Validation Criteria\n\n- [ ] Self-hosted switchboard (or public service) deployed and reachable on 80\u002F443 and 53\u002Fudp.\n- [ ] Alert channel (email and\u002For webhook) configured and test alert received.\n- [ ] At least one each of HTTP, DNS, cloud-credential, and document tokens generated with descriptive memos.\n- [ ] Decoy credentials planted in realistic, monitored locations (no production secrets co-located).\n- [ ] AD honey account created with SACL\u002FSIEM rule firing on any authentication.\n- [ ] Each token validated by a controlled trigger; alert confirmed end-to-end.\n- [ ] Token inventory exported (type, memo, location, alert channel, D3-DF\u002FD3-DUC mapping).\n- [ ] No tokens committed to public repositories or planted on out-of-scope systems.\n","# Deploying Honeytokens and Canarytokens\n\n> **Authorized Use Only:** Deception assets described here are defensive controls deployed inside your own environment. Deploying tokens, decoy credentials, or honeypots on infrastructure you do not own or administer, or using them to entrap third parties, may violate computer-misuse and privacy law. Deploy only on assets you own or are explicitly authorized to instrument, and route all alert data through approved monitoring channels.\n\n## Overview\n\nHoneytokens (a.k.a. canarytokens) are decoy artifacts — credentials, files, URLs, API keys, DNS names, database connection strings, documents — that have no legitimate operational use. Because no authorized user or process should ever touch them, **any** interaction is a high-fidelity signal of an intrusion, insider misuse, or reconnaissance. Unlike signature- or anomaly-based detection, honeytokens generate near-zero false positives: the alert *is* the compromise.\n\nThinkst's open-source **Canarytokens** project (https:\u002F\u002Fcanarytokens.org and the self-hostable `thinkst\u002Fcanarytokens-docker`) generates dozens of token types that \"phone home\" when triggered: an HTTP\u002Fweb-bug URL that fires on GET, an AWS API key that fires when used against AWS, an MS Word\u002FPDF document that fires on open, a DNS token that fires on resolution, a Slack API token, a Kubernetes `kubeconfig`, an Azure login certificate, a `log4shell` payload, and more. Each token is bound to a unique `memo` (so you know *where* it was planted) plus an alert channel (email and\u002For webhook).\n\nThis skill maps to MITRE D3FEND's **Decoy File (D3-DF)**, **Decoy User Credential (D3-DUC)**, and **Honeytoken** techniques. From an ATT&CK perspective, a triggered honey credential most commonly evidences adversary attempts to abuse or modify authentication material (**T1556 – Modify Authentication Process** and related credential-access activity), giving the SOC an early, unambiguous tripwire deep inside the kill chain — typically after initial access but before lateral movement completes.\n\n## When to Use\n\n- When you need high-fidelity intrusion detection in segments where traditional telemetry is sparse (file shares, password vaults, code repos, cloud accounts).\n- When validating that an attacker who reaches a \"crown-jewel\" host or document store is detected, not just blocked at the perimeter.\n- When seeding decoy credentials into LSASS-reachable memory, browser stores, `.aws\u002Fcredentials`, or password managers to catch credential dumping and reuse.\n- When instrumenting documents, repos, or wikis to catch data theft and ransomware staging.\n- When building a MITRE D3FEND-aligned deception layer as part of a defense-in-depth or zero-trust program.\n\n## Prerequisites\n\n- Docker Engine and Docker Compose v2 for self-hosting (`docker compose version`).\n- A registered domain you control plus DNS delegation for DNS-based tokens (NS records pointing at your switchboard host).\n- A public IPv4 address reachable on 80\u002F443 (HTTP tokens) and 53\u002Fudp (DNS tokens).\n- An SMTP relay or Mailgun account, and\u002For a Slack\u002FTeams\u002Fgeneric webhook URL for alert delivery.\n- Python 3.8+ for the helper script:\n  ```bash\n  python3 -m pip install requests\n  ```\n- For quick use with no hosting, an account-free token from the public service at https:\u002F\u002Fcanarytokens.org.\n\n## Objectives\n\n- Stand up a self-hosted Canarytokens instance (or use the public service) with working alerting.\n- Generate the major token types (HTTP, DNS, AWS key, MS Word\u002FPDF, Slack, kubeconfig) with descriptive memos.\n- Plant decoy credentials and decoy files in realistic, monitored locations.\n- Validate that each token fires and that alerts reach the SOC channel.\n- Catalogue deployed tokens and map them to MITRE D3FEND\u002FATT&CK for coverage tracking.\n\n## MITRE ATT&CK Mapping\n\n| ID | Official Technique Name | Relevance |\n|----|------------------------|-----------|\n| T1556 | Modify Authentication Process | A triggered honey credential reveals an adversary harvesting\u002Fabusing authentication material; the decoy provides a detection tripwire for credential abuse activity. |\n\n**Related MITRE D3FEND defensive techniques** (the offensive counter-mapping for this control):\n\n| D3FEND ID | Technique | Role |\n|-----------|-----------|------|\n| D3-DF | Decoy File | Canary documents, fake configs, decoy archives placed and monitored. |\n| D3-DUC | Decoy User Credential | Honey credentials (AWS keys, AD accounts, kubeconfig) integrated with a monitored decoy asset. |\n| D3-DO | Decoy Object | Umbrella for honeytokens\u002Fcanarytokens as monitored decoy artifacts. |\n\n## Workflow\n\n### 1. Deploy a self-hosted Canarytokens switchboard\nClone the official Docker repo and create the two environment files from their distributed templates:\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fthinkst\u002Fcanarytokens-docker\ncd canarytokens-docker\ncp switchboard.env.dist switchboard.env\ncp frontend.env.dist frontend.env\n```\nSet the core variables. In `frontend.env`:\n```ini\nCANARY_DOMAINS=canary.example.com          # general-purpose token domains (comma-separated)\nCANARY_NXDOMAINS=nx.example.com            # domains reserved for PDF\u002FDNS tokens\nCANARY_PUBLIC_IP=203.0.113.10              # public IP of this host\n```\nIn `switchboard.env`:\n```ini\nCANARY_PUBLIC_DOMAIN=canary.example.com\nCANARY_MAILGUN_DOMAIN_NAME=mg.example.com\nCANARY_MAILGUN_API_KEY=key-xxxxxxxxxxxxxxxx\nCANARY_ALERT_EMAIL_FROM_ADDRESS=canary@example.com\nCANARY_ALERT_EMAIL_FROM_DISPLAY=Canarytokens\nCANARY_ALERT_EMAIL_SUBJECT=Canarytoken Triggered\n# WireGuard token seed:\n# dd bs=32 count=1 if=\u002Fdev\u002Furandom 2>\u002Fdev\u002Fnull | base64\nCANARY_WG_PRIVATE_KEY_SEED=\u003Cbase64-seed>\n```\n\n### 2. Bring the stack up\n```bash\ndocker compose up -d\n# HTTPS with automatic Let's Encrypt certs (after editing certbot.env):\n# docker compose -f docker-compose-letsencrypt.yml up -d\ndocker compose ps\ndocker compose logs -f frontend\n```\nThe frontend (token generator UI) is now served on your `CANARY_PUBLIC_DOMAIN`; the switchboard listens on 80\u002F443 and 53\u002Fudp to receive triggers.\n\n### 3. Generate an HTTP (web-bug) token via the API\nBoth the public service and a self-hosted frontend expose a `POST \u002Fgenerate` endpoint. Create an HTTP token that fires on any GET:\n```bash\ncurl -s https:\u002F\u002Fcanarytokens.org\u002Fgenerate \\\n  -F 'type=http' \\\n  -F 'email=soc@example.com' \\\n  -F 'memo=Internal wiki - IT admin passwords page' \\\n  -F 'webhook_url=https:\u002F\u002Fhooks.slack.com\u002Fservices\u002FT000\u002FB000\u002FXXXX'\n# Response JSON includes: token, auth, hostname, url, url_components\n```\nThe returned `url` is the trip-wire link; place it where only an intruder would find it (a fake bookmark, a hidden link in a wiki page, an email signature).\n\n### 4. Generate a cloud credential (AWS API key) honeytoken\n```bash\ncurl -s https:\u002F\u002Fcanarytokens.org\u002Fgenerate \\\n  -F 'type=aws_keys' \\\n  -F 'email=soc@example.com' \\\n  -F 'memo=Decoy AWS keys - jenkins build host \u002Froot\u002F.aws\u002Fcredentials'\n# Response contains access_key_id and secret_access_key plus a downloadable\n# credentials file via \u002Fdownload?token=\u003Ctoken>&auth=\u003Cauth>&fmt=aws_keys\n```\nDrop the keys into a plausible `~\u002F.aws\u002Fcredentials` on a monitored host. Any `sts:GetCallerIdentity` or other AWS call using them triggers an alert with the source IP and user agent.\n\n### 5. Generate a document token (MS Word \u002F PDF) for data-theft detection\n```bash\n# MS Word\ncurl -s https:\u002F\u002Fcanarytokens.org\u002Fgenerate \\\n  -F 'type=msword' \\\n  -F 'email=soc@example.com' \\\n  -F 'memo=Q4-Layoffs-DRAFT.docx on FILESERVER01\\\\HR$' \\\n  -o token-meta.json\n# Download the weaponized document:\ncurl -s \"https:\u002F\u002Fcanarytokens.org\u002Fdownload?fmt=msword&token=\u003Ctoken>&auth=\u003Cauth>\" -o Q4-Layoffs-DRAFT.docx\n```\nFor PDFs use `type=adobe_pdf`. The document phones home when opened (DNS\u002FHTTP callback), exposing the reader's IP.\n\n### 6. Plant a DNS token for resolver-level tripwires\n```bash\ncurl -s https:\u002F\u002Fcanarytokens.org\u002Fgenerate \\\n  -F 'type=dns' \\\n  -F 'email=soc@example.com' \\\n  -F 'memo=DNS canary referenced in backup script comments'\n# Response 'hostname' is a unique FQDN; any resolution of it fires an alert.\n```\nEmbed the hostname in scripts, configs, or `\u002Fetc\u002Fhosts` comments. Because resolution alone triggers it, DNS tokens catch reconnaissance even when egress HTTP is blocked.\n\n### 7. Generate infrastructure tokens (Slack, kubeconfig, Azure)\n```bash\n# Slack API token canary (fires when the fake token is used against Slack)\ncurl -s https:\u002F\u002Fcanarytokens.org\u002Fgenerate -F 'type=slack_api' \\\n  -F 'email=soc@example.com' -F 'memo=Decoy Slack bot token in repo .env'\n\n# Kubeconfig canary (fires when used against the kube API)\ncurl -s https:\u002F\u002Fcanarytokens.org\u002Fgenerate -F 'type=kubeconfig' \\\n  -F 'email=soc@example.com' -F 'memo=Decoy kubeconfig in \u002Fhome\u002Fdeploy\u002F.kube\u002Fconfig'\n```\nCommit decoy `.env` \u002F `kubeconfig` files only to repos and hosts you instrument, never to public repos.\n\n### 8. Plant Active Directory honey credentials (decoy user)\nCreate a non-privileged-looking but never-used AD account whose authentication is alerted on. Set a SPN so it appears Kerberoastable bait, and forward Event ID 4768\u002F4769\u002F4625 for it to your SIEM:\n```powershell\nNew-ADUser -Name \"svc_backup_legacy\" -SamAccountName \"svc_backup_legacy\" `\n  -AccountPassword (ConvertTo-SecureString 'C0mpl3xDecoy!2026' -AsPlainText -Force) `\n  -Enabled $true -Description \"Legacy backup service (do not use)\"\nSet-ADUser svc_backup_legacy -ServicePrincipalNames @{Add=\"MSSQLSvc\u002Fdecoy.example.com:1433\"}\n```\nAdd a Windows audit ACL\u002FSACL or a SIEM correlation rule so any 4768\u002F4769 for `svc_backup_legacy` pages the SOC — no legitimate logon should ever occur.\n\n### 9. Validate and catalogue\nTrigger each token from a controlled host and confirm the alert lands:\n```bash\n# HTTP token\ncurl -s \"https:\u002F\u002Fcanary.example.com\u002F\u003Ctoken-url>\" >\u002Fdev\u002Fnull\n# DNS token\ndig +short \u003Cunique-hostname>\n# AWS key token\nAWS_ACCESS_KEY_ID=\u003Cid> AWS_SECRET_ACCESS_KEY=\u003Csecret> aws sts get-caller-identity\n```\nRecord each deployed token (type, memo, location, alert channel, D3FEND mapping) in an inventory. Use the helper script below to bulk-generate and export this inventory as JSON.\n\n## Tools and Resources\n\n| Tool \u002F Resource | Purpose | Link |\n|-----------------|---------|------|\n| Canarytokens (public) | Free hosted token generation | https:\u002F\u002Fcanarytokens.org |\n| canarytokens-docker | Self-hosted switchboard + frontend | https:\u002F\u002Fgithub.com\u002Fthinkst\u002Fcanarytokens-docker |\n| canarytokens (core) | Source for the token engine | https:\u002F\u002Fgithub.com\u002Fthinkst\u002Fcanarytokens |\n| Canarytokens docs | Per-token-type usage guides | https:\u002F\u002Fdocs.canarytokens.org |\n| MITRE D3FEND | Defensive technique taxonomy (D3-DF, D3-DUC) | https:\u002F\u002Fd3fend.mitre.org |\n| MITRE ATT&CK T1556 | Modify Authentication Process | https:\u002F\u002Fattack.mitre.org\u002Ftechniques\u002FT1556\u002F |\n\n## Token Type Reference\n\n| `type` value | Token | Fires when |\n|--------------|-------|-----------|\n| `http` | Web-bug URL | URL is requested (GET) |\n| `dns` | DNS name | Hostname is resolved |\n| `aws_keys` | AWS API key | Keys used against AWS |\n| `msword` \u002F `adobe_pdf` | Office\u002FPDF document | Document is opened |\n| `slack_api` | Slack API token | Token used against Slack |\n| `kubeconfig` | Kubernetes config | Used against the kube API |\n| `azure_id` | Azure login certificate | Cert used to authenticate to Azure |\n| `qr_code` | QR code | Encoded URL is requested |\n| `web_image` | Image web-bug | Image is loaded |\n| `log4shell` | Log4j JNDI string | Vulnerable logger evaluates it |\n| `cmd` | Sensitive command (Windows) | Process\u002Fcommand is executed |\n\n## Validation Criteria\n\n- [ ] Self-hosted switchboard (or public service) deployed and reachable on 80\u002F443 and 53\u002Fudp.\n- [ ] Alert channel (email and\u002For webhook) configured and test alert received.\n- [ ] At least one each of HTTP, DNS, cloud-credential, and document tokens generated with descriptive memos.\n- [ ] Decoy credentials planted in realistic, monitored locations (no production secrets co-located).\n- [ ] AD honey account created with SACL\u002FSIEM rule firing on any authentication.\n- [ ] Each token validated by a controlled trigger; alert confirmed end-to-end.\n- [ ] Token inventory exported (type, memo, location, alert channel, D3-DF\u002FD3-DUC mapping).\n- [ ] No tokens committed to public repositories or planted on out-of-scope systems.\n",{"name":5,"tags":55,"author":57,"domain":40,"license":15,"version":58,"nist_csf":59,"subdomain":36,"description":7,"mitre_attack":61},[36,35,31,56,42,34,33,41],"breach-detection","mahipal","1.0",[60],"DE.CM-01",[62],"T1556","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fdeploying-honeytokens-and-canarytokens",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":74,"prompt":84,"zipAvailable":85},[75,78,81],{"tool":76,"command":77},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill deploying-honeytokens-and-canarytokens",{"tool":79,"command":80},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill deploying-honeytokens-and-canarytokens",{"tool":82,"command":83},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill deploying-honeytokens-and-canarytokens","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdeploying-honeytokens-and-canarytokens\u002FSKILL.md",true,[87,92,98,102],{"path":88,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdeploying-honeytokens-and-canarytokens\u002FLICENSE",{"path":93,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fapi-reference.md","REFERENCE","参考文档",3632,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdeploying-honeytokens-and-canarytokens\u002Freferences\u002Fapi-reference.md",{"path":99,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Fstandards.md",1534,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdeploying-honeytokens-and-canarytokens\u002Freferences\u002Fstandards.md",{"path":103,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":106,"sourceHtmlUrl":107},"scripts\u002Fagent.py","SCRIPT","脚本",6773,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fdeploying-honeytokens-and-canarytokens\u002Fscripts\u002Fagent.py",[109,135,159,186,211,238],{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":116,"publishedAt":50},"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",[115],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[117,118,119,120,121,40,122,123,124,125,46,126,127,128,129,130,131,132,133,134],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","security","incident response","identity","pr","code","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":142,"publishedAt":50},"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",[141],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[143,131,144,145,121,146,40,124,147,148,149,150,151,152,153,154,155,156,157,158],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":169,"publishedAt":50},"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",[165,168],{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[153,170,171,172,173,40,174,175,147,176,177,178,179,180,37,181,182,183,184,185],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","t1078","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":193,"publishedAt":50},"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",[192],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[194,195,196,40,197,198,199,200,201,202,203,32,204,205,206,207,150,208,209,210],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":212,"name":213,"nameZh":6,"description":214,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":215,"categories":216,"keywords":218,"publishedAt":50},"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",[217],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[219,220,221,40,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237],"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":239,"name":240,"nameZh":6,"description":241,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":242,"categories":243,"keywords":245,"publishedAt":50},"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",[244],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[121,246,40,247,45,248,249,250,251,252,253,181,254,182,255,256,257,258,259,260],"triaging security incident","siem","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]