Gli attacchi che creano più impatto non sono sempre quelli evidenti. Spesso sono quelli che restano sottosoglia abbastanza a lungo da aumentare il tempo di esposizione e la superficie coinvolta. Il costo arriva dopo: diagnosi che si allunga, contenimento che parte tardi, ripristino più complesso, più sistemi da verificare, più incertezza su cosa sia stato toccato.
Questo articolo raccoglie un’analisi di sei tecniche di evasione tipiche e le traduce in un contesto aziendale. Per ciascuna mostra quali segnali possono emergere, cosa possono indicare e quali capacità servono per gestirle senza basarsi su un singolo controllo o su un verdetto automatico.
In scenari di questo tipo il Security Operations Center (SOC) va inteso come una funzione operativa, non come un semplice cruscotto di alert. Porta metodo, attribuzione e contenimento quando i segnali sono ambigui, aiutando l’azienda a prendere decisioni rapide e tracciabili e a ridurre sia il tempo di esposizione sia la probabilità di recidiva.
DKOM – Il processo non attribuibile
Il SIEM segnala traffico verso un IP già noto come malevolo. Nei controlli più immediati l’elenco dei processi sembra normale, ma le connessioni risultano reali. La discrepanza è il segnale, perché la rete “parla” ma l’host non attribuisce.
In scenari più evoluti può entrare in gioco DKOM, una tecnica con cui il malware rende poco affidabili i metodi più comuni di enumerazione dei processi. L’attività resta operativa, ma non compare dove ci si aspetterebbe.
- Requisiti per una gestione efficace: capacità di correlare rete e host quando l’origine non è evidente, elevare il livello di osservazione fino ad attribuire il traffico a una causa reale, preservare evidenze utili e applicare containment rapido per interrompere comunicazioni e limitare l’espansione.
Sandbox evasion – Comportamento adattivo in analisi
Dopo una segnalazione, il campione viene analizzato in sandbox e non mostra comportamenti chiaramente malevoli. Nel contesto reale, però, continuano a emergere segnali sospetti sull’endpoint. Il rischio è considerare l’esito del sandbox come “verdetto”.
Molti malware moderni profilano l’ambiente prima di attivare il payload e, se riconoscono un contesto da laboratorio, restano inattivi. Non è un limite teorico: è un modo per produrre falsi negativi operativi.
- Requisiti per una gestione efficace: un’analisi che non dipenda dall’esito del sandbox, osservazione estesa nel tempo per intercettare attivazioni ritardate, ambienti di test sufficientemente realistici e validazione sul contesto dell’endpoint reale tramite telemetria e timeline coerenti.
Anti-debugging – Ostacoli all’analisi del campione
In fase di analisi un campione può crashare, terminare o cambiare comportamento appena viene osservato. Questo rende meno affidabile ciò che si riesce a vedere e allunga i tempi necessari per capire capability e impatto.
Le tecniche anti-debugging esistono proprio per questo: ridurre la visibilità durante l’analisi e guadagnare tempo. Il risultato, lato azienda, è che le conclusioni “veloci” rischiano di essere parziali.
- Requisiti per una gestione efficace: separare la decisione operativa dall’analisi profonda, ricostruire l’accaduto con telemetria, rete e artefatti anche quando il campione altera il comportamento sotto osservazione, e produrre indicatori affidabili per remediation e prevenzione di recidive.
Fileless PowerShell – Esecuzione senza file su disco
Nei log compare l’avvio di PowerShell con comandi codificati o modalità non interattive, ma sul disco non c’è uno script da trovare. In questi casi l’esecuzione è già avvenuta e l’artefatto principale è la traccia nei log.
Nel modello fileless l’attacco lavora in memoria e riduce le scritture su disco, usando strumenti già presenti. Cercare il file “colpevole” diventa un vicolo cieco.
- Requisiti per una gestione efficace: logging adeguato per ricostruire comandi e ScriptBlock, lettura delle catene parent/child e delle connessioni in uscita per capire cosa è stato eseguito e scaricato, e verifica sul perimetro per identificare pattern replicati su altri endpoint.
Cifratura ransomware – Crittografia ibrida e ripristino
File illeggibili, estensioni cambiate, richiesta di riscatto. A quel punto la priorità non è capire il nome della famiglia ransomware, ma fermare la propagazione e mettere in sicurezza la ripartenza.
Il ransomware moderno usa una cifratura progettata per rendere il recupero impraticabile senza la chiave dell’attaccante. Per questo l’esito, nella pratica, dipende soprattutto da quanto l’organizzazione è pronta a isolare, ripristinare e ripartire nel minor tempo possibile.
- Requisiti per una gestione efficace: procedure di containment e isolamento per bloccare propagazione e movimento laterale, piano di ripristino basato su backup testati e priorità di recovery, e identificazione del punto d’ingresso e delle credenziali esposte per evitare una seconda ondata.
Citando un esempio reale, l’efficacia del SOC Cyberlys ha permesso di scongiurare danni irreparabili: la tempestività degli interventi notturni sui clienti MDR ha contratto i tempi di ripristino, trasformando potenziali giorni di fermo in poche ore di attività da parte degli specialisti di Cyberlys.
BYOVD – Abuso di driver vulnerabili firmati
In telemetria compare il caricamento di un driver firmato, apparentemente regolare. Poco dopo le difese degradano o l’EDR risulta disabilitato senza una causa evidente. È uno scenario in cui “firmato” non equivale a “sicuro”.
Con la tecnica BYOVD, descritta anche nel nostro articolo sul threat hunting, l’attaccante usa un driver reale ma vulnerabile per ottenere privilegi elevati e neutralizzare protezioni. L’impatto non è solo l’evento in sé, ma la perdita di fiducia nella postura dell’endpoint.
- Requisiti per una gestione efficace: controllo e governance sul caricamento di driver e componenti ad alto privilegio, capacità di correlare rapidamente quell’evento con degrado delle difese e altri segnali post-compromissione, e verifiche di integrità/estensione per ripristinare fiducia nei sistemi prima della rimessa in produzione.
Cosa succede in un SOC quando scatta l’alert
Quando arriva un segnale di sicurezza, le situazioni realmente nitide sono rare. Spesso i segnali non sono lineari: la rete mostra traffico ma l’endpoint non lo spiega, un campione in sandbox sembra innocuo mentre sul sistema reale qualcosa continua, oppure un componente apparentemente legittimo compare poco prima che le difese degradino. In questi scenari la differenza non la fa un singolo strumento, ma la capacità di portare rapidamente dall’ambiguità a una lettura affidabile.
In questi casi entra in gioco il lavoro di un SOC. Il focus iniziale è stabilire se l’evento è reale, se è ancora in corso e quanto può estendersi, cercando coerenza tra host e rete e alzando il livello di osservazione quando il quadro non torna. Poi si riduce il rischio prima che diventi propagazione, e solo dopo si ricostruisce la catena con ordine per capire come è entrato, cosa ha eseguito, se esiste persistenza e quali azioni servono per evitare recidive.
Le attività di un SOC per l’evasione malware
Le tecniche di evasione cambiano i dettagli, ma producono sempre lo stesso bisogno aziendale: passare da un segnale a una gestione operativa, in tempi compatibili con l’operatività. I punti che seguono riassumono le capacità pratiche del SOC che entrano in gioco in questi scenari.
- Attribuisce il traffico a una causa reale quando rete e host non tornano, invece di fermarsi ai controlli standard che possono essere elusi (caso “processo fantasma”).
- Riduce i falsi negativi del sandbox estendendo l’osservazione e validando sempre sul contesto reale dell’endpoint, non sul verdetto di un singolo test.
- Ricostruisce catene fileless leggendo command line e sequenze di esecuzione, con logging adeguato su PowerShell (es. ScriptBlock Logging, Event ID 4104) quando non esiste alcun file su disco.
- Riconosce tentativi di manipolazione delle difese monitorando indicatori concreti, come eventi di injection e anomalie su processi critici, prima che diventino propagazione.
- Intercetta BYOVD e driver “legittimi ma pericolosi” tenendo sotto controllo il caricamento dei driver (es. Sysmon Event ID 6) e confrontandolo con liste di rischio e coerenza operativa.
- Gestisce ransomware come problema di continuità operativa contenendo la propagazione e guidando ripristino e messa in sicurezza del perimetro; nelle fasi iniziali preserva evidenze utili (anche in memoria) invece di “spegnere e sperare”.
- Trasforma l’incidente in azioni correttive misurabili su logging, hardening, segmentazione, controllo driver e procedure, riducendo la probabilità di recidiva.
Perché un SOC 24/7 fatto di persone fa la differenza
Le tecniche di evasione descritte hanno un obiettivo semplice: restare operative abbastanza a lungo da trasformare un alert “gestibile” in un impatto reale. Un SOC 24/7 serve a chiudere questa finestra, intercettando i pattern, contenendo subito e guidando le decisioni quando non c’è tempo per interpretazioni lente o interventi a tentativi.
Nella pratica, la maggior parte degli alert è rumore. Aggiornamenti di sistema, software legittimi che si comportano in modo insolito, attività che sembrano sospette ma hanno una spiegazione banale. Molti SOC si limitano a girare questi alert via mail, lasciando al cliente l’onere di capire cosa sia importante e cosa no. Ma quando nove notifiche su dieci sono rumore, il rischio è che anche la decima (quella che conta) venga ignorata o arrivi troppo tardi.
Quando l’alert è reale, riconoscerlo non è sufficiente. Serve collegare indizi che presi singolarmente non significano nulla, ma insieme raccontano una storia. È quello che fanno ogni giorno gli analisti del SOC e del Cyber Threat Intelligence Team di Cyberlys: non inoltrano notifiche, ma analizzano, correlano e intervengono. È la differenza tra ricevere una mail e avere qualcuno che ti dice cosa sta succedendo davvero.
