TeslaCrypt – Infection en 3 requêtes HTTP

Bulletin d’alerte du CERT-FR :http://www.cert.ssi.gouv.fr/site/CERTFR-2015-ALE-015/CERTFR-2015-ALE-015.html

Avez-vous déjà entendu parler de TeslaCrypt ? Si le terme de Ransomware vous dit quelque chose, c’est que vous y avez déjà été confronté, que ce soit en prévention ou en réaction.

Introduction

Le Ransomware est un logiciel malveillant qui a pour but de crypter absolument tous les fichiers d’exploitation qu’il pourra trouver sur son chemin dans le seul but de prendre la société cible en otage et ainsi espérer que cette dernière ne cède au chantage de la rançon. Cette rançon est variable mais se paiera toujours en Bitcoin et généralement via le réseau alternatif Tor, qui garantit l’anonymat de la transaction. Moyennant quelques valeurs morales de la part du pirate, on obtient, en échange de ces Bitcoins, une clef qui permet de décrypter vos fichiers.

Bien entendu, pour la plupart des sociétés, il n’est pas question de céder au chantage et il s’enclenche alors une longue procédure de « nettoyage » et de restauration des serveurs infectés.

Un de nos clients a récemment été confronté à une nouvelle version de ce TeslaCrypt, non reconnu par les antivirus du marché. En effet, l’alerte a été lancée lorsquele profil d’un utilisateur John Doe a été entièrement crypté, ainsique quelques partages réseaux, empêchant ainsi l’exploitation d’un des outils métiers.

La sonde Securactive Performance Vision a alors joué un rôle important dans la compréhension du déroulement de l’infection. En effet, un audit de performance Réseau et Application étant en cours chez ce client, la sonde analyse tout le trafic du coeur de réseau.

Etape 1 : S’informer

En effectuant quelques recherches sur la toile, on peut trouver ce simple schéma de fonctionnement des cryptolocker :

On peut en déduire que l’infection se déroule en deux phases, d’abord l’exécution du binaire, puis la récupération de la clef de cryptage.

De plus, ce virus est véhiculé uniquement par du spam ciblé et via pièce jointe. Il y a donc de fortes chances que John Doe ait malencontreusement ouvert un .zip issu d’un mail malveillant, ayant échappé au contrôle de l’antispam.En analysant les journaux du serveur de mail, c’est effectivement le cas.

Etape 2 : Retrouvez rapidement sur quel serveur l’utilisateur John Doe s’est connecté

On sait que John Doe possède un client léger associé à un nom DNS, ce qui nous permet donc de retrouver son adresse IP.

De plus, on sait que tout allait bien la veille au soir. On est alors capable de placer les bons filtres dans la sonde Performance Vision et ainsi visualiser d’un seul coup d’oeil les échanges entre l’utilisateur et les serveurs Citrix.

On constate que John Doe s’est connecté à 8:51:25 sur le Citrix 13 après avoir été redirigé par le portail Citrix9. On constate également que sa connexion Citrix s’est arrêtée à 10:14:56.

On suppose donc que le seul contact « informatique » de John Doe a été le Citrix 13 entre 8h51 et 10h14.

Etape 3 : Que s’est-il passé sur ce Citrix ?

Si l’on regarde les échanges entre le Citrix13 et le Proxy sur notre tranche horaire, on peut constater quelques URLs intrigantes :

En forant un peu plus, on découvre le détail des HITs des pages grâce au décode HTTP de la sonde.

On constate donc une infection en deux temps :

• Téléchargement d’un binaire à9:09:32

• Récupération de l’IP Publique du client et de la clef de cryptage à9:09:40

À partir de là commence le cryptage des données. En témoigne lesSMB status object name not foundsuivants qui sont remontés lors de la première requête CIFS à destination du NAS sur le répertoire de l’application.Cela concorde avec l’heure de la première plainte utilisateur.

Conclusion

Récapitulatif :

• Réception d’un mail incluant des mots familiers à l’utilisateur John Doe avec Pièce Jointe en .zip associé ;

• Ouverture du .zip par John Doe, qui contient une macro en .js (Exemple : http://pastebin.com/xXNEa51X) ;

• Récupération du binaire en tentant sur 2 URLs malveillantes ;

• Récupération de l’IP publique de l’utilisateur ;

• Récupération de la clef de cryptage via 2 URLs malveillantes ;

• Cryptage des données disponibles en écritures pour John Doe.

Une fois la pièce jointe téléchargée, seulement 3 GET HTTP ont suffit pour provoquer un arrêt de production ! Si la sonde Securactive Performance Vision n’a pas pour rôle premier de gérer l’historique réseau, sa fonction d’indexation et de décode HTTP se sont rendu très utile dans ce cas là.

Annexe

En analysant l’URL ainsi que le fichier téléchargé associé sur VirusTotal, on constate que seulement 8/66 sont capable de détecter l’URL malicieuse et 4/54 sont capable de bloquer le TeslaCrypt. Et Microsoft, l’antivirus du client n’est pas dans la liste … Il est donc resté impuissant.

UPDATE :Microsoft Endpoint bloque maintenant le virus, soit 4 jours après l’attaque, et la plupart de ses concurrents également.

Source :

• http://blog.talosintel.com/2015/12/cryptowall-4.html

• http://blog.checkpoint.com/2015/12/18/angler-ek-pushing-teslacrypt/