Gli MSP sono il bersaglio dei ransomware Akira e Lynx

Sintesi

• Acronis Threat Research Unit (TRU) ha analizzato esemplari recenti delle famiglie Akirae  Lynx per individuare le ultime modifiche e i perfezionamenti messi in atto dai malintenzionati.

• Akira e Lynx hanno in comune il modello RaaS e le tattiche di doppia estorsione.

• È probabile che Lynx e SafePay incorporino elementi del codice sorgente divulgato di LockBit, mentre Akira presenta delle somiglianze con Conti (che ha a sua volta influenzato LockBit), il che suggerisce la provenienza da un codice base comune.

• Questi malware compromettono i sistemi tramite furto delle credenziali, vulnerabilità VPN, ricognizione, escalation dei privilegi, elusione delle misure di difesa ed esfiltrazione/crittografia dei dati, e prendono di mira le PMI con metodi riciclati, ma comunque molto sofisticati.

• Questi gruppi di hacker disattivano i software di sicurezza, eliminano le copie shadow e cancellano i registri degli eventi per evitare di essere individuati e per ostacolare le operazioni di ripristino.

• Un fatto curioso: l'esemplare di ransomware Lynx che abbiamo osservato per questo articolo è in grado di inviare in stampa una richiesta di riscatto.

Introduzione

Nell'ambito del nostro costante impegno di monitoraggio dei gruppi specializzati in ransomware e delle loro attività, abbiamo messo sotto osservazione i due gruppi che si sono distinti nel primo trimestre del 2025 e non erano ancora stati esaminati nelle nostre ricerche precedenti: Akira e Lynx.

• Akira ha colpito oltre 220 vittime, tra cui molte aziende di piccole dimensioni come studi legali, studi contabili e imprese edili. Ha preso di mira anche potenziali Managed Service Provider (MSP), come Hitachi Vantara[1] e Toppan Next Tech.[2]
• Linx ha colpito circa 145 vittime. La sua strategia di attacco a larga diffusione si concentra sulle piccole aziende, anche se non abbiamo a disposizione un buon numero di esempi specifici. A esempio, è stato segnalato l'attacco a una stazione televisiva affiliata alla CBS con sede a Chattanooga, nel Tennessee.[3]

[1] https://www.bleepingcomputer.com/news/security/hitachi-vantara-takes-servers-offline-after-akira-ransomware-attack/

[2] https://www.holdings.toppan.com/en/info/toppan_info20250408.pdf

[3] https://www.scworld.com/brief/cbs-affiliate-purportedly-compromised-by-lynx-ransomware-gang

Non tutte le vittime sono MSP, ma questi gruppi criminali non sembrano fare distinzioni quando si tratta di scegliere gli obiettivi. Sono pronti a colpire qualsiasi organizzazione che prometta un discreto guadagno. Detto questo, gli MSP si distinguono come i principali bersagli per i criminali informatici perché permettono l'accesso a un'ampia rete di altri clienti, amplificando il potenziale risultato.

Approfondiamo ora i singoli gruppi:  

1.   Il ransomware Akira: uno sgradevole ritomo

2.   Il ransomware Lynx colpisce le aziende private

Il ransomware Akira viene segnalato nel 2022, con un numero ridotto di operazioni. Nel 2023 entra nella classifica dei 10 gruppi specializzati in ransomware, firmando in quell'anno 174 attacchi. L'analisi dei picchi di attività ha evidenziato numerose somiglianze tra questi esemplari e il ransomware Conti. Conti era legato al gruppo di hacker russo Wizard Spider, che nel 2022 fu protagonista di una fuga di dati che includeva anche codice sorgente e alcuni messaggi scambiati tra i suoi stessi membri. Dopo quell'incidente, Wizard Spider venne sciolto. Non è ancora noto se Akira sia un rebranding del marchio Wizard Spider o un nuovo attore che sfrutta parte dei codici divulgati. Nel 2024, Akira si è classificata di nuovo tra i primi 10 gruppi specializzati in ransomware per numero di attacchi (315 le vittime note).

Agli albori della sua attività, il ransomware Akira ha sferrato attacchi di phishing ed exploit di vulnerabilità come Cisco CVE-2023-20269, per accedere ai dati delle vittime. Nel 2024, Akira ha preso di mira principalmente le VPN degli utenti sfruttando varie vulnerabilità, tra cui SonicWall Firewall CVE-2024-40766, permettendo agli aggressori di disattivare i firewall e di connettersi all'infrastruttura.

Nel 2025, TRU ha rilevato l'utilizzo da parte di Akira di credenziali amministrative sottratte/acquistate per tentare di ottenere l'accesso a computer/server. Se le credenziali funzionavano, il gruppo era in grado di disattivare i software di sicurezza. In caso contrario, veniva avviata l'esfiltrazione remota e poi la crittografia, spesso tramite strumenti legittimi inseriti in una whitelist e non scansionati né monitorati dai sistemi degli utenti colpiti.

Dopo aver ottenuto l'accesso, gli aggressori hanno raccolto ulteriori informazioni, avviato movimenti laterali e innescato strumenti di crittografia. Prima di crittografare i file, gli hacker di Akira archiviano ed esfiltrano i file delle vittime sui propri server, come previsto dallo schema di doppia estorsione.

L'esemplare analizzato è un file PE64 scritto in C/C++ e compilato utilizzando gli strumenti di Visual Studio Build. Il file è stato individuato in circolazione per la prima volta alla fine del 2024.

L'esecuzione inizia dalla funzione WinMain, che è grande e contiene molto codice. All'avvio della funzione, il malware acquisisce la data e l'ora correnti e crea un file di log nella stessa cartella in cui viene eseguito.

L'esemplare acquisisce quindi gli argomenti della riga di comando e li confronta con l'elenco salvato. Ecco i comandi supportati e la rispettiva descrizione

 Una volta salvati i valori dagli argomenti, l'esemplare ottiene tutte le unità logiche disponibili sul sistema e controlla il tipo di ogni unità. Se il tipo corrisponde al valore dell'unità di rete e se viene passato l'argomento '-localonly', l'unità viene saltata.

Il passo successivo è l'acquisizione di un elenco di tutti i processi in esecuzione nel sistema. Per ottenerlo, l'esemplare utilizza la funzione 'WTSEnumerateProcess'. Tale funzione viene utilizzata principalmente per enumerare i processi sui server remoti, ma utilizzando il valore 'NULL' come argomento dell'handle, Akira fa in modo che la funzione enumeri i processi sul sistema locale.

Successivamente, carica alcuni simboli in un buffer che viene poi decrittografato durante il loop. Viene così generato il comando PowerShell, che elimina tutte le copie shadow che utilizzano l'oggetto WMI.

L'esemplare imposta quindi le informazioni di autenticazione da utilizzare per effettuare chiamate al sistema locale. Nel frammento, utilizza 'CoSetProxyBlanket' con gli argomenti seguenti:

●      dwCapabilities = 0 – nessun flag di capacità.

●      pAuthInfo = NULL – DCOM utilizza l'identità proxy corrente (ovvero il token del processo o il token di impersonificazione).

●      dwImpLevel = 3 – il processo del server può simulare il contesto di sicurezza del client e agire per suo conto.

●      dwAuthLevel = 3 – esegue l'autenticazione solo all'inizio di ogni chiamata di procedura remota quando il server riceve la richiesta.

●      pServerPrincName = NULL – nessuna autenticazione reciproca.

●      dwAuthzSvc = NULL – nessuna autorizzazione.

●      dwAuthSvc = NULL – nessuna autenticazione.

L'esemplare carica quindi le stringhe che verranno utilizzate per le importazioni dalla libreria 'fastprox.dll', ovvero un Marshaller personalizzato WMI. Utilizza anche alcune importazioni dalla libreria COM 'wbemprox.dll'. Qui vengono utilizzati sia COM che WMI per controllare i privilegi ed eseguire comandi PowerShell decodificati.

Dopo l'esecuzione del comando, l'esemplare richiama la funzione 'GetSystemInfo' e avvia la creazione di thread eseguibili. Crea tre diversi tipi di thread con numeri di thread diversi:

 Il numero di thread di crittografia dipende direttamente dal numero di CPU del computer ottenuto utilizzando 'GetSystemInfo'. Ad esempio, in un computer con sei processori logici, vengono creati due thread per i parser delle cartelle, mentre gli altri quattro vengono utilizzati per la crittografia. Questi numeri vengono scritti nel file di registro.

Nella routine di crittografia dei file, Akira utilizza sia le chiamate API di Windows sia le funzioni di CRT (runtime C). Per ripetere l'azione sulle cartelle nel sistema, Akira crea un iteratore di directory.

Se viene trovato un file, il ransomware cerca i due simboli \' e '.' nel suo nome. Questa operazione serve per determinare se un file è una cartella. In caso affermativo, l'esemplare ne confronta il nome con l'elenco salvato. Se il nome corrisponde, la cartella viene ignorata dalla crittografia. Se il file non è una cartella, l'esemplare trova l'estensione cercando l'ultimo simbolo '.' nel nome e lo confronta anche con le estensioni salvate.

Le seguenti cartelle ed estensioni di file sono escluse dalla crittografia, poiché potrebbero compromettere il funzionamento del sistema: $Recycle.Bin, System Volume Information, Boot, ProgramData, Windows, temp , .dll, .exe, .akira

Tutti gli altri file vengono aperti con i diritti di accesso 'GENERIC_ALL'. L'esemplare ottiene il risultato di questa operazione utilizzando la funzione 'GetLastError'. Il codice dell'ultimo errore viene quindi confrontato con il valore '20h' (32 in decimale), che corrisponde all'errore 'ERROR_SHARING_VIOLATION'. Se c'è corrispondenza, l'esemplare richiama una funzione che forza la chiusura del processo che blocca questo file.

Per la chiusura forzata dei processi, l'esemplare utilizza l'API Restart Manager. Dopo aver creato una sessione, il malware registra una risorsa, ovvero un nome di file bloccato. Quindi, trova l'elenco dei processi che gestiscono questo file. Prima di terminare i processi dell'elenco, l'esemplare ottiene il proprio PID per evitare di interrompere sé stesso.

Per crittografare i file, Akira utilizza ChaCha20. Se come argomento è stata fornita la percentuale del file, Akira calcola la quantità di dati da leggere. Per farlo, utilizza le costanti magiche salvate, che dipendono dalla dimensione della chiave e che in questo caso è sempre 256.

Dopo aver scritto i dati crittografati, viene eseguita un'ulteriore operazione di scrittura utilizzando un buffer da 512 byte (200 in esadecimale), che contiene una chiave ChaCha20, crittografata con RSA.

Nelle prime versioni di Akira veniva utilizzato un algoritmo di crittografia modificato derivato dal ransomware Conti, che includeva ChaCha20 e RSA. Sebbene gli esemplari più recenti utilizzino gli stessi cifrari, nelle prime versioni gli autori hanno commesso un errore durante l'implementazione degli algoritmi, generando una chiave solo una volta durante l'esecuzione. In quel caso, ogni file crittografato aveva lo stesso keystream, il che ha permesso alle agenzie di Cyber Security di creare un decrittografo. In seguito, Akira ha migliorato il proprio schema di crittografia e ora questa chiave viene generata distintamente per ogni file. Anche la versione Linux utilizza ChaCha20 per crittografare i file, sfruttando però la libreria CryptoPP, mentre le versioni Windows implementano i cifrari direttamente nell'esemplare, senza utilizzare librerie esterne.

Molto attivo nel 2024, Akira ha continuato a colpire anche nel 2025. Sebbene l'esemplare analizzato presenti alcune somiglianze con il codice sorgente divulgato di Conti, la sua evoluzione lo sta rendendo una delle minacce più insidiose dell'anno. Non è chiaro quanto tempo Akira conceda alle vittime per pagare il riscatto: le richieste di riscatto rivelano solo che c'è un prezzo calcolato per ogni vittima, che dipende dai dati sottratti, i quali includono anche informazioni bancarie. L'unità TRU ha riferito di una vittima i cui dati sono stati divulgati a soli cinque giorni di distanza dalla violazione da parte del ransomware Akira.

SHA256

88da2b1cee373d5f11949c1ade22af0badf16591a871978a9e02f70480e547b2

URL

https://akiral2iz6a7qgd3ayp3l6yub7xx2uep76idk3u2kollpj5z3z636bad.onion

https://akiralkzxzq2dsrzsrvbr2xgbbu2wgsmxryd4csgfameg52n7efvr2id.onion

Osservato per la prima volta a metà del 2024, Lynx presenta numerose somiglianze con il ransomware INC, analizzato da TRU nel 2023. Poiché operano come gruppo che fornisce servizi RaaS (Ransomware-as-a-Service), gli autori di Lynx sono alla costante ricerca di affiliati e pubblicano sui forum underground russi annunci sulle loro ricerche. L'autore del post afferma che Lynx intende colpire solo il settore privato, è dotato di un proprio builder, supporta le versioni per Windows e Linux e offre un servizio di archiviazione dei file sottratti. Inoltre, gli affiliati potranno accedere al pannello di amministrazione del sito di data leak.

Nell'aprile 2024, un utente di un forum underground ha pubblicato un'offerta per la vendita di tre copie del builder per il ransomware INC, ognuna al prezzo di 300.000 unità, probabilmente rubli. Il funzionamento descritto nel post è simile a quello degli esemplari analizzati del ransomware INC, ma non sappiamo se si effettivamente si tratta del codice sorgente di INC.

Poco dopo la pubblicazione del post, è comparso il ransomware Lynx. Essendo il gruppo INC ancora attivo nel 2025, riteniamo sia improbabile che abbia semplicemente cambiato marchio. È invece possibile che Lynx abbia acquistato il builder di INC sui forum underground e ne abbia modificato il codice.

Traduzione dal russo:

"Vendesi codice sorgente del ransomware INC, a soli 3 acquirenti.

aes-ctr-128 + curve25519-donna

IOCP, la stessa versione Linux, include build ESXI compatibile con tutti i sistemi

Pannello - react, backend -nodejs + TypeScript, completamente integrato in Docker, può essere avviato con un unico comando, nessuna complicazione"

Lynx si avvale tipicamente di e-mail di phishing per distribuire il malware alle vittime. Una volta ottenuto l'accesso ai computer delle vittime, gli attaccanti raccolgono innanzitutto informazioni sul sistema e sull'infrastruttura, e tentano poi di acquisire le credenziali utente per avviare movimenti laterali nell'intento di infettare più computer nella rete. L'accesso ai computer delle vittime consente inoltre agli aggressori di analizzare il software installato e di individuare vulnerabilità utili in un secondo momento per eseguire il ransomware.

Negli attacchi del 2025 sono stati osservati tentativi di disinstallazione dei software di sicurezza che Lynx ha rilevato.

In questa fase, gli attaccanti esfiltrano i file sui server e quindi innescano il crittografo.

L'esemplare analizzato è un file PE32, scritto in C\C++. Non è compresso né offuscato

e supporta numerosi comandi. Ogni comando e la relativa descrizione sono salvati nel codice:

Dopo aver ottenuto gli argomenti dalla riga di comando, questo esemplare di Lynx li confronta con quelli salvati. Se trova corrispondenze, imposta il valore appropriato su '1'. In caso contrario, imposta il valore '0'. Il risultato viene salvato nella variabile globale.

Se un argomento richiede informazioni aggiuntive, ad esempio il percorso della directory nell'argomento '--dir', Lynx salva anche questi dati utilizzando un offset aggiuntivo dalla stringa della riga di comando.

Se viene passato l'argomento '--verbose', l'esemplare Lynx restituisce informazioni diverse, come le impostazioni, lo stato di alcune operazioni e l'avanzamento della crittografia.

Questo argomento forza gli esemplari Lynx a ricercare e a montare qualsiasi unità nascosta nel sistema. Il nostro esempio carica un elenco salvato di lettere di unità e inizia a controllarle una per una. Quando trova un'unità, verifica se il suo tipo corrisponde a DRIVE_NO_ROOT_DIR. Se c'è corrispondenza, l'unità viene montata utilizzando la funzione 'SetVolumeMountPointW'.

Lynx utilizza due metodi per terminare i processi, entrambi abilitati tramite argomenti della riga di comando. Quando viene passato l'argomento '--kill', viene creato lo snapshot di tutti i processi in esecuzione nel sistema e viene avviata l'iterazione. Ogni nome di processo viene confrontato con l'elenco salvato e, se c'è corrispondenza, il processo viene terminato.

L'argomento '--kill' è utilizzando anche per forzare la chiusura dei servizi. Il nostro esempio utilizza SC Manager e la funzione 'EnumServicesStatusExW' per ottenere l'elenco di tutti i servizi in esecuzione sul sistema. Lynx confronta quindi questo elenco con i nomi salvati. Quando trova una corrispondenza, viene chiamata la funzione 'ControlService' con il flag 'SERVICE_CONTROL_STOP'.

I processi successivi vengono terminati per evitare errori di violazione della condivisione dei file durante la crittografia:

sql, veeam, backup, exchange, java, notepad

Servizi arrestati:

sql, veeam, backup, exchange

Quando viene fornito l'argomento '--stop-process', l'esemplare utilizza l'API Restart Manager per terminare i processi durante la crittografia. Questa funzione viene chiamata solo se il file che Lynx tenta di crittografare è impegnato in un altro processo. L'esemplare registra questo file come risorsa per determinare il processo. Ottiene anche il proprio PID per evitare di arrestare sé stesso.

Prima di avviare la routine di crittografia, Lynx cerca tutte le unità presenti sul sistema e controlla il tipo di ogni unità. Per la crittografia, accetta solo unità con flag 'DRIVE_REMOVABLE', 'DRIVE_FIXED' e 'DRIVE_REMOTE'. Quando trova l'unità adatta, apre il relativo handle ed esegue la funzione 'DeviceIoControl' con il parametro '53C028h' come codice di controllo, che corrisponde a 'IOCTL_VOLSNAP_SET_MAX_DIFF_AREA_SIZE'.

Si tratta di un codice di controllo non documentato che modifica la dimensione massima di una copia shadow. Poiché 'lpInBuffer' contiene il valore '1', impostando una dimensione così ridotta viene forzata l'eliminazione delle copie shadow. Una volta completate queste operazioni, tutte le unità rilevate vengono passate alla routine di crittografia.

L'esemplare Lynx crea thread che presentano la funzione 'sub_275600' come indirizzo iniziale. Il numero di thread equivale al numero dei processori ottenuto con la chiamata 'GetSystemInfo' moltiplicato per quattro.

I thread con questo indirizzo iniziale vengono utilizzati per cercare i file. L'esemplare Lynx accede a una cartella e crea al suo interno una richiesta di riscatto; inizia quindi a cercare i file utilizzando le funzioni 'FindFirstFile' e 'FindNextFile'. Se il file individuato è una cartella, il malware ne confronta il nome con l'elenco salvato. Se il nome della cartella corrisponde, la cartella viene ignorata.

Se il file individuato non è una cartella, può anche essere escluso dalla crittografia. Il malware confronta estensioni e nomi dei file. Se la dimensione del file è 0, viene ignorato.

Quando viene trovato un file appropriato, come prima cosa l'esemplare controlla se è impegnato in un altro processo. Se viene passato l'argomento '--stop-process', l'esemplare forza la chiusura del processo che contiene il file, altrimenti il file viene ignorato. Quindi, l'esemplare determina la propria capacità di accesso in scrittura al file. Per farlo, scrive un blocco di dati alla fine del file. Prima del processo di scrittura, l'esemplare imposta 36 byte di '2' nel buffer. Il numero di caratteri che deve essere impostato nel buffer, nonché la dimensione del buffer che deve essere scritta nel file, vengono calcolati sommando 32 alla lunghezza della stringa 'LYNX'.

Se Lynx non ha accesso in scrittura al file, tenta di ottenerne la proprietà. Nel codice di esempio, tenta di acquisire il privilegio 'SeTakeOwnership' e di modificare la proprietà del file creando e impostando una nuova struttura ACL che concede i privilegi di scrittura.

All'inizio della routine del thread, Lynx decodifica la stringa salvata in formato Base64:

8SPEMzUSI5vf/cJjobbBepBaX7XT6QT1J8MnZ+IEG3g=

Questo valore è una chiave pubblica ECC che viene utilizzata per generare la chiave AES. Ogni thread inizializza i provider di crittografia con i flag 'CRYPT_VERIFYCONTEXT' e 'PROV_RSA_AES'. L'esemplare genera quindi 32 byte casuali utilizzando la funzione 'CryptGenRandom'.

Quindi calcola l'hash della chiave generata e salva le costanti SHA512 nel binario.

Dopo che il thread ha letto il file trovato, il malware crea un thread di crittografia a cui passa il segnale di completamento ed esce. Il thread di crittografia ottiene i dati dal thread precedente, ovvero i dati dei file letti e le chiavi di crittografia. A seconda del risultato di 'GetQuedCompletionStatus', l'esemplare passa a uno dei cinque casi.

Durante il processo di debug, il primo caso attivato è stato il caso due. In questo frammento l'esemplare controlla prima alcuni valori e poi esegue un'operazione di scrittura sul file corrente. Vengono scritti '116' byte di dati, inclusa la chiave crittografata.

L'esemplare accede quindi a 'Case 0', dove controlla che l'offset del blocco di crittografia corrente non sia maggiore della dimensione del file. Quando accede a questo caso la prima volta, l'offset del blocco è sempre '0' in modo da far sì che il thread legga i dati dei file. Quando invece la condizione è soddisfatta, l'esemplare indica che il file non contiene più dati da crittografare e forza il thread a scrivere un blocco crittografato nel file. Inoltre, imposterà l'istruzione case sul valore '3'.

L'esemplare accede quindi a 'Case 1', dove preleva la dimensione del file e rimuove '116'. L'azione comporta la rimozione dalla crittografia di un blocco di dati già scritto.

Completati tutti questi preparativi, l'esemplare avvia il loop di crittografia dei dati del file. Richiama la funzione 'sub_AE1110' che utilizza AES per crittografare la chiave. Di conseguenza, il valore v32 viene utilizzato come keystream(v16) e sottoposto a un'operazione XOR con i dati dei file. Per ogni 16 iterazioni del loop di crittografia, viene generato un nuovo keystream.

Infine, il malware scrive dati crittografati nel file e accede a 'Case 3', dove aggiunge al file l'estensione '.LYNX'. A questo punto il thread cancella la memoria e attende il file successivo.

Lynx archivia un messaggio di richiesta di riscatto in formato Base64. Carica la richiesta e la passa alla funzione 'CryptStringToBinaryA', che viene richiamata con il flag 'CRYPT_STRING_BASE64'.

Il messaggio decodificato non contiene l'ID della vittima, che sarà aggiunto dopo il processo di decodifica. L'ID è codificato e diverso per ogni esemplare.

Una volta completato il processo di crittografia, l'esemplare utilizza le importazioni dall'intestazione 'Winspool' per individuare tutte le stampanti connesse. Verifica i nomi delle stampanti, li confronta con i nomi salvati per evitarle e quindi invia le richieste di riscatto a tutte le stampanti trovate.

Oltre ai file di testo, al termine del processo di crittografia la richiesta di riscatto viene impostata anche come sfondo del desktop.

Non è chiaro se Lynx sia semplicemente una versione del ransomware INC ridenominata, ma sappiamo che i codici dei due malware presentano delle somiglianze. Gli esemplari analizzati sono in grado di arrestare processi, montare unità nascoste, eliminare copie shadow e crittografare file su condivisioni di rete. Nonostante la crittografia dei file sia particolarmente avanzata, gli aggressori caricano i file sui propri server perché questo malware prevede un doppio schema di estorsione che costringe le vittime a pagare il riscatto non solo per la decrittografia ma anche per evitare la divulgazione di dati privati.

SHA256

571f5de9dd0d509ed7e5242b9b7473c2b2cbb36ba64d38b32122a0a337d6cf8b