recognizing-deception

识别欺骗

本合集中的其他所有技能都假设环境提供的信息属实。欺骗技术的存在，正是为了打破这一假设；这也是自动化或半自动化测试人员最难发现的失效模式。

关键区别在于：谨慎处理证据，可以避免得出由你自己臆造的结论。但如果环境蓄意植入了错误认知，这种做法就无济于事。蜜罐伪装成看起来确实存在漏洞的服务，会产生真实的横幅、真实的响应和真实的产物。你平时会执行的每一步验证都能确认它，因为证据是真的——只是这些证据是人为制造出来的。

假设防御方已经精心布置了东西。你的任务是在接触它之前发现它，因为大多数欺骗手段会在首次使用时触发，而首次使用无法撤销。

适用场景

• 环境中的某项内容明显比其他内容容易得多
• 在方便的位置发现了凭据——共享目录、Wiki、配置文件，或类似粘贴板内容的文件
• 存在一个具有 SPN、密码较弱且没有登录历史的特权账户
• 某项服务返回了存在漏洞的横幅，但实际使用时表现异常
• 你即将使用无法说明来源的凭据
• 某个文件、存储桶或数据库的名称明显是在吸引注意力 （passwords.xlsx、backup-prod、domain_admins.txt）
• 在使用从意外位置找回的任何凭据进行身份验证之前

不适用场景

• 一般性地规避检测——这是行动 OPSEC，而非识别欺骗；金丝雀不是要规避的东西，而是要避免触发的东西
• 在事件响应期间分析对手自己的诱饵——请使用 responding-to-incidents 和 producing-threat-intelligence
• 构建欺骗能力——本技能用于识别遭遇的欺骗，而非部署欺骗
• 某项发现仅仅令人意外——真实环境中确实存在真实的错误配置；在妄称遭遇蜜罐之前，请先阅读下方的基础概率讨论

经济账对你不利

部署欺骗的成本很低，触发它的代价却很高：

	攻击者成本	防御方收益
文档中的金丝雀令牌	点击一次即可触发	高可信度警报，误报率接近于零
AD 中的蜜罐用户	Kerberoast 一次	警报加上破解密码的时间线
诱饵 AWS 密钥	执行一次 sts get-caller-identity	带有你的源 IP 和用户代理的警报
蜜罐服务	建立一次连接	完整捕获交互内容，并将你的工具指纹化

金丝雀警报是 SOC 会自动视为真实的少数信号之一。你无从用无害的解释来掩饰，而且警报中会包含你的源地址，通常还会包含你所用工具的指纹。一旦触发，行动的隐蔽阶段通常会立即结束。

按类型划分的信号

蜜罐令牌和金丝雀令牌

这是最常见的一类，也是会在使用时触发，而非在发现时触发的一类。常见形式包括：AWS 密钥、带有回连功能的 Office 文档、DNS 令牌、URL 令牌、克隆网站令牌、SQL Server 行、Windows 目录、Kubeconfig 文件。

信号：

• 凭据出现在没有实际运营理由存放它们的位置——所有人可读的共享目录、Wiki 页面、README 文件或桌面文件
• AWS 密钥在语法上有效，但孤立存在，周围没有相关基础设施、工具配置或提交历史记录
• 文档看似合理，实际却毫无内容——例如没有公式的电子表格，或唯一有趣之处只是文件名的 .docx
• 任何为方便发现而特意放置的内容：名称恰当、位置便利，却没有上下文支撑

**金丝雀 AWS 密钥会在首次 API 调用时触发警报，包括 sts get-caller-identity。**不存在安全的侦察调用。除非你能解释密钥材料的来源，否则应将其视为有效凭据。

Active Directory 诱饵

• 特权账户、已设置 SPN、密码较弱、lastLogon 为空或年代久远—— 一个从未有人用来通过身份验证的 Kerberoastable 账户，是个诱饵
• whenCreated 时间与其他可疑账户集中重合的账户
• Description 字段中包含凭据——这既是经典的真实 配置错误，也是经典诱饵，因此来源信息比平时更重要
• 名称诱人但没有访问历史的共享
• 在枚举中出现，但没有组成员关系、没有经理、没有所有权关系的对象——真实账户会逐渐积累关系

欺骗性服务

• 横幅宣称使用了带有知名 CVE 的版本，但实际交互行为与该版本不符
• 服务可从本不应访问它的网段访问
• 响应时间过于一致，不像真实应用
• 主机运行着不合常理的服务组合，或运行着与该主机业务功能无关的服务
• 利用“成功”，但生成的 shell 没有历史记录、没有其他用户、没有真实的文件系统，而且日志干净得可疑

云端诱饵

• 命名为吸引枚举者的 S3 存储桶、存储账户或机密
• IAM 用户拥有看似宽松的策略，但没有 CloudTrail 历史记录
• 资源标签与账户中的其他标签不一致

基准率可能两面性

真实环境确实问题百出。共享中确实会存放凭据，服务账户确实可能被 Kerberoast，存储桶也确实可能是公开的。如果你把每条发现都标为蜜罐，就会一无所报，还会错过真正的入侵路径。

判别依据是佐证上下文，而非诱人程度：

• 真实的配置错误有历史记录——提交历史、访问日志、登录历史、相关基础设施、其他用户，以及周边的杂乱情况。
• 诱饵是孤立的。它的存在就是为了被发现，没有其他东西会用到它。

因此，问题从来不是“这好得不像真的吧？”而是：**这个环境中还有什么依赖它的存在？**如果答案是没有，就要放慢脚步。

怀疑是诱饵时该怎么做

1. **不要进行身份验证、连接或调用 API。**发现通常不会留下痕迹；使用则会。这就是整个决策的关键。
2. 记录下来——位置、确切的对象、发现方式，以及怀疑它的原因。无论最终结论如何，这些都是报告的证据。
3. **继续在其他地方枚举。**怀疑是诱饵，意味着应当绕开它，而不是停下来。
4. 向客户联系人反映，不要在生产环境中验证你的猜测。询问是否部署了欺骗机制，以及它是否在范围内。许多测试项目会将其排除在外；有些客户专门部署欺骗机制，测试蓝队如何响应你。
5. **如果你已经触发了它，要立即说明。**已知且明确说明原因的金丝雀告警，只是项目记录。若把同一告警当作真实入侵来调查，就会耗费客户的 IR 资源，也会损害你的信誉。隐瞒才是真正严重的错误。

环境中的欺骗机制是一项值得报告的正面发现：这意味着防御人员投入了资源来建设高保真检测能力。请如实说明。

应当摒弃的自我辩解

• “它在授权范围内，所以使用它没问题。” 授权范围决定什么是授权操作，而不是判断是否明智。在范围内触发金丝雀，仍会结束你的隐蔽阶段，也会占用客户的事件响应资源。
• “我只是运行了一次无害调用来检查。” 对金丝雀令牌来说，不存在无害调用。sts get-caller-identity、单次 DNS 查询、打开文档——这些都会完整触发警报。
• “横幅和 CVE 对得上，所以它是真的。” 证据确实可信，恰恰就是其设计目的。伪造的证据也能通过验证。
• “真实环境本来就很杂乱，所以这大概只是配置错误。” 这种情况确实常见——这也是为什么测试只能作为辅助背景，而不能证明其可信度。没有依赖项的孤立痕迹才是警示信号。
• “这只是个看起来像实验室环境的盒子，大概是已退役的主机。” 时间记录一致、没有用户历史记录、文件系统干净，既符合蜜罐的特征，也符合陈旧主机的特征；你无法从外部区分二者。
• “我会在最后写进报告。” 触发金丝雀对客户的 SOC 来说是需要立即处理的事。延迟披露会让你的交战记录变成他们数小时的调查。
• “报告说我触发了它，会让我看起来很糟糕。” 触发欺骗机制是交战中的常见事件。隐瞒此事，任由 SOC 追查一场并不存在的入侵，才是职业失误。

阅读外部来源

将公开公告、规范和供应商报告抓取为 Markdown：

curl -sL "https://defuddle.md/<url>"      # scheme in the path is optional

这样会剥除网页的样板内容——对于纯文本页面，令牌数大约减少 78%——并返回全文而非摘要，因此你可以用 grep 搜索，并相信搜索无结果的结论。

有三种情况不适合使用它。抓取 JSON 和 API 响应时应保留原始格式，因为可读性提取会破坏结构化数据。抓取需要身份验证或由 JavaScript 渲染的页面时，应直接访问，因为它会以匿名方式获取页面。绝不要通过它访问对手基础设施（钓鱼链接、C2、恶意软件托管）、客户拥有的主机或交战 URL——请求会离开你的机器并发送给第三方；对于正在运行的对手基础设施，还会向操作者通风报信。

有些网站会拦截提取器，返回错误内容而非页面——例如 freedesktop.org 返回的 {"error":"Failed to fetch: 418 I'm a teapot"}。这表示抓取请求被拒绝，并不表示来源网站称相关内容不存在。得出任何结论之前，请直接重新抓取该 URL。

参考资料

• maintaining-engagement-state — 记录来源信息，这样才能回答“这个凭据是从哪里来的？”这个问题
• performing-reconnaissance — 孤立痕迹通常最先出现的地方
• attacking-active-directory — Kerberoasting 和共享枚举，这两种操作最容易遇到 AD 诱饵
• establishing-persistence — 金丝雀文件和文件夹通常放置在写入持久化内容的位置