Détection d’une intrusion système avec des commandes de base de Linux (Partie 2) – Homputer Security

[Ldfa]

Dans cet billet, nous effectuerons une simple analyse pour détecter des activités louches “à chaud” sur un système à l’aide d’outils de base de Linux.
Cet article est la suite de Détection d’une intrusion système avec des commandes de base de Linux (Partie 1) .

Nous analyserons une machine nommée Magento2, suspectée d’avoir un malware.

Lançons la commande top pour voir les processus en cours d’exécution sur cette machine.

Déjà, nous découvrons un processus qui utilise 300 % des ressources CPU de la machine !

De cette image, nous apprenons déjà deux choses:
Il existe un compte d’utilisateur du nom de pula sur le système et un processus louche s’exécutant sur le système avec le pid 12958.

Dans le dossier /proc du processus, nous découvrons le script à la base du processus louche.
Ce script connecte en réalité la machine à un serveur distant via le port tcp 3333.
Par ailleurs, l’adresse ip du serveur en question y est également révélée.

lsof nous confirme qu’une connexion s’est réellement établie entre la machine et ce serveur.
De plus, cette commande nous informe sur l’emplacement du répertoire comprenant le script malicieux qui a été exécuté (/home/pula/.ttp/a).

Avant de consulter le répertoire de l’utilisateur pula, voyons s’il existe des tâches planifiées par cet utilisateur.

Crontab nous informe que trois tâches ont été planifiées par cet utilisateur pula.
Le script utilisé dans la première tâche se trouve également dans le dossier /home/pula/.ttp/a.
Il y’a de fortes chances que le processus au PID 12958 soit lié à ce script.

Jetons à présent un coup d’oeil au contenu du script upd situé dans le dossier /home/pula/.ttp/a.

Une série de scripts nous mène vers la commande responsable de la connexion non authorisée. Cette commande utilise en réalité un fichier binaire exécutable du nom de crond.

Un simple scan nmap via proxychains sur l’adresse ip du serveur découvert dans la commande nous informe sur tous les ports ouverts de ce serveur.

Une connexion sur le serveur web de l’adresse nous apprend que nous  avons en réalité affaire à un pool de minage.

Sur l’une des pages du serveur, nous retrouvons la commande exécutée.

Nous pouvons en déduire que le fichier binaire utilisé par la commande est sans doute Minerd , un fork du légitime mineur de cryptomonnaie CPUMiner.
Ce programme a sans doute été renommé pour tromper la vigilance des utilisateurs.

Une analyse des fichiers auth.log générés par le système que nous apprend que des connexions ssh ont été établies par ce même utilisateur pula durant la période du 5 Février au 2 Mars !
Malheureusement, la rotation des logs auth.log définie sur cette machine ne conserve que 4 fichiers auth.log et les plus anciens sont effacés.
Alors, il est fort probable que la toute première intrusion ait eue lieu à une date antérieure à la date du 5 Février.

La seconde ligne de crontab conduit quant à elle vers un script Perl obfusqué qui cache sûrement un autre malware.

Nous n’apprendrons malheureusement rien de la dernière ligne de Crontab car le dossier /tmp en question est vide. Cela est sans doute dû à un redémarrage effectué par l’utilisateur habituel de la machine.

Un coup d’oeil dans le répertoire $Home de l’utilisateur pula, et nous découvrons d’autres fichiers malicieux. Parmi lesquels un script conçu pour réaliser des attaques par force brute.

Sans doute le serveur était également sur le point d’être utilisé pour réaliser des attaques par force brute sur d’autres serveurs ssh …

Notre analyse nous a permis de découvrir un malware mineur de cryptomonnaie sur cette machine et le serveur auquel il se connectait.
Elle a aussi surtout permis de comprendre l’importance du monitoring, qui peut permettre de détecter très rapidement des activités malicieuses sur des machines.

mdestroy

Share this:

Afficher l’article complet