Protocolli, web attacks e C2 detection

Quando analizzi un evento di sicurezza, il primo riflesso deve essere mappare l’artefatto al protocollo che lo trasporta. Ogni protocollo lascia tracce diverse in un packet capture o nei log NetFlow, e conoscere il layer giusto ti dice dove cercare l’indicatore.

Dai protocolli agli eventi

Il punto chiave d’esame: ARP vive a Layer 2 e non ha indirizzo IP sorgente/destinazione; un evento di poisoning si riconosce da un MAC che risponde per più IP o da gratuitous ARP non richiesti. ICMP è Layer 3 e non usa porte: attributi come Type e Code, non i port number, identificano l’anomalia.

Riconoscere i web attack

Sul traffico HTTP in chiaro (o dopo decrypt) tre famiglie dominano gli scenari:

• SQL injection — payload nell’URI o nel body con ' OR 1=1--, UNION SELECT, commenti SQL (--, #), spesso URL-encoded (%27 per l’apice). Bersaglio: il database dietro l’applicazione.
• Cross-Site Scripting (XSS) — iniezione di <script>, gestori onerror=/onload=, tag <img> malformati. Bersaglio: il browser di un altro utente, non il server; è un attacco client-side che sfrutta il mancato output-encoding.
• Command injection — metacaratteri di shell (;, |, &&, `, $()) uniti a comandi come whoami, cat /etc/passwd. Bersaglio: l’OS che esegue il comando lato server.

Distinguere la vittima è ciò che l’esame verifica: SQLi colpisce il DB, XSS il browser della vittima, command injection il sistema operativo dell’host.

Traffico cifrato: perché serve TLS inspection

Con TLS il payload applicativo è illeggibile: non vedi né l’URI né il body, quindi le firme HTTP classiche sono cieche. Hai due strade:

1. TLS inspection (decrypt) — un dispositivo come Firepower/NGFW o un proxy fa da terminatore, decifra, ispeziona e ricifra. Richiede la gestione delle chiavi/certificati e ha impatto su privacy e performance.
2. Analisi dei metadati — senza decifrare guardi SNI, il certificato del server, l’impronta JA3/JA3S del client/server, la cadenza e la volumetria dei flussi. È l’approccio quando il decrypt non è praticabile (pinning, compliance).

Rilevare il Command-and-Control (C2)

Un impianto compromesso deve “chiamare casa”. I due pattern d’esame:

• Beaconing — la macchina infetta contatta il C2 a intervalli regolari (es. ogni 60 s, spesso con jitter). Il tratto distintivo non è il contenuto ma la periodicità: connessioni ripetute allo stesso destinatario, di dimensione simile, a cadenza fissa. Lo riconosci in NetFlow anche se il payload è cifrato.
• DNS tunneling — i dati vengono incapsulati nei nomi DNS: sottodomini lunghi ed encodati (Base32/hex), alto volume di query verso un unico dominio autoritativo, record type insoliti (TXT, NULL, CNAME). Sfrutta il fatto che il DNS è quasi sempre permesso in uscita.

L’idea forte: il comportamento (regolarità, volumetria, entropia dei nomi) tradisce il C2 anche quando la crittografia nasconde il payload. È qui che l’analisi dei metadati e del pattern batte le firme sul contenuto.

Trappole tipiche d’esame

• Scenario: connessioni ricorrenti ogni 30 s verso lo stesso IP esterno, payload TLS illeggibile. → Risposta giusta: è beaconing C2; lo si identifica dalla periodicità/regolarità dei flussi (metadati), non serve decifrare il payload.
• Scenario: picco di query DNS con sottodomini lunghi e casuali verso un unico dominio, molti record TXT. → Risposta giusta: DNS tunneling per esfiltrazione/C2, non semplice traffico DNS legittimo.
• Scenario: nel body HTTP compare <script>alert(1)</script>. → Risposta giusta: XSS; la vittima è il browser di un altro utente, non il server né il database.
• Scenario: un host risponde in ARP per più indirizzi IP con lo stesso MAC. → Risposta giusta: ARP spoofing/MITM a Layer 2; ARP non ha IP sorgente affidabile, ci si basa sul mapping IP↔MAC.
• Scenario: serve ispezionare traffico HTTPS ma il payload è cifrato. → Risposta giusta: applicare TLS inspection/decrypt (es. Firepower/proxy) oppure, se il decrypt non è possibile, analizzare metadati (SNI, certificato, JA3).