浏览器配置异常与痕迹清理结果判断分析

浏览器配置异常与痕迹清理结果判断分析

0x02电子取证/浏览器相关检查 中给出了 IE 注册表配置查询、TypedURLs 历史记录查询、以及 InetCpl.cpl 痕迹清理命令等取证入口。这些内容在当时的环境下主要面向 IE 浏览器，但在真实应急场景中，这些检查结果所代表的分析逻辑至今仍然适用：浏览器配置是否被篡改、用户访问过什么、痕迹是否被清理过。

在已有的 0x03 文章中，浏览器痕迹与下载执行链分析 聚焦下载执行链的完整还原，浏览器下载与LNK和JumpList用户操作链分析 聚焦用户操作链的证据分层。本文不重复这些内容，而是聚焦 0x02 浏览器检查中另一类结果：浏览器配置异常（主页/搜索引擎被篡改）和痕迹清理动作的判断方法。

0x01 浏览器检查结果要回答的三个问题

浏览器配置与痕迹分析应优先回答：

  1. 浏览器配置是否被改过？ 主页、搜索引擎、新标签页是否指向非预期地址。
  2. 用户访问过什么？ TypedURLs、历史记录中是否包含可疑站点。
  3. 痕迹是否被清理过？ 清理动作是用户自发、安全软件触发，还是攻击者主动抹痕。

这三个问题决定了浏览器检查结果是停留在"配置信息记录"，还是能升级为"攻击链中的关键证据"。

0x02 浏览器配置异常的判定方法

1. 主页被篡改

0x02 中给出的检查命令：

reg query "HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main" /V "Start Page"
reg query "HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main" /V "Start Page"

如果结果类似：

Start Page    REG_SZ    http://go.microsoft.com/fwlink/p/?LinkId=255141

这是 IE 默认主页，属于正常。

但如果结果类似：

Start Page    REG_SZ    http://www.istartsurf.com
Start Page    REG_SZ    http://search.babylon.com
Start Page    REG_SZ    http://snap.do

则说明主页已被篡改。这类域名通常和浏览器劫持（Browser Hijacker）关联。

分析要点：

  • 对比 HKLM（计算机配置）和 HKCU（用户配置）的值是否一致
  • 如果不一致，HKLM 通常优先级更高，但某些劫持器会同时修改两处
  • 检查修改时间，判断篡改发生在什么时间窗
  • 查看 Default_Page_URL、Search Page、Default_Search_URL 是否也被修改

2. 搜索引擎被篡改

reg query "HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main" /V "Default_Search_URL"
reg query "HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main" /V "Search Page"

如果搜索引擎指向非预期的第三方搜索站，或者被重定向到广告联盟域名，同样说明浏览器配置被劫持。

分析要点：

  • 正常搜索引擎通常指向 bing.com、google.com、baidu.com 等已知站点
  • 劫持器通常指向不知名的搜索代理站或广告填充站
  • 有些劫持器不直接改搜索引擎，而是通过 BHO（Browser Helper Object）或扩展注入重定向

3. 扩展与 BHO 异常

虽然 0x02 中没有直接给出 BHO 检查命令，但在实际分析中，浏览器配置篡改往往和以下注册表位置强相关：

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects"
reg query "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Ext" /s

如果发现未知的 BHO 或扩展，且其 CLSID 指向非系统目录的 DLL，通常说明：

  • 浏览器劫持器通过 BHO 实现持久化
  • 每次浏览器启动都会加载恶意组件
  • 仅改回主页设置无法彻底修复

4. 现代浏览器的配置检查

对于 Chrome / Edge / Firefox，配置篡改的检查方式不同，但逻辑一致：

Get-Content "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Preferences" | Select-String "homepage"
Get-Content "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Preferences" | Select-String "startup_urls"
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Google\Chrome" -ErrorAction SilentlyContinue
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Edge" -ErrorAction SilentlyContinue

通过组策略强制设置主页或启动页，是企业环境中常见的管控方式。但如果策略指向可疑域名，或者策略键值被非管理员账户修改，则说明配置可能被恶意篡改。

0x03 TypedURLs 的分析方法

1. TypedURLs 的证据价值

0x02 中给出的检查命令：

reg query "HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\typedurls"

TypedURLs 的价值在于：它记录的是用户手工在地址栏输入或粘贴过的 URL，而不是浏览器自动访问的 URL。

这意味着：

  • TypedURLs 中的地址更可能是用户主动访问的
  • 对比完整 History，TypedURLs 更适合证明"用户知道自己在访问什么"
  • 对排查钓鱼站、临时恶意站点很有帮助

2. TypedURLs 的局限性

  • 最多只保留最近 50 条
  • 只覆盖 IE，不覆盖 Chrome / Edge / Firefox
  • 可能被用户或攻击者手工清理
  • 不能证明用户"打开了页面并交互"，只能证明"输入过这个地址"

3. TypedURLs 结果如何写成结论

如果 TypedURLs 中出现：

url1    REG_SZ    http://legitimate-site.com
url2    REG_SZ    http://suspicious-download.example.com/tool.exe
url3    REG_SZ    http://10.0.0.55/admin

更合理的分析结论是：

  • 用户曾在 IE 地址栏中输入或粘贴过这些地址
  • 其中包含可疑域名和内网地址
  • 但不能仅凭 TypedURLs 写成"用户已下载并执行了恶意文件"

如果要升级到更强结论，需要和 Downloads、History、进程日志交叉验证。

0x04 InetCpl.cpl 痕迹清理的判断方法

1. 0x02 中给出的清理命令

0x02 记录了通过 InetCpl.cpl 清理 IE 痕迹的命令：

RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 8
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 2
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 1
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 255
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 4351

这些命令分别对应：

参数清理内容
8临时 Internet 文件
2Cookies
1历史记录
16表单数据
32密码
255全部删除
4351全部删除 + 插件数据

2. 如何判断清理动作的性质

当在进程日志（4688 / Sysmon 1）或命令历史中发现上述命令时，需要判断：

  • 是用户自发清理？ 普通用户偶尔会清理浏览器缓存，尤其是磁盘空间不足或浏览器异常时。
  • 是安全软件触发？ 某些安全软件或系统优化工具会自动调用清理命令。
  • 是攻击者主动抹痕？ 如果清理动作发生在入侵时间窗内，且和其他攻击动作紧邻，反取证概率极高。

判断要点：

  • 清理时间是否和入侵时间窗重合
  • 清理参数是否为"全部删除"（255 或 4351）
  • 清理动作是否紧跟在可疑下载或执行之后
  • 是否有多个浏览器痕迹同时被清理

3. 清理后的证据恢复

即便攻击者调用了 ClearMyTracksByProcess，以下证据可能仍然存在：

  • 浏览器 SQLite 数据库中的已删除记录（未被覆盖前可恢复）
  • 磁盘上的缓存文件碎片
  • Recent / LNK / Jump List 中的文件访问痕迹
  • Prefetch / Amcache 中的执行记录
  • 进程日志中的命令执行记录本身

也就是说，清理浏览器痕迹不等于抹掉了所有证据。攻击者清理的只是"浏览器层面的记录"，系统层面的行为痕迹往往还在。

0x05 浏览器劫持在应急中的定位

1. 浏览器劫持通常是独立问题

在大多数应急场景中，浏览器主页/搜索引擎被篡改属于：

  • 用户安装了捆绑软件
  • 访问了恶意站点被静默安装
  • 被钓鱼页面诱导安装了"工具栏"

这类问题通常不涉及高级入侵，更多属于 PUP（Potentially Unwanted Program）范畴。

2. 但有时也是入侵链的一环

在某些场景下，浏览器配置篡改可能是入侵链的一部分：

  • 攻击者通过浏览器漏洞植入后门
  • 恶意扩展窃取浏览器 Cookie 和 Session
  • 劫持器作为木马的附属组件被安装

此时浏览器配置异常就不只是"主页被改了"，而是：

  • 说明主机已被恶意软件获得执行权限
  • 可能有更深层的持久化或后门
  • 需要继续排查进程、服务、计划任务

3. 如何区分两种情况

关键判断标准：

  • 是否只有浏览器配置被改，还是同时有异常进程、服务、计划任务
  • 篡改的注册表键值是否关联到已知恶意 CLSID 或 DLL
  • 浏览器扩展/BHO 是否指向非系统目录的可疑文件
  • 是否有网络连接指向已知恶意域名

如果只有配置被改、没有其他异常，通常是 PUP。如果配置被改 + 异常进程/服务/连接同时存在，则应按完整入侵处理。

0x06 三个最容易误判的边界

1. 主页被改不等于主机被控

浏览器主页被篡改是最常见的"浏览器问题"，但它本身不能证明攻击者已经拿到主机控制权。很多劫持器只修改浏览器配置，不涉及系统层面的持久化或后门。

2. TypedURLs 中有可疑地址不等于已执行

TypedURLs 只说明用户输入过地址，不能说明：

  • 页面是否加载成功
  • 是否触发了下载
  • 下载的文件是否被执行

需要和 Downloads、进程日志、文件时间线交叉验证。

3. 痕迹被清理不等于攻击者所为

ClearMyTracksByProcess 或浏览器缓存被清空，可能是：

  • 用户自己清理的
  • 安全软件自动清理的
  • 系统优化工具触发的
  • 浏览器自动清理策略

必须结合时间窗和上下文判断，不能看到清理痕迹就写成"攻击者反取证"。

0x07 公开资料与分析借鉴

1. Wikipedia: Browser Hijacking

Wikipedia 关于浏览器劫持的条目系统梳理了已知劫持器家族和感染方式：

  • Conduit、Babylon Toolbar、Snap.do、istartsurf.com 等经典劫持器
  • 劫持器通常通过捆绑软件、恶意扩展、驱动下载传播
  • 部分劫持器包含间谍软件功能（键盘记录、凭据窃取）

最值得借鉴的一点是：浏览器劫持器不只是一个"配置修改"问题，部分家族同时具备间谍软件和广告软件特征，需要排查是否有更深层的持久化。

公开来源：

2. Malwarebytes: Browser Hijacker

Malwarebytes 的浏览器劫持器专题说明了：

  • 劫持器的主要感染途径（捆绑软件、恶意扩展、驱动下载）
  • 劫持器如何修改注册表实现持久化
  • 部分劫持器会修改注册表使得手动恢复困难

最值得借鉴的一点是：劫持器的持久化机制往往不止于修改主页设置，还可能通过 BHO、注册表键值、服务等多种方式保持存在。

公开来源：

3. NordLayer: What is Browsing Forensics

NordLayer 的浏览器取证文章说明了浏览器取证在企业安全中的定位：

  • 浏览器取证分析 Web 会话以检测攻击来源和性质
  • 浏览器 Artifact 包括书签、Cookie、访问站点、下载记录
  • 浏览器取证能检测会话劫持、凭据盗用等攻击

最值得借鉴的一点是：浏览器配置异常不应孤立分析，应和 Cookie、Session、下载记录等 Artifact 联合判断。

公开来源：

4. Elite Digital Forensics: Browser Forensics Explained

Elite Digital Forensics 的浏览器取证深度参考，清楚说明了浏览器证据的证明边界：

  • 浏览器 Artifact 通常只能证明"某个 Profile 在某个时间记录了某个 URL"
  • 不能自动证明"是谁在键盘前操作"
  • 强结论需要和 OS 层面的证据交叉验证
  • 下载 Artifact 在和文件系统元数据关联后证明力显著提升

最值得借鉴的一点是：浏览器配置检查和痕迹分析结论必须标注证据强度边界，不能过度推断。

公开来源：

0x08 建议的交付结构

浏览器配置异常与痕迹清理分析结果建议整理为如下表格：

检查项检查结果异常判断结论强度建议
HKLM Start Pagehttp://istartsurf.com主页被篡改中检查关联 BHO/扩展
HKCU Start Pagehttp://istartsurf.com用户级也被篡改中两处同时被改
Default_Search_URL正常搜索引擎未被改——
TypedURLs含 suspicious.example.com用户访问过可疑站弱需交叉验证下载/执行
BHO发现未知 CLSID可能存在持久化组件中到强提取 DLL 分析
进程日志ClearMyTracksByProcess 255浏览器痕迹被全部清理强结合时间窗判断性质
Chrome Preferencesstartup_urls 被策略修改组策略强制设置中检查策略来源

0x09 和其他分析篇怎样联动

本文最适合和以下专题联动：

  • 浏览器痕迹与下载执行链分析：提供下载执行链的完整还原方法
  • 浏览器下载与LNK和JumpList用户操作链分析：提供用户操作链的证据分层
  • 日志清理与反取证痕迹识别：提供痕迹清理动作的更广泛分析框架
  • 重点目录异常文件与落地载荷关联分析：提供浏览器劫持器落地文件的分析

本文的定位是聚焦 0x02 浏览器检查中"配置异常"和"痕迹清理"这两类特定结果，而不是覆盖整个浏览器取证领域。

0x0A 总结

浏览器配置异常与痕迹清理分析的关键，不是简单记录"主页被改了"或"缓存被清了"，而是回答：

  • 配置篡改是独立问题还是入侵链的一环
  • TypedURLs 中的可疑地址能支撑什么级别的结论
  • 痕迹清理是用户自发、安全软件触发，还是攻击者反取证
  • 浏览器层面的清理是否影响了系统层面的证据

当你能从 IE 注册表配置、TypedURLs、InetCpl.cpl 清理命令这些 0x02 检查结果中读出攻击意图和证据边界时，浏览器相关检查才真正从"配置信息查询"升级为 0x03 的"浏览器配置异常与痕迹清理分析"。