ClickFix攻击深度剖析：从虚假验证码到系统沦陷的完整攻击链

原创

于 2026-07-03 16:16:16 发布 · 494 阅读

1. 攻击手法深度剖析：从虚假验证码到系统沦陷

最近安全圈里讨论得比较多的一个事儿，就是所谓的“ClickFix”攻击又玩出了新花样。这次不再是简单地弹个假窗口让你点“确定”，而是把微软自家签名的正经工具给拖下水，结合了Google日历这种我们天天用的服务，搞了一套相当隐蔽的传播链。我花了不少时间研究相关的报告和样本，感觉这波操作确实体现了当前攻击手法的一些新趋势：滥用合法工具（Living-off-the-Land Binaries, LOLBins）和可信第三方服务（Trusted Third-Party Services），把攻击痕迹藏得越来越深。咱们今天就掰开揉碎了讲讲，这种攻击到底是怎么一步步把你系统里的秘密给偷走的。

简单来说，整个攻击链可以看作一场精心设计的“闯关游戏”。攻击者的目标不是暴力破门，而是骗过门卫（用户），利用大楼里本身就有的工具（微软脚本），去仓库（你的电脑）里取走宝藏（敏感信息）。它最大的特点就是“看起来很正常”。每一步都尽量贴合正常的用户操作或系统行为，让传统的基于签名或简单行为分析的防御手段很难生效。

1.1 攻击的起点：那个似曾相识的“验证码”

一切始于一个你很可能在网上见过无数次的场景：一个弹窗，告诉你需要完成验证码才能继续访问某个内容或下载某个资源。这就是“ClickFix”攻击的经典开场。攻击者会伪造一个看起来非常逼真的验证码确认框，通常嵌入在钓鱼网站、被黑的广告网络，甚至是经过SEO投毒（搜索引擎优化投毒）后排在搜索结果前列的恶意页面里。

这个虚假验证码的“高明”之处在于它的交互设计。它不会让你直接在网页里输入，而是会“提示”你： “请复制下方代码，并粘贴到Windows运行对话框（Win+R）中执行以完成验证。” 旁边会提供一个长长的、看起来像是一串命令的文本。这个设计巧妙地利用了用户的两个心理：一是对“验证”流程的习以为常，二是对“运行对话框”这个系统自带工具的信任。用户会觉得：“哦，这是系统级的验证，应该没问题。” 于是，大多数人会不假思索地复制那串命令，按下Win+R，粘贴，回车。

注意： 这是整个攻击链中唯一需要用户手动操作的环节，也是防御的第一个关键点。任何要求你将不明代码复制到运行对话框、命令提示符或PowerShell中的“验证”请求，都极有可能是恶意攻击。正规的网页验证码绝不会要求你进行这样的系统级操作。

那串被复制的命令，就是打开潘多拉魔盒的钥匙。传统的ClickFix攻击，这串命令可能直接就是 powershell -c “一串恶意代码” 。但安全软件对直接调用 powershell.exe 并执行编码命令的行为已经盯得很紧了。所以，攻击者升级了。

1.2 核心诡计：披着“微软签名”外衣的执行代理

这次攻击最核心的升级点，就在于它没有直接调用PowerShell。用户粘贴并执行的那条命令，看起来大概是这样的：

wscript.exe “C:\Windows\System32\SyncAppvPublishingServer.vbs” “/RefreshServerPolicy” “|” “powershell -w hidden -c 恶意代码”

我们来拆解一下这条命令的“合法”外衣：

wscript.exe ：这是Windows系统自带的、用于运行VBScript脚本的合法解释器。它的出现本身不会引起任何警报。
SyncAppvPublishingServer.vbs ：这是关键。这个Visual Basic脚本文件是微软Application Virtualization（App-V）客户端组件的一部分，位于系统目录下，并且拥有微软的数字签名。App-V是一种应用虚拟化技术，在企业环境中用于集中管理和部署软件。这个脚本的正常功能是刷新App-V的服务器发布策略。 因为它有微软签名，且是系统原生文件，绝大多数安全软件会将其视为高度可信的进程。
参数 /RefreshServerPolicy ：这是该VBScript脚本的一个合法命令行参数，用于触发策略刷新操作。

问题出在后面的部分。攻击者利用了 SyncAppvPublishingServer.vbs 脚本的一个设计特性（或者说漏洞）：它在处理某些参数时，可能会将后续的输入错误地解析并传递给其他执行引擎。在上面的恶意命令中， “|” 之后的内容被“注入”了。

实际发生了什么？ 当 wscript.exe 加载这个签名的VBScript时，脚本本身会开始执行。但由于参数被精心构造，脚本的执行逻辑被引导去调用 ShellExecute 或类似的函数，而调用内容正是 “|” 之后的那段字符串。由于管道符 | 在命令行中的特殊含义，或者脚本本身对参数的拼接处理存在缺陷，导致 powershell -w hidden -c 恶意代码 这部分被当作一个新的命令执行了。

这样一来，从进程链上看，父进程是 wscript.exe ，它加载了一个微软签名的VBScript。然后由这个“可信”的脚本进程，去创建了 powershell.exe 子进程。对于许多只监控直接由用户或可疑父进程启动的PowerShell实例的安全产品来说，这种通过“清白”的、签名的系统组件发起的调用，其可疑程度会大大降低。这就是典型的“离地攻击”（Living off the Land）手法，也是ATT&CK框架中 T1218.005 - Signed Binary Proxy Execution: Mshta 和 T1059.001 - Command and Scripting Interpreter: PowerShell 两种技术的结合运用。

实操心得： 在威胁狩猎或事件响应中，不能只看PowerShell本身是否被调用，更要看它的父进程是谁。一个由 svchost.exe 、 wscript.exe 、 cscript.exe 、 mshta.exe 或者微软签名的各类 *.vbs 、 *.js 脚本启动的PowerShell，尤其当其命令行包含隐藏窗口( -w hidden )、编码命令( -EncodedCommand )或从网络下载执行( -c IEX (New-Object Net.WebClient).DownloadString() )等参数时，必须视为高度可疑事件进行深入调查。