Drupal, phishing et un nouveau botnet de cryptominage

0

Il est bien connu que les solutions de sécurité doivent s’adapter rapidement aux nouvelles méthodes d’attaque. Il existe plusieurs moyens d’y parvenir, que ce soit par l’application régulière des correctifs et mises à jour de sécurité, par le recours à la veille des menaces, etc.

Imperva utilise la détection d’anomalies comme l’un des outils permettant d’identifier les menaces émergentes et de bâtir de nouvelles défenses. Nos chercheurs en sécurité analysent régulièrement les schémas détectés et c’est ainsi que nous avons découvert l’existence du botnet Ash.

Le schéma ressortant de notre moteur de détection d’anomalies était http://xxx.xxx.xxx.xxx/a.sh. Celui-ci indique le nom d’une ressource, provenant de plusieurs serveurs distants, employée comme charge malveillante dans de nombreuses attaques, parmi lesquelles le désormais tristement célèbre Drupalgeddon2.

Ce n’est pas si souvent qu’il nous est donné d’observer le cycle de vie d’un botnet, depuis sa création jusqu’à sa disparition. Lorsque nous en avons l’opportunité, cela nous offre une perspective unique sur le mode de fonctionnement des botnets et sur la façon de les bloquer.

Détection du botnet

Par une charge malveillante commune

Il s’est avéré que la charge malveillante était diffusée par un groupe de plusieurs centaines d’adresses IP appartenant à un vaste ensemble de sites sur une période s’étendant sur plus de 30 jours. Le caractère spécifique et distinct de cette charge ainsi que sa propagation par le même outil d’infection portent à croire que toutes ces adresses IP faisaient partie d’un seul et même botnet.

Description de la charge malveillante

Le fichier a.sh initial est un simple script bash qui télécharge une archive compressée, puis en extrait et lance un exécutable nommé « i ». L’archive contient 21 fichiers différents : textes, scripts bash, exécutables, bibliothèques statique, ainsi que du code Python. « i » est un fichier exécutable ELF 64 bits qui, étonnamment, n’est détecté par aucun des moteurs antivirus regroupés dans VirusTotal.

ELF 1

L’objectif de « i » est double : propagation du malware et cryptominage. La propagation s’effectue via un serveur C&C central exploitant à la fois des vulnérabilités connues (Drupalgedon) et des e-mails de phishing. La partie cryptominage est exécutée par pas moins de quatre logiciels spécialisés différents : xmrig, jce_cn_cpu_miner, xmr_stack et luk-cpu.

Parmi ces mineurs, nous avons pu remonter jusqu’à deux portefeuilles de cryptomonnaie contenant actuellement environ 200 XMR, soit l’équivalent de 28 000 dollars :

  • 48edfHu7V9Z84YzzMa6fUueoELZ9ZRXq9VetWzYGzKt52XU5xvqgzYnDK9URnRoJMk1j8nLwEVsaSWJ4fhdUyZijBGUicoD
  • 45Pw3bWFJXQiR1hN97huM6BbNPpnYdPytWnTUbkEm6KS9MExU7Gtr3nBsVoZA746qhCEwqVsFuPdwfXVtZwXxHQ6LDyfBaL

Par d’autres schémas comportementaux communs

La mise en corrélation des comportements dans le temps entre les différents attaquants est un puissant moyen d’isoler les botnets. Une charge malveillante identique, utilisée par des adresses IP multiples comme ici, est un schéma comportemental commun aisément détectable. Lorsque la charge est inconnue, inconstante ou insuffisamment distinctive, il est possible de recourir à des corrélations plus subtiles.

L’un de ces schémas porte sur les sites visités par les adresses IP sources en fonction du temps. La définition d’une mesure qui révèle si deux adresses IP différentes ont visité ou non des groupes similaires de sites au même moment permet de regrouper celles représentant des botnets potentiels.

Il apparaît que des corrélations comportementales de ce type sont également présentes dans le cas qui nous intéresse, ce qui nous permet d’étalonner la mesure de similarité employée dans notre méthode de regroupement. La combinaison des deux méthodes nous a permis d’identifier avec succès des botnets supplémentaires parmi nos données.

Structure et cycle de vie du botnet

Distribution des attaques

Fait intéressant, l’attaque a été menée par une seule adresse IP « maître » qui, lors du pic, a été responsable de la majorité des assauts contre plusieurs centaines de sites cibles tandis que la masse des adresses IP « subalternes » en effectuaient chacune une partie bien plus réduite, ne visant généralement qu’une dizaine de sites par jour. Une caractéristique à noter est que l’IP maître a changé à quatre reprises au cours de la période de 60 jours étudiée, de sorte qu’il existait toujours exactement une adresse IP jouant ce rôle à un instant donné, comme le montre le graphique ci-dessous, où chaque courbe de couleur correspond à une IP différente.

ELF 2

Les IP maîtres appartiennent vraisemblablement à une ou plusieurs machines en possession de l’auteur de l’attaque tandis que les autres adresses sont celles de serveurs applicatifs infectés et embrigadés dans le botnet.

Il est amusant de noter que l’IP maître active entre le 8 et le 22 juin (courbe rouge) est soudain devenue oisive entre le 15 et le 18 juin, au moment du coup d’envoi de la Coupe du Monde de la FIFA, ce qui pourrait indiquer que l’auteur de l’attaque est un amateur de football, confirmant ainsi l’hypothèse que l’activité de l’IP maître n’est pas déclenchée par un robot mais par un être humain, propriétaire de la machine.

Création

Comme vous pouvez le voir sur le graphique précédent, le pic de l’attaque, à partir du 20 mai environ, a été précédé d’une période pendant laquelle une seule adresse IP était active, utilisant les mêmes charges malveillantes. Les mêmes sites allaient être par la suite attaqués par les autres adresses IP du réseau. L’outil d’infection utilisé par cette IP était différent de celui employé pendant le pic de l’attaque.

La période durant laquelle seule cette IP a été active sur le réseau peut être considérée comme une phase de reconnaissance menée par l’auteur de l’attaque, qui recherchait sans doute des vulnérabilités dans les sites que le botnet a ciblés ultérieurement.

Durée

En dehors des IP maîtres, dont chacune s’est attaquée à des sites multiples quotidiennement sur une période prolongée, la plupart des autres adresses sont sorties du botnet au bout de quelques jours, 998 d’entre elles sur 2034 (soit près de 50 %) étant observées jusqu’à deux jours de suite :

ELF 3

Plusieurs facteurs peuvent expliquer la brièveté de l’apparition de la plupart des adresses IP :

  • Rapidité de détection et d’élimination de l’infection sur de nombreuses machines contaminées
  • Utilisation parcimonieuse de chaque adresse IP infectée par l’auteur de l’attaque afin d’éviter sa détection

Volatilité

La participation des adresses IP dans l’activité du botnet a suivi une dynamique intéressante. Leur taux de rotation dans le botnet était relativement élevé, comme le montre le graphique ci-dessous. En moyenne, environ 25 % des adresses IP actives (marquées en orange) dans le botnet un jour donné ne l’étaient plus (en bleu) le lendemain, étant remplacées par un nombre équivalent de nouvelles.

ELF 4

Nous constatons que l’activité globale du botnet Ash a chuté entre le 15 et le 18 juin, sans que nous puissions trouver d’explication technique à ce phénomène. Cependant, il est à noter que cette période correspond au début de la Coupe du Monde de football. Il n’est donc pas à exclure que les opérateurs du botnet aient fait une pause dans leur activité malveillante afin de regarder quelques matches.

Dans l’ensemble, l’activité totale du botnet a culminé entre le 20 et le 28 mai puis a commencé à faiblir les jours suivants.

Sur le graphique ci-dessous, nous pouvons voir chaque site attaqué, marqué d’une couleur différente, ainsi que le nombre d’adresses IP l’ayant assailli.

ELF 5

Du point de vue des victimes

Si un site était infecté, il se mettait à produire de la cryptomonnaie pour le compte de l’auteur de l’attaque. Cela pouvait éventuellement aboutir à un déni de service si l’attaquant monopolisait la puissance du processeur pour son activité de minage. En outre, un serveur infecté continuait de propager le malware à d’autres victimes, ce qui risquait d’entacher sa réputation et de le faire inscrire sur liste noire par les outils de sécurité.

La relation plusieurs-à-plusieurs entre les sites attaqués et les adresses IP attaquantes du botnet Ash débouche sur une situation courante dans laquelle, du point de vue de la cible, il est difficile de détecter qu’un assaut volumétrique est en cours, étant donné que chaque IP n’envoie qu’un nombre restreint de requêtes par jour à chaque site, avant de se tourner vers le suivant.

La figure ci-dessous indique le nombre de requêtes envoyées par une seule IP attaquante à une seule application en un seul jour. Comme vous pouvez le voir, dans la grande majorité des cas (84 %), une adresse attaquante a exécuté une unique requête vers un seul site au cours d’une même journée.

Ainsi, en décorrélant simplement les adresses IP attaquantes de leurs cibles, l’assaillant peut éviter que le site visé repère une IP source par des mesures volumétriques.

Une telle asymétrie entre la complexité des tâches respectives des attaquants et des défenseurs est typique du domaine de la cybersécurité.

Neutralisation

Comme nous l’avons dit précédemment, à moins que la charge malveillante ne soit bloquée par les règles de sécurité existante (ce qui n’est pas le cas pour les attaques Zero Day), la victime a toutes les peines du monde à détecter une telle campagne d’attaques distribuées. Une perspective plus large englobant des cibles multiples – comme celle dont bénéficie un prestataire de sécurité dans le cloud – est nécessaire.

De ce point de vue, les corrélations comportementales entre les adresses IP et les différents sites ciblés deviennent évidentes et peuvent servir à identifier des attaques synchronisées comme celles du botnet Ash. En outre, lors d’attaques ultérieures par le même botnet, il est possible de les neutraliser en bloquant les requêtes issues des adresses IP appartenant au botnet, chaque fois qu’une activité synchrone et corrélée est détectée parmi ces dernières. En outre, nous vous recommandons les mesures suivantes :

  1. Installez en permanence les plus récents correctifs de sécurité.
  2. Déployez une solution de sécurité disposant d’une vision globale pour détecter et bloquer les activités malveillantes invisibles du point de vue d’une seule application.

Il est à noter que le blocage d’emblée de toutes les requêtes issues des adresses IP ayant participé à l’attaque mettrait en péril l’activité légitime des machines d’utilisateurs de bonne foi, infectées à leur insu. Par conséquent, des indices supplémentaires doivent être employés, par exemple la détection d’un outil automatique, afin de distinguer les activités légitimes et malveillantes en provenance d’une même adresse IP.

Share.

About Author

Threat Analytics Manager au sein de la division Imperva Defense Center d'Imperva. Diplômé en science informatique de l'institut de technologie Technion en Israël (2006), Nadav Avita évolue depuis plus de 10 ans dans le domaine l'informatique, tout d'abord comme ingénieur logiciel puis comme développeur Linux Kernel chez Imperva qu'il rejoint en 2010. Depuis 2013, Nadav est rattaché à l'équipe de recherche d'Imperva et évolue pour devenir en avril 2018 Threat Analytics Manager.

Leave A Reply