Esaurimento Servizi: Service Exhaustion Flood (T1499.002)

La simulazione controllata di un Service Exhaustion Flood in un contesto red team richiede ambienti isolati (lab virtualizzati o range dedicati) e autorizzazione formale scritta. Eseguire questi test contro infrastrutture di produzione, anche interne, senza pianificazione con il blue team è irresponsabile e potenzialmente illegale.

Per HTTP flood applicativi lo standard di fatto in ambito lab è Apache JMeter (open source), che permette di modellare thread group con centinaia di virtual user contro endpoint HTTP/HTTPS, misurando il degrado di risposta del target. Alternative più leggere sono wrk (open source), utile per benchmark ad alta concorrenza con sintassi minimale come wrk -t12 -c400 -d30s https://target-lab.local/, e hey (open source), pensato per generare carico HTTP configurabile in termini di richieste al secondo. Per test più realistici che includano logica di navigazione, Locust (open source) permette di scrivere scenari in Python con utenti simulati che eseguono flussi applicativi completi.

Per il caso specifico della SSL renegotiation, il tool storico di riferimento è thc-ssl-dos (open source, disponibile su GitHub), che sfrutta l'asimmetria computazionale dell'handshake TLS. Prima di usarlo va verificato se il target abbia la rinegoziazione abilitata: con openssl s_client -connect target:443 si può digitare R durante la sessione per tentare una rinegoziazione manuale. Se il server risponde con un nuovo handshake, è vulnerabile per design a questa classe di attacchi.

Una catena d'attacco tipica in un esercizio red team parte con una fase di reconnaissance applicativa: identificare endpoint costosi in termini di CPU (ricerche full-text, generazione PDF, query complesse), enumerare header di risposta per capire il web server sottostante (Apache, Nginx, IIS) e la sua versione. Segue una fase di baseline: misurare il tempo di risposta normale con carico minimo, per poi incrementare progressivamente la concorrenza fino a osservare il degrado.

Su ambienti Linux, un attaccante interno può stressare un servizio esposto localmente con ab -n 100000 -c 500 http://localhost:8080/expensive-endpoint (Apache Bench, open source, incluso nel pacchetto apache2-utils). Su Windows, PowerShell con Invoke-WebRequest in loop parallelo tramite ForEach-Object -Parallel può generare carico applicativo mirato senza tool esterni. Per test di endpoint API JSON pesanti, k6 (open source) di Grafana Labs consente di scriptare in JavaScript scenari con checkpoint di performance e soglie di failure automatiche.

La detection di T1499.002 si basa sulla correlazione tra picchi anomali di connessioni applicative e degradazione delle risorse di sistema del servizio bersaglio. A differenza dei flood volumetrici, il traffico può essere modesto in termini di pacchetti al secondo ma devastante in termini di richieste applicative.

Su Windows, le fonti chiave sono WinEventLog:Application per errori del web service (IIS, Apache), WinEventLog:Sysmon per correlazione dei processi e Windows:perfmon per il monitoraggio di CPU e memoria per processo. Un pattern d'allarme utile combina il conteggio di connessioni entranti verso porte 80/443/8080 in una finestra temporale (tipicamente 1-5 minuti) con la CPU sostenuta del processo w3wp.exe o httpd.exe sopra soglia (es. 85% per oltre 3 minuti). Le variabili di tuning MITRE definiscono TimeWindow, TargetServicePort e CPUThreshold come parametri chiave.

Su Linux, i log di riferimento sono auditd:SYSCALL, NSM:Flow e linux:syslog. In particolare, monitorare gli access log di Nginx e Apache per burst di codici di risposta 5xx (500, 502, 503) è indicatore diretto di worker exhaustion. Un tasso di connessioni per secondo verso un vhost specifico che superi la baseline storica di 3-4 deviazioni standard merita alert. Utile monitorare anche i segfault dei worker tramite dmesg e i messaggi OOM killer nel journal.

Su macOS, il unifiedlog accessibile via log show --predicate 'subsystem == "com.apple.network"' fornisce visibilità sui servizi hostati (MAMP, Apache). Le variabili chiave sono TLSHandshakeRate (rinegoziazioni al minuto) e ServiceCrashFrequency.

In ambienti IaaS AWS, la telemetria si costruisce combinando AWS:CloudTrail, AWS:VPCFlowLogs e AWS:CloudWatch. Un burst di traffico sulla porta target rilevato dai VPC Flow Logs, correlato a saturazione CPU su EC2 target (>90% per 3+ minuti), costituisce firma robusta. Attenzione anche al pattern di attaccante interno: un'istanza EC2 compromessa che genera flood verso un'altra istanza dello stesso account.

Sul fronte controlli preventivi, la mitigazione M1037 (Filter Network Traffic) suggerisce l'uso di Web Application Firewall per l'ispezione layer 7 e di CDN con protezione DDoS upstream come Cloudflare, Akamai o AWS Shield per assorbire il traffico prima che raggiunga l'origin.

I falsi positivi più frequenti derivano da eventi legittimi di traffico: lanci di prodotto, campagne marketing, crawler dei motori di ricerca (verificare il reverse DNS di IP con volumi anomali), test di carico interni non comunicati al SOC, health check aggressivi di load balancer misconfigurati.

L'analisi forense post-incidente di un Service Exhaustion Flood richiede la ricostruzione della timeline degli eventi correlando artefatti di rete, log applicativi e metriche di sistema. Il primo obiettivo è determinare inizio, durata e picco dell'evento, il secondo è identificare gli IP sorgente e la loro distribuzione geografica, il terzo è quantificare l'impatto sulla disponibilità in termini di richieste fallite e tempo di indisponibilità.

Su Windows Server con IIS, gli artefatti primari sono i log W3C in C:\inetpub\logs\LogFiles\W3SVC/, che contengono timestamp, IP client, user-agent, URI richiesto e tempo di elaborazione (time-taken). Un aumento anomalo del campo time-taken concentrato su specifici endpoint conferma l'esaurimento risorse applicativo. I Windows Event Log nella sezione Application e System registrano eventi ASP.NET (EventID 1309 per unhandled exception, EventID 1325 per worker process recycling) e crash del pool applicativo. I contatori Performance Monitor, se abilitati in continuous logging via Data Collector Sets, forniscono la curva temporale di CPU, memoria e connessioni concorrenti per w3wp.exe.

Su Linux, la ricostruzione parte dagli access log e error log di Nginx o Apache in /var/log/nginx/ e /var/log/apache2/. Il comando awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20 estrae rapidamente i top 20 IP sorgente per volume di richieste. Il file /var/log/syslog o journalctl mostrano OOM killer, segfault dei worker e restart dei servizi. auditd, se configurato per tracciare le syscall di rete, permette di correlare le connessioni accettate dal processo target. Utile anche ss -s e i dati di conntrack per verificare l'esaurimento della tabella di stato del kernel.

Su macOS, il unifiedlog è la fonte principale, accessibile per finestre temporali con log show --start "YYYY-MM-DD HH:MM:SS" --end "...". Per servizi Apache preinstallati o installati via MAMP, i log restano nelle path standard /var/log/apache2/ o nella directory dell'installazione MAMP.

In ambienti cloud AWS, la timeline si ricostruisce da VPC Flow Logs interrogabili via Amazon Athena (a pagamento, pay-per-query) con SQL su S3, filtrando per destination port e destination IP dell'istanza target. CloudWatch Metrics fornisce le curve storiche di CPUUtilization e NetworkIn, mentre CloudTrail documenta eventuali azioni di scaling automatico o modifiche a security group durante l'incidente.

Gli artefatti da preservare per l'analisi includono: log applicativi non ruotati (attenzione alla logrotate policy), snapshot dei processi e delle connessioni al momento del picco (se disponibili tramite EDR come CrowdStrike Falcon o SentinelOne — entrambi a pagamento), dump di memoria del processo web server se il crash ha lasciato core dump abilitati via ulimit -c unlimited.

I dati MITRE ATT&CK forniti per T1499.002 non elencano gruppi APT, software o campagne formalmente attribuite a questa specifica sotto-tecnica. Questa assenza è significativa e va contestualizzata: gli attacchi di Service Exhaustion Flood sono storicamente dominio di attori hacktivisti, cybercriminali con motivazione estorsiva (Ransom DDoS) e operatori di botnet-for-hire, categorie che raramente ricevono attribuzione formale nel database MITRE, orientato prevalentemente al tracciamento di threat actor statuali e cyberespionage.

Dal punto di vista dell'analisi strategica, il valore della threat intelligence su T1499.002 risiede nella comprensione dei pattern di targeting e dei modelli operativi più che nell'attribuzione. I settori storicamente più colpiti includono servizi finanziari e trading online, dove pochi minuti di indisponibilità durante orari di mercato generano perdite quantificabili, e-commerce durante eventi promozionali critici (Black Friday, lanci prodotto), gaming e piattaforme di streaming dove il churn degli utenti frustrati è immediato, media indipendenti e organizzazioni della società civile, target ricorrenti di hacktivismo di regime.

Un trend rilevante riguarda l'evoluzione degli attacchi da volumetrici puri verso tecniche applicative sofisticate. Gli operatori difensivi hanno maturato capacità di mitigazione dei flood UDP e SYN grazie a CDN e scrubbing center, spingendo gli attaccanti verso layer 7, dove le richieste appaiono legittime e richiedono ispezione contestuale. La disponibilità di stresser/booter services commerciali sul dark web ha democratizzato l'accesso a capacità di attacco applicativo un tempo riservate ad attori sofisticati, con abbonamenti mensili accessibili in cryptocurrency.

Un secondo trend è l'abuso di infrastruttura cloud legittima come sorgente di attacco: istanze EC2, container Kubernetes compromessi o account cloud rubati vengono impiegati per originare traffico HTTP flood da IP con reputazione pulita, complicando il filtering basato su reputation. Questa tattica è particolarmente insidiosa contro target che implementano geoblocking o whitelist di provider, poiché il traffico proviene da AWS, Azure o GCP.

Un terzo pattern osservato è la combinazione di T1499.002 con T1657 (Financial Theft) in schemi di Ransom Denial of Service (RDoS): gruppi come quelli che si sono presentati storicamente sotto nomi come Fancy Lazarus o REvil (in operazioni collaterali) hanno inviato richieste di riscatto in Bitcoin minacciando flood applicativi prolungati contro target del settore finanziario e delle telecomunicazioni.

Dal punto di vista della priorità difensiva, il CISO deve valutare l'esposizione dei servizi rivenue-critical e la copertura contrattuale con provider DDoS protection, verificando periodicamente i playbook di attivazione e i tempi di failover verso configurazioni di emergenza (rate limiting aggressivo, challenge JavaScript, CAPTCHA).

MITRE ATT&CK T1499.002 (Service Exhaustion Flood), tattica TA0040 (Impact), mitigazione M1037 (Filter Network Traffic), detection strategy DET0173 con analytics AN0489-AN0492. MITRE D3FEND per mappatura tecniche difensive Network Traffic Filtering e Resource Access Pattern Analysis. Documentazione ufficiale di Apache JMeter, wrk, hey, Locust, thc-ssl-dos, k6, Apache Bench. Per la sezione ethical hacker, SOC e forensic analyst è stata integrata conoscenza professionale di cybersecurity relativa a tool open source verificabili e comandi standard di sistema.