Esaurimento Risorse OS: OS Exhaustion Flood (T1499.001)

Per riprodurre T1499.001 in un contesto di red team autorizzato, l'ambiente di riferimento è un laboratorio isolato con generatori di traffico controllati e un target rappresentativo (tipicamente un server nginx o un servizio TCP legacy) su cui misurare la degradazione. La regola operativa è tassativa: nessun test contro infrastrutture di terzi o di produzione senza autorizzazione scritta.

Lo strumento storico per generare SYN flood è hping3 (open source), disponibile nei repository standard di Kali e Debian. Un test controllato di SYN flood contro un target di laboratorio si esegue tipicamente con una sintassi del tipo:

hping3 -S -p 80 --flood --rand-source

Il flag -S imposta il flag SYN, --flood rimuove il rate limiting interno e --rand-source randomizza gli indirizzi sorgente per simulare uno scenario distribuito. Per l'ACK flood si sostituisce -S con -A, ottenendo pacchetti ACK privi di connessione associata che forzano il kernel target a scansionare la tabella di stato.

Un'alternativa più moderna è hping3 integrato in script Python con Scapy (open source), che consente maggiore controllo sui campi TCP e sulla generazione di sequence number pseudo-casuali. Scapy si presta bene a test di ricerca perché permette di misurare la soglia oltre la quale il target inizia a droppare connessioni legittime. Per volumi più elevati in laboratorio si utilizza TRex (open source, sviluppato da Cisco), un generatore di traffico stateful capace di saturare interfacce da 10Gbps e oltre.

Durante il test, l'ethical hacker deve strumentare il target per raccogliere metriche significative: numero di connessioni in stato SYN_RECV (osservabile con ss -tan state syn-recv su Linux), utilizzo di CPU in softirq, e latenza di risposta di un client legittimo che tenta connessioni parallele. Questo permette di distinguere tra un attacco che satura effettivamente il backlog e uno che invece degrada la macchina per altre vie (interrupt storm, ad esempio).

Lato mitigazioni da validare nel post-test, vanno verificate configurazioni come SYN cookies (parametro net.ipv4.tcp_syncookies su Linux), tuning di tcp_max_syn_backlog, e presenza di appliance upstream. Il report al cliente deve includere la soglia di traffico oltre la quale il servizio degrada, il tempo di recovery dopo la cessazione del flood, e raccomandazioni concrete su rate limiting a livello di edge firewall o CDN. Tool come iperf3 (open source) servono invece a stabilire la baseline di banda utile prima del test.

La detection di OS Exhaustion Flood si basa principalmente su telemetria di rete e su segnali di degrado a livello di stack TCP dell'endpoint. Le tre analytic MITRE di riferimento (AN1012 per Windows, AN1013 per Linux, AN1014 per macOS) convergono su un pattern comune: burst di pacchetti SYN o ACK non correlati a connessioni legittime, concentrati in finestre temporali brevi (30 secondi–2 minuti) verso porte di servizio esposte.

Su Windows le fonti primarie sono i log Microsoft-Windows-TCPIP e la telemetria Sysmon (open source), correlati con feed NSM dal firewall perimetrale. Gli eventi da monitorare includono il rapido incremento di connessioni in stato half-open e i warning del kernel TCP/IP relativi a esaurimento di risorse. Un alert efficace incrocia il rate di pacchetti SYN in ingresso con l'assenza del corrispondente ACK finale del client, indicatore diretto di handshake incompleti.

Su Linux la telemetria utile arriva da auditd sui syscall di rete (accept, socket) e da flussi NSM raccolti tramite Zeek (open source) o Suricata (open source). Un contatore prezioso è /proc/net/netstat, in particolare la metrica TCPBacklogDrop che cresce quando il kernel scarta connessioni per backlog pieno. Anche ListenOverflows e ListenDrops sono segnali diretti. La query può essere strumentata con node_exporter di Prometheus (open source) per generare alert su derivate temporali di questi contatori.

Su macOS le fonti sono l'unified log e osquery (open source), che espone la tabella process_open_sockets utile a rilevare processi locali che aprono volumi anomali di socket — scenario di attacco interno o compromise che usa l'host come vettore.

I parametri di tuning critici sono la soglia di connection rate (tipicamente 500–2000 SYN/s per host di produzione medi, ma va calibrato sulla baseline), la finestra di aggregazione e la verifica del parent process nel caso l'attacco parta da un host interno compromesso. È fondamentale distinguere tra flood esterni (che si vedono al perimetro) e traffico legittimo di picco: eventi come rilascio di aggiornamenti software, apertura di trading window o campagne marketing generano burst legittimi che vanno esclusi tramite allow-list di sorgenti note.

I falsi positivi più frequenti includono scanner di vulnerabilità autorizzati, load test schedulati e retry aggressivi di client mal configurati. Un correlation rule maturo incrocia il segnale di rete con l'assenza di ticket di change management aperti nella finestra temporale, riducendo drasticamente il rumore. L'integrazione con la mitigazione M1037 (Filter Network Traffic) — abilitazione di SYN cookies e filtering upstream via CDN — chiude il ciclo detection-response.

L'analisi forense di un incidente di OS Exhaustion Flood ha caratteristiche particolari: essendo una tecnica di Impact prevalentemente network-based, gli artefatti significativi risiedono in gran parte in log volatili o esterni all'endpoint, e la timeline va ricostruita correlando fonti eterogenee.

Su Linux, gli artefatti chiave includono i contatori del kernel TCP catturati (idealmente) da un agent di monitoring durante l'evento: /proc/net/netstat con metriche TCPBacklogDrop, ListenOverflows, ListenDrops, e /proc/net/sockstat per il conteggio di socket in TIME_WAIT e SYN_RECV. Se il sistema aveva attivo auditd con regole sui syscall di rete, i record SYSCALL per accept() e socket() mostrano il pattern di richieste. Il journal di systemd spesso contiene messaggi del tipo TCP: request_sock_TCP: Possible SYN flooding on port XXXX generati automaticamente dal kernel quando l'euristica interna rileva la condizione — questo è uno degli artefatti forensi più affidabili per datare l'inizio dell'attacco.

Su Windows, i canali Microsoft-Windows-TCPIP/Operational e il log System contengono eventi legati a esaurimento di risorse TCP. Sysmon con configurazione network-aware registra le connessioni entranti anomale. Le performance counter storiche (se PerfMon era attivo) mostrano il picco di TCPv4\Connections Reset e Segments Received/sec. Per macOS, l'unified log conserva messaggi del kernel network stack, estraibili con log show --predicate 'subsystem == "com.apple.network"' --start .

La timeline forense dovrebbe integrare log del firewall perimetrale, NetFlow o Zeek conn.log (open source) per ricostruire la distribuzione degli IP sorgente e la durata del flood. Nei casi di attacchi distribuiti reali, gli IP sorgente sono tipicamente spoofati o appartengono a botnet: pivotare su feed di threat intelligence per verificare la presenza in blocklist note aiuta l'attribuzione. Piattaforme come AbuseIPDB (freemium) o GreyNoise (freemium) permettono di caratterizzare rapidamente le sorgenti.

Un elemento spesso trascurato è la ricerca di attività laterale durante o subito dopo il flood: l'esaurimento di risorse è frequentemente usato come diversivo per coprire esfiltrazioni o movimenti laterali. L'analista deve espandere la finestra di analisi ±30 minuti rispetto al picco e cercare accessi anomali, esecuzioni di binari sospetti, o modifiche a policy di sicurezza su asset critici. La ricostruzione tramite Plaso/log2timeline (open source) aiuta a costruire una supertimeline che correli eventi di rete e host.

Per la conservazione delle evidenze, la priorità è acquisire immediatamente i log di firewall, IDS e router (soggetti a rotazione rapida), le catture PCAP se disponibili, e uno snapshot dei contatori del kernel prima che il sistema venga riavviato per il recovery.

I dati MITRE ATT&CK forniti per T1499.001 — OS Exhaustion Flood non associano gruppi APT, software o campagne specificamente documentate a questa sotto-tecnica. Questa assenza è essa stessa un dato di intelligence significativo: gli attacchi di esaurimento OS sono per natura commodity, spesso attribuiti a attori non-state, gruppi hacktivisti, botnet-as-a-service commerciali e crimine organizzato con motivazioni estorsive, più che ad APT strutturate con obiettivi di spionaggio.

Dal punto di vista dell'analisi di intelligence, questo posiziona T1499.001 in una categoria di rischio orizzontale: qualunque organizzazione con servizi esposti è un target potenziale, e il costo di ingaggio per l'attaccante è basso. I broker di stresser/booter service commerciali offrono capacità di flood a prezzi accessibili, spostando la barriera d'ingresso da competenza tecnica a semplice disponibilità economica. Questo cambia la modellazione della minaccia: il threat actor rilevante non è il gruppo APT nation-state, ma il cliente occasionale del servizio DDoS.

I pattern di targeting osservabili in questa classe di attacchi coincidono con motivazioni estorsive (Ransom DDoS, spesso preceduto da nota di riscatto che minaccia flood prolungati), hacktivismo (targeting di siti governativi o media in relazione a eventi geopolitici), competizione commerciale sleale verso servizi online, e diversione durante operazioni di intrusione più sofisticate. Quest'ultimo pattern è particolarmente rilevante per team di threat intelligence che supportano SOC: un flood improvviso su un servizio esposto va sempre correlato con eventuali segnali deboli di intrusione su altri asset dell'organizzazione nella stessa finestra temporale.

La collocazione tattica nella fase TA0040 (Impact) implica che, quando osservata come tecnica primaria, l'obiettivo è la disruption; quando osservata in combinazione con tecniche di Initial Access o Exfiltration, va interpretata come manovra di copertura. La produzione di intelligence utile in questo dominio si concentra su tracking di infrastrutture di command & control delle botnet, monitoraggio di forum underground dove vengono venduti servizi di stress test illegali, e correlazione tra eventi geopolitici e ondate di attacchi verso specifici settori (finanziario, energetico, media).

Sul piano dei trend evolutivi, si osserva una convergenza tra tecniche di esaurimento OS classiche e amplification attack a livello applicativo, con attaccanti che combinano più vettori simultanei per aggirare mitigazioni specifiche. La mitigazione M1037 (Filter Network Traffic) rimane efficace se implementata a livello upstream tramite CDN o scrubbing center dedicati, mentre le difese solo on-premise sono strutturalmente insufficienti contro flood volumetrici distribuiti. Il threat intelligence officer dovrebbe includere nei report periodici la baseline di traffico osservato e le variazioni stagionali, per contestualizzare eventuali picchi anomali.

MITRE ATT&CK T1499.001 (OS Exhaustion Flood), tattica TA0040 (Impact), mitigazione M1037 (Filter Network Traffic), analytic AN1012/AN1013/AN1014 della detection strategy DET0356. Riferimenti D3FEND per artefatti di rete e Network Traffic Analysis. Documentazione ufficiale di hping3, Scapy, Zeek, Suricata, osquery, auditd e parametri kernel Linux net.ipv4.tcp_*. Per redazione dei contenuti operativi (comandi, tool, artefatti) è stata utilizzata conoscenza professionale in ambito cybersecurity, limitata a strumenti open source e servizi verificabili.