L'attaque «Cloud Snooper» contourne les mesures de sécurité du pare-feu – Sophos News – Serveur d’impression

Au cours d'une enquête sur une infection par un logiciel malveillant des serveurs d'infrastructure cloud hébergés dans le cloud Amazon Web Services (AWS), les SophosLabs ont découvert une attaque sophistiquée qui employait une combinaison unique de techniques pour échapper à la détection et qui permet au malware de communiquer librement avec sa commande et contrôler (C2) les serveurs via un pare-feu qui devrait, dans des circonstances normales, empêcher précisément ce type de communication d'atteindre le serveur infecté.

Nous avons publié un rapport détaillé sur l'attaque, que nous avons nommé Cloud Snooper.

Bien que nous ayons découvert la technique utilisée sur AWS, le problème n'est pas un problème AWS en soi. Il représente une méthode de ferroutage du trafic C2 sur un trafic légitime, tel que le trafic Web normal, d'une manière qui peut contourner de nombreux, sinon la plupart, des pare-feu.

La complexité de l'attaque et l'utilisation d'un ensemble d'outils APT (Advanced Persistent Threat) sur mesure nous donnent des raisons de croire que le malware et ses opérateurs étaient un acteur de menace avancé, éventuellement parrainé par l'État-nation.

Les systèmes compromis exécutaient des instances Linux et Windows EC2.

Un trafic anormal déclenche des alertes

Comme cela arrive souvent avec des incidents comme celui-ci, notre enquête a commencé lorsque quelqu'un a remarqué une anomalie. Alors que les groupes de sécurité AWS (SG) étaient correctement réglés, configurés uniquement pour autoriser le trafic HTTP ou HTTPS entrant, le système Linux compromis écoutait toujours les connexions entrantes sur les ports 2080 / TCP et 2053 / TCP.

Une analyse de ce système a révélé la présence d'un rootkit qui accordait aux opérateurs du malware la possibilité de contrôler à distance le serveur via les AWS SG. Mais les capacités de ce rootkit ne se limitent pas à le faire dans le cloud Amazon: il pourrait également être utilisé pour communiquer avec et contrôler à distance les logiciels malveillants sur n'importe quel serveur derrière n'importe quel pare-feu de limite, même un serveur sur site.

En déroulant d'autres éléments de cette attaque, nous avons en outre identifié d'autres hôtes Linux, infectés par le même rootkit ou un rootkit similaire.

Enfin, nous avons identifié un système Windows compromis avec une porte dérobée qui communiquait avec un C2 similaire à d'autres hôtes Linux compromis, en utilisant un format de configuration très similaire. La porte dérobée est apparemment basée sur le code source du fameux malware Gh0st RAT.

À ce stade de l'enquête, nous avons encore des questions ouvertes. Par exemple, on ne sait toujours pas comment les attaquants ont réussi à compromettre le système du client en premier lieu. L'une des théories de travail est que les attaquants sont entrés par effraction dans un serveur via SSH, protégé par une authentification par mot de passe.

Illustration de haut niveau

Avant de commencer notre description technique, fournissons une vue de haut niveau de l'attaque Cloud Snooper. Cela pourrait aider le lecteur à se faire une idée globale de la façon dont ses éléments sont liés les uns aux autres.

Dans l'illustration ci-dessus, notre château représente l'infrastructure de serveur ciblée; Dans le cas de l'incident sur lequel nous avons enquêté, le serveur était hébergé par Amazon Web Services (AWS). À son périmètre, le Groupes de sécurité AWS (SG) – un ensemble de règles de pare-feu qui assurent la sécurité au niveau du protocole et de l'accès aux ports – limitent le trafic réseau entrant.

Par exemple, vous pouvez généralement configurer un groupe de sécurité AWS qui autorise uniquement le trafic Web – c'est-à-dire les paquets TCP qui arrivent aux ports 80 ou 443 – à atteindre votre serveur. Le trafic réseau avec tout autre port de destination ne dépasse jamais les SG.

L'infection implique un rootkit qui inspecte le trafic réseau et une porte dérobée que les attaquants utilisent le rootkit pour envoyer des commandes à la porte dérobée et en recevoir des données.

Afin de contourner les règles du pare-feu, représentées ici comme des gardes, les attaquants communiquent avec le rootkit en envoyant des demandes d'apparence innocente (représentées dans l'illustration comme un loup en vêtements de mouton) au serveur Web sur les ports normaux du serveur Web. Un écouteur qui inspecte le trafic entrant avant qu'il n'atteigne le serveur Web intercepte les demandes spécialement conçues et envoie des instructions au logiciel malveillant en fonction des caractéristiques de ces demandes.

L'auditeur envoie une commande C2 «reconstruite» au cheval de Troie de porte dérobée installé par le rootkit. Selon les commandes incluses dans le trafic C2, l'attaquant peut utiliser la porte dérobée pour voler des données sensibles à la cible.

Les données collectées sont ensuite restituées avec le trafic C2. Seulement cette fois, le rootkit doit le masquer à nouveau afin de contourner les gardes: le loup s'habille à nouveau en vêtements de mouton. Une fois à l'extérieur, le trafic C2 restitue les données collectées aux attaquants.

Pendant toute une opération, le trafic Web normal, représenté comme un mouton, continue de circuler vers et depuis le serveur Web via la porte autorisée. Visuellement, le trafic C2 reste largement indiscernable du trafic Web légitime.

Démontage des outils Cloud Snooper

Comme vous le verrez dans la description ci-dessous, certains échantillons que nous avons collectés sont directement liés les uns aux autres, tandis que d'autres appartiennent à une famille de logiciels malveillants complètement différente. Néanmoins, tous ces échantillons ont été collectés à partir de la même infrastructure, et donc nous les considérons comme faisant partie du même ensemble d'outils.

La description commence par le malware Linux, puis progresse dans son homologue Windows qui est apparemment basé sur Gh0st RAT.

Dans l'ensemble, nous avons découvert et étudié 10 échantillons au cours de l'enquête, qui peuvent être ventilés comme suit:

Gestionnaire de communications Cloud Snooper

La pièce centrale de l'attaque est un fichier nommé snd_floppy – un module du noyau qui configure un filtre de paquets réseau, à l'aide d'un hook Netfilter (NF_INET_LOCAL_IN et NF_INET_LOCAL_OUT).

Ce composant a contribué à donner aux opérateurs du malware la possibilité de communiquer avec le malware, malgré le pare-feu protégeant les serveurs AWS EC2.

le NF_INET_LOCAL_IN est un type de hook qui est déclenché avant que le paquet n'atteigne le port de destination.

Le gestionnaire de hook installé inspecte le tampon de socket de chaque paquet IPv4, à la recherche d'une commande cachée dans un en-tête – la commande étant le numéro de port source du paquet provenant de la machine de l'attaquant. Ces commandes / ports source peuvent être l'un des numéros de port suivants: 1010, 2020, 6060, 7070, 8080, 9999.

Les pare-feu empêchent généralement les machines derrière le pare-feu de recevoir du trafic envoyé vers des sources arbitraires destination ports, mais ils ne font pas attention à la la source les ports, car les ports source sont normalement éphémères et ne concernent pas le serveur ou les services qu'il héberge.

Dans une instance de cloud typique, le serveur peut être configuré pour recevoir le trafic de n'importe quelle adresse IP sur le port 80 / TCP (pour HTTP) et sur 443 / TCP (pour HTTPS), de sorte que le pare-feu laisse passer tout le trafic vers ces ports vers le serveur. Tant que le trafic entrant dans l'un de ces ports standard correspond au modèle recherché par le gestionnaire de communications, il exécutera l'une de ses instructions intégrées. Tout le reste sera ignoré et le serveur servira les pages Web normalement aux navigateurs.

Par exemple, si le gestionnaire de communications reçoit un paquet TCP SYN avec un port d'origine de 6060, le logiciel malveillant déchiffrera un fichier intégré qui a été chiffré avec RC4 (la clé est «YaHo0 @»).

Il déposera ensuite ce fichier déchiffré comme / tmp / snoopy, attendez une demi-seconde, puis exécutez-le en tant qu'application de mode utilisateur avec le call_usermodehelper () syscall. Immédiatement après cela, il supprime / tmp / snoopy fichier, de sorte que l'application snoopy continue de fonctionner en mémoire sans fichier physique présent.

Si la commande est 9999 en tant que paquet TCP SYN, le / tmp / snoopy processus se termine automatiquement (au cas où tuer tous est pris en charge par OS), en passant les commandes suivantes à call_usermodehelper () syscall.

/ bin / sh -c / tmp / snoopy
rm -rf / tmp / snoopy
killall / tmp / snoopy

REMARQUE: exécution snoopy à nouveau alors qu'il est déjà en cours d'exécution n'a aucun effet; en utilisant un mécanisme de verrouillage de fichier, snoopy s'assure qu'une seule instance est en cours d'exécution. Si cela se produit, il affichera:

[ERROR]    il y a déjà une instance.

Voici la logique du NF_INET_LOCAL_IN gestionnaire de hook, qui écoute les paquets SYN envoyés au serveur, en utilisant les différents ports source:

si TCP:
    si tcp.src_port == 6060:
        si tcp.flags == SYN:
            drop_payload ()        # drops / runs snoopy
            revenir NF_STOP
    elif tcp.src_port == 7070:
        tcp.dst_port = 2080
        adjust_tcp_checksum ()
        revenir NF_STOP
    elif tcp.src_port == 9999:
        si tcp.flags == SYN:
            kill_payload ()        # tue le processus snoopy
            revenir NF_STOP
    elif tcp.src_port == 2020:
        revenir NF_STOP
    elif tcp.src_port == 1010:
        tcp.dst_port = 22
        adjust_tcp_checksum ()
        revenir NF_STOP
    autre:
        revenir NF_ACCEPT
elif udp:
    si udp.src_port == 8080:
        udp.dst_port = 2053
        adjust_udp_checksum ()
        revenir NF_STOP
autre:
    revenir NF_ACCEPT

Et voici la logique du NF_INET_LOCAL_OUT gestionnaire de crochet:

si TCP:
    si tcp.dst_port == 7070:
        tcp.src_port = 443        # or, 80 dans une autre variante
        adjust_udp_checksum ()
        revenir NF_STOP
    si tcp.dst_port == 2020:
        revenir NF_STOP
    si tcp.dst_port == 1010:
        tcp.src_port = 443        # or, 80 dans une autre variante
        adjust_udp_checksum ()
        revenir NF_STOP
    autre:
        revenir NF_ACCEPT
elif upd:
    si udp.dst_port == 8080:
        udp.src_port = 53
        revenir NF_STOP
autre:
    revenir NF_ACCEPT

Explication

Pour déclencher la charge utile (snoopy), un attaquant enverrait le paquet suivant:

Ensuite, le snoopy le module serait accessible par le C2, en utilisant le port source 7070 pour TCP ou 8080 pour le contrôle UDP:

Sur le chemin du retour, NF_INET_LOCAL_OUT Le gestionnaire de hook reconstruit à nouveau le paquet, pour vous assurer que son port source est restauré sur le port d'origine où le paquet entrant était destiné. De cette façon, le trafic C2 circule de manière transparente à travers le ou les ports autorisés par les AWS SG:

Aucun autre hook Netfilter dans la chaîne, tel que les règles INPUT / OUTPUT iptables, ne traitera le paquet si le hook retourne NF_STOP. Cela semble être le but de la commande TCP 2020: contourner les autres crochets Netfilter.

Dans les cas où le Netfilter reçoit du trafic entrant avec un port source de 1010 / TCP, il dirige le contenu vers le port Secure Shell (SSH), 22 / TCP. Pour le trafic sortant, nous avons vu deux variantes utilisant le port 80 ou le port 443. Cela permettra à une connexion SSH de contourner un AWS SG avec des restrictions IP sur le trafic vers le port 22.

Par conséquent, le but ultime de la snd_floppy rootkit est de fournir un canal de contrôle secret pour le snoopy processus en mode utilisateur, exécuté sur un hôte compromis.

Ces canaux de contrôle secrets peuvent être établis via n'importe quel port autorisé par les AWS SG, qu'il s'agisse de 80, 443, 22 ou de tout autre port.

De l'extérieur, le système compromis affichera un volume de trafic inhabituellement important provenant des ports distants 6060, 7070, 8080 et 9999.

Mais quel est le snoopy module? Qu'est ce que ça fait?

Le module Snoopy

snoopy est un cheval de Troie de porte dérobée qui peut être exécuté à la fois comme outil de ligne de commande et comme démon (bien qu'il doive être lancé avec le -ré drapeau pour cela). La version interne de la porte dérobée est 3.0.1-2.20170303.

Il ouvre les services HTTP et / ou DNS sur un système compromis et permet la tunnellisation du trafic, fonctionnant à la fois comme serveur proxy SOCKS5 inverse et client.

Par exemple, le trafic de contrôle entrant peut également être relayé vers un autre serveur.

Lorsqu'il est exécuté avec -h , l'outil imprime la syntaxe suivante:

Utilisation: rrtserver [OPTIONS]
OPTIONS:
-h
-ré
-s IPv4[:PORT:udp:dns]

Où:

• -h l'option imprimera l'utilisation ci-dessus
• -ré exécutera l'outil en tant que démon
• -s permet de spécifier une adresse de serveur à laquelle lier le socket d'écoute, son numéro de port et le protocole utilisé pour le trafic: DNS basé sur UDP ou HTTP basé sur TCP

Le binaire nécessite le privilège root; lors de l'exécution, il appelle geteuid () pour obtenir l'ID utilisateur. S'il échoue, il imprime la ligne ci-dessous et se ferme:

"Les privilèges d'administrateur sont requis."

Il définit le répertoire de travail sur / tmpet obtient un verrou pour le fichier / tmp / rrtserver-lock. Le fichier de verrouillage est utilisé pour s'assurer qu'il n'y a qu'une seule version de l'outil en cours d'exécution.

Le trafic HTTP entrant est accepté sur le port 2080 et le trafic DNS sur le port 2053.

REMARQUE: les numéros de port 2080 et 2053 sont ceux par défaut; l'outil peut être exécuté avec différents numéros de port spécifiés comme paramètres.

Snoopy analyse le trafic DNS / HTTP reçu pour en extraire des commandes cachées – ces commandes sont appelées "Messages rrootkit" et se distinguent par la présence d'un en-tête ou d'un marqueur magique.

Par exemple, pour trouver "Messages rrootkit" dans le trafic HTTP, Snoopy analyse la requête HTTP pour voir si elle commence par "GET / * HTTP / 1.1 r ndata:" ou "HTTP / 1.1 200 OK r ndonnées:".

Ensuite, le "Messages rrootkit" commencerait par un en-tête magique 0xE381B7F5. Si cet en-tête est trouvé, ces données sont appelées msg-data.

Le reçu msg-data est ensuite décrypté avec RC4, en utilisant la clé bien spécifique «Un système basé sur YARN pour le traitement parallèle de grands ensembles de données».

L'outil lance ensuite plusieurs composants supplémentaires. Ces composants traiteront les reçus msg-data.

En fonction d'un en-tête magique distinct dans chaque msg-data, les données seront traitées par un autre composant.

Les composants initiés sont:

Enregistrement

snoopy stocke de nombreux messages de débogage en texte clair.

Cependant, avec le niveau de journalisation interne défini sur 0 (aucun), aucun message de débogage n'est jamais imprimé. Par conséquent, ces messages de débogage ne sont utilisés que dans la phase de test du malware.

Certains des messages de débogage sont en chinois:

• 远程 路径 太长! – Le chemin distant est trop long!
• 远程 文件 不 存在! – Le fichier distant n'existe pas!
• 远程 内存 空间 分配 失败! – L'allocation d'espace mémoire à distance a échoué!
• 远程 路径 不 存在! – Le chemin distant n'existe pas!
• 远程 文件 已 存在! – Le fichier distant existe déjà!
• 连接 失败! – La connexion a échoué!
• 连接 成功! – La connexion a réussi!
• 参数 错误! – Erreur de paramètre!

Certains messages révèlent une mauvaise grammaire anglaise:

• vue introuvable
• view-shell: les données n'appartiennent pas à SHELL

Construire un client

En sachant comment fonctionne le protocole C2, il est possible de créer un client à qui parler snoopy soit directement, soit via snd_floppy rootkit.

Pourquoi?

Premièrement, le client peut envoyer une requête ping à un hôte situé sur le même réseau pour voir s’il est infecté ou non.

Deuxièmement, si un hôte est infecté, le client peut le désinfecter à distance en snoopy pour exécuter sa routine de désinfection (voir le rmmod ci-dessous – après l'avoir servi, le rootkit a cessé de répondre car il a été déchargé).

Enfin, construire un tel client est cool.

La capture d'écran suivante montre le client en action. le snd_floppy rootkit intercepte le trafic sur le port 22, même s'il est destiné au démon SSH (vu comme 981 / sshd dans l'instantané ci-dessous). Ensuite, il réachemine ce trafic en interne vers le snoopy module.

Tant que le rootkit est actif, les attaquants peuvent tenter de faire passer le trafic de contrôle via n'importe quel port autorisé par le pare-feu (la capture d'écran montre que l'utilisation des ports 21 et 24 ne fait aucune différence – ces paquets sont toujours redirigés par le rootkit vers le porte de derrière).

Gh0st RAT (la version Linux)

En dehors de ces exemples, nous avons également récupéré une porte dérobée Linux différente, une porte dérobée qui n'ouvre aucun port. Au lieu de cela, il s'appuie sur un mécanisme d'interrogation C2.

L'analyse de cette fonctionnalité de bot révèle qu'elle appartient à Gh0st RAT, seulement c'est une version qui a été écrite pour Linux.

Il est difficile de dire si Gh0st a toujours existé en tant que RAT multi-plateforme, ou si les attaquants ont développé un Gh0st basé sur Linux après la fuite en ligne du code source de Gh0st pour Windows.

À la fin de la journée, il est logique d'avoir des clients déployés sur différentes plates-formes, en utilisant un format de configuration unifié et un protocole C2, tout en ayant un serveur unique pour tous ces clients.

Néanmoins, nous laisserons les conjectures hors de cette description, en nous concentrant plutôt sur ce que font réellement les échantillons récupérés.

/ bin / snort est une porte dérobée qui contacte un C2 distant pour récupérer et exécuter des commandes. Son fichier de configuration interne est crypté avec RC4, en utilisant le mot de passe: "r0st @ # $":

185[.]86[.]151[.]67: 443; | 1; 1; 1; 1; 1; 0; 0; | 10-20; | 10

le «1; 1; 1; 1; 1; 0; 0;» une partie de la config sont les drapeaux qui se tiennent pendant sept jours de la semaine.

le '10 -20; ' semblent indiquer les heures de travail (10h à 20h), donc le jour de la semaine actuel et l'heure actuelle devraient correspondre à ce qui est dans la configuration.

S'il n'y a pas de match, le bot s'endort pendant un peu plus de sept minutes (423.756 secondes), puis vérifie à nouveau l'heure.

En cas de match, il tente d'atteindre le C2; s'il ne le peut pas, il réessaye dans une minute.

Le trafic vers le C2 est crypté avec un double RC4, où une clé est générée de manière aléatoire en fonction de l'heure actuelle.

La porte dérobée a six commandes:

• Le bot efface la variable environnementale HISTFILE, pour vous assurer qu'aucun historique n'est conservé / bin / bash exécution; le C2 répond avec une chaîne, le bot définit le TERME variable à cette chaîne
  Ensuite, il reçoit une commande et l'exécute avec / bin / bash, avec ou sans le «-c» commutateur (permet d'exécuter des commandes comme indiqué dans les guillemets)
  La sortie de la commande exécutée est renvoyée
• Manipulations de fichiers:
  • Recherchez et obtenez l'horodatage du fichier spécifié
  • Renommer le fichier spécifié
  • Supprimer récursivement tous les fichiers du répertoire spécifié
• Plus de manipulations de fichiers:
  • Lire le contenu du fichier spécifié
  • Recherche récursive de fichiers
  • Écrire des données dans un fichier spécifié
  • Créer un répertoire spécifié
• Les deux commandes suivantes manipulent les descripteurs de fichiers avec fcntl () syscall et fork des processus enfants
• Recevoir des données et les enregistrer dans un fichier local /usr/include/sdfwex.h

Il semble que /usr/include/sdfwex.h contient un horodatage (année, mois, jour, heure, minutes) pour le début de la connexion C2.

Si le bot ne peut pas ouvrir ce fichier, il essaie de l'ouvrir /tmp/.llock – si ce fichier ne peut pas également être ouvert, le bot ignore la vérification de l'horodatage et continue d'essayer de se connecter au C2.

D'autres variantes de cet exemple utilisent différentes configurations, telles que:

nuage[.]newsofnp[.]com: 443; | 1; 1; 1; 1; 1; 1; 1; | 00-24; | 1
charge[.]CollegeSmooch[.]com: 82; | 1; 1; 1; 1; 1; 1; 1; | 00-24; | 10

Pour le signal de balise qu'il envoie au C2, il collecte la configuration de base du système dans une empreinte digitale. Ces informations consistent en:

• Nom d'hôte et adresse IP
• Type de plateforme, tel que lu dans / proc / version, tel que 'x86_64'
• Nom complet de la version Linux, tel que lu dans /etc/issue.net et / etc / issue, tel que:
  • «Red Hat Enterprise Linux Server version 6.10 (Santiago)»
  • «Ubuntu 16.04.5 LTS»

Les communications avec le C2 sont toujours cryptées à l'aide d'un algorithme sur mesure qui repose sur une clé RC4 aléatoire temporelle avec des couches de cryptage supplémentaires.

Logiciel malveillant Windows

NSIProvider.dll est une DLL de service Windows malveillante, exécutée sous svchost.exe.

Le nom du service est NSIProvider, enregistré avec le nom de la description «Fournisseur d'interface de magasin Netword».

REMARQUE: «Netword» avec «d».

La DLL est fortement masquée.

Une fois démarré en tant que service, il crache facilement des messages de débogage documentant l'opération.

DebugView de Sysinternal affiche ces messages:

00000000 0.00000000	[4052] DLL_PROCESS_ATTACH.
00000001 0,00489140	[4052] Rundll32Entry ()
00000002 0,01733349	[4052] ServerLoadPayload ()
00000003 0,01749189	[4052] Obtenir le nom de fichier du module.
00000004 0,01753826	[4052] Obtenez le nom du fichier de charge utile.
00000005 0,01757095	[4052] Basculez vers le répertoire de charge utile.
00000006 0,01768074	[4052] Lisez le fichier de charge utile.
00000007 0,01811264	[4052] Déchiffrez les données de charge utile.
00000008 0,06122175	[4052] Vérifiez les données de charge utile.
00000009 0,06732560	[4052] ServerExecutePayload ()
00000010 0,06740102	[4052] Appelez Shellcode.

Une fois chargée, la DLL localise le fichier de charge utile chiffré et le charge en mémoire.
Les étapes sont les suivantes:

• Obtenez le nom de fichier du module actuel avec GetModuleFileName () API, c'est-à-dire % PATH% NSIProvider.dll
• Concaténer le nom de fichier du module actuel avec «.Crt», par exemple. % PATH% NSIProvider.dll.crt
• Allouez de la mémoire avec VirtualAlloc () et lire l'intégralité du fichier de charge utile en mémoire
• Initialiser une table de permutation composée de 256 DWORD
  Chaque valeur de la table de permutation est calculée comme suit:

  * ptr = ((* ptr >> 1) & 0x54384748 | ~ (* ptr >> 1) & 0xABC7B8B7) ^ 0x467F3B97;
  ...
  PERM_TABLE[*index] = * ptr;
  

• Démarrer la boucle de déchiffrement – dans cette boucle, une valeur de clé est soustraite de chaque octet de la charge utile chiffrée; la valeur de clé elle-même est calculée à chaque itération sur la base de la valeur de clé précédente, de l'index actuel de l'octet déchiffré et de la table de permutation:

  ptr = __ptr_index ++;
  val = PERM_TABLE[((*ptr & 0x67612505 | ~*ptr & 0x989EDAFA) ^ (KEY & 0x67612505 | ~KEY & 0x989EDAFA)) & ((*ptr & 0x67612505 | ~*ptr & 0x989EDAFA) ^ (KEY & 0x67612505 | ~KEY & 0x989EDAFA) ^ 0xFFFFFF00)];
  KEY = (val & 0x432AA81D | ~ val & 0xBCD557E2) ^ ((KEY >> 8) & 0x432AA81D | ~ (KEY >> 8) & 0xBCD557E2);
  

• La charge utile décryptée révèle une somme de contrôle, un nombre de zéro octets, suivi du shellcode initial lui-même:
  

Le blob de charge utile déchiffré est copié dans un tampon de mémoire nouvellement alloué et le shellcode initial (commence à partir d'octets EB 17 58 dans l'image ci-dessus) est appelé.

Le shellcode initial décryptera ensuite le reste du blob, en utilisant une clé XOR qui commence à partir de 0x2B, puis incrémenté par l'index de l'octet déchiffré, c'est-à-dire que les valeurs de clé XOR sont: 0x2B, 0x2C, 0x2E, 0x31, etc.

Comme le reste de l'objet blob est déchiffré, le fichier de configuration est également déchiffré, suivi par d'autres parties.

Une fois que le shellcode initial a terminé le décryptage, le blob entièrement décrypté sera composé de:

Une fois décodé, le shellcode de deuxième étape est appelé – c'est la porte dérobée elle-même.

Lorsqu'il obtient le contrôle, il obtient dynamiquement toutes les API dont il a besoin en utilisant des hachages d'API codés en dur. Pour trouver des hachages correspondants à partir des noms d'API, le shellcode s'appuie sur une légère modification de l'algorithme ROR-13. La seule différence est qu'il vérifie si l'octet zéro est à la fin de la boucle, a donc un ROR supplémentaire pour l'octet zéro final.

Toutes les DLL requises sont chargées dynamiquement.

Ensuite, il décompressera et chargera 2 stubs en tant que DLL. Les deux DLL ont le nom interne LIBEAY32.dll.

Les deux DLL reposent sur une version plus ancienne (2004) de libeay32.dll – voici quelques chaînes trouvées dans le corps de ces DLL:

Partie MD2 d'OpenSSL 0.9.7d 17 mars 2004
Partie MD4 d'OpenSSL 0.9.7d 17 mars 2004
MD5 fait partie d'OpenSSL 0.9.7d 17 mars 2004
SHA fait partie d'OpenSSL 0.9.7d 17 mars 2004
SHA1 fait partie d'OpenSSL 0.9.7d 17 mars 2004

La porte dérobée s'appuie sur ces DLL pour les fonctions cryptographiques nécessaires pour communiquer avec le C2.

Le format de configuration est cohérent avec les binaires ELF, c'est-à-dire les sept '1;' signifie que le bot doit être actif sept jours par semaine, toutes les heures (00-24), le C2 communique via HTTPS.

La même configuration est connue pour être utilisée par Gh0st RAT.

Juste comme / bin / snort décrit ci-dessus, le bot vérifie également si le jour et l'heure actuels correspondent à ceux spécifiés dans la configuration.

S'il n'y a pas de match, le bot s'endort également pendant un peu plus de sept minutes (423.756 secondes), puis vérifie à nouveau le temps.

Les extraits de code ci-dessous montrent que le délai de 423 756 millisecondes spécifié dans / bin / snort l'exécutable est identique à son homologue Windows:

Exécutable ELF: / bin / snort	les fenêtres shellcode:

Sous Linux, le nombre 423 756 est multiplié par 1 000, puis passé à tu dors() syscall qui prend un argument en microsecondes.

Sous Windows, le même nombre est transmis à l'API Sleep (), qui prend l'argument en millisecondes.

Dans les deux cas, le retard obtenu est identique: 7,062 secondes.

Conclusion

Ce cas est extrêmement intéressant car il démontre la véritable nature multiplateforme d'une attaque moderne.

Un attaquant bien financé, compétent et déterminé ne sera probablement jamais limité par les limites imposées par les différentes plates-formes.

La construction d'une infrastructure de serveur unifiée qui dessert divers agents travaillant sur différentes plates-formes est parfaitement logique pour eux.

En ce qui concerne la prévention contre cette attaque ou des attaques similaires, les SG AWS fournissent un pare-feu aux limites robuste pour les instances EC2. Cependant, ce pare-feu n'élimine pas la nécessité pour les administrateurs réseau de conserver tous les services orientés vers l'extérieur entièrement corrigés.

L'installation par défaut du serveur SSH nécessite également des étapes supplémentaires pour le durcir contre les attaques, le transformant en un démon de communication solide comme le roc.

CIO

Ports ouverts sur un hôte local

• TCP 2080
• udp 2053
• tcp 10443

Exemple:

utilisateur @ hôte: ~ $ sudo netstat -peanut | grep ": 2080  |: 2053"
tcp 0 0 0.0.0.0:2080    0.0.0.0:* ECOUTER 0 34402 2226 /snoopy
udp 0 0 0.0.0.0:2053    0.0.0.0:* 0 34398 2224 /snoopy

Pour vérifier si ces ports sont ouverts sur un hôte compromis à distance avec IP 192.168.5.150:

utilisateur @ hôte: ~ $ sudo nmap 192.168.5.150 -p 2080
...
SERVICE DE L'ÉTAT DU PORT
2080/ tcp filtré autodesk-nlm

utilisateur @ hôte: ~ $ sudo nmap 192.168.5.150 -p 2053 -sU
...
SERVICE DE L'ÉTAT DU PORT
2053/ udp filtré lot105-ds-upd

Connexions entrantes à partir des ports distants:
1010, 2020, 6060, 7070, 8080, 9999

Domaines:

• nuage[.]newsofnp[.]com
• ssl[.]newsofnp[.]com
• charge[.]CollegeSmooch[.]com

IP:

• 62[.]113[.]255[.]18
• 89[.]33[.]246[.]111
• 185[.]86[.]151[.]67

Noms de fichiers:

• / tmp / rrtserver-lock
• / proc / sys / rrootkit
• /tmp/rrtkernel.ko
• / usr / bin / snd_floppy

Module noyau:

Messages Syslog:

• «… Insmod: ERREUR: impossible d'insérer le module / usr / bin / snd_floppy: le fichier existe»
• «… Noyau: snd_floppy: chargement du module hors de l'arborescence ternit le noyau.»
• «… Noyau: snd_floppy: échec de la vérification du module: signature et / ou clé requise manquantes – altération du noyau»