Log4Shell: come sono cambiati i volti degli aggressori nel tempo

A seguito del nostro articolo del 4 febbraio 2022 sulla scansione di Log4Shell e sui rilevamenti degli attacchi da quando è stato segnalato il bug, Sophos risponde alle domande dei lettori su chi c'è dietro a tutto questo

Il 4 febbraio 2022 abbiamo pubblicato un articolo sulle tendenze osservate da Sophos relative a coloro che scansionano e attaccano la vulnerabilità Log4Shell nel software Apache Log4J, come osservato dai clienti di Sophos Firewall.

In risposta, un lettore su Twitter ha chiesto informazioni sulla distribuzione delle scansioni tra provider di hosting e host sospetti. Una domanda molto perspicace, quindi ho deciso di vedere se avevo le informazioni per rispondere.

I dati utilizzati sono un campione basato sui clienti che partecipano alla telemetria di Sophos e questo numero può variare nel tempo. È comunque molto utile. Sono state usate le percentuali per esaminare gli ASN della sorgente (autonomous system numbers) di scansioni e tentativi di attacco, ed entrambi i set di dati di dicembre 2021 e gennaio 2022 sono abbastanza grandi da dipingere un quadro piuttosto interessante.

Abbiamo considerato due settimane in particolare. Il primo set di dati va dal 17 dicembre 2021 al 23 dicembre 2021 ed esamina chi stesse effettuando la scansione durante il picco degli attacchi nelle settimane successive alla scoperta del bug. Il secondo set di dati copre dal 19 gennaio 2022 al 25 gennaio 2022, che è circa un mese dopo, con i dati più aggiornati che avevamo a portata di mano quando abbiamo iniziato l’attività.

Ci sono state molte speculazioni su chi sta generando tutto questo traffico. Lo strumento software Apache Log4J è così ampiamente distribuito, in così tanti prodotti e servizi, che sia i criminali sia gli aggressori degli stati nazionali sarebbero sciocchi a perdere l’occasione di proteggere potenzialmente un punto d’appoggio all’interno di un’organizzazione che lo ha installato da qualche parte. I ricercatori della sicurezza hanno anche eseguito una scansione a volume per valutare il rischio che gli aggressori abbiano successo e per monitorare l’avanzamento della correzione dei bug.

Abbiamo anche assistito a un numero limitato di attacchi automatizzati su larga scala contro i dispositivi VMware Horizon e IoT da parte di Mirai e altre botnet. Il ricercatore della sicurezza Dr. Vesselin Bontchev ha risposto al nostro post originale su Twitter, notando che stava principalmente osservando scanner e botnet che attaccavano la sua rete.

Scansione delle sorgenti nel dicembre 2021

Allora, cosa c’è nei dati? Ebbene, quell’intensa settimana di dicembre, con un numero limitato di firewall che condividevano la telemetria, abbiamo osservato 1.497 indirizzi IP univoci originati da 234 ASN univoci che scansionavano e attaccavano in sette giorni. I primi 20 ASN sono indicati nella tabella in base alla percentuale di traffico generato. Questo set di dati ha una coda molto lunga.

Con pochissime eccezioni, i primi 20 sono principalmente provider di hosting, VPS o cloud. Nella mia esperienza, questo rappresenta un miscuglio di penetration tester, criminali informatici e stati nazionali. I pochi rimanenti sono o ricercatori della sicurezza o IP noti per ospitare VPN anonime, a dimostrazione del fatto che l’ondata iniziale è stata in definitiva una corsa alla raccolta di informazioni e allo sfruttamento a proprio vantaggio prima che molti avessero l’opportunità di valutare e correggere le vulnerabilità.

Le sorgenti di scansione a gennaio 2022

Ora possiamo esaminare il secondo set di dati. Questi dati sono stati raccolti dal 19 gennaio 2022 al 25 gennaio 2022 e includono un numero maggiore di firewall. Come notato in precedenza, questo non dovrebbe alterare le percentuali tanto quanto il volume grezzo.

Nonostante il forte aumento del volume di telemetria, contiene solo 268 indirizzi IP univoci (rispetto ai 1.497 di dicembre) da 93 ASN (234 a dicembre). Si tratta di un cambiamento drammatico nelle operazioni, dalla mischia che abbiamo osservato prima delle vacanze di Natale a gruppi molto più selezionati di scanner e aggressori.

Come ricercatore della sicurezza queste differenze sono molto interessanti. Prima di tutto, il panorama si è spostato in modo significativo verso la ricerca proveniente da fonti identificabili e da VPN anonime o servizi di hosting.

La fine dell’ora amatoriale?

La mia impressione da tutto quanto descritto sopra è che i dilettanti e i criminali meno abili siano passati a imprese più brillanti e più interessanti. Cos’è rimasto? Una rumorosa coorte implacabile di aggressori potenzialmente pericolosi combinati con ricercatori della sicurezza troppo ansiosi che creano abbastanza rumore da rendere difficile per i SOC e i red teamer trovare il segnale d’allarme.

Inoltre, la coda è MOLTO più corta anche se si tratta di un set di dati molto più corposo. Probabilmente abbiamo raggiunto un punto in cui i tipi di sonde inviate dai ricercatori della sicurezza e dai robot come Mirai possono essere vagliati e smistati dagli alert utilizzando le regole YARA, per iniziare a identificare i reali tentativi di sfruttamento hands-on-keyboard.

Come ho affermato prima, questo software è incorporato in troppi sistemi per non essere un tesoro per i penetration tester e i criminali informatici nei molti anni a venire. Ora che l’attività è cessata, possiamo iniziare a perfezionare le nostre difese e gli alert per dare la caccia a quelli veramente pericolosi.

Quello che non dobbiamo dimenticare è che i sistemi interni alle nostre reti non protetti e privi di patch offrono opportunità per l’escalation dei privilegi e l’esecuzione di codice in remoto, anche se “remoto” significa un altro sistema interno su cui qualcuno si è intrufolato. Le organizzazioni che hanno eliminato il rischio proveniente dai sistemi connessi a Internet ora devono applicare lo stesso controllo internamente per garantire che questa non sia la loro futura rovina.

 

La minaccia è cambiata, ma non è svanita.

Lascia un commento

Your email address will not be published. Required fields are marked *