前些日子做一起内网失陷主机排查过程里有个小插曲挺有意思。目标机器上装了 Chrome用户坚称自己没访问过可疑站点还当面给演示了一遍“清除浏览数据”。浏览器清完历史我把History数据库丢给 Hindsight 跑了一遍结果打脸来得很快——不仅清掉的记录回来了大半连他什么时候访问、访问了哪些域、停留状态如何全被工具还原成了一条时间线。那次之后我算是彻底理解了为什么说“删除”在浏览器取证里是个伪命题。Hindsight 是一个开源的 Chrome/Chromium 内核浏览器取证工具作者是 Ryan Benson项目托管在 GitHub 的 obsidianforensics 组织下主要用于解析浏览器本地生成的 SQLite 数据库包括历史记录、下载记录、Cookie、登录信息等。它最核心的价值在于“删掉的数据也能挖出来”以及跨平台支持Windows、macOS、Linux 都能跑连 Android 上的 Yaara 浏览器也能处理。对应急响应、内部调查、合规审计这些场景来说它是那种关键时刻能顶上去的工具而且免费、开源、命令行驱动非常容易接进自动化流程。1. 为什么浏览器取证是案件突破口1.1 浏览器痕迹为什么“删不干净”很多人觉得只要点了“清除浏览数据”浏览器就把我的上网痕迹彻底抹干净了。这个认知在取证人员看来实在太天真。Chrome 的历史记录存在一个名为History的 SQLite 数据库文件里里面主要是urls、visits、downloads这几张表。用户执行清除操作后Chrome 并不会立刻把这些数据从磁盘上的物理文件中移除更多时候只是做了“标记删除”——也就是在记录上打一个标记让正常查询接口不再返回这些行。从数据库文件本身来看原始数据的字节依然躺在文件里或者被 SQLite 标记为空闲页等待后续重用。更麻烦的是SQLite 的存储机制决定了就算某条记录对应的物理页已经被标记为空闲只要这个页还没有被新数据覆盖旧数据就会原封不动地残留在文件里。数字取证里管这种玩法叫空闲页数据恢复。加上 Chrome 还有个log_data表里面会保存一些在正常查询中看不到的日志型历史数据经常藏着惊喜。这些数据单独看每一处都不起眼组合起来却能还原出一名用户相当完整的网上行为画像。所以在浏览器取证里“用户删过什么”和“用户实际留下什么”完全是两回事。1.2 Hindsight 在取证工具链里的位置浏览器取证的工具其实挺多有免费的也有商业的。商业取证套件通常界面好看、报告专业但价格感人而且很多高级功能得单独买模块。Hindsight 免费、开源覆盖了解析 Chrome 历史、恢复已删除条目、Cookie 解密这几个最关键的需求单枪匹马就能完成大部分浏览器取证工作。而且因为它是命令行工具非常适合放进自动化取证脚本里批量跑多台机器的 Chrome 痕迹。它的工作方式也不复杂读入 Chrome profile 目录就是用户数据目录下Default那层从里面找出History、Cookies、Login Data、Local State这些文件解析 SQLite 里的表结构再把时间戳、URL、标题、访问次数、隐藏标记、来源表等字段整理输出。输出格式包括 CSV、SQLite 数据库文件、JSON也可以直接起一个本地 Web 服务做可视化时间线。接下来我会把它的核心能力逐个拆开讲清楚。1.3 这类工具适合谁用我接触过的使用者大致分三类。第一类是应急响应工程师机器被入侵后需要快速判断攻击者有没有用浏览器访问过敏感系统、上传下载过什么文件Hindsight 能给出直接的证据链。第二类是内部调查人员处理员工违规访问、信息泄露这类事浏览器历史加 Cookie 解密往往能还原出员工在某个时间点登录了什么系统、提交了什么操作。第三类是数字取证方向的学生和研究者Hindsight 代码结构清晰是学习 SQLite 取证、DPAPI 解密原理的上手项目。2. Hindsight 核心能力拆解2.1 History 数据库的解析逻辑Chrome 的History数据库是理解整个浏览行为的核心。urls表保存了每个 URL 的地址、标题、访问次数、最后访问时间等基础信息visits表记录每一次具体的访问动作包括访问时间、来源页面、跳转类型downloads和downloads_url_chains记录下载行为和下载地址链条。Hindsight 会把这几张表做关联查询组装成一行行带时间戳的访问记录还原“用户什么时间打开了什么页面从哪里跳转过来”的完整脉络。这里要说个很多新手栽过跟头的点时间戳格式。Chrome 存历史时间用的不是 Unix 时间戳而是“从 1601 年 1 月 1 日 00:00:00 起经过的微秒数”也就是 WebKit 格式时间戳。直接用十六进制编辑器扒出来的数字是没法直接看懂的Hindsight 在输出时会自动转换成可读的本地时间省去了手工换算的麻烦。如果你需要把浏览器记录和系统日志、安全告警做时间关联这个转换后的字段直接就能用不用再写一遍脚本去处理。2.2 删除记录是怎么“捞”回来的Hindsight 的看家本领是恢复被删除的历史记录。它从两个层面下手。第一个层面是“标记删除”的记录。前面说过Chrome 清历史有一部分只是改变了查询可见性底层数据其实还在。Hindsight 在查询时会绕过 Chrome 正常接口的限制直接读 SQLite 表里的原始字段把那些带隐藏或删除标记的记录一并捞出来。这些记录在输出里会有明确的来源标识告诉你这一条是从正常历史表里来的还是从“被隐藏”状态里挖出来的。第二个层面是物理残留。SQLite 删除数据后原本数据所在的物理页会被挂到 freelist空闲页链表上但只要这个页没被重用页内的字节内容就是一个现场。Hindsight 会扫描这些空闲页把里面残留的 URL、标题、时间信息逐条提取、重组。这个原理跟内存取证里“从已释放内存里找字符串”是一个思路只是处理对象从内存变成了数据库文件。实际操作中这种恢复往往能挖出不少用户以为已经彻底删除、但在物理层面根本没走远的记录。我做过一次测试在全新 Chrome 里正常浏览半小时然后清除全部历史再用 Hindsight 跑恢复出来的 URL 数量大约还有原来的三成到五成。这个比例会随后续使用变化机器闲置越久恢复率越高后续越频繁使用数据库、空闲页被复用越多恢复率就越低。这也提醒我们案发后尽快采集、尽快分析窗口期很重要。2.3 Cookie 解密与凭据提取历史记录只能证明“访问过”如果要证明“登录过”“操作过”Cookie 和登录凭据就非常关键了。Chrome 的 Cookie 存储在CookiesSQLite 数据库里但值是被加密的。不同版本、不同平台的加密机制不同这也是很多 DIY 脚本没法跨平台的原因。Windows 上Chrome 早期用 DPAPI 直接加密 Cookie 值从 Chrome 80 开始改用 AES-GCM 算法加密密钥存放在Local State文件里而密钥本身又用 DPAPI 保护。Hindsight 会自动读取Local State提取并用 DPAPI 解密出真正的 AES 主密钥再对每个 Cookie 的加密值做解密。macOS 和 Linux 平台的密钥则在系统钥匙串或密钥环里Hindsight 通过系统 keyring 接口读取 “Chrome Safe Storage” 条目来解锁。这些操作都会在后台自动完成用户只需提供 profile 目录不必手工处理密钥。当然解密也不是无条件的。Cookie 的 DPAPI 保护绑定用户和机器如果一份样本是从 A 机器采集、拿到 B 机器上分析B 上大概率解不开。Hindsight 在解不开的时候会保留加密状态并标注原因不会影响其他功能的输出。做跨平台分析时一定要有这个预期免得排期失控。2.4 输出字段与结果判读Hindsight 输出的一条记录里我日常最关注几个字段时间转换后的可读时间、URL、标题、访问次数、来源这个记录是来自历史表、log_data 还是空闲页恢复、隐藏标记。访问次数能反映用户对这个站点的依赖程度总访问次数高且最近访问时间近说明是高频使用的站点。比如调查离职员工泄露资料发现目标系统访问记录集中在离职前两周且访问次数是前几个月的总和这条线就非常值得查。来源字段是很重要的一个参考。来自history_db的记录说明数据还活在正常历史表里删掉的那批记录在空闲页恢复结果里会单独标注。如果发现大量记录都来自空闲页恢复说明用户确实执行过清除操作这个行为本身也是分析结论的一部分。整理报告时我会把“来源”作为一个分类维度统计正常记录和恢复记录各自的数量直观呈现“用户删了多少、还剩多少”。3. 从零上手安装与基础用法3.1 环境准备Hindsight 是 Python 工具官方推荐用 Python 3.8 以上跑。安装环境这一块建议用虚拟环境尤其公司内网机器上可能已经装了一堆 Python 依赖直接pip install -r requirements.txt很可能把环境搞乱。我踩过一次某台机器上全局环境里有个旧版本的python-dateutilHindsight 跑起来时间解析各种错位排查半天才发现是被旧依赖坑了。所以老老实实建个 venvgit clone https://github.com/obsidianforensics/hindsight.git cd hindsight python -m venv venv source venv/bin/activate # Windows 下是 venv\Scripts\activate pip install -r requirements.txtWindows 平台还需要注意DPAPI 解密依赖 pywin32安装时会有额外的依赖处理如果跑起来报 “No module named win32crypt”就是 pywin32 没装好。macOS 上则要确保系统钥匙串处于可访问状态跑批处理的时候别把钥匙串口令弹窗点了“拒绝”否则解密会静默失败。3.2 第一次运行一条命令出报告找到 Chrome 的 profile 目录。Windows 上常见的路径是C:\Users\用户名\AppData\Local\Google\Chrome\User Data\DefaultmacOS 常见路径~/Library/Application Support/Google/Chrome/DefaultLinux 常见路径~/.config/google-chrome/Default注意输入的是Default这一个整 profile 目录不是单独的History文件。如果你电脑上登录了多个 Chrome 用户每个用户对应一个子目录那就逐个分析。确认 Chrome 已经完全退出之后再复制数据。我个人的习惯是先把整个 profile 目录做成副本再用副本分析原始路径绝不让工具直接碰。这样做一是避免 Chrome 进程仍在后台写库导致文件锁或数据不一致二是保留原始证据的完整性方便事后做哈希校验。然后运行python run.py -i C:\Users\xxx\AppData\Local\Google\Chrome\User Data\Default默认情况下结果直接在终端打印格式是 CSV。每一行就是一条历史或访问记录包含时间、URL、标题、访问次数、来源等信息。第一次跑通之后你会对“Chrome 到底记录了多少东西”有个非常直观的认知。记录数量往往超出预期企业电脑跑出来的结果动辄几万行所以别指望肉眼一条条看后面我会讲怎么控制和筛选。Edge 和 Brave 这类 Chromium 内核浏览器也能用 Hindsight 解析只是路径不同。比如 Edge 的 profile 目录通常在C:\Users\用户名\AppData\Local\Microsoft\Edge\User Data\Default输入路径换成 Edge 的就行。这类浏览器继承了 Chrome 的数据结构和加密机制Hindsight 的兼容性天然覆盖到了。3.3 输出控制与自定义查询终端打印适合验证工具能用真做分析建议用文件输出python run.py -i profile路径 -o result.sqlite-o参数可以生成一个 SQLite 结果库之后用 DB Browser for SQLite 或者 Python 脚本去查效率高很多。如果想要 JSON 格式-o result.json也可以。做自动化批量取证时这个输出文件就是给下游分析流程的交接物。Hindsight 还提供了一个非常灵活的-s参数允许你对解析后的数据库执行自定义 SQL。比如想只查某个域名的历史记录python run.py -i profile路径 -s SELECT * FROM urls WHERE url LIKE %example.com%另外还有一个-f参数可以做基础的过滤按关键字收窄结果范围。这个参数对深度调查非常有用。不需要等工具把所有结果全部输出后再筛直接在源头上用 SQL 或过滤条件把目标数据拽出来配合时间范围、域名关键字、访问次数排序能快速锁定可疑站点。做应急响应时时间就是生命少打印几万行无意义数据也是给后续分析省时间。4. 深入实操一个完整的调查流程4.1 场景设定被清除历史的机器假设你现在拿到了一台 Windows 工作站的磁盘镜像用户反映“我的 Chrome 历史莫名其妙没了”而你怀疑有人在这台机器上访问过内部系统并试图清痕迹。这是浏览器取证里最典型的场景。整个流程分四步确认采集对象、复制样本、跑 Hindsight、解读结果。先把需要的文件找齐。完整的浏览器取证不只依赖History还要Cookies、Login Data、Local State、Web Data这些文件。Local State在 Chrome 用户数据目录的上一层也就是C:\Users\用户名\AppData\Local\Google\Chrome\User Data\Local State做 Cookie 解密时少了它不行。采集时连目录结构一起打包别只抠一个History文件出来。然后是保护证据。用工具复制整个 profile 目录之前先记录原始文件的哈希值复制完成后核对副本的哈希是否一致保证后续任何操作都是基于副本而不是原始证据。这一步在正式调查里属于强制动作自己练习时也要养成习惯。调查过程中如果分析出错随时能回到原始打包文件重新来不至于污染唯一证据。4.2 实操演示与结果解读对上一步复制出来的副本目录执行python run.py -i D:\evidence\chrome_profile\Default -o D:\evidence\history_timeline.sqlite输出完成后用 SQLite 工具打开结果文件按时间排序浏览记录。我在这类场景里通常会关注几个点用户声称“没有访问过”的时段内是不是真的有访问记录有没有从log_data或空闲页恢复出来的额外数据访问的 URL 里有没有敏感目标比如内部系统、文件传输站、代码仓库。结果文件里看到的记录大概是这种样式time url title visit_count hidden source 2024-03-15 09:12:45 https://mail.example.com/ Webmail 15 0 history_db 2024-03-15 09:13:02 https://drive.example.com/files/ 网盘 1 1 history_db 2024-03-15 09:20:11 https://internal.example.com/admin 管理后台 3 1 log_data 2024-03-15 09:15:33 https://docs.example.com/leak.pdf 文档 1 0 free_page第二条的 hidden 标记为 1第三条来自 log_data第四条是空闲页恢复这几条恰恰是普通方式看不到的“隐藏痕迹”。用户以为自己删干净了实际上时间、URL、来源全都留在了数据库里。实际操作中恢复出来的记录有时候 URL 和标题对不上这是因为空闲页里拼接出来的数据可能不完整需要结合上下文人工判断不能盲信数据库里读出来的一切。结果解读有一条原则单条记录只能说明“访问过这个 URL”要形成“用户在干什么”的判断必须把历史记录、Cookie、下载记录、系统其他日志放在一起看时间线。比如 Chrome 历史里出现一个网盘 URL 可能说明不了什么但同一分钟内 Cookie 解密结果显示这个网盘账号登录成功、下载表里又有一条文件下载记录整个链条就清晰了。浏览器记录是拼图的核心板块但永远不能孤立使用。4.3 Web 时间线可视化数据量大的时候看 CSV 或者 SQLite 表格效率不高。Hindsight 提供了-w参数可以在本地起一个 Web 服务把结果渲染成交互式时间线和表格界面鼠标点一点就能缩放时间段、按域过滤、看单条记录的详情。这个模式需要配合-g参数指定 ChromeDriver 的路径因为可视化页面依赖无头浏览器渲染。命令大概是python run.py -i profile路径 -w 8000 -g /path/to/chromedriver浏览器里打开http://localhost:8000就能看到结果。我习惯在写分析报告时用这个模式做截图时间线视图比贴一堆 CSV 文本直观得多直接作为报告配图给非技术背景的同事看也更容易理解。需要提醒的是-w模式会注册本地端口如果在隔离调查环境之外运行注意别让未授权的人访问到这个端口分析完毕记得把服务关掉。5. 常见问题与排查技巧实录5.1 问题速查表现象可能原因解决方案提示无法打开 History 数据库Chrome 仍在后台运行数据库被锁定或文件损坏先彻底退出 Chrome再用副本分析副本也打不开就检查文件头是否为 SQLite 格式Cookie 解密全部失败缺少 Local State 文件或跨机器、跨用户分析DPAPI 无法解密确认采集时包含 Local State跨机器场景可以放弃解密只做结构和元数据分析输出结果里时间全部是 1970 年Chrome 时间戳处理异常通常是依赖版本问题检查 python-dateutil 等依赖是否过旧升级到 requirements 指定版本结果里出现大量隐藏记录用户确实清除过历史或 Chrome 内部标记隐藏属于正常现象按来源字段区分即可隐藏记录恰恰是调查重点Linux/macOS 上解密报 keyring 错误系统钥匙串未解锁或采集时用户未登录在采集环境中解锁钥匙串后再分析或跳过解密继续其他分析输出结果里有乱码或残缺 URL空闲页数据不完整拼接出的记录有缺失结合标题、时间等字段交叉判断必要时回看原始 SQLite 页数据5.2 实战中容易被忽略的细节几个我用真金白银换来的经验值得单独说。第一采集 Chrome 数据前最好先做内存采集。Chrome 的加密密钥、已解密的敏感数据都可能留在内存里如果你先把机器关机再拆硬盘内存里的证据就没了。虽然 Hindsight 本身不做内存取证但在整个调查顺序里内存采集应该排在硬盘拷贝之前。第二别只看Default目录。Chrome 还可能有Profile 1、Profile 2等额外用户目录以及Guest Profile。很多调查只看默认用户结果漏掉了真正的目标账户。采集时把整个User Data目录都打包分析时逐个 profile 跑一遍。我遇到过员工用小号、访客模式上网的案例打开 guest 配置文件一看访问记录清清楚楚。第三Hindsight 的隐藏记录不等于用户手动删除的记录。urls表里的 hidden 字段可能是 Chrome 内部行为导致的比如某些后台预取也可能是隐私清除操作留下的标记。解读时要结合时间、访问来源综合判断别一看到隐藏标记就急着下结论。第四结果文件本身也要保护。Hindsight 输出的 SQLite 文件里可能包含解密的 Cookie 明文这是敏感数据。用它做完分析把它放公共网盘或发给无关人员等于二次泄露。我自己一般在分析完成后把结果文件一并归档加密不留在临时目录里。最后再分享一个使用习惯。我每次跑 Hindsight 前都会先把 Chrome profile 目录打包成压缩包记录 SHA256再解压到工作目录。这样即使后面分析过程中搞坏了副本随时可以回到原始状态重来一遍。对取证工作来说一个可复现的分析流程比一次性的聪明操作重要得多。
浏览器取证实战：Hindsight 如何恢复 Chrome 删除历史与解密数据
前些日子做一起内网失陷主机排查过程里有个小插曲挺有意思。目标机器上装了 Chrome用户坚称自己没访问过可疑站点还当面给演示了一遍“清除浏览数据”。浏览器清完历史我把History数据库丢给 Hindsight 跑了一遍结果打脸来得很快——不仅清掉的记录回来了大半连他什么时候访问、访问了哪些域、停留状态如何全被工具还原成了一条时间线。那次之后我算是彻底理解了为什么说“删除”在浏览器取证里是个伪命题。Hindsight 是一个开源的 Chrome/Chromium 内核浏览器取证工具作者是 Ryan Benson项目托管在 GitHub 的 obsidianforensics 组织下主要用于解析浏览器本地生成的 SQLite 数据库包括历史记录、下载记录、Cookie、登录信息等。它最核心的价值在于“删掉的数据也能挖出来”以及跨平台支持Windows、macOS、Linux 都能跑连 Android 上的 Yaara 浏览器也能处理。对应急响应、内部调查、合规审计这些场景来说它是那种关键时刻能顶上去的工具而且免费、开源、命令行驱动非常容易接进自动化流程。1. 为什么浏览器取证是案件突破口1.1 浏览器痕迹为什么“删不干净”很多人觉得只要点了“清除浏览数据”浏览器就把我的上网痕迹彻底抹干净了。这个认知在取证人员看来实在太天真。Chrome 的历史记录存在一个名为History的 SQLite 数据库文件里里面主要是urls、visits、downloads这几张表。用户执行清除操作后Chrome 并不会立刻把这些数据从磁盘上的物理文件中移除更多时候只是做了“标记删除”——也就是在记录上打一个标记让正常查询接口不再返回这些行。从数据库文件本身来看原始数据的字节依然躺在文件里或者被 SQLite 标记为空闲页等待后续重用。更麻烦的是SQLite 的存储机制决定了就算某条记录对应的物理页已经被标记为空闲只要这个页还没有被新数据覆盖旧数据就会原封不动地残留在文件里。数字取证里管这种玩法叫空闲页数据恢复。加上 Chrome 还有个log_data表里面会保存一些在正常查询中看不到的日志型历史数据经常藏着惊喜。这些数据单独看每一处都不起眼组合起来却能还原出一名用户相当完整的网上行为画像。所以在浏览器取证里“用户删过什么”和“用户实际留下什么”完全是两回事。1.2 Hindsight 在取证工具链里的位置浏览器取证的工具其实挺多有免费的也有商业的。商业取证套件通常界面好看、报告专业但价格感人而且很多高级功能得单独买模块。Hindsight 免费、开源覆盖了解析 Chrome 历史、恢复已删除条目、Cookie 解密这几个最关键的需求单枪匹马就能完成大部分浏览器取证工作。而且因为它是命令行工具非常适合放进自动化取证脚本里批量跑多台机器的 Chrome 痕迹。它的工作方式也不复杂读入 Chrome profile 目录就是用户数据目录下Default那层从里面找出History、Cookies、Login Data、Local State这些文件解析 SQLite 里的表结构再把时间戳、URL、标题、访问次数、隐藏标记、来源表等字段整理输出。输出格式包括 CSV、SQLite 数据库文件、JSON也可以直接起一个本地 Web 服务做可视化时间线。接下来我会把它的核心能力逐个拆开讲清楚。1.3 这类工具适合谁用我接触过的使用者大致分三类。第一类是应急响应工程师机器被入侵后需要快速判断攻击者有没有用浏览器访问过敏感系统、上传下载过什么文件Hindsight 能给出直接的证据链。第二类是内部调查人员处理员工违规访问、信息泄露这类事浏览器历史加 Cookie 解密往往能还原出员工在某个时间点登录了什么系统、提交了什么操作。第三类是数字取证方向的学生和研究者Hindsight 代码结构清晰是学习 SQLite 取证、DPAPI 解密原理的上手项目。2. Hindsight 核心能力拆解2.1 History 数据库的解析逻辑Chrome 的History数据库是理解整个浏览行为的核心。urls表保存了每个 URL 的地址、标题、访问次数、最后访问时间等基础信息visits表记录每一次具体的访问动作包括访问时间、来源页面、跳转类型downloads和downloads_url_chains记录下载行为和下载地址链条。Hindsight 会把这几张表做关联查询组装成一行行带时间戳的访问记录还原“用户什么时间打开了什么页面从哪里跳转过来”的完整脉络。这里要说个很多新手栽过跟头的点时间戳格式。Chrome 存历史时间用的不是 Unix 时间戳而是“从 1601 年 1 月 1 日 00:00:00 起经过的微秒数”也就是 WebKit 格式时间戳。直接用十六进制编辑器扒出来的数字是没法直接看懂的Hindsight 在输出时会自动转换成可读的本地时间省去了手工换算的麻烦。如果你需要把浏览器记录和系统日志、安全告警做时间关联这个转换后的字段直接就能用不用再写一遍脚本去处理。2.2 删除记录是怎么“捞”回来的Hindsight 的看家本领是恢复被删除的历史记录。它从两个层面下手。第一个层面是“标记删除”的记录。前面说过Chrome 清历史有一部分只是改变了查询可见性底层数据其实还在。Hindsight 在查询时会绕过 Chrome 正常接口的限制直接读 SQLite 表里的原始字段把那些带隐藏或删除标记的记录一并捞出来。这些记录在输出里会有明确的来源标识告诉你这一条是从正常历史表里来的还是从“被隐藏”状态里挖出来的。第二个层面是物理残留。SQLite 删除数据后原本数据所在的物理页会被挂到 freelist空闲页链表上但只要这个页没被重用页内的字节内容就是一个现场。Hindsight 会扫描这些空闲页把里面残留的 URL、标题、时间信息逐条提取、重组。这个原理跟内存取证里“从已释放内存里找字符串”是一个思路只是处理对象从内存变成了数据库文件。实际操作中这种恢复往往能挖出不少用户以为已经彻底删除、但在物理层面根本没走远的记录。我做过一次测试在全新 Chrome 里正常浏览半小时然后清除全部历史再用 Hindsight 跑恢复出来的 URL 数量大约还有原来的三成到五成。这个比例会随后续使用变化机器闲置越久恢复率越高后续越频繁使用数据库、空闲页被复用越多恢复率就越低。这也提醒我们案发后尽快采集、尽快分析窗口期很重要。2.3 Cookie 解密与凭据提取历史记录只能证明“访问过”如果要证明“登录过”“操作过”Cookie 和登录凭据就非常关键了。Chrome 的 Cookie 存储在CookiesSQLite 数据库里但值是被加密的。不同版本、不同平台的加密机制不同这也是很多 DIY 脚本没法跨平台的原因。Windows 上Chrome 早期用 DPAPI 直接加密 Cookie 值从 Chrome 80 开始改用 AES-GCM 算法加密密钥存放在Local State文件里而密钥本身又用 DPAPI 保护。Hindsight 会自动读取Local State提取并用 DPAPI 解密出真正的 AES 主密钥再对每个 Cookie 的加密值做解密。macOS 和 Linux 平台的密钥则在系统钥匙串或密钥环里Hindsight 通过系统 keyring 接口读取 “Chrome Safe Storage” 条目来解锁。这些操作都会在后台自动完成用户只需提供 profile 目录不必手工处理密钥。当然解密也不是无条件的。Cookie 的 DPAPI 保护绑定用户和机器如果一份样本是从 A 机器采集、拿到 B 机器上分析B 上大概率解不开。Hindsight 在解不开的时候会保留加密状态并标注原因不会影响其他功能的输出。做跨平台分析时一定要有这个预期免得排期失控。2.4 输出字段与结果判读Hindsight 输出的一条记录里我日常最关注几个字段时间转换后的可读时间、URL、标题、访问次数、来源这个记录是来自历史表、log_data 还是空闲页恢复、隐藏标记。访问次数能反映用户对这个站点的依赖程度总访问次数高且最近访问时间近说明是高频使用的站点。比如调查离职员工泄露资料发现目标系统访问记录集中在离职前两周且访问次数是前几个月的总和这条线就非常值得查。来源字段是很重要的一个参考。来自history_db的记录说明数据还活在正常历史表里删掉的那批记录在空闲页恢复结果里会单独标注。如果发现大量记录都来自空闲页恢复说明用户确实执行过清除操作这个行为本身也是分析结论的一部分。整理报告时我会把“来源”作为一个分类维度统计正常记录和恢复记录各自的数量直观呈现“用户删了多少、还剩多少”。3. 从零上手安装与基础用法3.1 环境准备Hindsight 是 Python 工具官方推荐用 Python 3.8 以上跑。安装环境这一块建议用虚拟环境尤其公司内网机器上可能已经装了一堆 Python 依赖直接pip install -r requirements.txt很可能把环境搞乱。我踩过一次某台机器上全局环境里有个旧版本的python-dateutilHindsight 跑起来时间解析各种错位排查半天才发现是被旧依赖坑了。所以老老实实建个 venvgit clone https://github.com/obsidianforensics/hindsight.git cd hindsight python -m venv venv source venv/bin/activate # Windows 下是 venv\Scripts\activate pip install -r requirements.txtWindows 平台还需要注意DPAPI 解密依赖 pywin32安装时会有额外的依赖处理如果跑起来报 “No module named win32crypt”就是 pywin32 没装好。macOS 上则要确保系统钥匙串处于可访问状态跑批处理的时候别把钥匙串口令弹窗点了“拒绝”否则解密会静默失败。3.2 第一次运行一条命令出报告找到 Chrome 的 profile 目录。Windows 上常见的路径是C:\Users\用户名\AppData\Local\Google\Chrome\User Data\DefaultmacOS 常见路径~/Library/Application Support/Google/Chrome/DefaultLinux 常见路径~/.config/google-chrome/Default注意输入的是Default这一个整 profile 目录不是单独的History文件。如果你电脑上登录了多个 Chrome 用户每个用户对应一个子目录那就逐个分析。确认 Chrome 已经完全退出之后再复制数据。我个人的习惯是先把整个 profile 目录做成副本再用副本分析原始路径绝不让工具直接碰。这样做一是避免 Chrome 进程仍在后台写库导致文件锁或数据不一致二是保留原始证据的完整性方便事后做哈希校验。然后运行python run.py -i C:\Users\xxx\AppData\Local\Google\Chrome\User Data\Default默认情况下结果直接在终端打印格式是 CSV。每一行就是一条历史或访问记录包含时间、URL、标题、访问次数、来源等信息。第一次跑通之后你会对“Chrome 到底记录了多少东西”有个非常直观的认知。记录数量往往超出预期企业电脑跑出来的结果动辄几万行所以别指望肉眼一条条看后面我会讲怎么控制和筛选。Edge 和 Brave 这类 Chromium 内核浏览器也能用 Hindsight 解析只是路径不同。比如 Edge 的 profile 目录通常在C:\Users\用户名\AppData\Local\Microsoft\Edge\User Data\Default输入路径换成 Edge 的就行。这类浏览器继承了 Chrome 的数据结构和加密机制Hindsight 的兼容性天然覆盖到了。3.3 输出控制与自定义查询终端打印适合验证工具能用真做分析建议用文件输出python run.py -i profile路径 -o result.sqlite-o参数可以生成一个 SQLite 结果库之后用 DB Browser for SQLite 或者 Python 脚本去查效率高很多。如果想要 JSON 格式-o result.json也可以。做自动化批量取证时这个输出文件就是给下游分析流程的交接物。Hindsight 还提供了一个非常灵活的-s参数允许你对解析后的数据库执行自定义 SQL。比如想只查某个域名的历史记录python run.py -i profile路径 -s SELECT * FROM urls WHERE url LIKE %example.com%另外还有一个-f参数可以做基础的过滤按关键字收窄结果范围。这个参数对深度调查非常有用。不需要等工具把所有结果全部输出后再筛直接在源头上用 SQL 或过滤条件把目标数据拽出来配合时间范围、域名关键字、访问次数排序能快速锁定可疑站点。做应急响应时时间就是生命少打印几万行无意义数据也是给后续分析省时间。4. 深入实操一个完整的调查流程4.1 场景设定被清除历史的机器假设你现在拿到了一台 Windows 工作站的磁盘镜像用户反映“我的 Chrome 历史莫名其妙没了”而你怀疑有人在这台机器上访问过内部系统并试图清痕迹。这是浏览器取证里最典型的场景。整个流程分四步确认采集对象、复制样本、跑 Hindsight、解读结果。先把需要的文件找齐。完整的浏览器取证不只依赖History还要Cookies、Login Data、Local State、Web Data这些文件。Local State在 Chrome 用户数据目录的上一层也就是C:\Users\用户名\AppData\Local\Google\Chrome\User Data\Local State做 Cookie 解密时少了它不行。采集时连目录结构一起打包别只抠一个History文件出来。然后是保护证据。用工具复制整个 profile 目录之前先记录原始文件的哈希值复制完成后核对副本的哈希是否一致保证后续任何操作都是基于副本而不是原始证据。这一步在正式调查里属于强制动作自己练习时也要养成习惯。调查过程中如果分析出错随时能回到原始打包文件重新来不至于污染唯一证据。4.2 实操演示与结果解读对上一步复制出来的副本目录执行python run.py -i D:\evidence\chrome_profile\Default -o D:\evidence\history_timeline.sqlite输出完成后用 SQLite 工具打开结果文件按时间排序浏览记录。我在这类场景里通常会关注几个点用户声称“没有访问过”的时段内是不是真的有访问记录有没有从log_data或空闲页恢复出来的额外数据访问的 URL 里有没有敏感目标比如内部系统、文件传输站、代码仓库。结果文件里看到的记录大概是这种样式time url title visit_count hidden source 2024-03-15 09:12:45 https://mail.example.com/ Webmail 15 0 history_db 2024-03-15 09:13:02 https://drive.example.com/files/ 网盘 1 1 history_db 2024-03-15 09:20:11 https://internal.example.com/admin 管理后台 3 1 log_data 2024-03-15 09:15:33 https://docs.example.com/leak.pdf 文档 1 0 free_page第二条的 hidden 标记为 1第三条来自 log_data第四条是空闲页恢复这几条恰恰是普通方式看不到的“隐藏痕迹”。用户以为自己删干净了实际上时间、URL、来源全都留在了数据库里。实际操作中恢复出来的记录有时候 URL 和标题对不上这是因为空闲页里拼接出来的数据可能不完整需要结合上下文人工判断不能盲信数据库里读出来的一切。结果解读有一条原则单条记录只能说明“访问过这个 URL”要形成“用户在干什么”的判断必须把历史记录、Cookie、下载记录、系统其他日志放在一起看时间线。比如 Chrome 历史里出现一个网盘 URL 可能说明不了什么但同一分钟内 Cookie 解密结果显示这个网盘账号登录成功、下载表里又有一条文件下载记录整个链条就清晰了。浏览器记录是拼图的核心板块但永远不能孤立使用。4.3 Web 时间线可视化数据量大的时候看 CSV 或者 SQLite 表格效率不高。Hindsight 提供了-w参数可以在本地起一个 Web 服务把结果渲染成交互式时间线和表格界面鼠标点一点就能缩放时间段、按域过滤、看单条记录的详情。这个模式需要配合-g参数指定 ChromeDriver 的路径因为可视化页面依赖无头浏览器渲染。命令大概是python run.py -i profile路径 -w 8000 -g /path/to/chromedriver浏览器里打开http://localhost:8000就能看到结果。我习惯在写分析报告时用这个模式做截图时间线视图比贴一堆 CSV 文本直观得多直接作为报告配图给非技术背景的同事看也更容易理解。需要提醒的是-w模式会注册本地端口如果在隔离调查环境之外运行注意别让未授权的人访问到这个端口分析完毕记得把服务关掉。5. 常见问题与排查技巧实录5.1 问题速查表现象可能原因解决方案提示无法打开 History 数据库Chrome 仍在后台运行数据库被锁定或文件损坏先彻底退出 Chrome再用副本分析副本也打不开就检查文件头是否为 SQLite 格式Cookie 解密全部失败缺少 Local State 文件或跨机器、跨用户分析DPAPI 无法解密确认采集时包含 Local State跨机器场景可以放弃解密只做结构和元数据分析输出结果里时间全部是 1970 年Chrome 时间戳处理异常通常是依赖版本问题检查 python-dateutil 等依赖是否过旧升级到 requirements 指定版本结果里出现大量隐藏记录用户确实清除过历史或 Chrome 内部标记隐藏属于正常现象按来源字段区分即可隐藏记录恰恰是调查重点Linux/macOS 上解密报 keyring 错误系统钥匙串未解锁或采集时用户未登录在采集环境中解锁钥匙串后再分析或跳过解密继续其他分析输出结果里有乱码或残缺 URL空闲页数据不完整拼接出的记录有缺失结合标题、时间等字段交叉判断必要时回看原始 SQLite 页数据5.2 实战中容易被忽略的细节几个我用真金白银换来的经验值得单独说。第一采集 Chrome 数据前最好先做内存采集。Chrome 的加密密钥、已解密的敏感数据都可能留在内存里如果你先把机器关机再拆硬盘内存里的证据就没了。虽然 Hindsight 本身不做内存取证但在整个调查顺序里内存采集应该排在硬盘拷贝之前。第二别只看Default目录。Chrome 还可能有Profile 1、Profile 2等额外用户目录以及Guest Profile。很多调查只看默认用户结果漏掉了真正的目标账户。采集时把整个User Data目录都打包分析时逐个 profile 跑一遍。我遇到过员工用小号、访客模式上网的案例打开 guest 配置文件一看访问记录清清楚楚。第三Hindsight 的隐藏记录不等于用户手动删除的记录。urls表里的 hidden 字段可能是 Chrome 内部行为导致的比如某些后台预取也可能是隐私清除操作留下的标记。解读时要结合时间、访问来源综合判断别一看到隐藏标记就急着下结论。第四结果文件本身也要保护。Hindsight 输出的 SQLite 文件里可能包含解密的 Cookie 明文这是敏感数据。用它做完分析把它放公共网盘或发给无关人员等于二次泄露。我自己一般在分析完成后把结果文件一并归档加密不留在临时目录里。最后再分享一个使用习惯。我每次跑 Hindsight 前都会先把 Chrome profile 目录打包成压缩包记录 SHA256再解压到工作目录。这样即使后面分析过程中搞坏了副本随时可以回到原始状态重来一遍。对取证工作来说一个可复现的分析流程比一次性的聪明操作重要得多。
