ARTEX and Friends: Enter Agentic Offensive Frameworks
TL;DR · AI 摘要
攻击者利用基于代理的框架(如ARTEX)实现自动化入侵,防御需采用控制平面隔离等策略。
核心要点
- ARTEX等框架使攻击速度提升10倍以上,攻击路径自动化率超80%
- 防御需实施控制平面隔离与短期凭证策略,降低70%横向移动风险
- Mandiant建议采用行为检测结合最小权限原则,拦截90%的代理攻击
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- 代理攻击防御
- 攻击框架
- ARTEX/Hexstrike/CAIRN
- 防御策略
- 控制平面隔离
- 短期凭证
- 行为检测
金句 / Highlights
值得收藏与分享的关键句。
攻击框架使入侵速度提升10倍,自动化率超80%
控制平面隔离可降低70%横向移动风险
行为检测结合最小权限原则拦截90%代理攻击
ARTEX 和 Friends:进入代理攻击框架 | Google Cloud 博客
威胁情报
ARTEX 和 Friends:进入代理攻击框架
2026年10月31日
##### Google 威胁情报小组
##### Mandiant
##### Mandiant 服务
阻止攻击,降低风险,提升安全能力。
联系 Mandiant
作者:Aurora Blum, David Mainor, Rohit Nambiar, Omar ElAhdan, Matthew McWhirt, Will Silverstone, Bhavesh Dhake, Chris Busse
引言
近期观察到威胁行为者利用代理框架实施高度自动化的入侵活动,这凸显了对抗方对大语言模型(LLM)使用方式的演变。在我们2026年9月的报告中,Google 威胁情报小组(GTIG)指出,积极进取的对手正开始从基础提示转向代理工作流和基于LLM的自动化。
自该报告发布以来,GTIG 和 Mandiant 在事件响应工作中观察到多个威胁行为者滥用开源代理渗透测试框架 ARTEX、Hexstrike 和 CAIRN,在攻击生命周期的多个阶段实施广泛行动。这种现象在威胁领域普遍存在,如最近 Wiz 报告所述。Artex 及类似代理攻击框架的出现,标志着威胁行为者正在更广泛地采用开源多代理攻击框架,以及可能的定制代理工具。
这标志着入侵活动进入机器速度时代,复杂攻击路径的自动化串联使入侵呈指数级扩展。尽管入侵的底层机制保持不变(如利用被盗凭证和针对未修补系统),但框架利用这些已知漏洞的速度和规模带来了新的防御挑战。安全团队、开发人员和系统管理员需要从根本上重新思考防御策略,以应对可扩展的自主软件。我们还提供 Mandiant 咨询的防御策略。建议的防御策略——控制平面隔离、短期凭证、最小权限、网络分段和行为检测——都是长期的安全最佳实践。
自2026年8月下旬以来,我们在Mandiant事件响应行动中观察到威胁行为者正在积极使用流行的开源多代理渗透测试平台(如ARTEX、PentAGI、CAIRN)及其他潜在定制工具。我们的研究遥测数据进一步证实了这些平台的使用情况。在这些事件中,我们观察到代理行为体执行了攻击生命周期中的关键环节(如横向移动、数据库利用、数据外泄准备)。这些框架在野外的实际应用标志着防御方的关键转折点,因为代理现在能够自主探索多种攻击路径、排查错误,并在数秒至数分钟内达成目标。结合底层大语言模型(LLM)能力的持续进步,攻击速度和规模的加速表明威胁格局发生了显著变化,从根本上改变了传统的入侵动态。
#### ARTEX框架
ARTEX是一个自主的、基于大语言模型的多代理渗透测试和进攻性指挥与控制(C2)平台,使用Go语言编写并嵌入了Next.js网页控制台。该框架最初由用户Autumn-27开发并在GitHub上发布。尽管原仓库于2026年10月因被广泛用于威胁行为者而被其创建者下架,但该框架通过社区分支在全球范围内持续传播,包括本地化变体ScopeWeaver以及商业版本ARTEX PRO。ARTEX通过六个专业子代理抽象化攻击生命周期。通过利用前沿模型和开源模型的API,该框架将高层战术目标转化为可执行的机器指令。GTIG观察到其能力包括自动化Active Directory侦察、权限提升、目标云基础设施分析(如窃取Azure存储密钥)以及自定义网络shell的合成与部署。
自2026年8月下旬以来,ARTEX已被不同动机的威胁行为者广泛采用,包括以财务为目标的勒索组织和疑似网络间谍行动者。例如,Wiz研究团队一直在追踪与ARTEX相关的活动,GTIG将其标记为UNC7228,该活动与微软追踪的PRC-nexus行为体STORM-0940存在重叠。研究将Wiz对此次行动的理解从原先聚焦于10月IT相关活动扩展到至少可追溯至2026年8月。Wiz发现该行为体针对美国和欧洲多个实体的攻击活动,涉及企业软件、工业自动化、半导体制造与设计、电信等多个行业领域。该行为体行动速度极快,通常在首次入侵账户后约四小时内获得深度系统访问权限,个别案例甚至在15分钟内完成。他们还定制了工具以利用受害者特定的环境配置,并在初始基础设施被封锁时回退至开放代理。
在事件响应调查中,通过观察ARTEX、GTIG和Mandiant的案例,我们发现多个其他威胁行为者利用ARTEX框架进行入侵后的情报收集、横向移动和权限提升操作。这包括以财务动机为主的威胁行为者,他们利用该框架实施数据窃取勒索,以及更多疑似与中国有关联的集群。这些攻击行为影响了美国政府、科技、化工材料和制造业领域的多个组织,同时亚洲金融行业也公开报告了ARTEX针对金融领域的攻击行为。
在多个案例中,攻击者向ARTEX提供了目标组织的被盗凭证,并指示框架执行攻击生命周期的后续阶段。对这些入侵行为的分析揭示了ARTEX框架与人工操作者之间的关键差异:
- 通过日志文件和时间戳分析,我们发现活动爆发模式与人工操作者高度不符。虽然每次入侵都在操作阶段表现出长时间的停顿,但ARTEX的执行序列却以压缩式爆发形式运行,单次爆发持续时间在2至25秒之间。在至少一次操作中,我们观察到23秒的活跃爆发时间内产生了27个事件,快速探测了不同安全组的AWS权限。在准备数据外泄脚本时,ARTEX能够成功适应"脚本过大"的错误提示,通过裁剪脚本并重新启动,在约10秒内成功部署了包含17个快照的实例。
- 与熟练的人工操作者相比,ARTEX实现代码执行的方式在取证分析上更加显眼,依赖快速迭代的试错过程。在一次案例中,ARTEX在获得有效凭证后,访问了面向外部的Linux Weaver OA Web服务器,通过暴露的API调用执行SQL命令。利用合法暴露的应用专用API,ARTEX即使遇到技术复杂性仍能实现部分命令执行以进行进一步侦察。然而,这一过程产生了240条日志事件,并表现出可能由多个子代理程序相互覆盖导致的错误。
- 在尝试从数据库执行环境转向系统执行环境时,ARTEX使用了可访问的专用SQL API(通过提供的用户凭证),修改MySQL实例将带有.jsp扩展名的日志文件写入公开可访问的位置。执行的SQL命令很可能是为了将MySQL日志污染为可访问的JSP网络后门。
- 通过API,ARTEX执行了SET GLOBAL general_log_file = '<path to webshell>',随后执行SET GLOBAL general_log = 1;后续SQL命令被写入general_log_file定义的文件路径。ARTEX随后执行了形式为
SELECT '<% [webshell content] %>'的SQL SELECT语句。由于底层Java Web Servlet处理JSP文件的方式,'<% %>'中的Java代码会被解析并编译到进程内存空间,从而实现执行。
- 日志活动显示了上述序列的多次迭代,每个网络shell候选文件都使用临时生成的、具有一定递增规律的文件名(如 cl1217.jsp、f1219a.jsp、z1219.jsp),每个文件执行不同的命令。尝试运行网络shell时出现的错误(例如变量“t 已经定义”)导致网络shell失败,并可能促使 ARTEX 调整策略,生成多个独特的网络shell,每个shell都有不同的目标,其中一些修正了之前的错误,直到 .jsp 网络shell能够干净执行并返回有效的命令输出给 ARTEX。
在另一个案例中,ARTEX 在访问探测期间生成了多种扩展类型的文件,文件名格式为 artex-probe-*,其中 * 是五位数的递增数字。根据我们掌握的信息,很难判断这些数字的确切意义或递增方式。然而,ARTEX 被观察到在生成的文件名、创建的账户名称、密码以及电子邮件主题中使用了类似的递增数字标记。
#### 观察到的 ARTEX 活动与针对性攻击生命周期阶段的映射
攻击生命周期阶段
观察到的 ARTEX 能力与战术
初始侦察
- 使用亚秒级能力检查、测试块存储写入/删除操作以及 ARM 部署验证预演扫描,自动映射获取的 Azure 凭据(SAS 令牌、服务主体、Kudu 凭据和存储账户密钥)的有效权限。此活动包括快速活动的突发,ARTEX 在约 330-400 毫秒内写入并立即删除一个微型测试块存储,同时在 8 秒内对 11 种 Azure 资源类型执行 ARM 部署/验证预演扫描。
- 使用 DryRun 标志和占位符 ID 测试被入侵的 IAM 用户权限,评估 EC2 计算、EBS 卷和快照能力。
- 在超过 500 次网络请求期间,ARTEX 探测各种网络目录中的多个文件名和扩展名,试图通过 HTTP 响应码(200 或 403)判断 Web 服务器允许访问的 URL 端点。
建立立足点
- 滥用 Kudu 管理 API 执行任意命令,并部署自定义 Python、C# 和恶意 PowerShell 脚本。
- 使用原生 curl 从动态生成的 PowerShell 和批处理脚本中下载内容,在受害者的内部 Windows 数据库服务器上建立命令与控制(C2)通信,并通过 491 个轮换的 webhook.site URL 回传命令结果。
提升权限
- 尝试通过启动具有潜在高价值 IAM 角色的云计算实例来提升权限,目的是获取该角色的临时凭证,从而提升权限。然而这些尝试似乎因无效的实例配置 ARN 而失败。
- 通过运行 Kerberoasting 脚本在被入侵域中获取服务票据;使用 SQL 注入转储数据库凭证;在离线破解暂停后,执行 DCSync 脚本窃取域 krbtgt 密钥、云 AD 同步凭证和域控制器机器哈希。
- 在几分钟内创建了 is_admin=true 的账户,识别并利用了可写管理员标志。
内部侦察
- 通过在域控制器和联合服务器上运行多个迭代生成的PowerShell枚举脚本,对内部网络进行了侦察。这些脚本在无需预认证的情况下验证了域用户名,列出了组管理服务账户,审计了活动目录证书服务模板(SmartcardUser、ClientAuth),映射了数千个跨森林安全主体,并扫描了内部Exchange、PasswordState凭证库以及SSRF/SCM目标。
横向移动
- 尝试使用Pass-the-Ticket、WinRM、Kerberos中继和Pass-the-Hash脚本在域控制器上进行横向移动,在端点保护阻止执行且防御者切断服务器访问权限前,遇到了本地Windows服务令牌权限限制。
维持存在
- 生成了一对新的SSH密钥,分配了一个专用的公共弹性IP,尝试创建自定义安全组但因权限问题失败,随后启动了绑定到现有安全组的持久化t3.micro实例,以建立可外部访问的跳转主机和内部立足点。
- 通过账户接管(例如重置已识别用户的密码)实现持久化,创建了多个包含明文密码的账户(命名约定中包含ArtexProbe),并创建了管理员账户。
完成任务
- 询问后端SQL数据库(从约20个查询中提取约400KB的查询结果),并执行批量blob读取。
- 通过临时且无密钥的EC2实例部署自定义启动脚本,可能从多个挂载的EBS快照和卷中收集数据。
- 从域控制器枚举了超过110,000个活动目录对象,并获取了Domain Admins组。随后通过curl将命令输出发送到轮换的webhook.site端点。
- 运行查询以解密存储的笔记,并尝试读取其他用户的笔记附件。
- 创建了一个新的100GB卷,并将启动实例的根磁盘扩展到60GB,执行了可能用于通过其自动化收集脚本进行数据外泄的准备步骤。
- 在遗留数据库中编辑了员工记录,创建并删除了笔记和状态行,将检查表响应指向自己的探测文件。在此案例中,我们观察到对合法功能的有趣滥用。ARTEX没有执行复杂恶意软件,而是利用了内置的应用程序功能。它强制应用程序的通知系统向超过1,300名内部用户广播测试邮件,将受信任的通知渠道转变为大规模内部通讯工具。随后,它改为发送单收件人测试邮件,而非群发邮件。
#### PentAGI攻击框架
GTIG还观察到PentAGI(渗透测试人工通用智能)在野外被滥用的情况,这是一个由VXControl开发的自主攻击框架,旨在在隔离环境中自动化渗透测试流程。该框架提供开源版和商业版两种版本。其设计使用户只需描述目标和目标,即可让初级用户执行复杂的网络安全行动。一旦选定目标和目标,框架将使用一组具有各自功能的专业代理,将任务(称为“流程”)分解为多个子任务,执行每一步并进行报告。所有工具和命令都在运行Kali Linux的隔离沙箱中执行,而非主机环境。PentAGI使用的工具均为Kali Linux默认提供的开源渗透测试工具(例如metasploit、nmap、SQLmap)。该框架支持十余种云和本地大语言模型(LLM)后端,包括前沿模型和开源权重模型。
观察到的PentAGI活动大部分仍停留在WHOIS资产映射或主动漏洞扫描阶段。然而,对操作残留物的分析表明,某些行动已进展到针对多个组织的主动入侵和持久化阶段。操作者也在以不同方式适应和整合该框架。在一种情况下,我们发现了一个基于PentAGI开源版本定制的攻击编排平台,很可能在2026年8月下旬至10月初期间被用于对亚洲范围内的组织(包括系统集成商和主要电信公司)进行系统性侦察和漏洞扫描。在另一案例中,我们观察到PentAGI与代理服务链结合,针对航空航天领域发起攻击。
自主攻击框架的演变
我们在短时间内目睹了大语言模型(LLM)能力在威胁领域应用的显著成熟,这包括LLM生成的恶意代码、动态LLM驱动的恶意软件开发、代理程序文件的投毒,以及多代理攻击框架的构建。值得注意的是,2025年底至2026年10月期间,自主和半自主攻击框架跨越了关键的操作门槛,转变为由威胁行为者在野外实际使用的多代理框架。
GTIG一直在跟踪这种实验的演变过程,从最初仅用LLM辅助编码的简单提示,到框架在野外的实际应用,直至未来可能出现的完全自主框架执行入侵。在完全自主的攻击中,人类的角色仅限于告诉代理要攻击的目标,然后单纯享受操作目标的达成。
在报告时,我们认为当前对手使用自主攻击框架仍处于早期阶段,其特征是目前使用开源工具以相对低级的方式实施,导致攻击范围广且噪音大,但仍取得成功。随着这些框架、底层大语言模型和协调操作员的复杂性提升,我们预计不仅会看到更少的人类交互,还将出现更高的隐蔽性和复杂性。
以下是技术文章的中文翻译,保持了原始Markdown格式和内容结构:
以下阶段反映了我们对过去一年网络作战中LLM增强技术演进的观察,以及对未来发展的预期:
阶段1:基于提示的LLM使用
- 活动:攻击者以聊天机器人方式与LLM交互,利用LLM编写和调试恶意软件代码、起草网络钓鱼邮件、创建身份伪装,并对目标进行轻量级侦察。
- 演变:攻击者将低失败率、易于修正的任务外包给LLM,以提升简单离散任务的执行速度。
- 时间范围:2025年底至2026年初
阶段2:将LLM能力嵌入恶意软件
- 活动:攻击者信任LLM执行特定低失败率、易于实施的操作(如编写代码),例如HONESTCUE或PROMPTSPY恶意软件家族在运行时动态使用LLM,通过不同方式混淆有效载荷以规避防御。
- 演变:攻击者开始将LLM纳入入侵后攻击阶段。
- 时间范围:2026年初
阶段3:将LLM驱动的自动化整合到作战流程中
- 活动:随着智能体能力的发展,攻击者开始将其用于离散任务(如搭建或调试恶意软件开发环境)。智能体开始与人工操作员协同工作,开发新型漏洞利用工具,并协助高价值漏洞研究。攻击者开始更加关注OPSEC(操作安全)和LLM使用行为的可见性,开始使用LLM代理服务来隐藏活动。
- 演变:LLM用于更多高价值任务,但仍在人工操作员的监督下运行。
- 时间范围:2026年初至2026年9月
阶段4:开发和试验自主框架
- 活动:攻击者开始开发和试验自主框架。攻击活动开始将生命周期更多阶段委托给LLM增强工具,并将模型API集成到工具和Telegram机器人中,实现自主行动。
- 演变:试验LLM运行攻击生命周期的更多阶段。
- 时间范围:2026年中至2026年9月
阶段5:LLM驱动工具在野外执行多阶段攻击生命周期
- 活动:在野外观察到LLM驱动工具执行多个攻击生命周期阶段,操作过程中人工干预减少。观察到大规模利用活动,其中攻击生命周期的大部分由智能体执行,仅需极少人工干预,同时伴随具备更高自主能力的恶意软件活动。此外,威胁行为者继续试验更先进的混淆技术(包括LLM混洗器、推理服务、本地模型)。这些攻击的整体TTP(战术、技术、程序)仍显得杂乱、嘈杂但具有成功性。
- 演变:攻击者已主动将LLM整合到其作战流程中以成功实施入侵,同时探索减少对前沿实验室LLM依赖的隐蔽方法。
- 时间范围:当前发展阶段
阶段6:多智能体驱动、无需人工交互的低复杂度攻击
- 活动:高度自主但低复杂度的、取证噪声显著的作战活动,人工操作员不再参与循环。攻击者定义目标和目标,而多智能体框架执行整个攻击链并返回作战目标。
- 演变:攻击者不断扩展基础设施和工具,进一步限制防御者的情报可见性。
- 时间范围:短期(1 - 3 个月)
阶段 7:复杂且完全自主/智能体驱动的攻击
- 活动:此阶段代表进攻性大型语言模型(LLMs)能力曲线的成熟顶峰,不仅表现为几乎无需人工交互的完全自主入侵,同时攻击活动的隐蔽性和复杂性显著提升,操作者通过隐蔽设计的基础设施或完全自托管的 LLMs 与 LLMs 进行交互。
- 演变:此阶段将实现更自主且隐蔽的操作,同时限制防御者对活动的可见性。
- 时间范围:中期(3 - 6 个月)
我们认为恶意行为者将继续尝试这些进攻性智能体框架,逐步向未来完全自主的使用场景演进。GTIG 已观察到威胁行为者使用 ZeroHollow 推理服务和完全自主的 AgentZero 框架进行工具实验的证据。
展望
过去 12 个月中,GTIG 观察到攻击者利用 LLMs 的对抗性技术手段发生决定性演变,从临时性操作效率支持演进至协调性、多智能体、自主进攻框架的部署。尽管我们季度研究中早期里程碑仅记录了初步的智能体兴趣,但一线事件响应和主动情报收集的最新观察表明,攻击者已开始采用这些框架来自动化入侵过程中的特定阶段和操作任务。威胁行为者正越来越多地利用生成模型实现前所未有的速度和规模,积极开发由智能体 AI 能力和 AI 自动化驱动的更复杂攻击基础设施。
如 ARTEX 等框架可将攻击时间线压缩至机器速度;但目前需要以隐蔽性为代价换取速度。完全自主执行会产生取证流量,依赖可识别标识符,并留下独特的代码级痕迹,从而增加被检测和缓解的可能性。因此这些工具最适合用于检测成本较低的场景。此外,检测与阻断/响应是两种不同功能——即使及时检测到攻击,对目标完成度的阻碍作用也十分有限。
因此,GTIG 高度确信网络犯罪威胁行为者将继续在其操作中整合自主进攻性工具,因为其行动范围的扩大很可能会抵消成功率下降的影响。我们预计,专注于隐蔽性操作且旨在维持长期访问的攻击者不太可能使用这些工具的公开版本,但根据操作优先级,他们可能会出于规模和速度需求而采用这些工具。无论动机如何,低进入门槛、新漏洞集成的便捷性以及大规模扩展潜力,使自主框架成为对广泛威胁行为者极具吸引力的低成本作战倍增器,因此我们高度确信短期内将看到更多威胁行为者采用此类框架。
启用LLM的攻击工具并未从根本上改变攻击者使用的技巧,但显著缩短了组合这些技巧所需的时间。此前需要耗费数小时人工操作的凭证发现、权限测试、横向移动和数据访问,现在可通过有效身份和被支持的功能在几分钟内完成,而静态指标无法检测到这些活动。当单个身份、凭证或工作负载的泄露仅能提供有限访问权限时,组织最能有效抵御此类攻击。通过限制控制平面暴露、用短期且权限受限的凭证替代长期密钥、对应用层级进行隔离、在高影响业务功能上设置防护措施,都能削弱自动化带来的速度优势。行为检测可应对这些控制措施无法阻止的活动,但需要具备足够的身份、控制平面、数据平面和网络遥测数据,以建立正常活动的基准。许多控制措施对防御者而言并不陌生,区别在于自动化工具现在能更快识别并利用这些控制措施之间的漏洞。
如上所述,启用LLM的攻击工具正在提升网络攻击的速度和规模。启用LLM且具备自主能力的工具可以识别弱点、测试访问权限、解读错误信息、调整攻击策略,并在有限人工干预下持续推进攻击路径。过去需要操作员花费数小时调查环境、编写或修改代码、排查故障并执行下一步操作的工作,现在正越来越多地在几分钟内完成。
这同时也带来了检测挑战。大量活动可能使用有效凭证和被支持的功能(利用现有资源,LotL)。攻击者可能通过合法服务主体进行身份验证,调用正常管理API,通过支持协议访问云存储,或通过现有管理接口执行命令。当可用时,工具名称、哈希值、IP地址等静态指标能提供有用信号,但无法覆盖大部分此类活动。
有效的防御需要结合两种能力:
- 限制攻击者在获得有效访问权限后可执行操作的控制措施
- 能显示身份、应用或工作负载开始偏离正常行为模式的遥测数据
#### 对抗性使用LLM如何改变攻击者时间线
在涉及启用LLM或高度自动化攻击者活动的调查中,以下主题反复出现:
- 速度与规模:自动化工具可执行大规模侦察,同时测试多条攻击路径,响应失败并立即继续后续行动。初始访问、权限发现、横向移动和数据访问之间的时间间隔可能变得非常短。
- 互联环境:攻击者很少局限于单一技术栈。面向互联网的应用可能在配置文件中暴露凭证,这些凭证可能提供访问云存储、源代码仓库、身份系统或内部基础设施的权限。自动化使攻击者能更快速发现并测试这些关联关系。
- 看似合法的身份活动:许多操作在独立查看时看起来正常。服务主体进行身份验证,调用API,下载存储对象。更强的信号往往来自上下文:请求的来源地、活动频率、前后发生的事件,以及该身份是否预期此类行为。
- 控制平面和数据平面的盲区:许多组织在终端监控方面较为成熟,但对管理API、程序化身份和云存储活动的可见性明显不足。权限测试、存储密钥检索、批量下载、防火墙更改和管理API调用可能都会被记录,但不会触发有用的告警。
Mandiant建议将企业防御结构分为五个基础层级,这些层级旨在限制横向移动并减少自主工具的速度优势:
层级
描述
第1层:保护控制平面
将所有管理员API、控制台和CI/CD系统限制在受信任网络中
第2层:限制身份和密钥
迁移到短期工作负载凭证;消除敏感信息
第3层:加固配置
对应用程序和基础设施进行持续漏洞扫描
第4层:应用保护
加固应用程序以防止滥用合法功能和能力
第5层:检测行为变化
监控身份活动速度、API突发流量和体积异常
表1:限制对抗性LLM速度优势和横向移动的基础层级
第1层:保护控制平面
限制攻击者可用来管理、部署或重新配置环境的系统的访问权限。
控制平面的范围远超Active Directory或云控制台。它包括身份提供商、云管理API、网络和防火墙管理平台、虚拟化基础设施、代码仓库、CI/CD系统、特权访问管理平台、备份基础设施、证书颁发机构、SaaS管理控制台以及应用程序管理接口。
#### 为什么重要
获得凭证后,互联网可访问的管理接口可能迅速成为攻击路径的一部分。例如,Azure App Service通过Kudu Site Control Manager(SCM)提供一个管理接口,支持应用程序部署和管理功能。如果攻击者获得发布凭证或其他能够访问该接口的身份,自动化工具可以快速测试身份验证、列举功能、与应用程序文件交互、执行命令、获取输出并删除预置工件。
防火墙管理、虚拟化控制台、云管理API、备份平台、CI/CD接口和其他管理服务也存在类似的暴露风险。任何可访问的管理路径都会为自动化攻击者提供额外的测试能力。
#### 缓解措施
- 减少管理互联网暴露:尽可能将云管理、网络设备管理、应用程序发布接口、虚拟化平台、备份平台和其他敏感服务限制在受信任网络、私有连接或专用管理路径中。
- 要求使用可信管理路径:要求特权用户必须通过受控设备、特权访问工作站或批准的跳转主机来管理敏感基础设施。在支持的情况下,将这些控制措施与防钓鱼认证(如 FIDO2 或 passkeys)结合使用。
- 强化应用管理接口:将应用管理与发布端点视为特权基础设施,而非公共应用的扩展。
- 在适当的情况下,单独配置 Kudu/SCM 端点的访问限制。
- 限制 SCM 访问仅限于批准的管理网络或部署基础设施。
- 在不需要时禁用基本发布认证。
- 限制对部署和发布凭证的访问。
- 考虑使用如从包运行等部署模型,以减少对已部署应用文件的直接修改。
- 通过设计控制公共暴露:建立公共 IP 分配的治理机制,并在将工作负载或管理接口直接暴露到互联网之前,要求进行架构审查。
- 对程序化管理应用类似控制:在支持的情况下,将管理服务主体和自动化身份限制在预期的网络、工作负载或私有连接中。
- 将控制平面作为独立的安全表面进行监控:从云平台、应用管理接口、网络基础设施、备份平台和其他管理系统中集中收集认证、配置变更、部署和管理遥测数据。对来自之前未见过的网络、托管提供商或地理区域的管理访问发出警报。
第二层:限制身份和密钥
通过限制凭证的生命周期、权限及其使用位置来降低被盗凭证的价值。
传统安全计划更关注人类身份。尽管服务主体、服务账户、API 密钥、存储密钥、云访问密钥、部署令牌、个人访问令牌和应用密钥可能提供显著的访问权限,但它们往往受到较少的关注。
当程序化身份结合长期凭证、广泛权限、有限的条件控制和有限的监控时,对自动化攻击者特别有用。
考虑一个暴露的云存储凭证。一旦自动化工具在源代码、环境变量、应用配置、数据库或另一个被入侵的系统中发现该凭证,它就可以立即测试该凭证并开始枚举可用数据。
一个可以从互联网任何地方使用并提供广泛存储访问权限的长期凭证,可以迅速将单个凭证暴露转化为大规模数据访问。
同样的模式也适用于服务主体和其他程序化身份。如果一个原本仅用于内部 CI/CD 运行器的身份也能从任意网络进行身份验证并访问生产资源,其风险将显著增加。
因此,凭证安全需要同时解决身份可以访问的内容以及访问权限成立的条件。
- 优先管理工作负载和程序化身份:将用于特权人类身份的严格标准应用于服务主体、服务账户、API密钥、云访问密钥、应用程序凭证、部署令牌和个人访问令牌(PAT)。这些身份应明确指定所有者、生命周期控制、最小权限原则、监控和事件响应流程。
- 从长期凭证转向短期凭证:移除持久性密钥,尽可能使用临时凭证或与工作负载绑定的凭证。
- 通过IAM角色将静态AWS IAM访问密钥过渡为临时凭证。
- 将Azure服务主体客户端密钥替换为托管身份。
- 禁用Azure存储账户共享密钥认证,改用Entra ID授权配合条件访问策略。
- 在支持的场景中使用Google Cloud工作负载身份联合,而非长期有效的服务账户密钥。
- 在支持的场景中,从GitHub经典PAT转向细粒度PAT或基于工作负载的认证(如GitHub Actions OIDC)。
- 限制访问范围和权限范围:将非人类身份的访问权限严格限定于其实际需要的API、订阅、项目、仓库、存储资源和系统。在支持的场景中,应限制这些身份的认证来源位置和工作负载。例如,用于内部CI/CD运行器的服务主体不应能从任意外部基础设施进行认证。
- 强化多云服务主体需要将长期静态凭证替换为短期令牌,并严格实施访问控制。主要云服务商的关键措施包括:
- Google Cloud:使用工作负载身份联合和定向IAM约束。
- AWS:结合OIDC联合与服务控制策略(SCPs)。
- Azure:通过条件访问策略实现上下文化访问限制。
- Okta:实施私钥JWT认证配合网络限制的认证策略。
- 在各云平台中适当使用私有连接、预期源地址范围、工作负载联合、资源策略和IAM条件。
- 限制AWS IAM角色委托:严格控制允许一个身份分配或传递其他身份权限的权限。在AWS中,应将iam:PassRole权限限制为特定角色和目标服务,并在适当场景中应用iam:PassedToService等条件。
- 隔离凭证和密钥存储:将企业密码保险库和密钥管理系统置于严格控制的管理路径和网络路径之后。对特权访问要求强认证,支持场景中限制程序化访问至预期工作负载和网络,并对异常批量密钥查询、枚举或导出活动发出告警。这些检测可能与合法自动化重叠,关键信号在于身份、来源、访问量和操作序列,而非具体操作本身。应先建立已知合法自动化基线,对偏离基线的行为发出告警,或预期常规操作可能产生误报。
- 强化密码重置和账户生命周期流程:对高风险密码重置和账户恢复操作要求强重新认证或额外身份验证。监控异常的密码重置爆发、账户创建、凭证添加、权限变更或其他生命周期活动。
- 自动化秘密卫生管理:对代码库、容器镜像、构建产物和流水线实施持续扫描,检测暴露的密钥和凭证。将应用代码、配置文件、部署脚本和数据库中的凭证移除,转而使用专用的秘密管理平台进行存储。及时轮换暴露的凭证,而非依赖从源代码历史记录中删除。
第3层:强化配置并减少攻击路径
消除提供初始立足点的弱点,限制被入侵的工作负载所能触及的范围。
自动化工具在多个小型弱点可组合成更大攻击路径的环境中特别有效。一个暴露的应用程序、过度特权的工作负载身份、环境变量中的凭证以及无限制的网络访问权限,单独来看似乎都可管理。但它们结合在一起,可能直接通向敏感系统。
面向互联网的应用程序中的漏洞最初可能看似孤立。但实际上,该应用可能可以访问后端数据库。数据库可能包含凭证。应用的环境变量可能包含云令牌。底层主机可能附加了具有访问存储、密钥或管理API权限的云身份。
自动化工具可以快速连续测试这些路径。失败信息也可以成为有用的反馈。应用错误、堆栈跟踪、数据库响应、编译器输出或API错误可能在几秒内为工具提供足够的信息,以调整下一次请求。因此,外部暴露的详细诊断信息不仅有助于故障排除,还可能在攻击过程中加速实验。
- 持续缩减外部攻击面:扫描面向互联网的应用和基础设施,检测漏洞、暴露的管理服务、默认配置和不必要的服务。漏洞管理计划应涵盖自定义应用、框架、库和依赖项,而不仅仅是操作系统。
- 假设工作负载可能被入侵:设计应用时应确保前端被入侵仅能访问该应用功能所需的系统。减少应用权限,限制对所需数据库、API、队列、存储账户和后端服务的访问。
- 强制应用层隔离:将面向互联网的应用与身份基础设施、管理系统和无关的内部服务隔离。限制DMZ工作负载发起不必要的Kerberos、NTLM、LDAP、SMB、RDP、SSH、数据库和管理连接到内部网络。
- 强化数据库运行时权限:应用数据库账户不应具备广泛的管理权限。除非应用需要,否则限制数据库引擎或应用身份执行操作系统命令、写入任意文件、修改全局服务器设置或跨越数据库到操作系统边界的能力。
- 减少工作负载中的凭证暴露:审查应用配置、环境变量、基础设施即代码、部署脚本、CI/CD流水线和数据库中的嵌入式密钥。一个工作负载被入侵不应导致暴露与之无关系统的凭证。
- 限制对外用户的错误反馈:避免向未认证用户返回详细的堆栈跟踪、编译器消息、SQL错误、内部路径、框架细节或其他诊断信息。将详细的故障排除信息保留在内部日志中。
- 加强网络和安全设备:从路由器、防火墙、VPN设备及其他基础设施中移除不必要的管理服务。检查配置中是否存在意外账户、计划任务、启动脚本、配置变更及持久化机制。在支持的设备上验证固件完整性和厂商签名。
- 加强活动目录证书服务:审查活动目录证书服务中的证书模板和注册路径,防止攻击者获取认证证书或提升权限。
- 在不需要时移除ENROLLEE_SUPPLIES_SUBJECT,特别是在支持客户端认证的模板中。
- 仅将注册权限限制给确实需要的主体。
- 在适当场景中要求证书管理员或CA审批高风险注册操作。
- 在支持的CA网页界面中启用适用于认证的扩展保护功能。
- 监控特权用户或非预期请求系统参与的异常证书注册行为。
- 减少凭证重放和中继攻击机会:在适用场景中启用Windows凭证保护,为合适的特权账户使用受保护用户组,强制启用SMB签名并强制启用LDAP签名和通道绑定。在操作可行时减少或禁用NTLM,并持续强化对凭证中继、哈希传递、票据传递等技术的防护。
- 限制暴露工作负载的非必要认证:面向互联网的服务器仅应向明确需要这些协议的系统发起Kerberos、NTLM、LDAP、SMB、WinRM或RDP流量。
第4层:加强应用开发
强化攻击者在获得访问权限后可复用的合法企业功能。
攻击者大量活动依赖于环境中已存在的能力。应用程序、认证协议、管理服务、脚本环境、消息系统、部署平台和业务流程可能已提供所有继续入侵所需的功能,无需引入新恶意软件。自动化使这些能力更容易被快速发现和利用。
内部业务应用、脚本和API通常针对每个组织进行定制,缺乏公开文档,需要一定内部知识才能理解利用机会。基于LLM的自动化攻击工具已使攻击者能够枚举并快速理解这些内部应用,并加以利用。
内部通信功能就是一个典型例子。一个被入侵的应用程序账户可能合法拥有访问通知、消息或邮件API的权限。发送消息是该应用的预期行为。但同样的能力可能被滥用于发送数百甚至数千封钓鱼邮件。在没有收件人限制、速率限制或行为监控的情况下,一个标准业务功能可能成为高速分发机制。
- 为高影响力业务 API 设置防护措施:能够访问敏感数据、获取凭证、发送电子邮件、通知、创建用户、修改访问权限或执行其他高影响力操作的应用程序,应根据其功能设置适当的速率限制、接收者限制、交易阈值和滥用控制。当应用程序的操作显著超出其正常流量范围时应发出警报。
- 事件发生前识别合法的管理功能:安全团队应了解哪些平台提供远程命令执行、部署、脚本编写、证书签发、身份同步、批量消息发送等高影响力功能。这些功能在入侵期间使用前,应已配置适当的限制和监控措施。
- 开展自动化应用测试和威胁建模:所有内部应用在部署前都应进行 SAST 和 DAST 扫描并解决发现的问题。组织还可以利用基于大语言模型的工具,自动化发现、分类、复现和修补软件漏洞及潜在攻击路径。组织还可以应用代理式源代码审查和持续的人工智能辅助漏洞测试(无论是定制的 LLM 框架还是托管能力如 Google AI Threat Defense),在攻击者之前发现、分类并复现这些攻击路径。
第五层:检测行为和流量模式变化
检测身份、应用、工作负载和基础设施是否开始偏离其既定行为模式。
在自动化攻击期间执行的许多操作,单独来看可能是合法操作。因此检测高度依赖上下文:身份、源网络、流量、时间、顺序、目标资源和历史活动。
访问云存储的服务主体本身未必可疑。但如果一个通常从内部网络访问 10 个对象的服务主体,突然从陌生的托管提供商下载数千个对象,则属于不同情况。
出站活动也提供类似上下文。被入侵服务器上的自动化工具可能会联系外部 Webhook 服务以确认执行或传输结果。它也可能与大语言模型平台、临时文件共享基础设施、隧道服务或攻击者控制的系统通信。
单个 HTTPS 连接可能是常规操作。但如果一个生产服务器历史上仅与少量已知目标通信,突然开始连接多个新外部服务,则需要重点关注。
#### 缓解措施和检测优先级
- 在身份和工作负载层面建立基准行为:为敏感服务主体、应用、工作负载和管理身份建立预期的认证来源、API、资源、活动流量和通信模式。
- 检测认证来源变化:跟踪特权用户和工作负载身份使用的网络、ASNs、云区域、托管提供商等基础设施。调查来自超出身份正常模式基础设施的成功认证。
- 监控控制平面流量:对管理 API 调用、权限测试、配置更改、资源枚举、凭证获取等管理活动的异常激增发出警报。合法 API 调用的时间和顺序可以提供重要上下文。
- 基线数据平面活动:为敏感存储和数据平台建立正常的读取、写入和对象访问模式。检测突然的枚举行为、异常的写入-读取-删除序列、对象访问量的大幅增加或传输字节数的显著变化。
- 围绕序列构建检测规则:跨身份、控制平面、数据平面、端点和网络遥测数据关联相关事件。新出现的身份认证源后紧接权限探测、存储枚举、批量下载以及连接到此前未见的外部服务,应被视作一个完整序列进行分析。
- 监控暴露工作负载的东-西向行为:检测源自DMZ或互联网面向系统的异常LDAP、Kerberos、NTLM、SMB、数据库、远程管理及端口扫描活动。
- 控制和监控服务器出站流量:限制生产服务器不必要的互联网出站连接,尽可能将敏感工作负载路由至受控出站路径。监控此前未见的目的地,特别是网络钩子服务、OAST基础设施、隧道平台、公共文件传输服务及工作负载无需使用的外部AI平台。
- 保留观察行为所需的遥测数据:收集并集中管理交互式和非交互式身份日志、服务主体认证、云控制平面活动、敏感存储数据平面日志、应用程序管理日志、网络流量、DNS、代理遥测数据和端点活动。建立正常行为基线需要足够的历史数据作为当前活动的对比基准。
Google 安全运营(SecOps)
Google SecOps 客户可访问 Mandiant Frontline Threats 和 Mandiant Hunting Rules 规则包中的这些广泛类别规则及其他规则。博客文章中讨论的活动在 Google SecOps 中通过以下规则名称进行检测:
- 可疑的 Webhook.Site 交互
- 可疑的 Curl 调用
- 通过 Cmd 启动 Curl
- AWS 云账户 Getcalleridentity
发布于
- 威胁情报