Esaurimento Applicativo: Application Exhaustion Flood (T1499.003)
La tecnica T1499.003 - Application Exhaustion Flood appartiene alla tattica TA0040 (Impact) del framework MITRE ATT&CK e rappresenta una forma sofisticata di Denial of Service che colpisce non l'infrastruttura di rete, ma specifiche funzionalità applicative particolarmente onerose in termini di risorse computazionali.
A differenza dei classici flood volumetrici che saturano la banda, questa tecnica sfrutta operazioni legittime ma costose lato server: ricerche complesse su database, generazione di report, operazioni crittografiche, upload di file, endpoint di autenticazione che innescano hashing lento come bcrypt. Bastano poche decine di richieste al secondo, indistinguibili da traffico legittimo a livello di volume, per portare CPU e memoria al 100% e rendere l'applicazione irraggiungibile.
L'attaccante conduce prima una fase di ricognizione per mappare gli endpoint più esosi — tipicamente identificando quelli con tempi di risposta più lunghi — e poi orchestra richieste ripetute e mirate. L'impatto operativo è duplice: interruzione del servizio con perdite dirette di fatturato per applicazioni transazionali, e possibile copertura per attività secondarie come exfiltration o brute force distribuiti su altri vettori.
Questa variante è particolarmente insidiosa perché aggira molte protezioni tradizionali: firewall di rete e mitigazioni volumetriche non rilevano anomalie quando il traffico rimane sotto le soglie di banda, e i WAF basati su signature faticano a distinguere richieste malevole da uso intensivo legittimo. La difesa richiede quindi visibilità profonda a livello applicativo, rate limiting per funzionalità e telemetria correlata di performance.
L'approccio red team a T1499.003 parte sempre da una fase di profilazione. Prima di lanciare qualsiasi payload, si mappa la superficie applicativa cercando endpoint che restituiscono tempi di risposta anomali rispetto alla media. Un semplice script che misura la latenza di ogni route scoperta con ffuf (open source) o feroxbuster (open source) è sufficiente per identificare i candidati: endpoint di ricerca full-text, generazione PDF, esportazioni CSV, funzioni di reset password con hashing lato server.
Per la simulazione controllata in laboratorio, il tool di riferimento è k6 (open source, con tier cloud a pagamento) di Grafana Labs. Uno scenario tipico definisce una funzione JavaScript che itera richieste POST verso un endpoint di ricerca con query costose, controllando concorrenza e ramp-up.
k6 run --vus 50 --duration 5m script.js
In alternativa, Locust (open source) offre orchestrazione distribuita in Python ed è utile quando si vuole simulare comportamento utente più realistico con pause e sequenze logiche. wrk2 (open source) è invece la scelta quando serve un rate costante e misurato senza coordinated omission, utile per stressare endpoint API REST.
Per i test contro applicazioni web con logica lato client complessa, Apache JMeter (open source) resta uno standard maturo, con supporto a scenari SOAP, GraphQL e WebSocket. Nel contesto GraphQL è particolarmente rilevante testare query annidate profonde o alias multipli che moltiplicano il carico backend — un pattern noto come query complexity attack. Il payload tipico chiede lo stesso campo con decine di alias, forzando il resolver a eseguire N volte la stessa operazione costosa.
Sul fronte della metodologia, un esercizio red team ben condotto include tre fasi. La prima è la baseline benchmarking: si misura la capacità nominale dell'endpoint con carico basso per stabilire il punto di rottura atteso. La seconda è il stress incrementale con incremento graduale della concorrenza fino a osservare degrado. La terza è la verifica dei controlli: si documenta se rate limiter, autoscaling e circuit breaker intervengono e con quale latenza.
Regole d'ingaggio fondamentali: eseguire sempre in ambienti isolati o in finestre concordate con il cliente, coordinarsi con il team infrastrutturale per evitare che l'autoscaling generi costi cloud imprevisti, e disporre di un kill switch immediato. Nel report finale, oltre agli endpoint vulnerabili, si documentano le soglie a cui la degradazione diventa percettibile e si suggeriscono contromisure come query cost analysis, caching aggressivo e rate limiting per-user su endpoint costosi.
Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?
Accedi alle lezioni gratuite e segui il percorso corretto fin dal primo passo
2 minuti · 7 domande
Che professionista cyber sei?
Scopri il profilo più vicino al tuo modo di pensare e inizia dal percorso giusto.