hunt-a-handle

搜寻用户名

在 OSINT 中，用户名复用是成本最低、关联能力很强的方法：只需一个字符串，几分钟内就能检查它是否关联到十几个平台上的同一个人。但这种方法也最容易被过度信任。枚举工具不会验证身份——它们只会通过 HTTP 检查账号是否存在——因此，命中列表只是一些候选项，仅此而已。最容易毁掉这类调查的错误，就是把工具的输出直接粘贴进报告。枚举只是低成本的前半部分；确认才是真正的工作。

步骤 1 — 明确授权范围

阅读 ../../ETHICS.md，并在进行任何查询前写下：调查对象、目标、范围内的筛选条件、范围外的操作（登录、联系、请求关注），以及适用的司法管辖区。搜寻用户名很容易偏离目标——一次扫描就会带你发现另外三十个平台，而误将使用同一字符串、但与调查无关的人纳入画像，也轻而易举。

完成标准：已写明调查范围，并且能够说出哪些行为会让你越界。

步骤 2 — 选择枚举工具

情况	选择	原因
只查一个用户名，需要快速扩大覆盖面	sherlock	快速扫描范围最广，但只检查是否存在
只查一个用户名，需要获取个人资料内容	maigret	会解析页面：显示名称、简介、ID、链接，有时还包括国家／地区和创建日期
需要了解命中是如何触发的	WhatsMyName 数据	每项检查都声明了 URI 和可供查看的匹配规则

sherlock jdoe_92 --timeout 10 --csv
maigret jdoe_92 --html

对于关联分析，maigret 更有价值，因为它会返回字段，而非布尔值。显示名称、头像 URL、自报位置、数字用户 ID 和“也称为”列表，都能为你提供可用于核查其他平台的信息。Sherlock 只会给出一个 URL 和一项断言。

WhatsMyName 是检测列表，而不是扫描器：它是一个 JSON 文件，包含各站点条目，每个条目都有 URI 模板和明确的匹配条件（预期的 HTTP 状态码、正文中预期出现的字符串，以及针对“缺失”情况的对应条件）。如果你对某个站点存疑，就查看它的条目——其中会准确说明工具将什么视为证据。许多封装工具和 Web 前端都使用同一份列表，因此，同一候选项出现在三种不同工具的结果中，往往只是同一条规则触发了三次，并非三次独立确认。

完成标准：记录每个候选项的平台、URL、发现它的工具，以及当前有效／失效状态。

步骤 3 — 生成变体

给定的用户名只是某个人命名习惯的一个样本。找出这种习惯，就能发现首次扫描遗漏的账号。

• 分隔符替换：john.doe、john_doe、john-doe、johndoe
• 截短形式和首字母：jdoe、johnd、j_doe、doej
• 数字后缀：出生年份、出生年份的两位数形式、1、99、007
• Leetspeak 和字符替换：j0hnd0e、johnd0e
• 将电子邮件地址的本地部分用作用户名，或将用户名用作电子邮件地址的本地部分
• 游戏昵称的构造方式：前缀、xX…Xx、战队标签、重复字母

完整的模式列表：reference/variant-patterns.md。

有两个重要的推断方向。用户名 → 姓名：jdoe_92 暗示用户名采用名字首字母加姓氏的模式，且出生年份可能是 1992 年；这只是待验证的假设，不是调查结论。姓名 → 用户名：如果你已经知道真实姓名，就生成这个姓名可能形成的用户名，并对它们也进行枚举——与从别人提供的用户名入手相比，这种做法往往更有效。

完成标准：已枚举所有变体，并将产生命中结果的变体纳入步骤 2。

第 4 步 — 确认或排除

对于每个候选账号，寻找能经得起怀疑的读者审视的证据。

强证据：

• 头像相同。使用 find-the-original-image 进行核实——如果匹配到的是图库照片或第三方图片，应排除，而非确认。
• 简介文本逐字相同或高度相似，尤其是保留了相同的错别字或不寻常的措辞。
• 明确声明的交叉链接：个人资料中链接了另一个个人资料。这是除本人承认外能获得的最佳证据。
• 两边都有相同的联系信息选择器（相同的电子邮箱或个人域名）。

中等强度证据：

• 不同平台上的账号创建日期集中在一个较短的时间段内——人们往往会在短时间内集中注册多个服务。
• 与相同的独特小型账号之间存在关注者／关注对象重合。
• 写作风格：习语、标点习惯、发帖时区。

单独来看证据较弱：用户名相同。这正是你要验证的事项，而非支持它的证据。

可获取数字用户 ID的平台特别有用。如果 ID 按注册顺序分配，即使个人资料隐藏了创建日期，ID 也能限定账号的创建日期范围。GitHub 的 https://api.github.com/users/<login> 会返回数字 id 和 created_at； Discord 的雪花 ID 会直接编码创建时间戳。各平台详情见：reference/platform-leakage.md。

完成标准：每个候选账号都已评定为已确认、可能相关或已排除，并在旁边写明各自的证据。

常见误判

存在性检查是基于 HTTP 的启发式判断。以下情况都会造成误报：

• 软 404。 网站返回 200 状态码，但页面显示“未找到用户”。如果匹配规则只看状态码，那么所有账号都会被判定为存在。
• 兜底个人资料页。 有些平台会为任意字符串显示通用页面外壳，只有 API 才会返回 404。
• 速率限制和 CAPTCHA 中间页。 验证页面的状态码是 200，且包含页面内容，因此可能同时符合“已找到”和“未找到”的规则——而且一旦触发速率限制，本轮扫描余下的结果就都不可信了。请单独重新运行失败的检查，不要只相信一次全面扫描。
• 保留、抢注和冒充账号。 账号已注册且确实存在，但并非目标人物的账号。
• 过时条目。 网站会更改其 404 行为，而检测列表更新滞后。没有命中并不代表账号不存在。

更深层的问题是账号碰撞。常见用户名属于许多互不相关的人；在十个平台上使用短用户名或词典词语的账号，十次中有更多时候分别属于不同的人，而非同一个人。置信度应随用户名的独特程度而变化：罕见的自创字符串本身就是较弱到中等强度的证据，而 mike 则毫无证明力。

不要通过登录、发消息或请求关注来消除歧义。默认情况下，这属于超出范围的互动，而且会让目标人物知道你的存在——参见 investigate-without-getting-made。

置信度评级

• 已确认 — 通过 find-the-original-image 核实头像相同，且另有一项强证据；或两个个人资料之间存在明确声明的交叉链接；或双方有相同的联系信息选择器。
• 可能相关 — 用户名独特，且有一项中等强度证据（创建日期集中、关注者重合或风格一致），并且没有相互矛盾的证据。
• 未确认 — 用户名相同，但没有其他匹配项。应将其报告为枚举命中项，而非目标人物的账号。
• 已排除 — 内容、语言、时间线或头像来源与目标人物不符。请记录排除结果，避免下一位分析人员重复工作。

实例演示

以 sunfish_ada 为例。Sherlock 返回 14 条命中结果。maigret 返回 9 条有内容的结果， 其中包括一个显示名称为“A. Okonkwo”的代码托管平台个人资料、一个使用相同头像的摄影 网站，以及一个资料内容为空的论坛个人资料。

首先排除论坛结果：在同一论坛上查询一个故意设得荒诞的用户名，也会返回 200，且页面内容完全相同。这是兜底页面，不是账户。

对摄影网站上的头像进行反向搜索（通过 find-the-original-image），发现只有代码托管平台的个人资料使用了同一张图片——这是有力证据。代码托管平台 API 提供了数字 ID 和创建日期，创建月份与摄影账户注明的加入日期相同。两项中等强度的证据加上头像匹配：两个账户都可确认。

某个微博客平台上也有一个用户名相同的账户，但它使用不同的语言发布无关内容，且账户注册时间比其他账户早了 6 年。这是不同的人，只是字符串相同——应予以排除，并明确说明，因为这是审查者最先会发现的问题。

线索拓展

新线索	技能
显示名称 / 真实姓名	find-anyone
暴露或推断出的电子邮箱	what-an-email-reveals
个人资料上的电话号码	whose-number-is-this
头像或发布的照片	find-the-original-image、secrets-in-file-metadata
带有地点线索的照片	where-was-this-taken
代码托管平台用户名	secrets-in-git-history
简介中的个人域名	who-owns-this-domain
凭据泄露数据中的用户名	what-leaked-about-you
已确认账户的完整发帖记录	pattern-of-life-from-socials
账户关系图本身	graph-the-network

法律与服务条款说明

自动枚举会通过脚本请求访问平台，无论数据是否公开，大多数服务条款都禁止这种行为。请保持较低的并发量，不要绕过 CAPTCHA，并在平台表示拒绝时停止。在欧盟和英国，将分散的公开账户信息汇总为在世人士的个人档案，属于处理个人数据，需要有合法依据并遵循数据最小化原则。

步骤 5 — 撰写报告

运行 write-the-intel-brief。提供平台 / URL / 置信度 / 证据表，列出排除项及理由，并优先说明这些用户名带出的真实姓名和联系信息线索。

完成标准：表格中的每个候选项都有评级和来源，且每条枚举命中结果都有据可查。