2026-08-23 04:51:30 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文详细介绍了红队侦察中如何从单一域名出发，利用证书透明度、搜索引擎、DNS和公开代码托管信息，发现与目标相关的Obsidian知识库(vault)或发布站点。文章提供了系统的方法论，包括通过CNAME记录、HTML标记等确认ObsidianPublish站点，以及通过GitHub代码搜索找到公开仓库。核心结论是形成可复核的证据链，并强调遵循最小证据原则，避免越界操作。 综合评分： 92 文章分类： 红队,漏洞分析,威胁情报,安全工具,实战经验

cover_image

红队侦察：发掘Obsidian知识库

原创

7月的风 7月的风

赛博57库

2026年7月31日 05:00 日本

在小说阅读器读本章

去阅读

| | | — | | RED TEAM RECON · FIELD GUIDE 信息搜集：怎样侦察发现暴露的Obsidian仓库从单一域名追到公开 vault 的证据链 |

| | | — | | 前言｜ 漏洞赏金或授权红队经常只有一个起点：target.tld。没有组织仓库清单，没有内部账号，也不知道对方是否使用 Obsidian。本篇只解决一个问题：怎样从这个单一域名出发，利用公开网页、证书、DNS 与公开代码托管信息，找到与目标相关的 Obsidian vault 或其发布副本；每一步都给出前置条件、操作、预期结果和下一跳。它不是组织资产盘点教程，也不要求先知道目标的 GitHub 组织。 |

先厘清交付对象。读者最后可能找到的是三种不同东西：

本文的发现链是：

| | | — | | 一个域名 → 候选主机与已索引页面 → 判断是否是 Obsidian Publish / 笔记站 → 从站点反查公开源码仓库 → 确认 vault 结构与历史暴露 → 只用最小证据完成报告 |

全文的 <TARGET_DOMAIN>、<HOST>、<OWNER>、<REPO> 都必须替换为漏洞赏金规则或书面授权涵盖的对象。发现疑似密钥、个人敏感资料或不在范围内的资产时，停止继续读取正文，按项目规则提交报告；不要验证令牌，也不要下载整个知识库。

0. 先定义“成功”：不是搜到 Obsidian 这个词

目标

从 target.tld 形成一条可复核的证据链：

| | | — | | 目标域名 ↔ 候选笔记站 / 源码仓库 ↔ Obsidian 结构证据 ↔ 公开访问位置 |

“页面里出现 Obsidian”只是弱线索；真正的成功至少满足下列之一：

• 公开站点可被确认是 Obsidian Publish，且存在超出预期公开范围的页面；

• 公开仓库含 .obsidian/ 与笔记主体，或同一 vault 的附件/历史可公开访问；

• 站点与公开仓库之间有可验证关联，例如页面源码、README、部署配置或自述中的互相引用。

最小证据格式

不要一开始抓正文。每条候选记录只需：

| | | — | | URL / repo: https://… 关联目标: 页面位于 <TARGET_DOMAIN>；或源码明确引用 <TARGET_DOMAIN> Obsidian 证据: publish 指纹 / .obsidian/app.json / workspace.json 暴露位置: 页面、默认分支、tag 或 commit SHA 观察时间: UTC 下一跳: 站点确认 / 源码关联 / 历史检查 / 停止并上报 |

方法一：从一个域名扩展出“笔记站候选”，不依赖组织清单

目的

发现 target.tld 下可能承载文档、wiki、notes、knowledge base 的主机和网页入口。此方法只建立候选集，不判断它们就是 Obsidian。

前置条件

• 漏洞赏金范围或书面授权允许测试 <TARGET_DOMAIN> 及其子域；

• 可使用浏览器、curl、jq、dig；

• 仅进行被动查询与对公开主页的正常 HTTP 访问，不做目录爆破或高频扫描。

步骤 1：用证书透明度记录收集候选主机

证书透明度记录通常能提供曾为目标域签发过证书的名称。查询并去重：

从结果中优先标记名称含 notes、docs、wiki、kb、knowledge、garden、research 的主机，再保留根域与 www。这些只是排序词，不是扫描字典。

预期结果： 一份候选 FQDN 列表，例如 notes.target.tld、docs.target.tld。 误报与边界： 证书名可能已失效、可能是第三方服务，也可能缺少未签发证书的主机；所以“未出现”不等于不存在。

步骤 2：用搜索引擎查已被索引的公开入口

在正常搜索界面中执行受域名约束的查询：

| | | — | | site:<TARGET_DOMAIN> (obsidian OR "knowledge base" OR wiki) site:<TARGET_DOMAIN> (notes OR documentation OR research) site:publish.obsidian.md "<TARGET_BRAND>" |

第三条中的 <TARGET_BRAND> 可从目标首页标题、公司名称或漏洞赏金项目名称获得；它用于找到可能仍使用 publish.obsidian.md/<site> 的旧链接或外部入口。

预期结果： URL、页面标题和搜索命中词组成的“已索引页面表”。 为什么这一步可靠但不充分： Google 的 site: 可把结果限制到指定域名或 URL 前缀，但官方明确说明，符合条件的 URL 不保证都会出现。因此它是发现器，不是排除器。Google site: 运算符文档

下一跳

• 找到候选主机或页面 → 方法二；

• 只有根域首页 → 仍可执行方法三，从页面链接与公开代码搜索寻找源码线索；

• 没有结果 → 在报告中记录“被动索引未命中”，不要写“目标没有 Obsidian”。

方法二：确认候选站是否是 Obsidian Publish 或笔记站

目的

将“看起来像文档”的主机，收敛为高置信度的 Obsidian Publish 站点、一般笔记站或非目标页面。这里检查的是站点指纹，不是目录枚举。

前置条件

• 已有 <HOST>，且位于授权域名范围；

• 允许访问该主机的首页与站点公开声明；

• 不使用认证绕过、路径爆破或参数探测。

步骤 1：检查首页、跳转和公开索引声明

第一条记录重定向链；第二条只读取站点主动公开的 robots 声明；第三条在首页响应中寻找 Obsidian Publish 的直接引用或页脚标记。若 robots 声明了 sitemap，只把 sitemap 中列出的 URL 加入候选，不自行猜测路径。

步骤 2：检查 DNS 是否给出直接证据

| | | — | | dig +short CNAME <HOST> |

若 CNAME 显示 publish-main.obsidian.md，这是强指纹：Obsidian 官方的自定义域名设置正是把域名 CNAME 指向该目标。Obsidian Publish 自定义域名说明

但不要把“没有这个 CNAME”当成否定结论。官方推荐经 Cloudflare 代理配置自定义域名，代理会隐藏源站 DNS 细节；也可以通过反向代理把 Publish 挂在域名的子路径下。因此，DNS 只能增加置信度，不能单独排除。

结果判断

| | | | | — | — | — | | 级别 | 证据组合 | 结论与下一跳 | | F0 | 普通站点，无笔记导航或 Publish 线索 | 记录后停止 | | F1 | 文档/双链式笔记导航，但无 Publish 强证据 | 作为静态笔记站，执行方法三反查源码 | | F2 | publish.obsidian.md 直接跳转、HTML 标记或 CNAME 命中其中两项 | 高置信度 Obsidian Publish，检查公开页面边界 | | F3 | F2 且页面/附件明显超出项目预期公开范围 | 停止扩展，按赏金规则最小化上报 |

Obsidian Publish 本身就是将选择的笔记托管为 wiki、知识库或文档站，默认地址形如 publish.obsidian.md/your-site。Obsidian Publish 介绍所以发现 F2 只能证明“发布过笔记”，不能自动证明整个私有 vault 被暴露。

方法三：从站点反查公开源码——找到真正的 Git vault

目的

从一个已确认的目标域或笔记站，发现公开代码托管上的候选仓库。这一步不需要先知道目标组织名：域名本身是枢轴。

前置条件

• 已有 <TARGET_DOMAIN> 或 <HOST>；

• 仅查看公开的 GitHub/GitLab 结果；

• 仓库与目标之间必须有可记录的关联依据，不能因为名称相似就归属给目标。

步骤 1：先从站点本身找明确源码链接

浏览页面页脚、About、贡献说明、RSS、公开 robots.txt/sitemap 中的链接；查看首页 HTML 里已公开的 github.com、gitlab.com 链接。优先级从高到低：

01 “Source / Edit on GitHub / Contribute” 链接；

02 README、部署页或页面源码中出现的仓库 URL；

03 GitHub/GitLab 项目中明确声明该域名是部署地址；

04 仅名称相似的仓库（只做候选，不能归属）。

预期结果： 至少得到一个 OWNER/REPO 与目标域的直接关联，或明确记录“站点未披露源码链接”。

步骤 2：以域名为内容枢轴搜索公开代码

在 GitHub Code Search 输入以下查询。它们以目标域为必需内容，不要求预先掌握组织名：

| | | — | | "<TARGET_DOMAIN>" path:*.md "<HOST>" path:*.md "<TARGET_DOMAIN>" path:.obsidian "publish-main.obsidian.md" "<TARGET_DOMAIN>" |

第一、二条常用于发现 README、部署说明、笔记正文或链接集合；第三条寻找 vault 配置中出现的目标域；第四条寻找公开的 Publish 自定义域名配置。GitHub Code Search 支持精确短语和 path: 限定符。GitHub Code Search 语法

对命中仓库只记录：仓库 URL、命中路径、匹配片段中目标域的上下文、默认分支和最近提交时间。再打开文件树确认是否存在 .obsidian/；此时仍不需要下载全部文件。

结果判断

| | | | | — | — | — | | 结果 | 解释 | 下一跳 | | R0 | 只有第三方引用目标域 | 不是目标 vault，结束 | | R1 | 仓库引用目标域，但没有 .obsidian | 可能只是站点配置或文档项目，保留关联证据 | | R2 | 仓库引用目标域，且含 .obsidian 与 Markdown 主体 | 高价值候选，进入方法四 | | R3 | 站点直接声明该仓库为源码，且仓库为 R2 | 已形成“域名 → 源码 vault”强链 |

方法四：确认仓库是不是 vault，而不是一个 Obsidian 示例

目的

用目录结构证明公开仓库是实际笔记库，而非仅包含主题、插件配置或教程示例。

前置条件

• 已得到 R2/R3 的公开仓库；

• 漏洞赏金范围允许检查该公开代码托管资产；

• 只需要路径与历史元数据时，优先使用无 blob checkout 的方式。

操作步骤

判定时使用组合证据：

• .obsidian/app.json、workspace.json 或 community-plugins.json：Obsidian 配置证据；

• 分层的 Markdown 笔记树：内容主体证据；

• 附件/图片目录与笔记相互引用：实际工作库或发布库的辅助证据；

• README、CNAME、部署配置或页面 URL：与目标域的归属证据。

预期结果

| | | | | — | — | — | | 级别 | 最小证据 | 结论 | | V0 | 只有 .obsidian 配置 | 可能是模板/主题，不能称为暴露 vault | | V1 | 配置 + 少量示例 Markdown | 可能是示例或公开文档库 | | V2 | 配置 + 成体系 Markdown + 附件/链接关系 | 可确认公开 vault | | V3 | V2 + 目标域关联 + 非预期敏感内容的最小证据 | 可提交漏洞报告 |

关键点是“目标关联”和“vault 结构”必须同时成立。单独看到一个公开 vault，或单独看到一个提到目标域的仓库，都不足以归属给漏洞赏金目标。

方法五：检查历史与发布副本——验证修复是否只删了当前文件

目的

确认公开 vault 是否存在“当前分支删除、历史或发布物仍可访问”的情况。此步骤只对已形成强关联的 R3/V2/V3 仓库执行，不把它扩展成所有公开仓库的猎取。

前置条件

• 已完成方法四；

• 本地 bare 镜像位于隔离目录，不会被推送到其他远端；

• 已知漏洞赏金政策允许历史提交与公开 Release 的检查。

操作步骤

第一条找相关路径是否曾出现；第二条输出提交 SHA、时间和提交说明；第三条仅枚举公开 Release 附件的元数据与链接，不批量下载。

预期结果

• H0：相关路径仅在预期公开的当前版本出现；

• H1：当前已移除，但历史 SHA/分支仍含 vault 路径；

• H2：公开 Release 或部署产物保留了旧副本；

• H3：路径对应的内容触及疑似敏感材料。

对 H1/H2，报告中写清“哪个 SHA、哪个 tag、哪个路径仍可访问”；对 H3，停止扩大查看，保存最小化定位证据并上报。发现 token 或私钥时，不以“测试是否有效”作为证明动作。

最小化漏洞报告：把“发现一个 vault”写成可复现的问题

报告中至少需要四部分：

01 目标关联：从 target.tld 到仓库或站点的链接证据；

02 Obsidian 证据：.obsidian 配置、Publish 指纹或 vault 目录结构；

03 公开访问证据：完整 URL、分支、tag 或 commit SHA，以及观察时间；

04 影响边界：公开的是已选择的发布页面、整个 Git vault，还是历史/附件副本；不复制无关笔记正文。

一个合格结论的示例结构：

| | | — | | 在 <TARGET_DOMAIN> 的公开文档页中发现 Source 链接指向 <OWNER>/<REPO>。 该仓库默认分支含 .obsidian/app.json、workspace.json 与笔记树，证明其为 Obsidian vault。 仓库 README 指定 <TARGET_DOMAIN> 为部署地址，完成目标关联。 历史提交 <SHA> 中的 <PATH> 当前仍可公开访问；附件/内容类型已按最小化原则确认。 |

相反，下列写法都不成立：

• “搜到 Obsidian，所以目标泄露笔记”；

• “GitHub 有同名仓库，应该属于目标”；

• “搜索引擎没搜到，所以目标没有 vault”；

• “疑似 token，已调用接口验证有效”。

结语：单域名场景最重要的是枢轴质量

从一个域名开始，最有效的不是堆更多扫描器，而是始终围绕同一条关联链推进：域名 → 笔记站/代码线索 → 公开仓库 → Obsidian 结构 → 历史或发布副本。

当任何一环缺少证据，就把它标记为候选，而不是把猜测写成漏洞；当证据足以证明非预期公开，就停止收集，把路径、版本和影响交给项目的披露流程。这才是漏洞赏金场景下可复现、可修复，也不会越界的信息搜集。

参考资料

01 Google Search Central：site: search operator

02 Obsidian Help：Introduction to Obsidian Publish

03 Obsidian Help：Custom domains

04 GitHub Docs：Understanding GitHub Code Search syntax

05 GitHub REST：List organization repositories

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：赛博57库 7月的风 7月的风《红队侦察：发掘Obsidian知识库》