Les MSP sont la cible privilégiée des ransomwares Akira et Lynx

Résumé

• L'Acronis Threat Research Unit (TRU) a analysé des échantillons récents des familles Akira et Lynx pour investiguer les derniers changements et ajustements que déploient Certaines personnes malveillantes.

• Akira et Lynx partagent un modèle RaaS et des tactiques de double extorsion.

• Manifestement, Lynx et SafePay intègra des éléments du code source de LockBit qui a fuité, et Akira partage des similitudes avec Conti (qui a également influencé LockBit), suggérant un code de base hérité partagé.

• Ils compromettent les systèmes par le biais d’identifiants volés, de vulnérabilités VPN, de la reconnaissance, d’élévation de privilèges, de l’évasion défensive et de l’exfiltration/du chiffrement de données, en ciblant les PME avec des méthodes sophistiquées mais recyclées.

• Les gangs désactivent les logiciels de sécurité, suppriment les clichés instantanés et effacent les journaux d’événements pour éviter la détection et entraver la restauration.

• Note d'humour : l’échantillon du ransomware Lynx que nous avons observé peut imprimer une demande de rançon sur les imprimantes.

Introduction

Dans le cadre de nos efforts soutenus pour suivre les gangs de ransomwares et leurs activités, nous considérons que deux groupes se démarquent au premier trimestre 2025 sans être couverts dans nos recherches précédentes : Akira et Lynx.

• Akira a attaqué plus de 220 victimes, dont de nombreuses petites entreprises telles que des cabinets d’avocats, des cabinets comptables et des entreprises de fabrication. De potentiels fournisseurs de services managés (MSP), tels que Hitachi Vantara[1] et Toppan Next Tech ont été ciblés.[2]
• Lynx a fait environ 145 victimes. Sa stratégie d’attaque massive vise principalement les petites entreprises, même si d'autres exemples existent. Un rapport signale une attaque contre une station de télévision affiliée à CBS basée à Chattanooga, dans le 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

Bien que toutes les victimes ne soient pas des MSP, ces gangs ne font pas de distinction. Ils sont prêts à frapper toute organisation qui promet un paiement décent. Cela dit, les MSP sont des cibles de choix pour les cybercriminels, car ils donnent accès à un réseau d’autres clients, amplifiant ainsi la prime potentielle.

Explorons chacun d’entre eux :

1. Ransomware Akira : un retour en force

2. Le ransomware Lynx vise essentiellement les structures privees

Le ransomware Akira est apparu en 2022 avec un faible nombre d'attaques. En 2023, il est entré dans la liste des 10 meilleurs gangs de ransomware, exécutant 174 attaques cette année-là. L'analyse des spikes a révélé que leurs échantillons partageaient de nombreuses similitudes avec le ransomware Conti. Or Conti était lié au groupe de menaces russe appelé Wizard Spider, qui a subi en 2022 une fuite de données comprenant du code source et des messages entre ses membres. Après cet incident, Wizard Spider a été dissous. On ne sait toujours pas si Akira est la nouvelle dénomination de Wizard Spider ou s'il s'agit d'un nouvel acteur qui utilise un code divulgué. En 2024, Akira s’est à nouveau classé dans le top 10 des gangs de ransomware par le nombre d’attaques (315 victimes connues).

Au début de ses opérations, le ransomware Akira a utilisé des attaques de phishing et l’exploitation de vulnérabilités, notamment Cisco CVE-2023-20269, pour accéder aux victimes. En 2024, Akira a principalement ciblé les VPN des utilisateurs en exploitant diverses vulnérabilités, notamment le pare-feu SonicWall Firewall CVE-2024-40766, qui permettait aux attaquants de désactiver les pare-feu et d’effectuer des connexions à l’infrastructure.

En 2025, TRU a détecté des opérateurs Akira en train d'utiliser des identifiants d’administrateur volés / achetés pour tenter d’accéder aux machines / serveurs. Ce faisant, ils désactivaient le logiciel de sécurité. En cas d’échec, ils lançaient l’exfiltration à distance, puis le chiffrement à l’aide d’outils légitimes qui sont souvent mis sur liste blanche et qui ne sont ni analysés ni sous surveillance.

Une fois obtenu l’accès, les attaquants ont effectué la collecte d’informations supplémentaires, le déplacement latéral et le déclenchement du crypteur. De plus, avant de chiffrer les fichiers, les opérateurs d’Akira ont archivé et exfiltré les fichiers des victimes sur leurs serveurs dans le cadre d’un système de double extorsion.

L’échantillon analysé est un fichier PE64 écrit en C/C++ et compilé à l’aide des outils Visual Studio Build. Ce fichier a été repéré pour la première fois fin 2024.

L’exécution commence à partir de la fonction WinMain, qui est volumineuse et contient beaucoup de code. Au démarrage de la fonction, elle obtient la date et l’heure du moment et crée un fichier journal dans le même dossier où elle a été exécutée.

L’échantillon récupère ensuite les arguments de ligne de commande et les compare à la liste enregistrée. Voici les commandes prises en charge et leur description

Après avoir enregistré les valeurs des arguments, l’échantillon récupère tous les lecteurs logiques disponibles sur le système. Le type de chaque lecteur est vérifié. S’il correspond à la valeur du lecteur réseau et que l’argument '-localonly' est ignoré ce lecteur sera ignoré.

L’étape suivante consiste à obtenir une liste de tous les processus en cours d’exécution dans le système. Pour ce faire, l’exemple utilise la fonction 'WTSEnumerateProcess'. Cette fonction est principalement utilisée pour énumérer les processus sur les serveurs distants, mais Akira utilise la valeur 'NULL' comme argument, ce qui signifie que cette fonction énumérera les processus sur le système local.

Ensuite, elle charge certains symboles dans un tampon, qui est ensuite déchiffré dans la boucle. La chaîne PowerShell suivante est alors générée : Cette commande supprime tous les clichés instantanés à l’aide de l’objet WMI.

L’échantillon définit ensuite les informations d’authentification qui seront utilisées pour effectuer des appels sur la machine locale. Ici, il utilise 'CoSetProxyBlanket' avec les arguments suivants :

●      dwCapabilities = 0 – aucun indicateur de capacités.

●      pAuthInfo = NULL – DCOM utilise l’identité proxy actuelle (qui est soit le jeton de processus, soit le jeton d’emprunt d’identité).

●      dwImpLevel = 3 – Le processus serveur peut emprunter le contexte de sécurité du client tout en agissant pour le compte du client.

●      dwAuthLevel = 3 – S’authentifie uniquement au début de chaque appel de procédure distante lorsque le serveur reçoit la demande.

●      pServerPrincName = NULL – pas d’authentification mutuelle.

●      dwAuthzSvc = NULL – aucune autorisation.

●      dwAuthSvc = NULL – pas d’authentification.

Ensuite, l’exemple charge les chaînes qui seront utilisées dans les importations à partir de la bibliothèque fastprox.dll, qui est de type WMI custom Marshaller. Il utilise également certaines importations de la bibliothèque COM 'wbemprox.dll. COM et WMI sont utilisés ici pour contrôler les privilèges et exécuter des commandes Powershell décodées.

Après l’exécution de la commande, l'échantillon appelle la fonction « GetSystemInfo » et commence à créer des threads. Il crée trois types de fils différents avec des numéros différents :

Le nombre de threads de chiffrement dépend directement du nombre de processeurs de l’ordinateur qui sera obtenu à l’aide de 'GetSystemInfo'. Par exemple, dans un ordinateur doté de six processeurs logiques, il crée deux threads pour les analyseurs de dossiers - les quatre autres seront utilisés pour le chiffrement. Ces numéros sont inscrits dans le fichier journal.

Akira utilise à la fois les appels d’API Windows et les fonctions de CRT (C runtime) dans la routine de chiffrement de fichiers. Pour effectuer des itérations dans les dossiers du système, il crée un itérateur de répertoire.

Lorsqu’un fichier est trouvé, il recherche deux symboles dans son nom - '\' et '.'. Cette opération permet de déterminer si un fichier est un dossier. S’il s’agit d’un dossier, l’exemple compare son nom avec la liste enregistrée. Si le nom correspond, le dossier sera ignoré du chiffrement. Si le fichier n’est pas un dossier, l’échantillon trouvera son extension en effectuant une recherche du dernier symbole « . » dans son nom et en le comparant également avec les extensions enregistrées.

Les dossiers et extensions de fichiers suivants sont exclus du chiffrement, car ils peuvent perturber le fonctionnement du système : $Recycle.Bin, System Volume Information, Boot, ProgramData, Windows, temp, .dll, .exe, .akira

Tout autre fichier sera ouvert avec les droits d’accessibilité 'GENERIC_ALL'. L’échantillon obtient le résultat de cette opération à l’aide de la fonction « GetLastError ». Le dernier code erreur est ensuite comparé à la valeur '20h' (32 en décimal), qui est l’erreur 'ERROR_SHARING_VIOLATION'. S’il correspond, l’échantillon appelle une fonction qui tuera le processus qui bloque ce fichier.

Pour arrêter les processus, l’échantillon utilise l'API Restart Manager. Après avoir créé une session, il enregistre une ressource, qui est un nom de fichier bloqué. Ensuite, l’échantillon trouve une liste de processus qui gèrent ce fichier. Avant de terminer les processus de cette liste, l’échantillon obtient son propre PID pour s’exclure de la finalisation.

Akira utilise ChaCha20 pour le chiffrement des fichiers. Si le pourcentage de fichier a été fourni en argument, Akira calculera la quantité de données qu’il doit lire. Il utilise des constantes magiques enregistrées, qui dépendent de la taille de la clé, systématiquement 256 dans ce cas

Une fois les données chiffrées écrites, il effectue une autre opération d’écriture en mémoire tampon de 512 octets (200 en hexadécimal). Il contient une clé ChaCha20, chiffrée avec RSA.

Dans les premières versions d’Akira, un algorithme de chiffrement de ransomware Conti modifié impliquait ChaCha20 et RSA. Alors que les derniers échantillons utilisent les mêmes chiffrements, dans les premières versions, les acteurs malveillants commettaient une erreur lors de l'implémentation des algorithmes en ne générant qu'une clé une seule fois à l’exécution. Le résultat était que chaque fichier chiffré avait le même flux de clés, ce qui permettait aux entreprises de cybersécurité de créer un déchiffreur. Akira a par la suite amélioré son schéma de chiffrement et cette clé est désormais générée pour chaque fichier séparément. La version Linux utilise également ChaCha20 pour chiffrer les fichiers, mais elle utilise la bibliothèque CryptoPP, tandis que les versions Windows contiennent des implémentations de chiffrement dans l’échantillon sans utiliser de bibliothèques externes.

Très active en 2024, Akira poursuit son activité en 2025. Bien que l'échantillon analysé partage certaines similitudes avec le code source Conti, il évolue et est devenu l'une des menaces les plus dangereuses de cette année. En outre, le temps qu’Akira accorde à ses victimes pour payer leurs rançons n’est pas clair – les notes de rançon révèlent seulement que le prix est calculé pour chaque victime, en fonction des données volées, qui peuvent inclure des données bancaires. TRU a observé une victime dont les données ont été divulguées au plus tard cinq jours après avoir été compromises par Akira.

SHA256

88da2b1cee373d5f11949c1ade22af0badf16591a871978a9e02f70480e547b2

URL

https://akiral2iz6a7qgd3ayp3l6yub7xx2uep76idk3u2kollpj5z3z636bad.onion

https://akiralkzxzq2dsrzsrvbr2xgbbu2wgsmxryd4csgfameg52n7efvr2id.onion

Observé pour la première fois à la mi-2024, Lynx présente de nombreuses similitudes avec le ransomware INC, analysé par TRU en 2023. Fonctionnant en tant que groupe de ransomware-as-a-service, les instigateurs de la menace Lynx recherchent constamment de nouveaux affiliés et publient des posts sur des forums russes clandestins. Il était annoncé que Lynx ne cible que le secteur privé, qu’il possède son propre constructeur, qu’il prend en charge les versions Windows et Linux et qu’il fournit un service de stockage des fichiers volés. En outre, les affiliés bénéficient de l'accessibilité au panneau d’administration du site de la fuite de données.

En avril 2024, un utilisateur d’un forum clandestin a posté une offre de vente de trois copies du constructeur de ransomware INC pour l'équivalent de 300 000 roubles chacune. La fonctionnalité décrite est similaire aux échantillons analysés du ransomware INC, mais on ne sait pas s’il s’agissait du véritable code source INC.

Peu de temps après, le ransomware Lynx est apparu. Étant donné que le groupe INC est toujours actif en 2025, il est peu probable qu’INC ait simplement changé de label. Lynx a très probablement acheté le constructeur INC sur des forums clandestins et a ajusté le code.

Traduction du russe :

« Vente du code source du ransomware INC pour 3 acheteurs uniquement.

aes-ctr-128 + curve25519-donna

IOCP, version Linux identique, ESXI compatible pour tous les systèmes

Panneau - react, nodejs + typescript, tout est encapsulé dans Docker et peut être démarré en une seule commande, pas de complications. »

Lynx utilise généralement des e-mails de phishing pour diffuser ses malwares aux victimes. Lorsque les attaquants accèdent aux ordinateurs des victimes, ils collectent d'abord des informations sur le système et l'infrastructure, tentent d'obtenir les identifiants utilisateur et opèrent des déplacements latéraux pour infecter davantage d'ordinateurs du réseau. L'accessibilité aux ordinateurs des victimes permet également aux attaquants d'investiguer les logiciels installés et de rechercher des vulnérabilités exploitables pour l'exécution d'un ransomware.

Lors des attaques de 2025, nous avons constaté que si un logiciel de sécurité est trouvé, Lynx essaie de le désinstaller.

Une fois cette étape effectuée, les attaquants exfiltrent d’abord les fichiers vers les serveurs, puis ils font exploser le chiffreur.

L’échantillon analysé est un fichier PE32, codé en C :\C++. Il n’est ni packagé, ni obfusqué.

L'échantillon prend en charge plusieurs commandes. Chaque commande et sa description sont enregistrées dans le code :

 Une fois qu’il a obtenu des arguments de la ligne de commande, l’échantillon Lynx les compare avec ceux enregistrés. En cas de correspondance, l’échantillon définit la valeur appropriée sur « 1 ». Sinon, l’échantillon définit la valeur « 0 ». Le résultat sera enregistré dans la variable globale.

Lorsqu’un argument nécessite des informations supplémentaires, telles que le chemin d’accès au répertoire dans l’argument '--dir', Lynx enregistre également ces données par un décalage supplémentaire à partir de la chaîne de ligne de commande.

Si l’argument '--verbose' est passé, l’exemple Lynx affichera différentes informations telles que les paramètres, l’état de certaines opérations et la progression du chiffrement.

Cet argument forcera les échantillons Lynx à rechercher et à monter n’importe quel lecteur caché dans le système. Ici, il charge une liste enregistrée de lettres de lecteur qu'il vérifie. Lorsqu’un disque est trouvé, il vérifie si son type est DRIVE_NO_ROOT_DIR. Si le type correspond, il le monte à l’aide de la fonction 'SetVolumeMountPointW'.

Lynx utilise deux méthodes pour terminer le processus ; les deux sont activées à l’aide d’arguments de ligne de commande. Lorsque l’argument '--kill' est passé, il crée un instantané de tous les processus en cours et les itère. Chaque nom de processus est comparé à la liste enregistrée, et s’il correspond, il est clos.

L’argument '--kill' est également responsable de la résiliation du service. Ici, il utilise SC Manager et la fonction 'EnumServicesStatusExW' pour obtenir une liste de tous les services en cours d’exécution sur le système. L’échantillon Lynx compare ensuite cette liste avec les noms enregistrés. Lorsqu’une correspondance est trouvée, la fonction 'ControlService' est appelée avec l’indicateur 'SERVICE_CONTROL_STOP'.

Les processus suivants seront interrompus afin d’éviter les erreurs de violation de partage de fichiers lors du chiffrement :

sql, veeam, backup, exchange, java, notepad

Services résiliés :

sql, veeam, backup, exchange

Lorsque l’argument « --stop-process » est activé, l’échantillon utilise l’API Restart Manager pour mettre fin aux processus pendant le traitement de chiffrement. Cette fonction ne sera appelée que si le fichier que Lynx tente de chiffrer est occupé par un autre processus. L’échantillon enregistre ce fichier comme ressource pour déterminer le processus. Il obtiendra également son propre PID pour s’exclure de la finalisation.

Avant de démarrer la routine de chiffrement, l’échantillon Lynx recherche tous les lecteurs du système. Le type de chaque lecteur est vérifié. Pour le chiffrement, il n’accepte que les lecteurs avec les indicateurs 'DRIVE_REMOVABLE', 'DRIVE_FIXED' et 'DRIVE_REMOTE'. Une fois le lecteur approprié trouvé, il ouvre le handle et exécute la fonction 'DeviceIoControl' avec le paramètre '53C028h' comme code de contrôle, à savoir 'IOCTL_VOLSNAP_SET_MAX_DIFF_AREA_SIZE'.

Il s’agit d’un code de contrôle non documenté qui modifie la taille maximale d’un cliché instantané. Comme le 'lpInBuffer' contient la valeur '1', la définition d’un conteneur de taille aussi faible forcera la suppression des clichés instantanés. Une fois ces opérations terminées, tous les lecteurs trouvés seront transmis à la routine de chiffrement.

L'échantillon Lynx crée des threads avec la fonction sub_275600 comme adresse de départ. Le nombre de threads est le nombre de processeurs — obtenu avec l’appel 'GetSystemInfo » — multiplié par quatre.

Les threads avec cette adresse de démarrage sont utilisés pour rechercher des fichiers. Lorsque l’échantillon Lynx entre dans un dossier, il crée une note de rançon dans ce dossier et commence à rechercher des fichiers à l’aide des fonctions « FindFirstFile » et « FindNextFile ». Si le fichier trouvé est un dossier, l’échantillon compare son nom avec la liste enregistrée. Si le nom du dossier correspond, il sera ignoré.

Lorsqu’un fichier trouvé n’est pas un dossier, l’exemple peut également l’exclure du chiffrement. Il compare les extensions et les noms de fichiers. Si la taille du fichier est de 0, il sera également ignoré.

Lorsqu’un fichier approprié est trouvé, l’échantillon vérifie d’abord s’il est occupé avec un autre processus. Si l’argument '--stop-process' est passé, l’échantillon annulera le processus qui contient le fichier ou sera ignoré. Ensuite, l’échantillon détermine s’il dispose d’un accès en écriture à ce fichier. Pour ce faire, il tente d'écrire un bloc de données à la fin du fichier. En amont, l’échantillon définit 36 octets de « 2 » dans la mémoire tampon. Le nombre de caractères qui doivent être définis dans la mémoire tampon, ainsi que la taille de la mémoire tampon qui doit être écrite dans le fichier, sont calculés à l’aide de la somme de la longueur de la chaîne « LYNX » et de 32.

Si Lynx ne parvient pas à écrire ce fichier, il essaiera d’en obtenir la propriété. Ici, il essaie d’obtenir le privilège 'SeTakeOwnership' et de modifier la propriété des fichiers en créant et en définissant une nouvelle structure ACL, qui accordera des privilèges d’écriture.

Au début de la routine de thread, Lynx décode la chaîne, enregistrée au format Base64 :

8SPEMzUSI5vf/cJjobbBepBaX7XT6QT1J8MnZ+IEG3g=

Cette valeur est une clé publique ECC, qui sera utilisée pour générer la clé AES. Chaque thread procède à l'initialisation des cryptofournisseurs avec « CRYPT_VERIFYCONTEXT » et « PROV_RSA_AES ». Ensuite, l’échantillon génère 32 octets aléatoires à l’aide de la fonction 'CryptGenRandom'.

Ensuite, l’échantillon calcule le hachage de la clé générée. Les constantes SHA512 sont enregistrées dans le fichier binaire.

Une fois que le thread a lu le fichier trouvé, l’échantillon crée un thread de chiffrement, lui transmet un signal de finalisation et se clôt. Le thread de chiffrement récupère les données du précédent, y compris les données de fichiers lus et les clés de chiffrement. En fonction du résultat « GetQuedCompletionStatus », l’échantillon passe dans l’une de cinq cases.

Au cours du processus de débogage, la première case déclenchée était la numéro deux. Ici, l’exemple vérifie d’abord certaines valeurs, puis effectue une opération d’écriture sur le fichier actuel. Il écrira « 116 » octets de données, y compris la clé chiffrée.

L’exemple entre ensuite dans la « Case 0 », où il vérifie si le décalage de bloc de chiffrement actuel n’est pas supérieur à la taille d’un fichier. Lorsque cette case est utilisée pour la première fois, le décalage du bloc sera toujours '0' et provoquera la lecture des données de fichiers par le thread. Mais lorsque la condition est remplie, l’exemple indique que le fichier n’a plus de données à chiffrer et forcera le thread à écrire un bloc chiffré dans le fichier. En outre, il définira la case sur la valeur « 3 ».

Ensuite, l’échantillon passe à la « Case 1 ». Ici, il prend la taille du fichier et en supprime la valeur « 116 ». Cette opération permet de supprimer du chiffrement un bloc de données déjà écrit.

Une fois toutes les préparations terminées, l’échantillon entre dans une boucle où il chiffre les données de fichiers. Ici, il appelle la fonction ‘sub_AE1110’, qui utilise AES pour chiffrer la clé de chiffrement. Par conséquent, la valeur v32 est utilisée comme un flux de clés (v16), sur lequel la fonction XOR sera appliquée avec les données de fichiers. À chaque 16 itérations de boucle de chiffrement, le flux de clés est généré à nouveau.

Enfin, l’échantillon écrit des données chiffrées dans le fichier et entre en « Case 3 », où il ajoute l'extension .LYNX au fichier. De là, le thread efface sa mémoire et attend le fichier suivant.

Lynx stocke un message de demande de rançon au format Base64. Lynx le charge et le passe à la fonction 'CryptStringToBinaryA', laquelle est appelée avec l’indicateur 'CRYPT_STRING_BASE64.

Bien que le message décodé ne contienne pas d'identifiant de victime, il est ajouté suite au décodage. Cet identifiant est codé en dur et différent pour chaque échantillon.

Une fois le processus de chiffrement terminé, l’échantillon utilise les importations à partir de l’en-tête « Winspool » pour rechercher toutes les imprimantes connectées. Il vérifie les noms des imprimantes, les compare avec les noms enregistrés pour les éviter et envoie des notes de rançon à toutes les imprimantes trouvées.

Outre les fichiers texte, la demande de rançon est également écrite comme un fond d’écran à la fin du processus de chiffrement.

Bien que l’on ne sache pas si Lynx est simplement le ransomware INC avec une nouvelle dénomination, nous savons qu’il a des similitudes en termes de code. Les échantillons analysés peuvent arrêter des traitements, monter des lecteurs cachés, supprimer des clichés instantanés et chiffrer des fichiers sur des partages réseau. Bien que le chiffrement soit fort, les attaquants transfèrent également des fichiers sur leurs serveurs dans le cadre d'un double système d'extorsion, obligeant les victimes à payer une rançon pour le déchiffrement, mais aussi pour la non-divulgation de leurs données privées.

SHA256

571f5de9dd0d509ed7e5242b9b7473c2b2cbb36ba64d38b32122a0a337d6cf8b

URL