Une analyse de Dridex, un logiciel malicieux ‘bancaire’ qui vole les mots de passe.

Comment CYDEF a répondu à une attaque Dridex

Le Trojan Dridex est une menace significative aux institutions financières depuis son identification en 2011.

Il y a quelques mois, un client de CYDEF a été infecté par ce logiciel malveillant. La publication suivante présente les étapes pour l’identification du logiciel malveillant, les efforts pour la réponse et la remédiation.

Qu’est-ce que Dridex?

Dridex est un logiciel malveillant conçu pour voler les noms d’usager et les mots de passe des victimes. Il a obtenu sa réputation de trojan bancaire en usurpant les comptes utilisés sur les sites bancaires.

Le logiciel malveillant est passé à travers de multiples évolutions pour ajouter à ses capabilités, notamment le vol de portefeuille de crypto-monnaie et l’évasion anti-virus (AV). Une portion de cette capabilité d’évasion vient de l’utilisation de techniques “vivre de la terre”, ou des outils systèmes communs comme Microsoft Office sont utilisés pour des fins malicieuses. En s’attachant à des logiciels de confiance très connus, Dridex peut outrepasser les outils AV standard.

Une fois que Dridex vole les informations d’identification et d’authentification de l’usager, les opérateurs du logiciel malveillant “ont le potentiel de faciliter des transferts par chambre de compensation automatisé et virement bancaires frauduleux, ouvrir des comptes frauduleux, et potentiellement adapter les comptes de victimes pour d’autres fraudes impliquant la compromission de courriel d’affaires ou des activités de mule d’argent.” (U.S. Cybersecurity & Infrastructure Security Agency, Traduction libre)

Dridex et la pandémie COVID-19

Dans le contexte de la pandémie de COVID-19, avec plusieurs employés travaillant de la maison pour éviter l’infection, les entreprises petites ou grosses doivent se fier aux ressources infonuagiques pour rendre leurs employés productifs, offrant du même coup à Dridex une nouvelle opportunité de voler des comptes usager.

Identifier l’incident Dride

Dans le contexte de notre client, Dridex a été détecté pendant que nous faisions notre surveillance de sécurité quotidienne. Nous avons identifié une nouvelle ligne de commande en Powershell :

Dridex power shell command line

Nous avons aussi identifié une nouvelle activité réseau provenant de Powershell et se dirigeant vers un ASN inconnu localisé en Russie. Nous avons rapidement téléchargé les journaux pour une investigation plus approfondie de cette activité suspecte.

C’est à ce moment que nous avons pu identifier la command Powershell suivante:

Powershell command line

La communication réseau pointait à l’adresse IP suivante :

Dridex incident IP address

Le processus parent rundll de la ligne de commande :

rundll command line

Utilisation suspecte de Powershell

Le code Powershell obfusqué était déjà plutôt suspect. En y ajoutant des commandes séparées et réassemblées via la concaténation de chaînes de charactères – nous savions qu’il y avait quelque chose qui clochait. L’utilisation de rudll32 -s shell32 était un indicateur clair que ceci était de l’activité non-légitime.

Il y a seulement un programmeur qui tente d’outrepasser la sécurité qui écrirait du code de cette manière.

À ce point, nous étions convaincus que ceci était un incident et avons contacté le client. Nous avons aussi suggéré que l’adresse IP soit bloquée au pare-feu.

Une fois le client avisé, nous avons continué de creuser. En regardant le reste des activités non-classifiées, nous avons trouvé la ligne de commande rundll32 suspecte et nous avons pu identifier le processus parent : Excel.

Puisqu’un fichier Excel était la source probable de la brèche, nous avons noté le temps précis d’occurrence et nous avons commencé à chercher dans les journaux pertinents.

S’attaquer à la défaillance de l’anti-virus et l’identification du logiciel malveillant

Après avoir ramassé tous les journaux bruts de notre stockage infonuagique, nous avons suivi trois étapes pour comprendre la brèche : nous procédé au confinement, identifié la souche du logiciel malveillant, et identifié le moment de la brèche.

L’antidote à la défaillance de l’anti-virus : la quarantaine

Une fois la brèche identifiée, notre client a scanné la machine en question avec un AV. Toutefois, l’AV n’a pas été en mesure de trouver le logiciel malveillant. Pour s’assurer que le logiciel malveillant était en quarantaine, le client nous a donné l’autorisation d’utiliser notre module de confinement. Nous avons désactivé la carte réseau de la machine pour prévenir les possibilités de propagation réseau.

Identifier la souche de logiciel malveillant

Une fois la machine mise en quarantaine, nous nous sommes attelés à l’identification de la souche spécifique du logiciel malveillant. L’identification de la famille de logiciel malveillant nous permettrait de déterminer s’il y a une méthode sécurité d’éradiquer le logiciel malveillant, ou si restaurer la machine à partir d’une image de confiance serait la solution idéale.

Pour ce faire, nous devions déobfusquer le code pour pouvoir le comparer à d’autres logiciels malveillants connus. En particulier, nous avions besoin d’extraire l’expression encodée en Base64.

La première étape était d’utiliser la fonction deflate sur le contenu. Ceci nous a donnée une archive compressée gzip. Ensuite, nous avons extrait le contenu du fichier pour avoir le résultat final.

En déobfuscant le code, nous avons trouvé l’URL rumetonare[.]com que nous avons utilisé pour trouvé la publication Twitter suivante correspondant à la fois à l’URL du CnC et au code Powershell observé.

Twitter tracks Dridex

Dridex avait infecté la machine de notre client. À partir de cette découverte, nous avons contacté le client pour lui indiquer que la manière de procéder la plus prudent serait de restaurer la machine à partir d’une image propre.

Reconstitution de la trame d’événements

Avec le logiciel malveillant identifié, nous devions comprendre la suite d’événements menant à l’infection. Cette trame d’événements pourrait nous indiquer la source de l’infection, le moment où la brèche est survenue et si des actions additionnelles devaient être prises pour rétablir l’environnement du client.

En utilisant le GUID du processus Excel, nous avons identifié toutes les activités provenant du processus dans les journaux bruts. En particulier, nous avons cherché le fichier Excel qui a démarré l’infection. Ultimement, un usager a reçu un courriel dans Outlook qui a fourni un lien vers le serveur de courriel web interne du client. Selon l’URL, nous avons déduit que le message disait à l’usager qu’un email était en quarantaine et que, pour avoir accès au message, l’usager

devait se connecter au courriel web et relâcher l’item de la quarantaine. À ce point, la victime a téléchargé le fichier Excel à partir du serveur de courriel web et a exécuté Dridex sans le savoir.

Une fois que nous avons identifié la source de l’infection, nous savions qu’il était peut probable que le client soit réinfecté immédiatement. Malgré le fait que l’incident avait un fort potentiel de dommage, il s’agissait aussi d’une opportunité de leçon apprise pour la sensibilisation à la sécurité.

Identifier les points de persistance potentiels

En plus de trouver la source, nous voulions identifier les points de persistance potentiels. Nous avons trouvé la ligne de commande suivant liée au logiciel malveillant :

Persistent Command Line Dridex

Cette ligne suggère deux choses : le script était soit une forme d’escalade de privilège du compte usager, ou une manière d’établir une persistance (ou potentiellement les deux). Ayant trouvé à la fois le vecteur d’entrée initial et la source potentielle de persistance, nous pouvions reconstruire la trame des événements.

Les impacts de Dridex : restaurer l’image d’une seule machine

À partir de toute cette information, notre client a décidé de restaurer la machine à partir d’une image propre. Comme mesure de précaution, le client nous a aussi demandé de continuer notre surveillance pour s’assurer qu’aucun signe de réinfection n’était présent sur la machine avant de la ré-attacher au domaine. Nous avons averti le client le jour suivant que nous n’avions observé aucun signe de réinfection et que celui-ci pouvait retourner aux opérations normales.

Lorsque les brèches surviennent, CYDEF persiste

Cet incident souligne l’important ce la sensibilisation à la cyber sécurité en milieu d’entreprise. Si l’individu n’avait pas donné suite à une demande provenant d’un courriel illégitime, la brèche ne serait jamais survenue.

Mais, après tout, l’erreur est humaine. Les employés commettent des erreurs. C’est pourquoi il est important d’adopter une approche en couche – avec un accès à de la sécurité hôte, des outils de détection et un support géré. CYDEF a été en mesure d’intervenir quand l’AV n’a pas pu identifier un problème, et nous avons traqué la brèche avec efficacité.

Êtes-vous intéressé à en savoir plus à propos de la détection des brèches liées à des erreur humaines? Contactez-nous. Il nous fera plaisir de vous aider.