Hijacking des serveurs de mise à jour AOMEI pour diffuser secrètement des malwares

Des chercheurs du laboratoire Threat Analysis de ManageEngine (METAL), en collaboration avec le Google Threat Intelligence Group (GTIG) et Mandiant, ont découvert la campagne et enquêté sur les attaques.

Dans des rapports publiés par Google et ManageEngine, l'activité est attribuée à un acteur menacé suivi sous le nom d'UNC7017, qui a utilisé l'infrastructure compromise pour diffuser un nouveau malware appelé CROSSROAD et un backdoor nommé SHINYROAD.

Les chercheurs ont identifié des organisations affectées dans plusieurs pays, notamment les États-Unis, l'Australie, l'Inde, Singapour, l'Espagne et la Suisse, dans des secteurs tels que les services informatiques, les télécommunications et l'enseignement supérieur.

Cependant, Google a mis en garde contre le caractère opportuniste des attaques et a indiqué qu'elles auraient pu toucher des organisations supplémentaires ayant vérifié les mises à jour logicielles pendant les courtes périodes où les fichiers malveillants étaient distribués.

Les attaques ont été détectées pour la première fois le 28 mai, lorsque ManageEngine a déclaré que son logiciel de sécurité d'extrémité avait repéré AOMEI Backupper installant soudainement l'outil d'administration à distance légitime Radmin sur des ordinateurs de deux entreprises non liées dans différents pays.

L'installation de Radmin était suspecte car les processus promotionnels intégrés d'AOMEI l'ont lancé, ce qui gère normalement le téléchargement et l'affichage de contenu promotionnel et de notifications.

Cependant, lorsque les chercheurs ont tenté de reproduire ce comportement sur leurs propres systèmes de test, ils n'ont rien trouvé de malveillant. Au contraire, le logiciel a contacté les serveurs d'AOMEI et a téléchargé le fichier de configuration légitime.

Des tests supplémentaires ont montré que, au lieu de remplacer définitivement des fichiers sur les serveurs d'AOMEI, les attaquants ont brièvement modifié deux fichiers de configuration utilisés par les systèmes de promotion et de notification.

Le premier fichier, down_html.ini, indique à AOMEI Backupper où télécharger les packages de mise à jour. Le second, Notifycfg.ini, contrôle les notifications et peut déclencher l'exécution de contenu sur l'ordinateur.

En modifiant ces fichiers, les attaquants ont redirigé le logiciel pour qu'il télécharge une archive ZIP malveillante, puis ont utilisé le mécanisme de notification pour exécuter le malware sans interaction de l'utilisateur.

Des chercheurs de Google ont ensuite confirmé ce flux d'exécution dans leurs propres tests.

Après avoir échoué à reproduire l'attaque originale, ManageEngine a commencé à surveiller en continu les serveurs d'AOMEI.

Le 16 juillet, cette surveillance a enfin capturé les modifications malveillantes alors qu'elles se produisaient, confirmant que les systèmes d'AOMEI servaient du contenu malveillant.

Les chercheurs ont également découvert que les attaquants avaient modifié la somme de contrôle attendue dans la configuration de mise à jour, permettant au archive malveillante de passer les vérifications de fichiers du logiciel.

Google et ManageEngine ont indiqué avoir identifié trois fenêtres où le fichier de configuration malveillant était envoyé par les serveurs d'AOMEI :

28 mai : fenêtre d'exposition de 10 minutes (05h40-05h50 UTC)

16 juillet : fenêtre d'exposition de 6 minutes (08h33-08h39 UTC)

20 juillet : fenêtre d'exposition de 5 minutes (10h35-10h40 UTC)

Les attaquants ont restauré les fichiers de configuration à leur forme d'origine quelques minutes plus tard, rendant la compromission difficile à détecter.

Pendant ces fenêtres, le fichier de configuration malveillant a été utilisé pour installer les malwares CROSSROAD et SHINYROAD.

Une fois lancés, le downloader CROSSROAD a vérifié la reconnaissance effectuée sur l'ordinateur infecté, a téléchargé des composants supplémentaires et a établi une persistance via une tâche planifiée.

SHINYROAD est un backdoor qui a utilisé des composants légitimes Radmin pour charger du code malveillant et établir une connexion sortante vers un serveur de commande et de contrôle contrôlé par l'attaquant.

Cela a permis aux attaquants d'exécuter potentiellement des commandes et des charges supplémentaires sur les ordinateurs compromis.

Pendant l'attaque du 20 juillet, Google a également observé une seconde technique visant à voler des hachages d'authentification Windows en forçant le système de notification du logiciel à accéder à une ressource WebDAV contrôlée par l'attaquant via une fenêtre contextuelle invisible.

Cette technique pourrait exposer des hachages NTLM qui peuvent être collectés par le serveur contrôlé par l'attaquant et ultérieurement crackés à l'aide d'outils divers.

Les chercheurs ont également identifié plusieurs adresses IP et noms de domaine utilisés pendant les attaques, notamment 8.210.84[.]56, serv.oss-cn-hongkong[.]aliyuncs.com, des noms de domaine sous storage-data[.]com, et storage.googleapis.com, un point de terminaison Google Cloud Storage légitime.

AOMEI indique que son directeur technique enquête

ManageEngine a informé BleepingComputer qu'il avait d'abord signalé à AOMEI les activités suspectes le 7 juin, plus d'un mois avant que les chercheurs ne capturent directement les fichiers de configuration malveillants sur ses serveurs.

À ce moment-là, AOMEI avait suggéré initialement que le contenu avait été intercepté et modifié en transit, une explication que les chercheurs ont rejetée.

"Les preuves ne soutenaient pas l'explication d'AOMEI concernant l'interception en transit", indique le rapport de ManageEngine.

"Les deux points de terminaison avaient récupéré le contenu via HTTPS depuis des hostnames AOMEI, dans différents pays et sur des chemins réseau non liés, et l'exécutable était arrivé via la séquence d'extraction propre à l'application plutôt que d'être écrit directement sur le disque par un processus externe. Le contenu avait été altéré avant d'atteindre l'un ou l'autre point de terminaison, dans le chemin de distribution hébergé par le fournisseur."

Lorsque ManageEngine a capturé une autre attaque le 16 juillet, il a immédiatement fourni à AOMEI les hashs originaux et modifiés, les différences de fichiers et les fichiers modifiés.