Wiz 智能体攻击研究识别出七项指纹，但归因仍有限制

Wiz 于 10 月 29 日发布研究，识别出智能体攻击的七项指纹，同时承认识别操作者依然困难。Wiz 的智能体攻击分析考察了涉及 AI 智能体的入侵；这类软件会使用模型来选择行动并操作工具。其核心矛盾在于可见性：可识别的行为可以帮助调查人员，但未必能可靠地确定攻击由谁控制。

Microsoft、CrowdStrike 和 Huntress 提供了有价值的参考点。它们的调查描述了不同类型的证据，从恢复的攻击者文件到客户身份验证记录。这些差异对于判断一起事件是否涉及自主执行、AI 辅助、传统脚本或几者的组合至关重要。

对于企业安全团队而言，眼前的压力来自运营层面。等待确定性的 AI 归因可能延误遏制，而将每一次自动化入侵都视为智能体攻击则可能扭曲优先级。实际问题在于，防御者能够多快识别未授权访问、关联相关活动并加以中断。

Wiz 智能体攻击研究将讨论转向可观察行为

这份报告的重要性在于其框架。它并未将 AI 的参与视为入侵发生后附加的标签，而是提出了调查人员可以检验的行为标准。这些标准为根据证据验证某种解释提供了起点。

有用的指纹能够支持调查；它不能取代攻击者实际达成结果的证据。

这种区分将安全分析与围绕术语的争论分隔开来。组织需要了解某个身份是否获得了未授权权限、凭证是否泄露，以及敏感记录是否被访问。确定相关软件则服务于一个相关但不同的目的。

可以考虑预警与结论之间的差异。一个异常序列或许足以启动调查，但并不能证明每个行动均由模型选择。调查人员可以同时保留两项判断：该活动值得关注，其运行机制仍不确定。

这在评估供应商研究时尤其相关。一份报告可以包含有价值的观察结果，同时对其更广泛解释留下未解问题。读者应区分底层记录与研究人员认为最可能的解释。

同样的严谨性也适用于“自主”一词。操作者可能批准一个目标、启动工具、审阅中间结果，并在其停滞时介入。将整个序列描述为自主，可能掩盖控制方式上的重要差异。

另一种做法是描述观察到的委托关系。软件是否选择目标、编写命令、解释错误，还是仅执行预先准备的列表？每种答案都对应不同的贡献，并对检测和响应产生不同影响。

这也改变了企业应向安全供应商提出的要求。关于识别 AI 的声明应有支持性示例、清晰的置信度表述，以及对替代解释的说明。即使攻击背后的模型未知，检测质量也应保持可评估性。

因此，相关比较在于自适应执行与防御者重建其过程的能力之间。传统自动化仍是该比较的一部分。它的存在并不排除工作流其他环节中存在模型。

模型可能协助生成随后独立运行的脚本。反过来，脚本也可能收集结果，供智能体决定下一步行动。客户日志未必会暴露这种分工。

对于采购方，这形成了一个直接的评估标准：询问产品是否能识别具有实质影响的未授权行为、解释其证据，并帮助响应人员采取行动。如果缺少这些能力，一个自信的 AI 标签意义不大。

七项指纹提供线索，而非裁决

• 持续迭代： Wiz 描述了变化中的、机器节奏的活动，其持续时间超出典型人工会话。持续时长有助于建立背景。

• 书面理由： 工具中包含对预期行动的解释。这类文本提供了另一种可供检验的工件。

• 自适应纠正： 后续尝试会在失败后改变。调查人员可以比较这些修订。

• 广泛覆盖： 活动系统性地探索不同技术。其序列能够揭示组织方式。

• 并行探索： 多条可能路径同时受到关注。这扩大了响应人员必须关联的证据范围。

• 执行前验证： 在关键行动之前进行初步检查，并采取旨在约束执行的措施。

• 一次性工件： 描述性的临时文件和识别痕迹，为暂存与记录管理提供线索。这些内容概括了 Wiz 的智能体攻击指纹。

• 它们的综合意义： 多项相互一致的观察结果比孤立的命名模式更能支持一种假设。任何单一指纹都不应自动决定归因。

• 与合法自动化的比较： 在评估类似行为时，应考虑获授权的测试和管理工具。背景决定一项行动是否恰当。

• 检测层面的含义： 智能体攻击检测应在行为线索之外，确认身份、权限、目标和后果。

• 误报问题： 检测器需要根据获许可活动进行评估。否则，看似敏感的检测可能增加调查负担，却无法改善决策。

• 缺失证据问题： 缺少某个工件并不能证明智能体不存在。调查人员应记录采集限制。

• 置信度问题： 报告应区分直接观察、推断关系和未解决的解释。这些类别有助于审查。

• 授权问题： 决定性问题仍然是某项行动是否超越权限。准确的模型标签无法单独回答这一问题。

• 证据保全问题： 保留原始记录，使后续发现能够修正评估，而无需改写初始证据。

• 适应性问题： 基于呈现方式的特征需要接受审视。其效用取决于改变呈现方式是否足以绕过它。

• 运营问题： 响应人员需要足够证据来中断有害活动，而不必先解决关于其作者的所有不确定性。

• 报告问题： 高管应获得关于受影响系统和已确认后果的清晰说明，同时了解所提出机制的置信度。

ARTEX 与 Hermes 案例说明为何证据必须保持区分

Zscaler 于 10 月 14 日发布的调查，将 ARTEX——一个用于协调 AI 辅助安全测试的框架——与针对韩国金融机构的攻击联系起来。报告称，个人信息失窃影响约 67,000 人。研究人员描述了对互联网暴露应用的利用，包括查询门户和移动应用后端。其对一个以经济利益为动机、使用中文的行为者的评估具有中等置信度。相关发现见其金融行业入侵分析。

共享同一框架并不能证明共享同一操作者、动机或结果。

CrowdStrike 于 10 月 7 日发布的分析提供了另一种证据视角。它描述了从攻击者控制的基础设施中恢复出的 ARTEX 配置文件、Claude Code 会话历史和记忆文件。这类工件提供了超出受害者环境内部活动记录的可见性。CrowdStrike 在其ARTEX 基础设施分析中，并未将该韩国行动归因于某个具名对手。

这种区分之所以重要，是因为工具名称可能成为过于方便的组织原则。分析人员可以为技术比较而对事件进行分组，而无需声称由同一组织实施。读者在比较新闻标题时应保持这种区分。

泰国案例涉及不同的框架和不同的限制。Hunt.io 报告称，恢复的日志显示，在针对泰国财政部的入侵期间，Hermes 在没有命令审批提示的情况下运行。其 7 月 23 日的发布内容描述了内部探索以及系统已遭入侵的证据。

Hunt.io 表示，初始访问方法尚不清楚。它也没有发现被检查的财政部文件被外泄的证据。这些限制与其Hermes 入侵调查中的技术观察结果相伴存在。

最后这一限定改变了公开叙述。攻击者搜索文件的证据支持开展访问调查，但其本身并不能证明这些文件离开了环境。同样，缺少外泄证据也不应被视为不可能发生窃取的断言。

这些案例展示了事件审查必须回答的不同问题。恢复的配置有助于识别工具；会话记录有助于解释执行过程；受害者记录有助于确定影响。一个类别的证据不能自动填补另一个类别中的缺口。

对于开发人员，实际相关性在于暴露应用周围的边界。仅审查应用本身，可能无法回答有关凭证及其可访问服务的问题。调查需要确认这些关系，而非仅凭推断。

对于知识工作者，问题在于这些关系背后的信息。文档库、客户门户或内部搜索服务代表着对实际记录的访问。AI 解释的价值部分取决于它是否阐明了这种暴露。

这些是独立报告的事件，各自拥有不同的证据。将它们最大的数字和最强烈的主张合并，会形成一个更戏剧化的故事，但会得出更不准确的评估。

ConnectWise 使现有应用信任面临压力

Microsoft 于 10 月 21 日发布的分析将 ConnectWise Cloud Backup 遭入侵事件归因于 Storm-0940，后者被描述为一个与中国国家利益一致的行为者。Microsoft 表示，ARTEX 加速了对已泄露应用凭证的滥用，并尝试登录超过 2,250 个 Microsoft 365 租户。租户是一个组织的 Microsoft 云环境。

该公司明确区分了尝试访问与已确认影响。受影响的应用，甚至成功的身份验证，并不必然证明客户数据已被访问或窃取。其发现描述了在ConnectWise 行动分析中对既有应用信任的滥用。

核心暴露在于，当应用凭证落入敌对之手时，该应用本已持有的权限。

这同时给客户和供应商带来压力。客户需要了解其环境中授予了哪些权限。供应商则需要说明支撑这种关系的凭据发生了什么。

AI 的分析意义在于访问获得后会发生什么。如果软件能够以更少的操作人员关注来评估机会并采取行动，响应流程就会面临不同的工作负载。这并不会消除最初的信任决策。

应用程序认证也需要提出与熟悉的员工登录调查不同的问题。是哪一个应用程序采取了行动？适用了哪些权限？谁拥有其凭据？随后发生了哪些变化？在评估偏离授权关系的行为之前，答案必须先识别该授权关系。

对企业买家而言，这些问题应纳入供应商评估。一份有用的保障说明应涵盖凭据控制、客户可见性、事件沟通和恢复责任。关于安全 AI 的笼统表述不能替代这些运营细节。

尝试访问与成功访问之间的区别尤其值得关注。尝试次数衡量的是目标锁定情况。认证记录则确立了另一个阶段。权限变更或数据访问的证据则确立了更多阶段。每个阶段都需要各自的佐证。

混淆这些阶段可能会以相反的方式误导决策者。夸大的失陷数字会扭曲事件的规模。过于狭隘地关注登录成功，则可能忽略需要单独调查的重要变更。

恢复也引入了另一条边界。恢复供应商服务回答的是可用性问题。确认未经授权的访问已经结束，回答的则是安全问题。即使调查存在重叠，客户也需要适用于这两方面的证据。

因此，临时中断可能需要作出运营决策，而不是简单地进行技术重置。组织必须在对服务的依赖程度与支持恢复的证据之间进行权衡。这一判断应遵循当前的事件响应指南。

Wiz 对 agentic attacks 的研究之所以属于这一讨论，是因为它将注意力聚焦于执行模式。ConnectWise 的事件则提供了一种具体的信任关系。二者结合，促使人们审视授权、检测和响应如何相互作用。

对采购而言，教训很明确。买家应询问如何检查并约束集成的权限，以及如何让异常使用行为变得可见。无论攻击者选择何种框架，这些问题都依然有用。

对 AI 攻击的归因仍不如对未经授权访问的判断确定

Huntress 为 ConnectWise 事件提供了一项重要限定。其调查人员表示，他们的遥测数据与 Microsoft 的发现一致，但并未独立确认 AI 的参与。仅依据客户记录，他们自身的评估置信度为低至中等。

他们描述了在不同运行之间发生变化的工具，以及在被定向的应用程序身份被删除后仍持续出现的请求。Huntress 无法看到攻击者的系统及其底层模型使用情况。因此，其攻击执行分析将脚本、操作人员干预和智能体视为相互重叠的可能性。

对 AI 是否参与存在不确定性，并不会否定未经授权活动的证据。

这是对过度自信解读这些指纹最有力的制衡。一连串行为可以支持智能体假设，同时仍与其他解释相容。恰当的做法是陈述相互竞争的解释，并说明哪些证据能够将它们区分开来。

经修订的工具可能反映模型生成的修正，也可能反映人工编辑代码或选择已有选项。观察到修订只能证明行为发生了变化；识别其作者还需要额外佐证。

在讨论推理时，这一区别尤为重要。日志可以显示某项行动发生在错误之后，但通常不会揭示该行动背后的完整决策过程。报道应避免将合理的因果解释写成已观察到的事实。

AI 攻击归因还包含彼此独立的归因问题：其一是模型是否存在，其二是所用框架，其三是指挥它的人或组织。某一层面的置信度并不会自动转移到其他层面。

恢复得到的配置文件可以加强对某个框架的识别，却不能证明是谁在操作它。熟悉的基础设施模式可以支持对行为主体的评估，却不能证明特定模型生成了相关命令。

这也是为什么 Wiz、Microsoft、CrowdStrike 和 Huntress 之间的比较应聚焦于它们的证据。它们观察到的是运营活动的不同部分。一致性可以强化一种解释，但反复归因至原始来源并不构成独立佐证。

商业激励同样值得考虑，但不应因此否定相关研究。安全供应商有理由强调新兴威胁及其响应能力。读者应将已发布的观察结果与产品主张分开评估。

一项有用的产品比较会询问，该系统是否解释其告警，并保留审查所需的记录。它还应明确其观察哪些环境，以及哪些环境仍处于视野之外。广泛的可见性主张需要具体的范围说明。

对事件负责人而言，沟通上的挑战是将置信度和紧迫性区分开来。团队可以对 AI 是否参与缺乏充分信心，同时仍有强有力的理由采取遏制措施。面向高管的报告应让这两种判断都易于理解。

反过来也同样重要。即使有强有力证据表明某个智能体参与其中，也不能证明数据窃取的范围。归因可能变得更清晰，而影响仍未得到确认。

因此，agentic attack 检测应支持一条决策链：确认行为、判断其是否获得授权、识别受影响的资源，并记录尚存的不确定性。当模型标签能够改善这条决策链时，它才有价值。

至 2027 年 1 月需要关注什么

下一阶段应通过公开证据和运营结果来判断。与更清晰地说明智能体控制了什么、以及防御者阻断了什么相比，更多以 AI 为主题的事件公告价值较低。

最有力的确认将连接攻击者侧的工件、受害者侧的活动，以及独立确认的后果。

第一个信号是跨这些证据类别的更强佐证。应关注那些将恢复的智能体记录与受害者环境中的已认证行动对应起来的调查。这种对应将有助于区分直接委派与 AI 辅助准备。

此类报道将加强智能体正在处理重要执行工作的论点。相反，若案例仅由速度或代码风格支撑，更广泛的归因问题仍无法解决。不断增长的事件数量无法弥补薄弱的证据基础。

第二个信号是可衡量的检测质量。应关注那些说明拟议指纹如何应对授权自动化的评估。合法的测试、管理和部署活动提供了必要的比较基准。

如果检测器能够识别有害活动，同时控制调查负担，就能强化防御价值。若一个系统主要识别注释、命名惯例或节奏，则应更狭义地理解其效用。

相关结果在于分析人员能否更快地作出正确决策。买家应寻找关于检测到了什么、告警附带了哪些上下文、以及后续采取了何种响应的证据。仅仅描述模型智能无法证明这一结果。

第三个信号是针对受损集成更清晰的恢复报告。应关注那些将供应商补救、客户调查、服务恢复和移除未经授权访问分开说明的披露。每个阶段回答的都是不同的运营问题。

有证据表明这些阶段得到记录和协调，将增强人们对响应准备度的信心。持续存在的模糊性将暴露治理问题，即使最初的入侵机制已被充分理解。

这些信号都与 Wiz agentic attacks 讨论中贯穿始终的同一张力有关：攻击者可以委派工作，而防御者仍需要可靠的上下文。安全价值来自让这些上下文能够转化为行动。

维护易于访问的决策记录有助于实现这一目标。团队需要保留自己掌握的信息、采取行动的原因，以及仍未解决的问题。可搜索的工程知识库可以与专用安全系统一道支持这类文档记录。

眼下应采取的行动是审查贵组织将如何评估类似披露。明确谁负责应用程序权限、谁能够调取相关记录，以及谁有权批准遏制措施。要求供应商区分尝试访问、成功认证、权限变更和已确认的数据窃取。在自身的事件沟通中也保留这些区别。将七项指纹作为调查提示，然后根据可获得的证据检验相关解释。当供应商声称其系统能够检测 agentic attacks 时，要求其提供示例，说明告警确认了什么，以及响应人员随后采取了什么行动。这项审查为评估准备度提供了一个具体起点，无需等待完美归因。