Denial of Service Endpoint: Endpoint Denial of Service (T1499)

Un red team che deve validare la resilienza applicativa deve muoversi in un perimetro autorizzato per iscritto, tipicamente su ambienti pre-produzione o repliche isolate, evitando qualunque impatto su traffico reale. Le tecniche di endpoint DoS si prestano a esercizi mirati contro singoli servizi (web server, database, DNS) piuttosto che a saturazioni di banda.

Per stress test HTTP applicativi, wrk (open source) e hey (open source) permettono di generare carichi controllati misurando latenza e throughput. Un comando tipico con hey è hey -n 100000 -c 500 -m POST -T application/json -d @payload.json https://target-lab.local/api/endpoint, utile per verificare come l'applicazione gestisce richieste concorrenti con payload realistici. Con wrk, wrk -t12 -c400 -d60s --latency https://target-lab.local/ fornisce un profilo di latenza dettagliato.

Per simulare SYN flood in laboratorio, hping3 (open source) è lo strumento storico: hping3 -S --flood -p 80 target-lab.local genera pacchetti SYN con flag di flood. È la stessa classe di attacco integrata in ZxShell (S0412), che include un modulo SYN flood nativo. Sempre in ambito controllato, slowhttptest (open source) verifica la resistenza a Slowloris e RUDY con slowhttptest -c 1000 -H -i 10 -r 200 -t GET -u https://target-lab.local -x 24 -p 3, saturando le connessioni tenute aperte a lungo.

Per test su layer applicativi specifici, Locust (open source) consente di scriptare scenari realistici in Python, simulando comportamenti utente che colpiscono endpoint costosi (query complesse, upload, ricerche full-text). Un obiettivo tipico è identificare resource exhaustion primitives: endpoint che consumano CPU o memoria in modo sproporzionato rispetto al costo della richiesta, come ricerche wildcard, regex non ancorate o generazione di PDF on-demand.

Sul fronte dei crash persistenti, il fuzzing di parser (JSON, XML, immagini) con AFL++ (open source) o boofuzz (open source) può identificare condizioni di terminazione anomala su cui costruire proof-of-concept di DoS mirato. Un esempio è colpire endpoint di parsing con payload che innescano ricorsione profonda o billion laughs attack su parser XML non irrobustiti.

La fase di reporting deve documentare tempi di recupero, soglie di saturazione, comportamento dei circuit breaker eventualmente presenti e capacità dei sistemi di rate limiting a monte (WAF, reverse proxy) di assorbire il carico. È buona pratica coordinare la finestra di test con il SOC per evitare escalation e falsi allarmi verso i team di incident response.

La detection di T1499 si basa su segnali di saturazione risorse e pattern anomali di crash o restart dei servizi, differenziandosi a seconda della piattaforma monitorata. Il rilevatore MITRE DET0208 aggrega cinque analitiche coprendo Windows, Linux, macOS, IaaS e container.

Su Windows (AN0584), le fonti primarie sono WinEventLog:Sysmon, WinEventLog:Application e WinEventLog:System. Gli indicatori chiave sono i service crash ricorrenti (EventID 7031 e 7034 in System log), i restart anomali di servizi critici come w3wp.exe, svchost.exe o sqlservr.exe, e picchi sostenuti di CPU sopra soglia (tipicamente 90%) per finestre temporali significative. Sysmon EventID 1 correlato a processi che spawn ripetutamente con parent sospetti aiuta a distinguere il DoS locale da un semplice guasto applicativo. Le variabili di tuning includono TimeWindow, ServiceTarget e CPUThresholdPercent, che vanno calibrate per servizio.

Su Linux (AN0585), auditd:SYSCALL, syslog e journald:systemd forniscono la telemetria necessaria per correlare OOM killer, panic kernel e restart di daemon come nginx, httpd, sshd o mysql. Un pattern tipico è la sequenza Out of memory: Killed process seguita da restart ripetuti gestiti da systemd (Start request repeated too quickly). Le soglie RestartThreshold e OOMKillCount vanno adattate al workload normale del sistema.

Su macOS (AN0586), unifiedlog raccoglie i crash report; l'analitica cerca cluster di crash applicativi in finestre brevi, spesso associati a payload ad alta entropia, indicativi di binari malevoli progettati per innescare terminazioni ripetute.

In ambienti IaaS (AN0587), AWS CloudWatch, CloudTrail e VPC Flow Logs espongono metriche di StatusCheckFailed, saturazione CPU credits su istanze burstable e degrado dello stato di health. Un pattern rilevante è la sequenza di failure consecutivi correlata a spike di traffico o a eventi di scaling automatico che non riescono a compensare.

Nei container (AN0588), kubernetes:events e docker:events mostrano pod in CrashLoopBackOff, hitting frequenti dei limiti di cgroup e OOMKilled ricorrenti. La correlazione con entropia dell'immagine può indicare payload malevoli deployati come workload.

I falsi positivi principali derivano da memory leak legittimi, deploy difettosi, carichi stagionali (campagne marketing, eventi live) e job batch programmati. Una baseline per host e per servizio è indispensabile. In ottica D3FEND, i controlli di Resource Access Pattern Analysis e Process Spawn Analysis costituiscono le difese detection-side più pertinenti; sul fronte hardening, la mitigazione M1037 raccomanda WAF, CDN, filtraggio boundary e abilitazione dei SYN Cookies contro i SYN flood.

L'analisi forense post-incidente su T1499 mira a ricostruire quando è iniziato il degrado, quali risorse sono state esaurite, quale vettore lo ha causato e se l'attacco fosse un fine a sé stante o una copertura per attività parallele di intrusione.

Su Windows, la timeline si costruisce partendo dagli Event Log: System.evtx con EventID 7031 (service crashed) e 7034 (service terminated unexpectedly) segna i punti di rottura dei servizi; Application.evtx con EventID 1000 (application error) e 1001 (Windows Error Reporting) fornisce stack e moduli in fault. I file WER in C:\ProgramData\Microsoft\Windows\WER\ReportQueue contengono minidump analizzabili con WinDbg per confermare se il crash derivi da payload malformato o memory exhaustion. Sysmon EventID 1 e 5 tracciano process creation e termination correlabili al periodo di degrado. Le performance counter storiche (se abilitate via PerfMon o collezionate da agent EDR) permettono di ricostruire l'andamento di CPU, memoria e handle count.

Su Linux, journalctl --since "YYYY-MM-DD HH:MM" estrae il flusso systemd rilevante; dmesg o /var/log/kern.log contengono le entry dell'OOM killer con la sequenza invoked oom-killer, Killed process PID (name) e il badness score. Il file /var/log/syslog documenta i restart dei servizi. Se auditd era attivo, le regole su execve e connect consentono di correlare processi anomali all'inizio dell'evento. La lettura di /proc//status e /proc//limits durante l'incidente (se catturata) mostra il consumo reale di risorse.

In ambienti IaaS, CloudTrail conserva le API call di scaling, terminazione istanze e modifica security group; CloudWatch metrics fornisce la serie temporale di CPU, network e disk. VPC Flow Logs mostrano il pattern di ingresso — utile per distinguere DoS applicativo (poche connessioni con richieste costose) da flood volumetrico.

Nei container, kubectl get events --sort-by=.lastTimestamp e la storia dei pod (kubectl describe pod) documentano crashloop e OOMKilled. L'ispezione delle immagini con Trivy (open source) o grype (open source) verifica se payload di malware siano stati deployati.

Sul piano delle campagne documentate, l'attribuzione a Sandworm Team (G0034) per la disruption del 2019 contro siti governativi, ONG e settore privato in Georgia — condotta compromettendo un hosting provider locale — rappresenta un caso in cui l'endpoint DoS è servito come strumento di impatto strategico. Le famiglie OnionDuke (S0052) e ZxShell (S0412) integrano moduli DoS come funzionalità secondaria di RAT più ampi: la loro presenza in un incidente suggerisce che il DoS sia una delle capability disponibili, non necessariamente il vettore primario.

Il panorama degli attori documentati per T1499 nei dati MITRE è ristretto, ma significativo per profilo e implicazioni geopolitiche. L'unico gruppo formalmente mappato è Sandworm Team (G0034), unità attribuita al GRU russo (Unità 74455) e nota per operazioni disruptive ad alto impatto su infrastrutture critiche e obiettivi governativi. L'evento specifico associato alla tecnica è l'attacco del 2019 contro la Georgia, in cui la compromissione di un web hosting provider locale ha permesso l'interruzione simultanea di siti governativi, ONG e aziende private. L'operazione ha combinato accesso alla supply chain (l'hosting) con endpoint DoS come strumento di impatto finale, evidenziando come Sandworm privilegi effetti visibili e sistemici con valenza di segnale politico.

Sul fronte del tooling, i dati MITRE elencano due famiglie malware con moduli DoS integrati. OnionDuke (S0052) è un impianto storicamente attribuito a operazioni collegate all'ecosistema APT russo (Duke family, sovrapposto a Cozy Bear/APT29 in alcune analisi pubbliche), utilizzato come payload distribuito attraverso nodi Tor di uscita malevoli. La presenza di una capability DoS in un impianto principalmente orientato all'espionage riflette un design modulare tipico dei framework di stato-nazione, dove la disruption è una funzione opzionale attivabile su richiesta operativa.

ZxShell (S0412) è un RAT di origine cinese, in circolazione da oltre un decennio, il cui codice sorgente è stato pubblicato e ampiamente riutilizzato da diversi cluster. Il modulo SYN flood integrato lo rende immediatamente impiegabile per operazioni di impatto senza dipendere da tool esterni. La sua longevità e disponibilità pubblica ne fanno un indicatore ambiguo in fase di attribuzione: la sua presenza non identifica un singolo attore, ma segnala tipicamente operatività riconducibile a cluster di lingua cinese o a gruppi che ne hanno adottato varianti.

Il pattern strategico emergente è duplice. Da un lato, l'endpoint DoS come strumento politico e simbolico — il caso georgiano è l'esempio paradigmatico — dove l'obiettivo non è il danno economico ma il messaggio pubblico e la dimostrazione di capacità. Dall'altro, l'uso tattico come diversivo: generare rumore su servizi visibili per distrarre team di risposta mentre operazioni più silenziose (esfiltrazione, movimento laterale) procedono in parallelo.

Per un threat intelligence officer, le priorità di monitoraggio includono l'evoluzione delle capability disruptive di Sandworm nel contesto del conflitto in corso in Ucraina e le operazioni di hacktivismo state-aligned (gruppi pro-russi come Killnet e analoghi non presenti nel dataset MITRE ma osservati pubblicamente) che replicano tattiche di endpoint DoS contro governi e settori critici occidentali. La convergenza tra estorsione ransomware e minaccia DDoS/DoS come leva negoziale è un ulteriore trend da tracciare nei report dei principali provider di threat intelligence.

MITRE ATT&CK T1499 (Endpoint Denial of Service), tattica TA0040 (Impact). Gruppo G0034 (Sandworm Team). Software S0052 (OnionDuke) e S0412 (ZxShell). Mitigazione M1037 (Filter Network Traffic). Rilevatore DET0208 con analitiche AN0584-AN0588. Framework MITRE D3FEND per mapping controlli difensivi. Parti relative a comandi operativi, tool di stress test (wrk, hey, hping3, slowhttptest, Locust, AFL++, boofuzz) e procedure forensi derivano da conoscenza professionale di cybersecurity.