noahmurphx/clickfix-incident-response

# ClickFix 恶意软件事件响应 **个人硬件数字取证调查 · 2026年3月31日** 本文记录了我如何调查并验证针对我个人工作站的 ClickFix 社会工程攻击。Microsoft Defender 在恶意负载执行前进行了拦截；但我仍将此次警报视为完整安全事件，执行了完整的应急响应流程，并最终确认系统干净无残留。文章包含调查步骤、各阶段使用的工具、调查结果及经验总结。 ## 摘要 2026年3月31日下午3:39至3:41期间，Microsoft Defender 通过签名 `ClickFix.ZGA` 检测到三次执行尝试。这些尝试源于一个伪装成照片的压缩文件中的 ClickFix 诱饵，其中植入了恶意 PowerShell 命令。所有三次尝试均在代码执行前被拦截，状态显示为“已清除”。我没有停留在“杀毒软件已拦截”的表层判断，而是执行了完整的多工具验证：包括使用 Process Explorer 结合 VirusTotal 检查、审查 Autoruns 和计划任务、分析 PowerShell 脚本块日志、检查 %temp% 目录，并使用 Malwarebytes 进行二次扫描。最终结论：系统无持久化机制、无第二阶段执行、无出站连接。从始至终确认系统清洁。 ## 什么是 ClickFix ClickFix 是一种社会工程技术，它诱使受害者自行执行恶意命令，从而绕过通常能够拦截直接投递的浏览器和电子邮件保护机制。其经典变种使用伪造的 CAPTCHA 验证或浏览器更新页面，指示用户按下 `Win+R`，粘贴一个“验证”命令，然后回车。页面上的 JavaScript 会事先悄悄将恶意的 PowerShell 或 `mshta` 单行命令填充到剪贴板。 我遇到的变种使用了不同的诱饵载体：一个伪装成照片压缩包的 zip 文件，通过社会工程学引导用户右键点击文件夹并选择“在此处打开 PowerShell”。恶意文件被设计成通过 PowerShell 的工作目录上下文执行，实际负载通过后续命令拉取。Defender 在系统层面拦截了 PowerShell 的启动模式，在任何负载运行之前就阻止了它。 这种攻击之所以有效，是因为用户认为自己在遵循正常操作指南，而不是在运行攻击者的代码；该技术滥用的是用户对操作系统的信任，而非操作系统本身的漏洞。 ## 初始检测 **触发条件：** 2026年3月31日下午3:39至3:41期间，Microsoft Defender 警报 `Trojan:Win32/ClickFix.ZGA` 触发了三次。 **Defender 保护历史记录捕获信息：** - 两分钟窗口内发生了三次被阻止的执行尝试 - 每次尝试的命令行均为：`powershell.exe -noexit -WorkingDirectory C:\Users\Noah\OneDrive\Desktop\` - 状态：三次均为“已清除” **立即采取的行动：** 1. 停止与可疑文件的任何交互；没有关闭 PowerShell 窗口或点击任何提示框 2. 打开一份分类记录本，从此刻起为每个操作标注时间戳 3. 决定将此事件视为完整安全事件进行处理，即使 Defender 报告状态为“已清除”，因为三次重复的尝试表明这是活跃的攻击 staging 行为，而非单次意外触发 ## 调查流程 ### 阶段一：全面 Defender 扫描 首先进行最直接的检查：运行一次完整的 Defender 扫描，以确认初始行为拦截没有遗漏其他潜伏威胁。 **结果：** 清洁。除保护历史记录中已有的三次拦截外，未发现其他检测项或隔离项目。 ### 阶段二：检查 staging 位置的文件系统 检查了 ClickFix 负载通常存放中间文件的目录： - 审查了 `%temp%` 目录，查找在相关时间窗口内创建的 `.ps1`、`.vbs`、`.cmd` 和 `.bat` 文件 - 检查了桌面上的原始文件夹，查看是否有隐藏文件或最近修改的文件 - 检查了 `shell:startup` 启动文件夹，查看是否有新条目 **结果：** 在 `%temp%` 中未发现恶意脚本。启动文件夹清洁。只有原始压缩文件及其解压后的内容作为痕迹存在，这些文件已被隔离以供进一步分析。 ### 阶段三：进程遥测 **工具：** Process Explorer (Sysinternals)，并启用了 VirusTotal 集成。 在 VirusTotal 列可见的情况下遍历完整的进程树。Process Explorer 的 VT 集成会将进程哈希提交到 VirusTotal 并在界面内显示检测数量；这意味着我可以在不切换窗口的情况下审查每个运行进程是否具有已知恶意哈希。 **关注点：** - 孤立的 PowerShell 或 `mshta` 实例 - 运行在 `%TEMP%`、`%APPDATA%` 或 `%LOCALAPPDATA%` 下的进程 - 位于用户可写路径下的未签名二进制文件 - 任何进程的 VT 检测数大于零 **结果：** 所有运行进程的 VT 检测数均显示为 0/72 或接近零；所有路径均解析到预期位置（如 Program Files、System32、合法的用户已安装应用程序）；所有签名均有效。没有从 explorer.exe 或浏览器进程派生出可疑的子进程。 ### 阶段四：持久化机制审计 **工具：** Autoruns (Sysinternals) 和任务计划程序。 运行 Autoruns，并启用了“验证代码签名”和“隐藏 Microsoft 和 Windows 条目”以减少噪音。遍历了相关选项卡：登录项、计划任务、服务、WMI 和镜像劫持。 同时直接在图形界面中交叉检查任务计划程序，以确保 Autoruns 没有隐藏任何信息。 **结果：** 所有计划任务均指向合法来源：Adobe、Brave、Zoom、NVIDIA、OneDrive。在事件时间窗口内未创建新任务。未发现可疑的 Run 注册表键值、异常服务或 WMI 事件订阅。系统未显示任何已建立持久化机制的迹象。 ### 阶段五：PowerShell 脚本块日志 **工具：** 事件查看器，导航至 `应用程序和服务日志 > Microsoft > Windows > PowerShell > 操作`，筛选事件 ID 4104。 这是 ClickFix 调查的关键步骤：事件 ID 4104 会捕获反混淆后的脚本块内容，即使原始命令是 Base64 编码或压缩过的。如果有任何代码执行，这里将是证据出现的地方。 **结果：** 在相关时间窗口内，唯一的事件 ID 4104 条目是调用 `RNGCryptoServiceProvider` 的安全密码生成器函数的合法操作，与我的密码管理器的正常运行一致。未发现可疑的脚本块、编码负载或网络连接命令。 没有任何恶意的 4104 事件是 payload 从未突破 Defender 拦截的最有力证明。 ### 阶段六：独立的二次扫描 运行 Malwarebytes 免费版进行交叉引擎验证检查，因为依赖单一杀毒软件在真实攻击尝试后的“一切正常”报告是一个已知的盲点。 **安装前验证：** 在运行 Malwarebytes 安装程序前，验证了其哈希值。 - SHA-256: `AFC772D7ECAC253595759055B552B14B86A1E11A8541CFEFA11D4060B9470824` - VirusTotal: 0/72 检测 - 数字签名：颁发给 Malwarebytes Inc.，有效 **结果：** 全盘扫描清洁。扫描完成后卸载了 Malwarebytes，因为我希望只保留 Defender 作为唯一的常驻端点保护。 ### 阶段七：网络活动验证 这一步旨在回答“是否有任何进程向外发送信息？”的核心问题。 我运行了一个首次出站连接警报应用程序，它会标记任何首次进行出站网络连接的进程。我还有一个流量小部件，可以实时显示入站和出站网络流量，以及 CPU 和内存使用率。 **结果：** 在事件时间窗口内，没有触发任何首次出站连接警报。流量小部件未显示异常波动。这是整个调查中第二令人安心的数据点，仅次于干净的 4104 日志。 ## 调查结果总结 恶意负载在行为检测层被拦截，未能执行任何代码。未建立持久化机制。没有任何恶意进程尝试进行出站连接。除原始的诱饵文件（已被隔离和删除）外，未留下任何痕迹。 记录的信息如下： - 检测时间：2026年3月31日下午3:39至3:41 - 检测签名：`Trojan:Win32/ClickFix.ZGA` - 被拦截尝试次数：3 - 建立的持久化机制：无 - 出站连接：无 - 使用的验证方法：7种 ## 入侵指标 | 类型 | 值 | 备注 | |------|-------|-------| | 签名 | `Trogan:Win32/ClickFix.ZGA` | Defender 行为检测 | | 命令 | `powershell.exe -noexit -WorkingDirectory C:\Users\Noah\OneDrive\Desktop\` | Defender 捕获并拦截的命令行 | | 载体 | 伪装成照片的 zip 文件，配合社会工程学诱导在文件夹中打开 PowerShell | 非标准的 ClickFix 诱饵载体 | | 时间 | 2026-03-31 15:39 至 15:41 本地时间 | 窗口期内三次拦截尝试 | ## 我会做出哪些不同 从本次调查中我总结了几点改进措施，以增强未来的安全态势： **在系统范围内启用 PowerShell 脚本块日志记录，而不仅仅是默认的“操作”日志。** 完整的脚本块日志会捕获每个脚本块，而不仅仅是 Windows 标记为可疑的那些。我已通过注册表启用了此功能，这样未来的调查将拥有完整的覆盖范围，而不再依赖默认的子集。 **“信任但验证 Defender”的直觉得到了回报。** Defender 的保护历史记录显示“已清除”；这可以作为调查的起点，但不应是终点。对一个“已拦截”的警报执行完整的应急响应流程，能够发现可能在初始拦截后悄悄成功的第二阶段负载，并且无论结果如何，都能生成一份可追溯的记录。 **独立的检测层物有所值。** 首次出站连接警报器给了我一个完全独立于 Defender 和杀毒扫描器的第二信号。如果有任何进程向外通信，即使所有基于签名的工具都遗漏了它，该应用程序也会发出警报。使用不同方法论的分层检测，是避免盲点的关键。 **在调查过程中记录，而非事后回忆。** 响应过程中的带时间戳记录使得撰写报告成为可能；若试图几天后凭记忆重构，会丢失最清晰的细节。这是我愿意不加修改地带入安全运营中心角色的习惯。 ## 使用的工具 | 工具 | 用途 | |------|---------| | Microsoft Defender | 初始检测、保护历史记录审查、全面扫描验证 | | Process Explorer (Sysinternals) | 进程树分析，集成 VirusTotal | | Autoruns (Sysinternals) | 持久化机制审计 | | 任务计划程序 | 直接审查计划任务 | | 事件查看器 | 分析 PowerShell 事件 ID 4104 脚本块日志 | | Malwarebytes Free | 独立的二次全面扫描 | | VirusTotal | 验证安装程序和进程二进制文件的哈希 | | 首次出站连接警报器 | 独立的网络异常信号源 | ## 参考文献 - [Microsoft Defender PowerShell 日志记录文档](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows) - [Sysinternals 工具套件](https://learn.microsoft.com/en-us/sysinternals/) - [Microsoft 关于 ClickFix 的威胁情报](https://www.microsoft.com/en-us/security/blog/) *个人事件响应报告。调查于2026年3月31日在个人拥有硬件上进行。文档在调查过程中同步编写，并为作品集用途进行了润色。*

标签：AI合规, 域环境安全