品牌即诱饵：攻击者如何利用 AI 工具信任发动攻击

多年来，安全团队一直教导员工如何识别可疑软件、避开恶意链接、质疑陌生网站。但 2026 年观察到的两大威胁活动预示着：下一场安全挑战将截然不同。攻击者不再需要用户直接信任自己，他们只需要用户信任所冒充的品牌。

被标记为 Google Chrome AI（W17） 与 InstallFix / Claude Code（W20） 的两个威胁活动，技术层面截然不同：一个源自合法浏览器行为意外引发的安全与运维挑战，另一个则利用付费搜索结果和仿冒文档页面入侵开发者。但两者遵循同一底层逻辑 ——对 AI 工具的信任，已经成为攻击面。

生成式 AI 在企业环境中的落地速度，已远超管理其安装、配置与监控策略的制定速度。由此，企业正暴露在传统安全控制手段无法覆盖的风险之中。

Log360 （EventLog Analyzer）内部入侵与攻击模拟（BAS）团队已针对这两个活动开发并测试了相应检测规则。本文将从技术细节、战略关联以及安全团队可落地的缓解措施三个维度，逐一拆解。

一、W17 – Google Chrome AI：当可信软件表现出 "持久化" 行为

多数威胁活动依赖攻击者植入恶意代码或利用漏洞获取系统权限。W17 则完全不同：它展示了合法软件行为如何无意间创造出类似攻击者持久化技术（Persistence）的条件。

2026 年初，谷歌 Chrome 开始向启用该功能的终端下载 Gemini Nano—— 谷歌的端侧语言模型。该模型约 4GB 大小，存储于以下路径：

%LOCALAPPDATA%\Google\Chrome\User Data\OptGuideOnDeviceModel\weights.bin

对多数企业而言，最直接的担忧来自运维层面而非安全层面：数千台终端大规模下载 4GB 模型，将带来显著的带宽与存储压力，尤其当企业完全不知情时。在某些司法管辖区，该行为还可能引发终端存储授权与软件治理合规方面的疑问。

真正棘手的挑战出现在修复环节。 仅删除 weights.bin 文件无法阻止模型回归 ——Chrome 会把文件缺失视为需要修复的状态，除非先修改底层策略配置，否则浏览器会在后续启动时自动恢复该文件。从防御者视角看，这与恶意软件中常见的持久化模式高度相似：受信任的进程恢复管理员主动删除的组件。

另一个次级隐患是配置管理。Chrome 的端侧 AI 能力由以下设置控制：

Local State 文件中的 optimization‑guide‑on‑device‑model 配置；

注册表项 GenAILocalFoundationalModelSettings（位于 HKLM\SOFTWARE\Policies\Google\Chrome）。

当这些设置缺失或配置错误时，企业可能在不知情的情况下启用未经正式审批或治理的 AI 能力。安全团队往往紧盯可执行文件与浏览器扩展，却很少以同等审查力度监控浏览器策略变更。

从 MITRE ATT&CK® 视角看，该行为主要映射 T1105（Ingress Tool Transfer，工具传输） 与 T1112（Modify Registry，修改注册表）。 W17 的启示并非 Chrome 存在恶意行为，而是：合法软件同样可能产生与攻击者手法相似的行为，因此应当获得同等级的可见性与治理关注。

Log360 （EventLog Analyzer）检测方案 – W17

Log360（EventLog Analyzer） 已部署 5 条检测规则，覆盖 Chrome AI 部署全生命周期：

Gemini Nano 模型文件的创建；

来自谷歌 AI 基础设施的大规模下载；

缺失或配置错误的策略设置；

模型删除后的重新下载；

AI 相关配置设置的异常修改。

其中最具运维价值的检测关联：weights.bin 被删除后在同一主机上被重新创建。这一序列提供了强有力证据，表明浏览器本身正在逆转安全团队的修复动作。 另一条实用的早期预警指标：在模型落盘前，监控与谷歌 AI 内容分发基础设施的网络通信，让安全团队能够在攻击链条更早阶段识别该活动。

注：本文引用的覆盖率统计，基于 2026 年 5 月对选定 SIEM 平台默认检测内容的内部 BAS 测试结果。

修复建议（W17）

组织应先部署 GenAILocalFoundationalModelSettings 策略，再尝试删除已下载的模型文件。若策略未先行生效，仅删除文件只会导致模型在后续浏览器启动时被恢复；

建议安全团队同步监控浏览器策略变更，审查端侧 AI 能力是否符合企业策略，并确保 Sysmon、Windows 安全日志等端点遥测已启用，以支撑后续调查取证。

二、W20 – InstallFix / Claude Code：武器化开发者工作流惯例

如果说 W17 聚焦浏览器行为，W20 则瞄准企业环境的另一层：开发者工作流。

该活动由趋势科技于 2026 年 5 月公开记录，利用的正是许多开发者习以为常的习惯 ——直接从文档页面复制安装命令、不经逐行检查便直接执行。

攻击者购买了针对 "Claude Code install" 等搜索词条的付费搜索广告。点击广告的用户会被引导至与 Anthropic 官方文档高度相似的仿冒页面 —— 品牌标识、导航结构、安装说明一应俱全。唯一有实质差异的，是安装命令本身：它从攻击者控制的基础设施中拉取代码。

与传统 ClickFix 攻击不同，W20 没有伪造浏览器报错、虚假验证码或欺骗性警告来诱导用户操作。受害者自身安装合法软件的意图，本身就是社会工程机制。

其感染链在技术上相当精巧：

mshta.exe → cmd.exe（/v:on，启用延迟变量扩展） → SysWOW64 powershell.exe（‑EncodedCommand，编码命令） → C2 回连

载荷执行流程：检索 ZIP/HTA 双格式文件 → 利用延迟变量扩展重建 PowerShell 命令 → 启动 32 位 PowerShell 规避部分 AMSI 实现 → 受害者主机指纹识别 → 禁用 SSL 证书校验 → 内存中修补 AMSI → 最终与受害者专属的命令与控制（C2）基础设施通信。

最终载荷已关联 RedLine 窃密木马活动，主要窃取浏览器凭据、会话令牌与加密货币钱包。该活动已在多个地区被观测到，政府、教育、科技行业均有组织受影响。

从检测视角看，进程血缘链（Process Lineage）本身就是攻击的行为特征。

MITRE ATT&CK 覆盖的技术包括：

T1218.005 – 系统二进制代理执行：Mshta

T1059.005 – Visual Basic

T1059.003 – Windows 命令 Shell

T1059.001 – PowerShell

T1562.001 – 削弱防御机制

T1071.001 – Web 协议

Log360 （EventLog Analyzer）检测方案 – W20

Log360 （EventLog Analyzer）的 BAS 团队已部署 4 条检测规则：

通过 mshta.exe 进行远程载荷检索；

通过 cmd.exe 进行延迟命令扩展；

编码 PowerShell 执行与 AMSI 绕过活动；

与已知恶意基础设施的通信。

其中两条关联链对 SOC（安全运营中心）团队尤其实用：

第一条关联完整进程链，触发后应立即执行主机隔离、凭据审查与事件响应；

第二条关联初始载荷检索与 C2 通信，即便中间阶段被遗漏，也可能提供充分的失陷证据。

注：本文引用的覆盖率统计，基于 2026 年 5 月对选定 SIEM 平台默认检测内容的内部 BAS 测试结果。

修复建议（W20）

在运维可行的前提下，限制 mshta.exe 的网络访问，并阻止其生成子进程；

开发者工作流同样值得更严格的审查。安全团队应围绕 "安装命令允许从哪些来源获取" 建立明确指引；

确保启用 PowerShell 与进程创建日志记录，以支撑检测与调查。

三、信任利用原语：两大活动的共同底层逻辑

乍看之下，W17 与 W20 是完全不同的活动：一个源于合法浏览器行为，另一个源于恶意广告；一个在后台静默运行，另一个依赖用户显式操作；一个广泛影响企业终端，另一个精准锁定开发者。

连接二者的，是信任。

W17 利用的是用户与管理员对浏览器的信任，以及 "可信软件只会按管理预期运行" 的假设；

W20 利用的是开发者对熟悉文档与长期形成安装工作流的信任。

两个活动成功，都不是因为用户疏忽大意。它们之所以得逞，是因为被利用的信任本身是正当的，是在多年与广泛采用的软件品牌和熟悉工作流的交互中逐步建立的。

这是安全团队应当铭记的更深层教训：AI 正在浏览器、IDE、开发者工具与企业应用中加速普及，但围绕这些技术的治理仍处于成熟过程中。因此，每一个品牌认知度高、工作流成熟且被广泛采用的 AI 产品，都可能成为被冒充的目标。

攻击的交付机制会随活动不断变化 —— 今天是浏览器下载或付费搜索结果，明天可能是 IDE 插件、GitHub Action 或 AI 代理市场。但底层利用方式始终如一：攻击者越来越擅长攻击用户对 AI 工具的信任。

四、安全团队现在应该做什么

针对 W17：

先部署 Chrome AI 策略，再移除已下载的模型文件；

监控浏览器策略变更；

跟踪大型 AI 模型下载行为；

确保所需端点遥测已启用。

针对 W20：

限制 mshta.exe 网络访问、阻止其生成子进程；

启用 PowerShell Script Block Logging（脚本块日志记录）；

围绕开发者软件安装实践建立明确指引。

更宏观的视角： 两大活动暴露的并非纯粹的技术问题，而是治理缺口。大多数组织在软件安装、浏览器扩展、端点安全控制方面已具备成熟策略，但极少有组织建立针对 AI 工具的治理策略 —— 包括：哪些 AI 工具被批准使用、允许如何安装、允许哪些配置、应采集哪些遥测数据。

解决这些问题，可能比任何单条检测规则都更有效。

五、Log360 （EventLog Analyzer）现已提供检测能力

Log360 （EventLog Analyzer）针对 W17 与 W20 的检测规则已完成实验室验证，现已可用。组织在依赖这些检测之前，应先确认所需端点与审计遥测已启用。

这两大活动带来的最大启示，不是 AI 工具本身存在固有风险，而是：信任本身正成为攻击者越来越看重的目标。安全团队花了多年时间教导用户不要信任未知软件与可疑网站，而下一场挑战，是认清即使是熟悉且合规的 AI 品牌，也可能被用作滥用的载体。

在 AI 时代，攻击者不需要用户信任自己，他们只需要用户信任自己所模仿的品牌。

常见问题（FAQs）

  1. Log360检测W17威胁是否必须部署Sysmon端点日志采集？

    建议部署Sysmon，可完整捕获文件创建删除、注册表修改、网络通信行为；仅依靠Windows原生日志会丢失部分关键行为证据，影响W17检测链完整性。

  2. Log360针对W20攻击可以直接阻断mshta.exe恶意行为吗？

    Log360主要完成威胁检测、告警、事件链还原；阻断操作依靠端点安全组策略，可将告警联动推送至EDR/防火墙执行隔离处置。

  3. Log360的BAS模拟攻击测试可以复现W17、W20这两类威胁吗？

    BAS模块可以对W17、W20攻击行为做模拟验证，用来校验当前环境日志遥测是否齐全、检测规则是否生效。

相关文章推荐