// 2 ZERO-DAY · 2 CVE · 4 EXPLOIT NELLE ULTIME 24H

Esercizio di Laboratorio Consolidato: Simulazione Completa della Valutazione Wintermute

Bene. Hai passato nove pagine a costruire strumenti, scomporre concetti e osservare fallimenti in modi prevedibili. Ora li colleghiamo. Non è una CTF — non mi interessa se ottieni una shell. Mi interessa se sai guardare una rete, capire cosa vede un attaccante, e annotare cosa deve correggere un difensore. Questo è il lavoro.

Lab Wintermute di nuovo: Kali su 192.0.2.10, Metasploitable2 su 192.0.2.20, DVWA su 192.0.2.30. Rete NAT air-gapped. Snapshot acquisiti prima di iniziare, come descritto a Pagina 4. Vediamo il flusso di engagement che uso effettivamente per formare i junior.


Pre-Engagement: La Parte Noiosa che Salva le Carriere

Prima di toccare una tastiera, apro il documento di scope. Per Wintermute, è una autorizzazione di una sola pagina firmata dall'istruttore del corso che specifica i range IP (192.0.2.20–192.0.2.30), le tecniche permesse (ricognizione, identificazione vulnerabilità, revisione concettuale dell'exploitation — nessun accesso persistente), e i limiti temporali. Nessuna firma, nessun pacchetto. Ho visto studenti saltare questo passo nei laboratori pratici; in un engagement reale, questa è la differenza tra uno stipendio e una condanna penale.

La conferma dello snapshot viene dopo. Verifico lo stato di rollback in VirtualBox — la piccola icona a freccia accanto a ogni VM che indica uno snapshot salvato. Se il tuo lab non ha snapshot, fermati. Creane uno. Lo snapshot è la tua macchina del tempo; quando inevitabilmente misconfiguri un servizio durante l'ispezione, ripristini invece di ricostruire. Confermo anche l'isolamento di rete: la rete NAT denominata "Wintermute-Isolated" senza alcuna scheda esterna collegata alla VM Kali. Controlla questo nelle impostazioni di Rete di VirtualBox — L'Adapter 1 dovrebbe mostrare "NAT Network: Wintermute-Isolated," non "Bridged Adapter."

Perché questo è importante: Un adapter bridged collocerebbe la tua VM di attacco sulla stessa rete della macchina host, potenzialmente raggiungendo Internet o i tuoi dispositivi domestici. La modalità "NAT Network" in VirtualBox crea una rete software interna visibile solo alle VM membro.


Fase 1: Ricognizione Guidata da Python

Abbiamo costruito gli script di ricognizione a Pagine 5 e 6. Ora li eseguiamo in sequenza contro entrambi i target, raccogliendo output strutturato per l'analisi successiva.

Per prima cosa, lo script di discovery degli host — quello che scansiona la /24 per confermare che i nostri due target sono attivi. Da Kali:

python3 wintermute_hostdiscover.py --subnet 192.0.2.0/24 --output hosts.json

Questo emette un file JSON con gli host responsivi, i loro indirizzi MAC (utili per confermare che stai parlando con la VM corretta, non un dispositivo rogue), e i tempi di andata e ritorno. Guardo sempre il prefisso vendor del MAC — Metasploitable2 mostra tipicamente un OUI VirtualBox (00:08:27 o simile), che conferma che sono nel lab e non sto accidentalmente sondando la stampante del mio coinquilino.

⚠️ Solo uso autorizzato e difensivo.

Poi, l'enumerazione dei servizi contro i target confermati. Lo script che abbiamo costruito combina una scansione delle porte TCP con il banner grabbing:

python3 wintermute_services.py --target 192.0.2.20 --top-ports 1000 --output m2_services.json
python3 wintermute_services.py --target 192.0.2.30 --top-ports 1000 --output dvwa_services.json

Il flag --top-ports 1000 restringe la selezione delle porte di Nmap alle mille porte più comuni, mantenendo la durata della scansione gestibile per il lavoro di laboratorio. Per una valutazione completa useresti -p- (tutte le 65535 porte), ma in formazione, la velocità conta più della completezza.

Cosa cerco qui: su 192.0.2.20, mi aspetto di vedere SSH (22), FTP (21), Telnet (23), e servizi correlati a NFS. Il servizio NFS può essere identificato sondando direttamente la porta 2049, o interrogando il portmapper (porta 111) per la sua lista di servizi registrati [S2]. Su 192.0.2.30, mi aspetto HTTP (80) e possibilmente MySQL (3306) se il database di DVWA è esposto.

Il componente di banner grabbing cattura le stringhe di versione. Queste sono critiche — sono il modo in cui mappiamo alle vulnerabilità senza ancora exploitare nulla. Un banner come vsftpd 2.3.4 è un nome e un numero di versione che alimenteremo nella fase successiva.


Fase 2: Mappatura delle Vulnerabilità con NVD

È qui che i nostri fondamenti di Python ripagano. Abbiamo costruito uno script nelle pagine precedenti che interroga l'API v2.0 del NIST National Vulnerability Database (NVD) [S1][S6]. L'API v1.0 è stata ritirata nel dicembre 2023 [S6], quindi se hai copiato codice vecchio da Stack Overflow, si è rotto. L'API attuale risiede su https://services.nvd.nist.gov [S3] e richiede una API key per limiti di rate più alti.

Lo script legge i nostri banner di servizio, costruisce stringhe CPE (Common Platform Enumeration), e interroga il NVD:

python3 wintermute_nvd_mapper.py --services m2_services.json --api-key $NVD_KEY --output vuln_map.json

L'API NVD v2.0 include un parametro apiKey e un campo message per le informazioni di debugging [S6]. Imposto la mia key come variabile d'ambiente invece di hardcodarla — igiene di base. Lo script mette in pausa tra le richieste per rimanere educato; anche in laboratorio, alleno la disciplina del rate-limiting.

Cosa torna: identificatori CVE, punteggi di severità CVSS, e descrizioni. Per vsftpd 2.3.4, vedrai probabilmente una vulnerabilità di backdoor del 2011. È qui che mi fermo e spiego agli studenti: il CVE non significa che il target è vulnerabile. Significa che la versione del software potrebbe esserlo, se non patchata. La conferma richiede exploitation (fuori scope per il nostro focus difensivo) o evidenza aggiuntiva come il comportamento specifico del backdoor nel banner.

Correlo questi risultati manualmente in uno semplice script Python usando il modulo json — caricando sia l'inventario dei servizi che la mappa delle vulnerabilità, poi stampando una tabella di "servizio → versione → lista CVE." Nessun framework sofisticato necessario; l'apprendimento sta nel capire la mappatura, non nel perfezionamento dello strumento.


Fase 3: Comprensione dell'Exploitation Controllato

Ora camminiamo sul filo del rasoio. Metasploit è installato su Kali; lo usiamo per comprensione educativa, non per esecuzione contro target di produzione.

Avvio msfconsole e dimostro la selezione dei moduli per una vulnerabilità scoperta. I tipi di modulo Metasploit includono Exploit, Auxiliary, Payload, NOP, Post-exploitation, e Encoder [S4]. Per il nostro lab, mi concentro sui moduli Auxiliary — scanner e raccoglitori di informazioni che non consegnano payload.

Supponiamo di aver trovato un potenziale punto di template injection. Mostro la struttura del percorso del modulo: exploit/linux/http/skyvern_ssti_cve_2025_49619 [S5]. Il percorso racconta una storia — è un exploit contro un target Linux, via HTTP, nell'applicazione Skyvern, usando server-side template injection. Il numero CVE si lega ai record NVD. Spiego che un exploit usa un payload per consegnare codice da eseguire su un'altra macchina [S4], e che il payload apre una shell o una sessione Meterpreter per la post-exploitation [S4].

⚠️ Solo uso autorizzato e difensivo.

Ma ecco il momento critico di insegnamento: non eseguo l'exploit in questa fase del lab. Invece, dimostro la selezione del modulo, la revisione delle opzioni (show options), e l'esame dei payload (show payloads). Poi chiedo: cosa vedrebbe un difensore? Quali log genererebbe questo? Quali indicatori di rete? L'equivalente difensivo è capire l'attacco abbastanza bene da scrivere regole di rilevamento, non per replicare il danno.

Per CVE-2025-33053, noto che il modulo rilascia un file .url malevolo che raggiunge un server SMB controllato dall'attaccante [S5]. La risposta di un difensore: monitorare la creazione di file .url nelle directory utente, bloccare SMB in uscita verso host non attendibili, e formare gli utenti sulla componente di social engineering che consegna tali file.

Metasploit ora supporta anche il tagging con il framework MITRE ATT&CK nei riferimenti dei moduli [S5] — indico agli studenti questi tag così imparano a mappare le tecniche al linguaggio comune che usano i difensori.


Fase 4: Documentazione e Generazione del Rapporto

Un penetration test senza documentazione è indistinguibile da un attacco. Usiamo Python per strutturare i nostri risultati in un rapporto difendibile.

Ho costruito un semplice motore di template basato su Jinja negli esercizi di Pagina 3. I template Jinja usano segnaposto speciali che permettono sintassi simile a Python per il rendering di documenti con dati passati [S8]. Il mio script carica la mappa delle vulnerabilità e la renderizza:

python3 wintermute_report.py --findings vuln_map.json --template report_template.j2 --output wintermute_assessment.md

Il template include sezioni per: Executive Summary (rischio in termini di business), Risultati Tecnici (ogni vulnerabilità con evidenza), Host Interessati, e Rimediazione. Per ogni risultato, richiedo agli studenti di includere: il comportamento osservato (cosa abbiamo visto), la debolezza sottostante (perché è un problema), il controllo difensivo (come correggerlo), e il rischio residuo se non affrontato.

Le valutazioni di rischio le tengo semplici: Critico (exploitable da remoto, nessuna autenticazione, alto impatto), Alto (exploitable con bassa complessità), Medio (richiede condizioni o azione utente), Basso (information disclosure, impatto minimo). Non uso direttamente il CVSS per le valutazioni — è troppo granulare per la comunicazione esecutiva. Lo uso come input, poi applico giudizio basato sull'esposizione effettiva dell'ambiente target.


Post-Engagement: Chiusura Pulita

L'ora finale di ogni engagement conta quanto la prima. Verifico la capacità di ripristino dello snapshot — non ripristinando ancora, ma confermando che l'albero degli snapshot in VirtualBox mostri il nostro stato pre-engagement intatto. Solo dopo la consegna del rapporto e la revisione dell'istruttore procedo effettivamente al rollback, preservando il lab per lo studente successivo.

Conservazione delle prove: tengo gli output JSON, il rapporto renderizzato, e il documento di scope in una directory datata. Non specifico tempistiche di conservazione — la policy organizzativa varia, e nei contesti di formazione l'istruttore stabilisce queste regole [Coverage Gap]. Il principio è: conserva abbastanza per difendere il tuo lavoro se contestato, non così tanto da diventare tu stesso un rischio di data breach.

Sessione di lezioni apprese — scrivo tre miglioramenti difensivi che avrebbero impedito ogni risultato. Per il backdoor di vsftpd: processo di patch management, segmentazione di rete che impedisca l'esposizione FTP, e monitoraggio dell'integrità sui binari critici. Questo trasforma l'esercizio da "ho trovato un buco" a "capisco come il buco si è formato e come chiuderlo sistematicamente."


Nota Metacognitiva: Cosa Testa Effettivamente Questo Esercizio

Ho osservato studenti affrettarsi attraverso Wintermute trattandolo come un gioco da vincere. Quelli che diventano analisti utili rallentano in ogni fase e si chiedono: cosa dovrei spiegare a un amministratore di sistema a cui non importa dei miei strumenti? Quell'amministratore vuole sapere: è reale, è urgente, e cosa faccio lunedì mattina?

Se sai rispondere a queste tre domande dai tuoi dati raccolti con Python, hai passato. Non perché hai exploitato qualcosa. Perché l'hai capito abbastanza bene da rendere più sicuro il sistema di qualcun altro. Questo è il lavoro.

Letture consigliate