创建一个金丝雀令牌（Canarytoken），部署到某处，就能在关键时刻掌握情况。页面按全部（All）、微软（Microsoft）、钓鱼（phishing）、云（cloud）、数据库（database）和其他（other）分类，并提供搜索；下方列出多种令牌，如攻击者访问网址时提醒的网络臭虫（Web bug）、解析域名时提醒的 DNS、探测亚马逊云科技（AWS）基础设施时提醒的 AWS Infra、尝试使用信用卡时提醒的信用卡（Credit Card）、扫描二维码时提醒的二维码（QR code）、加载 MySQL 转储时提醒的 MySQL，以及 AWS keys 等。

把它部署到某处。

及时知晓。这是什么？

• Web bug：当攻击者访问你的 URL 时收到警报。
• DNS：当攻击者解析某个 DNS 名称时收到警报。
• AWS Infra：当攻击者探查你的 AWS 基础设施时收到警报。
• Credit Card：当攻击者尝试使用你的信用卡时收到警报。
• QR code：当攻击者跟随你的二维码时收到警报。
• MySQL：当攻击者加载你的 MySQL 转储文件时收到警报。
• AWS keys：当攻击者使用你的 AWS API Key 时收到警报。
• MCP configuration：当攻击者使用你的 MCP 配置时收到警报。
• Fake App：当有人在你的设备上打开一个虚假应用时收到警报。
• Log4shell：当某条 log4j 日志行易受 CVE-2021-44-228 影响时收到警报。
• Fast redirect：当攻击者访问你的 URL 时收到警报（然后将他们重定向）。
• Slow redirect：当攻击者访问你的 URL 时收到警报（然后重定向他们并收集更多信息）。
• Sensitive command：当运行可疑的 Windows 命令时收到警报。
• Windows Fake File System：当攻击者访问虚假文件系统中的文件时收到警报。
• Web image：当你上传给我们的图片被查看时收到警报。
• Azure login certificate：当攻击者使用你的 Azure 服务主体证书登录时收到警报。
• Microsoft Excel：当攻击者打开你的 Microsoft Excel 文档时收到警报。
• Microsoft Word：当攻击者打开你的 Microsoft Word 文档时收到警报。
• SVN：当攻击者签出 SVN 仓库时收到警报。
• Unique email address：当攻击者向这个唯一地址发送电子邮件时收到警报。
• Microsoft SQL Server：当攻击者访问你的 MS SQL Server 数据库时收到警报。
• Custom EXE / binary：当攻击者执行 EXE 或 DLL 文件时收到警报。
• Acrobat Reader PDF：当攻击者在 Acrobat Reader 中打开你的 PDF 文档时收到警报。
• Windows Folder：当攻击者在 Windows 资源管理器中浏览你的 Windows 文件夹时收到警报。
• JS cloned website：当攻击者克隆你的网站时（使用 JavaScript）收到警报。
• CSS cloned website：当攻击者克隆你的网站时（使用 CSS）收到警报。
• Kubeconfig：当攻击者使用你的 Kubeconfig 时收到警报。
• WireGuard VPN：当攻击者使用你的 WireGuard VPN 客户端配置时收到警报。
• Azure Entra ID login：当攻击者钓鱼你的 Azure Entra ID 登录时收到警报。
• Network Folder：当攻击者浏览映射的网络文件夹（WebDAV）时收到警报。
• SAML IdP App：当攻击者从你的身份提供商仪表板打开虚假应用时收到警报。
• SVG Image：当攻击者加载 SVG 文件时收到警报。

讨论气氛整体偏正面和务实，多数人认可这类蜜罐凭证或令牌已经很好用，并特别看好它在 LLM 驱动攻击检测中的价值，认为现有工具不够敏锐。真正的分歧不在于有没有用，而在于是否该自托管以避免回连厂商暴露，以及服务能否覆盖 Cloudflare、Stripe、OpenAI 等官方暂不支持的平台。

认为蜜罐令牌是应对 LLM 攻击和凭证滥用的利器

• 现有检测工具显得不够敏锐，而这类“被触碰即告警”的蜜罐令牌在 LLM 驱动的自动化攻击场景下尤其像及时雨，哪怕服务本身已不错，这一用途也让它价值倍增。（较多人） > 在防御基于大模型的攻击时它们简直是天赐之物，现有工具看起来都不太会分辨。（@charlesabarnes）

认可假银行卡诱饵，但担心托管回连会暴露，倾向自托管

• 有人欣赏连假银行卡、信用卡都做成蜜罐诱饵，觉得高仿金融凭证更容易让攻击者或自动化流程上钩；但同时担心这类服务必须回连厂商服务器才能告警，反而可能让对手察觉蜜罐，因此认为自托管版本更稳妥。（少数人）

希望覆盖 Cloudflare、Stripe、OpenAI 等不受支持平台，或能自己 DIY

• 有人对官方令牌类型迟迟没有扩展到 Cloudflare、Stripe、OpenAI 等常见服务感到意外，并提出 DIY 思路：为这些平台注册真实账号、生成 API 密钥，再自己写一套告警系统；核心诉求是把蜜罐能力延伸到任意凭证，而不是只依赖官方预置类型。（少数人）

调侃“假信用卡”和 AI 随手写的荒诞感

• 纯玩笑层面，有人拿“他们居然能做信用卡”开涮：虽然不是真卡，但让人好奇需要什么金融黑魔法；再叠加项目由 AI 随手写出来的背景，就变成“Claude 现在连假信用卡都会做了”的梗，折射出社区对 AI 生成敏感金融诱饵既好笑又不安的情绪。（少数人） > 他们居然能做信用卡；虽然是假的，但既然项目是 AI 随手写出来的，Claude 现在岂不是也会做假信用卡了？（@direwolf20）

有价值的补充

• 已有开发者把同样的蜜罐或金丝雀思路落地到自家 AI 基础设施项目（CanaryGrid）中，说明该模式正从传统凭证监控延伸到 AI 系统内部。（@hankyone）
• 这不是全新概念：Hacker News 上从 2015 年 Canarytokens 起，到 2022 年的 AWS Canarytokens“安全网”、四分钟部署蜜罐方案，再到 2024 年的相关帖，多年已有连续讨论，可作为背景延伸。（@dang）