文章总结： EDRkiller已成为勒索软件攻击标准配置，攻击者利用漏洞驱动程序等技术禁用安全软件。AI工具密集使用导致员工认知负担和职业倦怠。AI智能体面临提示注入等安全挑战，需采用多层次防御体系，包括威胁建模、沙箱隔离、权限最小化、实时防御层和持续对抗性测试。企业应主动监控权限提升和驱动程序安装阶段，并完善人才分析措施防范AI脑力透支。 综合评分： 88 文章分类： 威胁情报,AI安全,安全建设,安全运营,漏洞分析

---

EDR killer已成为勒索软件攻击的标准配置

原创

HelpNetSecurity HelpNetSecurity

安全行者老霍

2026年3月25日 09:01 北京

写在前：本文包括四篇文章

• EDR killer已成为勒索软件攻击的标准配置
• AI工具越多，职业倦怠越严重！最新研究揭示了原因
• 构建信任：自主AI智能体的安全蓝图
• 人工智能已从助手转变为自主行为体，而安全措施却始终未能跟上

EDR killer已成为勒索软件攻击的标准配置

作者：Anamarija Pogorelec

发布时间：2026年3月19日

勒索软件攻击者通常会在启动加密程序之前，部署专门用于禁用端点检测与响应（EDR）软件的工具。这些被称为“EDR 杀手（killer）”的工具，已成为勒索软件入侵的标准组成部分。ESET研究团队追踪到了近90种在实际攻击中被广泛使用的EDR killer。

各攻击团伙的工作流程如出一辙：攻击者获取高权限，部署EDA 杀手来破坏安全软件，随后运行加密程序。团伙成员青睐这种方法，因为它能提供一个短暂且可靠的窗口期来完成加密，而无需不断修改有效载荷以规避检测。

1. 分支机构选择工具，运营商提供加密程序

在勒索软件即服务（RaaS）运营中，服务运营商通常提供加密程序和配套基础设施。而EDR kilelr工具的选择则由分支机构负责。据ESET研究员Jakub Souček称，结果是分支机构数量越多，EDR杀手工具的种类就越丰富。

这种分工也意味着，根据具体攻击由哪个分支机构实施，防御者将面临来自同一勒索软件品牌的更广泛工具组合。

2. “自带漏洞驱动程序”技术占主导，替代方案正逐渐兴起

“自带漏洞驱动程序”技术仍是当前最常见的方法。攻击者将一个合法但存在漏洞的驱动程序植入受害者机器，安装后运行恶意软件，利用该驱动程序的漏洞获取内核级访问权限。该技术可靠、文献丰富，且开发工作量相对较小。

另一类规模较小但正在增长的EDR杀手工具，无需触及内核即可实现类似效果。这些工具通过干扰EDR通信或直接挂起进程，完全绕过了利用驱动程序的必要性。

最简单的EDR杀手工具依赖于内置的管理工具和命令，完全不需要专用驱动程序或内核访问权限。

3. 阻止易受攻击的驱动程序是必要的，但还不够

阻止易受攻击的驱动程序加载是一项重要的防御措施，尽管存在多种绕过技术。其实际意义在于，组织需要具备在EDR杀手有机会加载驱动程序之前就将其扼杀在萌芽状态的控制措施。

4. AI辅助开发正逐渐浮出水面

根据ESET的评估，至少部分近期观察到的EDR杀手显示出AI辅助代码生成的迹象。目前尚无确凿的取证标记能可靠地区分AI生成的代码与人工编写的代码，尤其当攻击者对其输出进行混淆或后处理时。

一个具体的例子来自Warlock勒索软件团伙部署的一款工具。该工具包含一段代码，会列出可能的修复方案，这是一种与AI生成的模板代码相关的模式。它还实现了一种试错机制，会循环尝试多个互不相关且常被滥用的设备名称，直到找到一个在目标系统上有效的，而不是利用单一的特定驱动程序。

Souček指出，这种“氛围编码”使得威胁态势的追踪和归因变得更加复杂。

5. 应对勒索软件入侵需要不同的防御策略

一旦安全解决方案成功遏制，网络钓鱼活动和通用恶意软件便会停止。但勒索软件入侵并不遵循这一模式。它们是交互式的人工驱动操作，攻击者会持续适应检测机制、工具故障及环境条件的变化。

这一区别对防御方如何分配资源优先级及设计检测策略至关重要。特别是针对EDR杀手活动，必须在权限提升和驱动程序安装阶段–即加密程序部署之前–就进行主动监控。

EDR killers are now standard equipment in ransomware attacks

AI工具越多，职业倦怠越严重！最新研究揭示了原因

作者：Anamarija Pogorelec

发布时间：2026年3月9日

围绕多个AI智能体构建的工作流程以及频繁切换工具，正在给大型企业员工带来认知负担。近期《哈佛商业评论》的一篇分析将这种现象描述为“AI脑力透支”，即因密集使用和监管AI系统而引发的一种精神疲劳。

员工越来越多地需要管理成群的AI智能体，这些智能体以极高的速度生成代码、整合信息并产出草稿。某些组织的绩效体系会奖励诸如令牌消耗量和AI产出量等活动指标。这种机制迫使员工在同一个工作日内监控更多的系统和成果。

按行业角色划分的员工报告的AI脑力透支情况（来源：《哈佛商业评论》）

研究劳动力与AI趋势的学者对来自各行业、不同岗位及职级的大型企业全职员工进行了调查。受访者详细描述了AI使用模式、工作体验，以及与这些工作流程相关的认知和情绪状态。

参与者描述了在长时间监督AI系统后出现的“嗡嗡作响”感、思维模糊、难以集中注意力、决策迟缓以及头痛等症状。研究人员将“AI脑力透支”定义为因过度使用或监督AI工具，超出个人认知能力所导致的心理疲劳。

需要持续监控AI系统的岗位对精神投入的要求更高，从而引发更严重的疲劳和信息过载。表示AI工具增加了工作量的员工也报告了更重的认知负担。监督需求与新增职责相结合，扩大了员工在工作日需要追踪的任务范围。

同时使用的工具数量也影响着结果。使用少量AI工具与生产力提升呈正相关，而增加工具数量则会削弱这种提升。这一规律反映了多任务处理和注意力的局限性。

1. 不同岗位的普遍程度各异

研究人员询问参与者是否曾因密集使用AI而经历过精神疲劳。部分依赖AI的员工报告了这种经历。

法律岗位的报告率最低，营销岗位最高。相较于其他职能部门，人力资源、运营、工程、财务和IT部门的报告率也较高。

参与者经常使用“脑雾”和“嗡嗡作响”等词汇。他们描述了与AI工具进行长时间的往来交互后，出现思维混乱、决策迟缓，以及需要远离屏幕以重置状态的情况。

一位高级工程经理描述了同时使用多种工具来权衡技术决策、生成草稿和汇总信息的情形。不断的切换和核查造成了思维混乱。精力从解决核心问题转移到了管理工具上。

一位财务总监描述了长时间借助AI进行起草和综合整理，结果导致无法判断输出内容是否合理。工作被迫暂停，直到第二天恢复专注力后才继续。

这些案例反映了与认知压力相关的信息过载和任务切换模式。密集的人工智能监督进一步加重了这种负担。

2. 可量化的商业成本

与“AI脑力透支”相关的认知压力会产生运营影响。报告出现该状况的员工还表示决策疲劳程度更高，这意味着可用于做出高质量决策的脑力资源更少。

错误发生频率增加。经历“AI脑力透支”的参与者报告称，他们不仅犯了更多易于纠正的小错误，还犯了更多可能影响安全、结果或重大决策的严重错误。

员工留任信号也发生了变化。报告“AI脑力透支”的员工更倾向于表达离职意愿。许多最密集使用AI的员工属于组织亟需留住的高绩效人才群体。

3. AI 减轻压力的领域

AI 的使用因任务而异，那些利用 AI 减少常规和重复性工作时间的员工报告的倦怠程度较低。将重复性任务移交出去，为创造性工作、协作以及更高价值的任务创造了更多空间。

团队支持和领导力影响了精神疲劳程度。当管理者抽出时间回答关于 AI 的问题时，员工报告的精神疲劳感较轻。将 AI 整合到共享工作流程中的团队，其压力比个人独立采用工具的团队更小。

组织信号塑造了使用体验。认为公司期望借助AI提高产出的员工报告的疲劳感更强；而认为组织重视工作与生活平衡的员工则报告的压力较小。关于AI如何融入日常工作的指导，有效减轻了各团队的认知压力。

研究人员总结道：“组织应完善人才分析措施，以监测整体认知负荷，并将与AI使用相关的心理疲劳视为一种新型工作风险加以防范。”

More AI tools, more burnout! New research explains why

构建信任：自主AI智能体的安全蓝图

作者：Vaibhav Agrawal，谷歌高级安全工程师

发布时间：2026年3月5日

AI智能体已从单纯的聊天机器人（仅回答问题）演变为能够利用各种集成工具执行操作的系统，且往往具有自主性，因此传统的安全模型已不再有效。作为Fitbit个人健康教练的安全负责人，我对此深有体会。

试想一个能够代表用户访问或更新健康记录的智能体。只需在网页中隐藏一条恶意指令（该智能体在处理该网页时会执行该指令），便可能操控该智能体执行非预期的操作，或泄露敏感的健康数据。

在医疗或金融等高风险行业，容错空间极小甚至为零。因此，我认为保障这些AI智能体的安全需要采取多层次的方法，类似于我们在安全领域构建的深度防御体系。本文将探讨这种方法。

1. 智能体风险主要存在于应用层

许多AI安全框架在AI智能体的安全问题上具有共性。它们提供风险管控建议，既包括宏观的战略视角，也涵盖针对性的技术控制措施。这些框架通常将AI威胁分为数据、基础设施、模型和应用四大类。

应用层是智能体风险最集中的领域。其中一种风险是提示词注入。这本身并非风险，但提示词的处理方式可能危及智能体、用户数据或底层系统。

当数据源自不可信来源时，例如基于 RAG（检索增强生成）的系统，这一问题会进一步加剧。隐藏在网页或文档中的恶意指令可能被作为上下文摄入并被视为可信输入，从而导致间接提示注入。

2. 面向 AI 智能体的“安全设计”蓝图

作为多层次防护策略的第一步，组织应在开发生命周期的早期阶段，为智能智能体采用对抗性威胁模型。可利用Maestro等智能体威胁建模框架。

该模型通过确立安全设计原则，可作为工程和安全团队的技术架构路线图，例如：

运行代码的智能智能体（例如用于月度数据分析的智能体）应在隔离的沙箱环境中执行。

在多智能体生态系统中，应实施角色分离，并对角色间的转换进行日志记录和控制。通过这种方式，可确保单个受损的子智能体不会导致整个系统遭到破坏。

为大语言模型（LLM）创建提示词时，需明确区分“系统”指令、“用户”数据和“第三方”数据。经过指令调优的大语言模型能够理解这种区分，这有助于防范提示词操纵攻击。

此外，若干核心防御策略也应纳入早期设计阶段：

通过明确的系统指令缩小智能体的权限范围。“你是健康教练，仅需回应健康相关查询”。虽然这并非万无一失，但有助于让智能体始终处于其定义的受限环境中。

仅向智能体授予最低限度的工具/API访问权限。例如，若健康智能体仅需读取步数数据，则不应拥有写入用户病历的权限。此外，对于任何敏感操作，应实施“人机协同”（HITL）机制。

智能体执行的每项操作都应携带发起用户的身份信息。这确保即使智能体遭到操控，也无法执行用户本人无权执行的操作。

构建安全的架构基础是一个良好的开端，但我们需要额外的防护层来构建坚固的智能体系统。

3. AI 智能体的实时防御层

诸如 Web 应用防火墙（WAF）等安全控制措施依赖于静态特征码，对 AI 智能体并不有效。由于大语言模型（LLM）具备处理自然语言的能力，攻击者能够设计出这些静态模式无法检测到的攻击。

要保护 AI 智能体，我们需要借助 AI 来防御。应部署一个实时防御型 LLM，专门用于检测并化解诸如提示词操纵或任何试图窃取敏感用户数据的攻击。如果不可信的输入试图欺骗模型，防御层会在主智能体处理请求之前就将其拦截并阻止。

此类额外层级可能会增加工作流的延迟，这通常是工程团队和管理层关注的问题。我建议使用专用的高速小型语言模型（SLM），该模型需针对提示注入攻击进行预训练或指令微调。Protect AI 推出的微调版 DeBERTa v3 便是此类开放权重 SLM 的一个典型代表。

4. AI 智能体编排的攻击性测试

最后一步是攻击阶段，该阶段将智能体的红队测试自动化。这是一项针对整个智能体编排的对抗性测试，涵盖智能体使用的工具、多智能体通信，甚至包括防御层本身。可使用 Garak 或 PyRIT 等开源对抗性扫描器来自动化此攻击过程。

通过为智能体生成具有情境感知能力的恶意提示，并利用Markdown注入等技术窃取数据，我们可以主动探测智能体中存在的此类安全风险。这将形成一个反馈循环，我们可以利用这些攻击性洞察直接强化防御过滤器以及智能体编排系统本身。

Engineering trust: A security blueprint for autonomous AI agents

人工智能已从助手转变为自主行为体，而安全措施却始终未能跟上

作者：Mirko Zorz

发布时间：2026年3月3日

企业人工智能部署已从试点项目转向生产系统，这些系统处理客户数据、执行商业交易，并与核心基础设施集成。这暴露了智能体所能做的事情与安全团队所能观察或控制的事情之间存在巨大差距。

2026年AI智能体安全形势

由AIUC-1联盟发布的简报（该简报在斯坦福大学可信AI研究实验室及40多位安全高管的协助下完成）记录了2025年出现的安全状况，并预测了2026年最可能影响企业的风险。报告的贡献者包括来自Confluent、Elastic、UiPath和德意志交易所的首席信息安全官（CISO），以及来自麻省理工学院斯隆管理学院、Scale AI和Databricks的安全研究人员和顾问。

根据简报中引用的安永（EY）调查，年营业额超过10亿美元的企业中，有64%因AI故障蒙受了超过100万美元的损失。五分之一的组织报告了与未经授权的AI使用（通常被称为“影子AI”）相关的数据泄露事件。

1. 三大安全问题主导当前局势

该简报指出了安全从业者当前面临的三类风险。

第一类是智能体挑战。AI系统已从响应查询的助手，演变为能够执行多步骤任务、调用外部工具并在无需逐项人工批准的情况下做出决策的自主智能体。这导致了无需外部攻击者介入即可发生的故障情况。一个拥有过度权限且隔离边界薄弱的智能体，仅通过常规操作就可能造成损害。80%的受访企业报告了高风险的智能体行为，包括未经授权的系统访问和不当的数据暴露。仅有21%的高管表示能够完全掌握智能体权限、工具使用情况或数据访问模式。

Databricks副总裁兼CISO Omar Khawaja指出，供应链中的AI组件不断变化，而现有安全控制措施假设资产是静态的，这在行为发生变化时会产生盲点。

第二类是可视化挑战。2025年，63%使用AI工具的员工将敏感的公司数据（包括源代码和客户记录）粘贴到了个人聊天机器人账户中。据估计，平均每家企业有1,200个非官方AI应用程序在使用，86%的组织表示无法掌握其AI数据流的情况。由于检测延迟及难以确定暴露范围，影子AI安全事件造成的损失平均比标准安全事件高出67万美元。

第三类是信任挑战。2025年，提示注入已从学术研究演变为反复出现的生产环境安全事件。OWASP的2025年大型语言模型（LLM）十大安全漏洞榜单中，提示注入高居榜首。该漏洞的存在源于大型语言模型无法可靠地区分指令与数据输入。目前有53%的企业采用检索增强生成（RAG）或智能体管道技术，这两者均会引入新的注入攻击面。

2. 现有框架无法充分应对智能体特有的风险

NIST AI RMF和ISO 42001等框架提供了组织治理结构，包括风险委员会和文档要求。但这些框架并未涉及首席信息安全官（CISO）在部署智能体时所需的具体技术控制措施，例如工具调用参数验证、提示注入日志记录，或是针对多智能体系统的隔离测试。

斯坦福大学可信人工智能研究实验室负责人Sanmi Koyejo承认，目前尚无大规模纵向研究对比采用技术特定框架的组织与依赖更广泛治理框架的组织之间的事件发生率。“AIUC-1仍处于早期采用阶段，而AI智能体安全领域尚处于萌芽期，尚无法进行此类受控对比，”他告诉Help Net Security。其实验室的研究发现，仅靠模型层面的防护措施是不够的：在72%的案例中，微调攻击绕过了Claude Haiku，在57%的案例中绕过了GPT-4o。技术性控制措施增加了模型安全机制所缺乏的输入验证、操作层防护措施以及推理链可视性。Koyejo将其比作传统网络安全中多因素认证（MFA）的采用，指出具体且可审计的技术控制措施在降低数据泄露风险方面，是高层政策承诺无法做到的。

据 Koyejo 介绍，率先采用技术驱动型 AI 安全标准的机构反馈称，其采购周期得以缩短，审计准备工作更加清晰，且在受监管环境中部署智能体时遇到的阻力显著减少。由 Koyejo 联合创立的 Virtue AI 已发布了一份案例研究，详细介绍了金融服务公司 AllianceBernstein 应用结构化 AI 安全控制措施的实践。

3. 为持续对抗性测试配置资源

该简报建议组织将持续的红队攻击测试长期融入日常运营中。1Password首席技术官Nancy Wang表示，对于缺乏内部AI安全专业知识的企业而言，其运营模式应结合平台默认设置、自动化和针对性专业知识，而非依赖庞大的专业团队。

“必须将基准防护措施内置于平台本身，”Wang说道。“沙箱化工具执行、范围限定且短效的凭证、运行时策略强制执行以及全面的审计日志记录，都不应需要定制化开发。”她指出，对抗性测试应集成到持续集成（CI）和发布工作流中，以便模型更新、提示词变更或智能体重新配置能自动触发预定义的攻击套件。随后，人类专家只需调查有意义的差异，而非手动重跑整个攻击脚本。

Wang建议根据风险等级对智能体进行分层管理。能够访问敏感数据或生产系统的智能体需要持续的对抗性测试和更严格的审查门槛。低风险智能体则可以依赖标准化控制措施和定期抽样检查。“目标是让持续验证成为工程生命周期的一部分，”她说。

科耶乔的实验室直接致力于解决自动化问题。针对该实验室称为“AutoRedTeamer”的研究表明，与简单粗暴的方法相比，自动化攻击选择可在覆盖更广泛漏洞的同时，将计算成本降低42%至58%。他建议资源受限的组织从与部署管道关联的自动化持续测试入手，在任何可访问敏感数据或真实世界工具的智能体进入生产环境前实施运行时防护措施，并针对高风险部署有选择地使用人工红队测试。

在身份与云安全领域，Wang指出，从高层次的政策声明转向可执行的控制措施–例如最小权限原则、短效凭证和范围限定令牌–显著减少了横向移动，并在发生安全事件时限制了影响范围。“具备严格限定权限和时限凭证的智能体程序根本无法访问其从未被授予的资源，”她表示，“这就是切实可观的差异。”

AI went from assistant to autonomous actor and security never caught up

（完）

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全行者老霍 HelpNetSecurity HelpNetSecurity《EDR killer已成为勒索软件攻击的标准配置》