Evooo1Bot Linux Botnet : Capacités et Techniques d’Attaque

Résumé

Evooo1Bot est un botnet Linux basé sur Mirai nouvellement identifié qui compromet les appareils périphériques pour établir une infrastructure proxy persistante. Le malware inclut des capacités avancées telles que la communication C2 cryptée, un module de relais SOCKS, et un arsenal d’exploits intégré. Il cible de nombreuses vulnérabilités affectant les appareils IoT et le matériel de réseau.

Enquête

FortiGuard Labs a découvert le botnet grâce à une télémétrie IPS qui a capturé des tentatives d’exploitation actives. L’enquête a révélé une architecture modulaire dans laquelle un script de chargement récupère des binaires adaptés à l’architecture du système cible. Les analystes ont également identifié plusieurs techniques d’évasion, y compris le déchiffrement de chaînes multiniveaux et les vérifications d’outils d’analyse.

Atténuation

Les organisations doivent prioriser le patching en temps opportun de tous les appareils exposés à Internet et des équipements réseau. Les mises à jour régulières du firmware et la surveillance continue des connexions sortantes suspectes sont essentielles pour réduire l’exposition. Désactiver les services non nécessaires sur les appareils périphériques peut également minimiser la surface d’attaque disponible.

Réponse

Si une activité Evooo1Bot est détectée, les appareils périphériques affectés doivent être isolés du réseau immédiatement pour arrêter le mouvement latéral et l’abus de proxy. Les enquêteurs doivent déterminer l’étendue de la compromission et rechercher des mécanismes de persistance tels que des tâches cron ou des services systemd. Les identifiants potentiellement exposés via le renifleur d’identifiants du botnet doivent également être tournés.

Exécution de simulation

Prérequis : Le contrôle pré-vol de télémétrie et de base doit avoir réussi.

Raison : Cette section détaille l’exécution précise de la technique de l’adversaire (TTP) conçue pour déclencher la règle de détection. Les commandes et le récit DOIVENT refléter directement les TTPs identifiés et viser à générer la télémétrie exacte attendue par la logique de détection. Des exemples abstraits ou non liés conduiront à un mauvais diagnostic.

• Narration de l’attaque & Commandes : Un adversaire a obtenu un accès initial à un serveur Linux. Pour s’assurer que leur agent botnet reste actif pendant une utilisation intensive des ressources, ils exécutent une commande qui télécharge une charge utile depuis un serveur C2 distant en utilisant curl -sL (silencieux, suit les redirections). Immédiatement après le téléchargement, le processus tente de manipuler sa propre priorité du noyau en écho -17 dans /proc/self/oom_score_adj. Cette combinaison spécifique d’un téléchargement « furtif » et de « protection des processus » est la signature d’Evooo1Bot.

• Script de test de régression :

  #!/bin/bash
  # Simulation du comportement d'Evooo1Bot
  # Objectif : Déclencher la règle de détection en correspondant aux deux conditions de CommandLine
  
  echo "[+] Lancement de la simulation d'Evooo1Bot..."
  
  # Étape 1: Simuler le téléchargement furtif en utilisant exactement les drapeaux dans la règle
  # Nous utilisons une boucle locale ou une URL fictive pour éviter un trafic externe réel si nécessaire
  # mais la CommandLine doit correspondre à la chaîne de la règle.
  echo "[+] Exécution de curl -sL pour simuler le téléchargement de la charge utile..."
  curl -sL http://localhost:8080/payload > /tmp/payload_test 2>/dev/null || echo "[!] Remarque : URL non accessible, mais commande exécutée."
  
  # Étape 2: Simuler l'ajustement du score OOM pour la persistance
  echo "[+] Ajustement de oom_score_adj pour prévenir la terminaison..."
  echo -17 > /proc/self/oom_score_adj
  
  echo "[+] Simulation terminée. Vérifiez le SIEM pour les alertes."

• Commandes de nettoyage :

  # Supprimer le fichier de charge fictive
  rm -f /tmp/payload_test
  
  # Réinitialiser le score OOM (bien qu'il n'affecte que le shell/processus courant)
  echo 0 > /proc/self/oom_score_adj