Mappa Globale#
Cosa fa#
Un penetration test e' un attacco simulato e autorizzato che misura la resistenza effettiva delle difese. A differenza del vulnerability scanning che si ferma all'identificazione, il pentest sfrutta attivamente le vulnerabilita' per dimostrare l'impatto concreto. Il documento critico e' la Rules of Engagement (ROE): senza ROE scritte, qualsiasi test diventa un reato, indipendentemente dalle intenzioni.
1. Planning#
La fase di planning definisce i confini entro cui il pentest puo' operare. E' la fase piu' importante: un test senza scope definito puo' causare danni reali e problemi legali.
Black-box vs White-box vs Gray-box:
| Tipo | Info disponibili | Simula | Pro | Contro |
|---|---|---|---|---|
| Black Box | Zero - nessuna info sul target | Attaccante esterno ignoto | Piu' realistico | Lento, puo' mancare vuln interne |
| White Box | Totale - codice, architettura, credenziali admin | Insider malintenzionato o audit interno | Massima copertura | Meno realistico, richiede piu' coordinazione |
| Gray Box | Parziale - credenziali utente base, schema rete | Dipendente compromesso, attaccante con foothold | Bilanciato | Il piu' comune in real world |
Dev parallel: black-box e' come testare un'API pubblica senza documentazione. White-box e' come fare una code review con accesso al repo completo. Gray-box e' come un integration test dove conosci i contratti delle API ma non l'implementazione interna.
2. Reconnaissance#
La recon raccoglie informazioni sul target prima di toccare qualsiasi sistema. La distinzione chiave e' tra passive (solo fonti pubbliche, nessun contatto diretto) e active (si interagisce con i sistemi target).
La network reconnaissance engage i target: e' quasi sempre illegale senza ROE esplicite. Passive recon (solo fonti pubbliche) e' legale anche senza autorizzazione. La linea di confine e' "hai toccato i loro sistemi?".
3. Scanning e Enumeration#
Dopo la recon passiva, il pentester mappa i servizi attivi e le versioni per capire dove cercare vulnerabilita' specifiche. In questa fase si usano vulnerability scanner che confrontano i servizi trovati con database di CVE noti.
flowchart LR
RECON[Recon OSINT] --> PORTSCAN[Port Scan Nmap]
PORTSCAN --> SERVICES[Service Enumeration]
SERVICES --> VULNSCAN[Vulnerability Scanner]
VULNSCAN --> FP[False Positive?]
FP -->|si - manuale| VERIFY[Verify Manualmente]
FP -->|no| EXPLOIT[Exploitation Phase]
VERIFY --> EXPLOIT
Lettura diagramma: La recon OSINT alimenta il port scan. L'enumerazione dei servizi identifica versioni. Il vulnerability scanner incrocia le versioni con i CVE noti. I falsi positivi vanno verificati manualmente prima di passare all'exploitation.
Credentialed vs Non-credentialed scan:
| Tipo | Come | Simula | Trova |
|---|---|---|---|
| Non-credentialed | Nessun account, solo accesso rete | Attaccante esterno | Servizi esposti, versioni vulnerabili |
| Credentialed | Account utente fornito dal cliente | Insider / attaccante con foothold | Patch mancanti, configurazioni errate, permessi eccessivi |
4. Exploitation#
La fase di exploitation e' dove il pentest si distingue dal vulnerability scan: anziche' fermarsi alla lista delle vulnerabilita', il pentester le sfrutta per dimostrare l'accesso reale. Il principio fondamentale e' che un exploit deve essere bloccato prima di causare danni irreversibili — il pentest si ferma alla proof-of-concept, non esegue l'esfiltrazione completa dei dati di produzione.
5. Post-Exploitation#
Il post-exploitation simula cosa farebbe un attaccante reale dopo aver ottenuto il primo accesso: spostarsi lateralmente verso altri sistemi, installare persistenza per mantenere l'accesso, e raggiungere l'obiettivo finale (dati sensibili, sistemi critici).
Dev parallel: il lateral movement in un pentest e' come un supply chain attack nel tuo stack PHP. Hai compromesso un servizio di terze parti (accesso iniziale), usi quella sessione per leggere environment variables con credenziali del database, poi accedi al database e da li' al file storage S3. Ogni passo usa le credenziali trovate nel passo precedente: e' esattamente il "pivot".
6. Reporting#
Il report e' l'output che il cliente ha pagato. Un pentest senza report scritto non ha valore: il cliente non sa cosa aggiustare, e il pentester non ha documentazione del lavoro svolto (necessaria anche legalmente).
Bug Bounty come variante white-hat:
I programmi di Bug Bounty sono una forma di pentest continuo ma con regole diverse: scope limitato definito dal vendor (spesso solo alcuni asset), pagamento per vulnerabilita' valide trovate (da centinaia a milioni di dollari), e segnalazione tramite piattaforme come HackerOne o Bugcrowd. La differenza fondamentale da un pentest tradizionale: il bug bounty ha scope pubblico, non e' un assessment completo, e non include post-exploitation o lateral movement.
| Penetration Test | Bug Bounty | |
|---|---|---|
| Scope | Definito per contratto | Pubblico, definito dal vendor |
| Output | Report completo | Singola vulnerabilita' per submission |
| Post-exploitation | Si (in scope) | No (quasi mai in scope) |
| Pagamento | Fisso (contratto) | Per vulnerabilita' trovata |
| Durata | Definita | Continuo / sempre aperto |
Collegato a#
- passive-reconnaissance - tecniche OSINT della fase recon
- mitre-attack-framework - mappatura TTP nelle fasi di exploitation e post-exploitation
- kill-chain - framework alternativo per le fasi del pentest
- lateral-movement - tecniche post-exploitation in dettaglio
- red-blue-purple-team - contesto dei ruoli offensivi e difensivi
- cve-nvd - database vulnerabilita' usato nella fase scanning
