Black Hat 2025最新披露的ECScape漏洞研究，揭示了AWS ECS服务中IAM安全边界的系统性缺陷。该漏洞允许攻击者通过伪造ECS代理会话，绕过隔离机制窃取同主机所有任务的IAM凭证，实现权限提升。研究表明，这一攻击基于ECS默认配置即可实施，影响数百万运行在EC2上的容器实例。本文将深入剖析攻击原理、演示实际利用过程，并探讨云原生架构下的新安全范式。

资源：

• • Black Hat USA 2025议题简介^[1]
• • Black Hat USA 2025演讲PPT^[2]
• • PoC源码^[3]

注：本文翻译自Sweet Security - Naor Haziz^[4]的文章《ECScape: Understanding IAM Privilege Boundaries in Amazon ECS》^[5]，可点击文末“阅读原文”按钮查看英文原文。

全文如下：

一、引言

本文是我们关于Amazon ECS安全的教育系列文章的第二部分。在第一部分 - Amazon ECS on EC2深度解析^[6]中，我们探讨了ECS代理、IAM角色和ECS控制平面如何为任务提供凭证。本文将展示当具有不同权限级别的任务共享同一EC2主机时，这些机制如何导致已知风险。这种跨任务凭证暴露凸显了当工作负载共享同一EC2实例时，依赖每个任务IAM范围界定和任务执行边界的固有风险，同时也解释了为什么Fargate（每个任务在独立的micro‑VM中运行）能提供更强的隔离性。我们的目标是帮助您理解Amazon ECS中的IAM权限边界，以及如何安全配置您的服务。

云环境提供了无与伦比的灵活性和可扩展性，但也带来了复杂的安全考量。如果您误以为存在容器级隔离而实际并不存在，则AWS服务之间微妙的交互可能会导致意外的权限暴露。在本文中，我将带您了解我是如何在Amazon ECS（弹性容器服务）中发现这种跨容器IAM凭证暴露的，演示相关技术（称为**"ECScape"**），并分享保护您自身环境的安全经验。通过揭开控制平面的神秘面纱，我们希望为读者提供构建隔离架构的知识，并推动相关改进。

二、内容提要

• • 核心发现：我们找到了一种利用未公开的ECS内部协议的方法，可以窃取同一EC2实例上其他ECS任务的AWS凭证。一个仅具备低权限IAM角色的恶意容器，能够获取同主机上高权限容器的权限。
• • 实际影响：这意味着您ECS集群中某个被入侵的应用程序，只要与高权限任务运行在同一实例上，就能通过窃取凭证冒充后者。不仅任务角色会暴露，AWS文档中声明"容器不可访问"的任务执行角色（由ECS代理使用）同样存在风险——该角色通常拥有从AWS Secrets Manager拉取密钥或访问私有容器仓库等敏感权限。一旦失陷，攻击者就能利用它窃取密钥或构件（artifacts）。
• • 技术原理：Amazon ECS任务通过本地元数据服务（169.254.170.2）获取凭证，每个任务有唯一的凭证端点。我们发现，通过操纵ECS在此过程中识别任务的机制，攻击者可以伪装成ECS代理获取主机上任意任务的凭证。整个过程无需容器逃逸（无需宿主root权限），但需要借助容器自身命名空间内的网络和系统技巧访问IMDS，从而让失陷容器模拟 ECS 代理。ECS官方文档已说明如何通过阻断IMDS访问来防御此类攻击。
• • 隐蔽性：窃取的密钥与真实任务的密钥完全等效。AWS CloudTrail会将API调用记录为受害任务角色的操作，因此初期检测极为困难——攻击行为会表现为受害任务在正常执行操作。
• • 缓解措施：如果您在 EC2 上运行 ECS，请避免将高权限任务与不可信/低权限任务部署在同一实例。关键服务建议采用专用主机或节点隔离，或直接使用AWS Fargate（每个任务运行在独立microVM中实现真正隔离）。尽可能禁用或限制任务的IMDS访问（阻断169.254.169.254、强制IMDSv2或启用ECS的ECS_AWSVPC_BLOCK_IMDS设置）。同时对所有任务IAM角色实施最小权限原则，并移除不必要的Linux能力（限制被入侵容器的操作能力）。下文将详细介绍最佳实践和检测技巧。

快速回顾：在EC2启动类型中，ECS控制平面会承担每个任务角色，通过ACS WebSocket将凭证推送给代理，再由代理通过169.254.170.2分发给任务。ECScape正是滥用了这个交付路径。

三、发现过程

我最初并非专门研究ECS，而是为了完善一个基于eBPF的实时监控工具。为了构建精确的每个任务仪表板，我需要一种快速本地化的方法来实现：进程→容器→ECS任务的映射，并标记集群名称、任务ARN和服务名称等元数据。

在实验中，我首先尝试从Docker容器标签获取数据（ECS会自动为每个任务添加包含任务ARN、任务定义家族（含版本号）、集群ARN和容器名称等标签）。但令人意外的是，这些标签中唯独缺少服务名称。

为获取缺失的服务名称，我转向ECS代理在每个容器网络命名空间内暴露的ECS任务元数据端点（v4版本，位于169.254.170.2/v4/…）。从容器内部查询该端点后，我成功获取了包括服务名称、任务定义族、版本号等完整信息——这完美契合我的监控需求。

出于职业敏感，我思考是否能让eBPF传感器直接模拟代理行为——通过查询相同元数据端点来聚合主机上任意进程的数据。但在尝试前，我复查了EC2实例IAM角色（即附加到容器主机的ecsInstanceRole）的权限，发现一个异常现象：该角色并不具备ecs:ListServices等常规ECS API权限，理论上它无法获取服务名称。然而代理却通过元数据端点准确提供了服务名称——这说明代理显然是从ECS控制平面而非公开API获取的这些信息。

好奇心驱使我进行了网络流量抓包分析。通过搭建本地代理观察ECS代理与AWS端点的通信，我发现了令人震惊的现象：

• • ECS代理建立了到AWS端点的WebSocket连接——后来证实这是ECS代理通信服务(ACS)，即代理与控制平面的专用通道
• • WebSocket握手请求中出现了一个醒目参数：?sendCredentials=true
• • 连接建立后，代理持续通过WebSocket接收明文JSON数据块，其中包含疑似的任务IAM凭证（访问密钥ID、密钥和会话令牌）——这些正是代理后续要分发给对应容器的凭证

此刻我意识到，ECS控制平面正在通过这个WebSocket通道主动推送任务凭证给代理。虽然这是代理向容器分发凭证的正常机制，但一个危险的想法浮现：如果我能劫持这个通道，是否就能获取本不该属于我容器的凭证？ 更关键的是：如果控制平面将所有任务凭证都发送给代理，那我能否伪装成代理，诱骗AWS也向我发送这些凭证？

这个疑问最终催生了ECScape攻击技术——一个探索如何通过突破容器边界并伪装ECS代理来窃取其他任务凭证的攻击场景。

四、ECScape攻击原理：伪装ECS代理窃取其他任务凭证

下面我们将逐步拆解ECScape的实际攻击流程。攻击者（某个容器内的恶意进程）的目标是获取同一EC2主机上所有其他任务的IAM凭证。具体步骤如下：

1. 1. 窃取主机IAM角色凭证：为伪装ECS代理做准备
2. 2. 定位ECS控制平面端点：找到代理通信的目标地址
3. 3. 收集必要标识信息：集群名称/ARN、容器实例ARN等用于身份认证
4. 4. 建立伪造的代理会话：通过WebSocket连接控制平面并请求发送凭证sendCredentials
5. 5. 收割所有运行中任务的凭证：用于后续横向渗透

4.1 步骤1：通过IMDS窃取EC2实例角色凭证

攻击起点是一个已被入侵的容器（EC2上运行的任意低权限ECS任务）。在默认配置下，容器可以访问实例元数据服务（IMDS）。只需向http://169.254.169.254/latest/meta-data/iam/security-credentials/{InstanceProfileName}发送curl请求，即可获取EC2主机IAM角色的访问密钥、秘密密钥和会话令牌——这些正是主机上ECS代理使用的凭证。至此，恶意容器已成功窃取主机角色凭证。

此时攻击者持有EC2实例的临时凭证（代表容器实例的STS会话）。需特别注意：这些凭证并非应用容器的任务角色凭证。由于IAM信任边界限制，仅凭实例配置文件的凭证无法直接接管任务角色：

• • 典型ECS任务角色仅信任服务主体ecs-tasks.amazonaws.com（ECS服务），不信任EC2实例角色本身
• • 实例配置文件的策略通常也不包含对任务角色ARN的sts:AssumeRole权限

因此，若攻击者尝试直接用实例凭证调用AWS STS来担任其他任务角色，将会因任务角色的信任策略（且可能存在IAM权限缺失）而失败。攻击者无法通过常规的 AssumeRole API 调用转向任务角色，必须另辟蹊径——这正是伪装代理的价值所在。

安全须知： 从容器内部读取IMDS（HTTP GET请求）不会被CloudTrail记录，因此初始凭证窃取行为具有隐蔽性。但当攻击者使用窃取的实例凭证调用AWS API时（后续步骤），这些操作将在CloudTrail日志中显示为实例角色所为。

4.2 步骤2：发现轮询端点URL（ecs:DiscoverPollEndpoint）

ECS代理并非与通用的公共API端点通信，而是通过AWS为每个集群和容器实例分配特定的轮询端点进行控制平面交互。攻击者利用窃取的实例角色凭证，调用ECS APIecs:DiscoverPollEndpoint。该API会返回形如https://ecs-a-1..amazonaws.com的专属URL，这正是代理接收ACS消息的真实通信端点。

实例IAM角色默认拥有调用DiscoverPollEndpoint的权限（这是代理正常工作的基础权限）。若API调用意外失败，攻击者仍可能通过特征猜测端点（通常包含区域标识和集群特征值），但直接调用API是最可靠的方式。至此，攻击者已掌握控制平面通信发起连接的目标地址。

4.3 步骤3：收集所需标识信息（集群ARN、容器实例ARN等）

真实的ECS代理连接ACS时需提交多项标识信息，以便后端知道由哪个集群和哪个特定的容器实例（EC2 主机）发起，攻击者必须伪造这些数据才能完成伪装。关键信息包括：

• • 集群ARN：标识ECS集群
• • 容器实例ARN：EC2实例在集群中的唯一标识（本质上是代理的身份凭证）
• • 代理版本信息：客户端版本字符串
• • Docker版本：主机的Docker运行时版本
• • ACS协议版本：ACS消息协议版本
• • 序列号：消息排序的初始序号

攻击者通过先前使用的任务元数据端点（169.254.170.2）可轻松获取集群ARN（每个任务的元数据都包含集群信息）。真正的挑战在于获取容器实例ARN——该信息通常不会通过标准元数据端点暴露给任务。但ECS代理提供了一个自省API（通常从主机访问），可返回容器实例ARN等敏感信息。在漏洞利用过程中，我们发现通过查询特定的本地端点，竟然可以从容器内部获取容器实例ARN。虽然也可以通过AWS API的ecs:ListContainerInstances获取，但这通常需要实例角色不具备的额外IAM权限。最终我们利用代理的自省API成功获取了包括容器实例ARN和代理版本在内的所有关键信息。

关键发现： 容器能访问代理自省API本身就是一个隔离缺陷。该API本应只绑定主机localhost或Unix套接字，但若暴露在链路本地地址且未被iptables规则过滤，容器便可直接访问。虽然这只是攻击链中的一小环，但充分说明了安全暴露面如何被攻击者利用。

至此，攻击者已掌握集群ARN、容器实例ARN等关键标识，完成了伪装ECS代理的全部准备工作。

4.4 步骤4：伪造并签署ACS WebSocket请求（伪装成代理）

此刻，攻击者需要与ECS控制平面建立伪造的代理会话。使用步骤2获取的轮询端点URL（例如https://ecs-a-1.region.amazonaws.com这类形式）和步骤3获得的标识符，攻击者构建一个与真实ECS代理完全相同的WebSocket连接请求。最关键的是，该请求必须使用窃取的实例配置文件凭证进行SigV4签名，这样AWS才会将其认证为来自合法容器实例的请求（真实代理进行API调用时也使用相同的签名流程）。

WebSocket URL包含所有标识符和配置的查询参数，例如：

wss://ecs-a-1.<region>.amazonaws.com/ws?
  agentHash=<agent-hash>&
  agentVersion=<agent-version>&
  clusterArn=arn:aws:ecs:<region>:<account-id>:cluster/<cluster-name>&
  containerInstanceArn=arn:aws:ecs:<region>:<account-id>:container-instance/<instance-uuid>&
  dockerVersion=<docker-version>&
  protocolVersion=<protocol-version>&
  seqNum=1&
  sendCredentials=true

关于此步骤的重要说明：

• • 采用步骤1窃取的实例角色的访问密钥（Access Key）、密钥（Secret）和令牌（Token），使用AWS签名版本4（SigV4）对请求进行签名。实例角色的IAM策略必须至少允许ecs:Poll操作（通常还包括我们使用的ecs:DiscoverPollEndpoint）。默认ECS实例角色策略确实包含ecs:Poll权限，因此没有问题。如果ecs:Poll未被允许，控制平面会拒绝连接。移除ecs:Poll也会破坏真实代理的认证流程，因此该操作不可行。
• • 我们在查询字符串中包含参数sendCredentials=true。这是关键标志，用于告知ACS后端："该代理需要接收此实例上所有任务的IAM凭证 payload"（正常代理始终设置此参数，因为它需要这些凭证）。
• • 将连接升级到 WebSocket 在底层被视为HTTPS请求，因此包含所有常规的签名标头（AWS日期、授权信息等）。握手完成后，连接将保持为持久化的WebSocket。

如果签名和参数全部正确，AWS会接受该WebSocket连接，就像对待真实容器实例上的ECS代理一样。从ECS控制平面的视角来看，我们的恶意进程现在只是该实例的另一个已授权代理会话。

事实证明，AWS并未严格强制实施"每个实例仅限一个代理"的规则。在我的测试中，最终出现了同一容器实例的两个并发连接——一个来自真实的ECS代理，另一个来自我的伪装会话。控制平面会同时向两者发送消息（如果AWS限制每次只能有一个连接，我的伪造代理会话可能会使真实代理离线或被拒绝，从而引发警报。但就目前情况而言，我可以在完全隐蔽的情况下窃听数据流）。

4.5 步骤5：从ACS通道收割所有任务角色凭证

当伪造的WebSocket会话建立后，攻击者将与真实ECS代理共享同一个多路复用的ACS消息流。通过这个通道，ECS控制平面会持续推送结构化消息：心跳包（包含序列号的存活检测）、任务生命周期指令（启动/停止/更新命令）、遥测数据，以及最重要的——IamRoleCredentials凭证载荷。

需要明确ECS处理任务凭证的标准流程：ECS服务（AWS中的ecs-tasks.amazonaws.com主体）会为每个任务角色（以及任务执行角色（如果配置了的话））执行STS:AssumeRole操作。ECS代理从不直接调用STS服务。控制平面会代您承担角色，获取临时凭证，然后通过ACS通道将这些凭证下发给代理。代理将其缓存在内存中，当容器请求凭证时提供给容器（执行角色凭证的传递方式类似，但由代理内部用于拉取镜像、写入日志等操作，不会通过元数据端点暴露）。

由于我们的伪造代理会话包含sendCredentials=true参数，且认证为正确的容器实例，ECS控制平面会推送该实例上所有配置了IAM角色的运行中任务的IamRoleCredentials消息。每条凭证消息包含：任务ARN（用于标识所属任务）、IAM角色ARN、凭证ID（用于元数据URI）、AccessKeyId、SecretAccessKey、SessionToken、过期时间以及角色类型标记（标识是任务的应用角色还是执行角色）。例如，如果该主机上有五个配置了IAM角色的任务，连接建立后我们将立即收到五组独立凭证。其中一组属于我们已攻陷的当前任务（已持有无需获取），但其余凭证属于其他任务——这代表着直接的横向提权机会。

伪造的代理通道还能保持隐蔽性。恶意会话会模拟代理的预期行为——确认消息、递增序列号、发送心跳——因此不会引发异常。ECS实际上允许同一容器实例存在多个认证会话，因此真实代理仍能正常运作并接收相同的凭证消息。从控制平面的视角看，这只是常规的凭证推送流程，毫无异常。

CloudTrail可见性分析：

• • 漏洞利用过程中的AWS API调用（如ecs:DiscoverPollEndpoint和构成WebSocket基础的ecs:Poll长轮询连接）会在CloudTrail中显示为容器实例IAM角色的操作
• • 使用窃取的任务凭证执行的后续操作将显示为任务角色的行为（会话上下文中包含任务ARN）
  这是少数可能的检测点之一：如果任务A的角色突然执行了非常规操作（尤其是在预期上下文或时间窗口之外），就会触发告警。
  关键点：仅通过ACS接收凭证载荷的行为不会产生任何CloudTrail事件——这是AWS到代理的内部推送。

需要注意的限制/细节：

• • 未定义任务角色的实例自然无凭证可窃取
• • 会话建立后启动的任务，其凭证也会通过ACS推送（只要恶意WebSocket保持连接就能持续捕获）
• • ACS流中也会包含执行角色凭证（用于拉取镜像等操作），虽然通常权限有限（如仅限访问该任务的ECR、CloudWatch Logs或Secrets Manager），但在某些攻击场景中仍可利用，或与其他凭证组合使用

总之，ECS将AssumeRole过程集中在控制平面，然后将这些临时凭据“移动”到主机代理，依赖ACS通道的保密性和按任务划分的元数据范围来实现隔离。通过伪装代理的上游连接，ECScape彻底瓦解了这种信任模型：一个被攻陷的容器可以被动收集同EC2实例上所有其他任务的IAM角色凭证，并立即以这些权限执行操作。

五、影响：为何ECScape漏洞危害如此严重

ECScape漏洞对所有在共享EC2主机上运行ECS任务的用户都产生了深远影响：

• • 跨任务权限提升：容器化工作负载通常假设一个被攻陷的应用不会影响其他应用（但EC2 上的 ECS并不保证这种隔离）。ECScape彻底打破了这种假设。一个低权限任务只需窃取其他任务的IAM凭证就能获得高权限。实际上，任何任务都可以权限层面冒充同主机上的其他任务，这直接破坏了多租户和纵深防御体系。例如：假设一个安全扫描容器（仅对少数资源具有只读权限）与数据库备份容器（拥有完整数据库和S3备份访问权限）共同运行。如果扫描容器被攻陷，攻击者就能通过ECScape获取备份容器的IAM角色，从而直接访问数据库或备份数据，您预期的隔离性将完全失效。
• • 主机角色冒充：通过步骤1从IMDS窃取的实例角色凭证，攻击者可以伪装成ECS容器实例与控制平面交互。这意味着攻击者可能：注册伪造任务、下达停止/启动任务指令，甚至将新容器实例注册到集群中...根据AWS的责任共担模型^[7]，EC2实例本身就是安全边界。在使用EC2启动类型时，保护实例级凭证的安全属于客户责任。
• • 执行角色窃取与密钥泄露：ECS控制平面不仅会下发应用角色凭证，还会向代理传送任务执行角色凭证。这些执行凭证本应用于ECS服务自身执行操作（如从私有ECR仓库拉取镜像、从Secrets Manager/Parameter Store获取密钥、向CloudWatch写入日志），严禁被应用程序代码使用。但在ECScape攻击场景中，恶意攻击者可以同时窃取执行角色令牌和应用角色令牌。通过这些凭证，攻击者能够：拉取其他服务的私有容器镜像、访问本应仅限代理使用的密钥或环境变量、读写其他任务的日志流。换言之，即使应用角色权限已被严格限制，窃取执行角色凭证仍可能通过ECR、Secrets Manager、Parameter Store或CloudWatch Logs实现跨任务间接数据窃取。

• • 元数据窃取与侦察：伪装成代理的收益远不止凭证。ACS数据流还携带大量任务元数据，攻击者可借此进行环境侦察，包括：
• • 运行中任务的ARN列表及其任务定义版本
• • 容器镜像ID与摘要
• • 各任务的CPU/内存配置
• • 网络详情（ENI ID、IP地址）
• • 容器实例自身属性（AMI ID、可用区等）
  这些信息能帮助攻击者绘制主机运行图谱，识别高价值目标。

• • 隐蔽性且难以即时检测：ECScape采取的攻击行为具有惊人的隐蔽性。从AWS的视角看，攻击者的所有操作都像正常行为：
• • 用于建立通信通道的ecs:Poll及相关API调用是ECS代理的常规操作（尽管来自同一实例的额外连接可能异常，但本身不会产生明显噪音）。
• • 使用窃取的凭证访问AWS资源时，会显示为合法的task roles在执行操作。CloudTrail日志仅会记录该角色（及任务ARN会话上下文）的行为，而不会显示明显的"第三方"迹象。除非与任务预期行为进行关联分析，否则无法直接判断凭证是否被盗。如果攻击者足够谨慎——例如仅执行符合该角色常规活动的操作（读取该角色通常访问的数据，或在非异常时段执行动作）——可能不会立即触发告警。
• • CloudTrail与审计线索：唯一的好消息是：由于每套任务凭证都关联特定任务ARN，任何AWS中的凭证使用都会归属到该任务角色。因此，如果任务A的凭证被用于执行该任务通常不会进行的操作（尤其在异常时间或不同环境中），调查将显示"任务A的角色在Y时间执行了X操作"——当任务A实际并未执行该操作时，这就构成了可疑证据。AWS文档指出CloudTrail会显示每个API调用所使用的任务角色。在ECScape攻击场景中，最终可能会发现例如Task B的角色在任务B未运行或空闲时执行了某些管理操作——这提示任务B的凭证遭到了滥用。这有助于事件响应（尽管属于事后追溯）。
• • 无需配置错误：ECScape最可怕之处在于它不需要任何明显的用户配置错误。ECS在EC2上的所有默认行为（启用IMDS、具有默认ECS权限的实例角色、多个任务共享EC2主机）已足以支撑攻击实施。换言之，数亿个在默认条件下运行的ECS任务理论上都存在漏洞。这不是"你误开了不该开放的权限"的问题，而更像是共享主机上凭证隔离机制的设计缺陷。

ECScape实机演示如下：

，时长02:31

在ECScape实机演示中，我在同一EC2实例上部署了三个ECS任务，来演示低权限容器如何提权并入侵敏感资源：

• • s3-control-task：该任务具有S3完全访问权限的任务角色，但没有任务执行角色。
• • database-task：该任务不具备任务角色，但其任务执行角色具有获取名为db-secret的密钥的权限，该密钥会作为环境变量注入容器。
• • ecscape-task：攻击者控制的任务。其任务角色附加了Deny *策略（理论上无法访问任何AWS API），且不具备任务执行角色。

演示过程中展示了ecscape-task如何：

• • 窃取s3-control-task的任务角色凭证，并利用其删除S3存储桶——这是该角色原本无法执行的操作。
• • 窃取database-task的任务执行角色凭证，直接打印db-secret的明文内容。

核心结论：当容器与高权限任务共享主机时，即使本身没有有效权限的容器也可能入侵高价值资源。这打破了多数团队依赖的隔离假设。

六、ECS 缓解措施与最佳实践

AWS官方对此问题的回应是：ECS正在按其设计初衷运行：共享同一EC2主机的容器默认处于同一信任域，除非用户主动隔离。换言之，AWS认为这是"预期行为"（其完整回应将在后文详述），因此既未发布补丁也未分配CVE编号。这意味着加固ECS-on-EC2环境的责任落在了用户肩上。 以下关键防护措施可有效防御ECScape类攻击场景：

• • 禁用或限制任务对IMDS的访问：实例元数据服务（IMDS）是攻击者获取实例角色凭证的第一跳。若容器无需访问IMDS，则应彻底阻断其访问路径。AWS支持禁用IMDSv1并强制使用IMDSv2的方法，甚至完全关闭实例的IMDS——但注意：ECS EC2主机上的IMDS若被完全禁用会导致ECS代理功能异常（代理本身需要IMDS获取凭证）。替代方案是通过网络控制阻断容器对169.254.169.254的访问。例如：
• • 使用awsvpc网络模式时，可通过安全组禁止任务ENI向IMDS IP发起的出站流量
• • 使用bridge网络模式时，可在主机配置iptables规则或通过ECS代理的ECS_AWSVPC_BLOCK_IMDS设置限制特定任务
  这是最有效的防护手段：若容器无法访问IMDS，则无法窃取伪装ECS代理所需的实例凭证
• • 限制ECS代理权限（ecs:Poll）：
• • 实例IAM角色必须保有ecs:Poll权限以维持ECS代理基本功能，故不可完全移除
• • 但务必确保任何任务角色都不被授予ecs:Poll或ecs:DiscoverPollEndpoint权限
• • 检查是否存在过度宽松的IAM策略（如任务角色被赋予ecs:*权限），此类配置可能使攻击者无需实例凭证即可自主发起攻击。
• • 隔离高权限任务：
• • 禁止将高敏感/高权限任务与不可信/低权限任务混部在同一EC2实例
• • 对持有管理员角色或访问核心数据的任务，应部署至独立EC2实例（或独立集群）
• • 将每个EC2主机视为故障域——同主机任务应具有相近的信任等级与权限水平
• • 建议为不同安全等级的任务配置专属容量或独立ECS集群
• • 采用AWS Fargate实现强隔离：
• • Fargate任务运行在独立micro VM中，拥有专属IMDS和ECS代理，不存在多任务共享底层主机问题
• • ECScape攻击链在Fargate环境中完全不适用（因为实例没有共同租户）
• • AWS官方明确推荐在多租户场景中使用Fargate以增加隔离性，避免此类风险（但需权衡成本因素）
• • 任务IAM最小权限原则：
• • 继续对所有任务 IAM 角色强制执行最低权限，虽然无法阻止凭证窃取，但可有效控制爆炸半径
• • 若任务A本就不需要管理员权限，即使任务B窃取其凭证也无法获得高权限
• • 理想情况下，即使攻击者入侵某个低权限任务并窃取同主机所有凭证，这些凭证的破坏力也应极为有限。对角色和权限进行划分会显着降低任何一个凭据泄露的价值。
• • 监控与检测机制：建立完善的监控体系以识别可疑行为：
• • 配置CloudTrail告警或AWS Config规则：监测IAM角色的异常使用模式。例如当某任务角色出现以下行为时应立即调查：
• • 在非正常时间段执行AWS操作
• • 从异常IP/地理位置发起调用（如凭证意外在AWS外部使用）
• • 调用该角色通常不会使用的API接口
• • 启用GuardDuty检测：
• • 该服务可识别EC2实例凭证被外部IP使用的情况
• • 对异常API调用模式具有基础检测能力（但针对AWS内部的任务凭证滥用需结合CloudTrail异常检测协同分析）
• • 主机层网络监控：
• • ECS代理通常仅连接特定AWS终端节点，若发现容器进程异常建立与AWS域的WebSocket连接即应告警
• • 正常环境下容器进程不应直接调用ecs:Poll等ECS API
• • 高级检测方案可部署sidecar代理或基于eBPF的监控工具，实时检测容器内实例凭证的使用行为

通过实施上述措施——特别是严格限制任务对IMDS的访问——可显著降低ECScape类攻击的风险。值得注意的是，本研究发布后AWS已更新官方文档，明确警示："同一EC2实例上运行的任务可能获取属于其他任务的凭证"，并强烈推荐使用Fargate获得更强的隔离保障，并通过CloudTrail监控跨任务角色使用情况。

七、负责任披露与AWS官方回应

当我们通过AWS协调披露计划报告ECScape漏洞时，经过技术评审，AWS确认该现象属于ECS在EC2上的设计特性而非安全漏洞。AWS认为：除非用户主动实施隔离，否则共享同一EC2实例的容器默认处于同一信任域。由于未突破AWS的安全边界，AWS未发布CVE编号或安全公告，但强调客户应据此设计架构。

AWS已通过ECS安全最佳实践博客^[8]公开重申这一立场，明确建议需要强隔离的场景应选用Fargate。

尽管如此，AWS仍采取了两个重要举措：

• • 文档更新：
• • 在具有 EC2 启动类型的 ECS 文档中新增警示：若用户未采取防护措施，同一主机上的任务可能获取其他任务的凭证
• • 明确说明任务凭证仅在实例级别隔离（非绝对的任务级隔离），并新增针对此类场景的具体说明
• • 新增Fargate作为强隔离方案推荐，同时强调通过CloudTrail审计任务角色使用情况
• • 此项变更标志着AWS对风险的官方确认，并为客户提供缓解指南

• • 非货币性认可：
• • 由于属于"预期行为"而非漏洞赏金范畴，我们未获得奖金
• • 但AWS在博客文章^[9]中公开致谢本研究
• • 这表明AWS认为该发现值得记录和认可，即使未将其归类为漏洞

从研究者视角看，ECScape深度探讨了ECS如何整合控制平面角色假设、主机凭证分发和容器隔离机制。核心教训在于：必须将每个容器视为潜在突破口并严格限制其影响范围。AWS提供的抽象层（任务角色、元数据服务等）虽然简化了开发，但当不同权限级别的任务共享主机时，其安全性完全取决于隔离机制的强度——而这些机制可能存在微妙缺陷。

随着行业向强隔离模式演进（如Fargate的per-task microVM、Firecracker、gVisor等沙箱技术，乃至Nitro Enclave等硬件隔离方案），这类跨容器凭证窃取将愈发困难。但当前仍有大量环境因成本或管理因素在共享EC2实例上运行异构工作负载。ECScape模糊了配置错误、设计取舍与漏洞利用之间的界限，凸显了纵深防御的重要性。阻断非必要IMDS访问、实施最小权限、隔离关键任务、监控异常行为等不仅是最佳实践清单项目，更是能切断攻击链的关键防御节点。

最终，提升此类场景的安全性需要共同责任：云服务商需持续优化隔离原语和凭证分发机制，云用户则需在设计时假设任何容器都可能变为恶意实体。通过深入理解ECS凭证分发机制（如本文所述）和信任边界，您将能做出更明智的云架构和监控决策。

引用链接

[1] Black Hat USA 2025议题简介:https://www.blackhat.com/us-25/briefings/schedule/#ecs-cape--hijacking-iam-privileges-in-amazon-ecs-45686
[2]Black Hat USA 2025演讲PPT:https://i.blackhat.com/BH-USA-25/Presentations/US-25-Haziz-ECS-cape-Hijacking-IAM-Privileges-in-Amazon-ECS-Wednesday.pdf
[3]PoC源码:https://github.com/naorhaziz/ecscape
[4]Naor Haziz:https://www.sweet.security/author/naor-haziz-2
[5]《ECScape: Understanding IAM Privilege Boundaries in Amazon ECS》:https://www.sweet.security/blog/ecscape-understanding-iam-privilege-boundaries-in-amazon-ecs
[6]**第一部分 - Amazon ECS on EC2深度解析**:https://naorhaziz.com/posts/under-the-hood-of-amazon-ecs/
[7]责任共担模型:https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-shared-model.html#security-shared-model-ec2
[8]ECS安全最佳实践博客:https://aws.amazon.com/blogs/security/security-considerations-for-running-containers-on-amazon-ecs/
[9]博客文章:https://aws.amazon.com/blogs/security/security-considerations-for-running-containers-on-amazon-ecs/