Contexte
Nous avons découvert récemment une nouvelle famille de backdoors multiplateforme pour environnement desktop. Nous avons d’abord obtenu la version Linux et grâce aux informations extraites du fichier binaire, nous avons pu trouver la version pour les ordinateurs de bureau Windows également. Qui plus est, la version Windows était également dotée d’une signature valide pour code. Examinons les deux en détail.
DropboxCache, connu également sous le nom de Backdoor.Linux.Mokes.a
Cette backdoor pour les systèmes d’exploitation Linux est compressée via UPX et elle est remplie de fonctions qui permettent de surveiller les activités de la victime, dont du code pour enregistrer l’audio et prendre des captures d’écran.
Après sa première exécution, le fichier binaire vérifie son propre chemin d’accès et, si nécessaire, se copie dans un des emplacements suivants :
- $HOME/$QT-GenericDataLocation/.mozilla/firefox/profiled
- $HOME/$QT-GenericDataLocation/.dropbox/DropboxCache
Voici un exemple d’emplacement : $HOME/.local/share/.dropbox/DropboxCache. Pour garantir la persistance, il utilise une méthode qui n’est pas très discrète : il se contente de créer un fichier .desktop dans $HOME/.config/autostart/$filename.desktop. Voici le modèle :
Ensuite, la backdoor établit une connexion avec son serveur de commande codé en dur. A partir de ce moment, elle réalise une requête HTTP par minute :
Cette requête de type « battement de coeur » répond avec une image d’un octet. Pour charger les données et recevoir les commandes, la backdoor se connecte au port TCP 433 à l’aide d’un protocole personnalisé et d’un chiffrement AES. Le fichier binaire contient les clés publiques codées en dur suivantes :
Le malware rassemble ensuite les informations obtenues via l’enregistreur de frappes, les enregistrements audio et les captures d’écran dans le dossier /tmp/. Ces données seront ultérieurement envoyées au centre de commande.
- /tmp/ss0-DDMMyy-HHmmss-nnn.sst (captures d’écran, JPEG, toutes les 30 s.)
- /tmp/aa0-DDMMyy-HHmmss-nnn.aat (enregistrements audio, WAV)
- /tmp/kk0-DDMMyy-HHmmss-nnn.kkt (enregistrement des frappes au clavier)
- /tmp/dd0-DDMMyy-HHmmss-nnn.ddt (données arbitraires)
DDMMyy = date : 280116 = 2016-01-28
HHmmss = heure : 154411 = 15:44:11
nnn = millisecondes.
Cette partie du code est capable de capturer l’audio de la boîte de la victime.
Toutefois, l’enregistrement audio n’est pas activé dans l’événement minuteur de ce fichier binaire, comme la fonction d’enregistrement des frappes au clavier. Vu que les auteurs ont établi un lien statique entre libqt, xkbcommon (la bibliothèque qui gère les descriptions de clavier) et OpenSSL (1.0.2c) et le fichier binaire, la taille du fichier binaire est supérieure à 13 Mo. Les criminels n’ont également fourni aucun effort pour obfusquer le fichier binaire de quelque manière que ce soit. Le fichier binaire contient en fait presque tous les symboles, ce qui est très pratique pendant l’analyse.
Il y a également des références aux fichiers source de l’auteur :
Il semblerait qu’il a été programmé en C++ et Qt, un cadre d’application multiplateforme. D’après les métadonnées du binaire, il aurait été compilé à l’aide de « GCC 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) » sur Ubuntu 14.04 LTS « Trusty Tahr ». D’après l’horodatage de qt_instdate, la dernière configuration des sources Qt remonte au 26 septembre 2015 (qt/qtbase.git: deprecated), ce qui signifie que la compilation du malware ne serait pas antérieure à la fin du mois de septembre 2015.
Nous détectons ce type de malware sous Backdoor.Linux.Mokes.a.
OLMyJuxM.exe, connu également sous le nom de Backdoor.Win32.Mokes.imv
Il y a quelques jours, nous avons découvert un échantillon qui semblait familier, bien qu’il avait été compilé pour des ordinateurs tournant sous Windows. Très vite, nous avons compris qu’il s’agissait d’une version Windows 32 bits de Backdoor.Linux.Mokes.a.
Une fois exécuté, le malware choisit au hasard un des neufs emplacements différents dans %AppData% pour s’installer en mode persistant sur l’ordinateur. Le fichier binaire crée également un fichier « version » dans le même dossier. Comme son nom l’indique, il stocke uniquement les informations relatives à la version avec le chemin d’installation complet du malware en lui-même :
Ensuite, les clés de la base de registres correspondantes sont créées dans HKCU\Software\Microsoft\Windows\CurrentVersion\Run pour garantir la persistance dans le système.
Après que le malware a exécuté sa propre copie dans le nouvel emplacement, l’API SetWindowsHook est utilisée pour établir la fonction d’enregistrement des frappes au clavier ainsi que pour surveiller les actions de la souris et les messages internes publiés dans la file d’attente de messages.
L’étape suivante de l’opération consiste à contacter le serveur de commande codé en dur. A part des différences au niveau des adresses IP et de la clé de chiffrement, le comportement observé est pratiquement identique.
Toutefois, cette version en particulier utilise une mise en oeuvre légèrement différente et tente d’obtenir la chaîne user-agent Windows par défaut.
En cas d’échec, cet échantillon utilise sa version codée en dur :
Il se connecte au serveur de commande de la même manière que la version Linux : il envoie un signal de type « battement de coeur » une fois par minute via HTTP (GET /v1). Pour récupérer les commandes ou pour charger/télécharger des ressources complémentaires, il utilise le port TCP 433.
Il utilise pratiquement les mêmes modèles de nom de fichier pour enregistrer les captures d’écran, les enregistrements audio, les frappes au clavier et autres données arbitraires. A la différence de la version Linux, l’enregistreur de frappes est actif dans cet échantillon. Voici un exemple de contenu du fichier de l’enregistreur de frappes, situé dans %TEMP% et créé par cet échantillon :
Ici aussi, nous avons repéré du code inattendu. La capture d’écran suivante montre des références à du code capable de capturer des images via une caméra connectée comme une webcam intégrée.
Comme dans la version Linux, l’auteur a laissé un certain nombre de chaînes suspectes dans le fichier binaire. La chaîne suivante est surprenant d’honnêteté.
Du point de vue du criminel, il est primordial de donner un air de légitimité au logiciel et d’éviter que Windows ne demande la confirmation de l’utilisateur avant d’exécuter un logiciel inconnu. Sur les ordinateurs Windows, ce résultat est obtenu grâce aux certificats de signature de code de confiance. Dans le cas qui nous occupe, le criminel a réussi à signer le fichier binaire à l’aide d’un certificat de confiance émis par « COMODO RSA Code Signing CA ».
Nous détectons ce type de malware sous Backdoor.Win32.Mokes.imv.
Evolution
Dans la mesure où ce malware a été développé spécifiquement dans une optique multiplateforme, il faut s’attendre à voir apparaître des échantillons pour Mac OS X également.
Mise à jour
(01-02-2016 10:45 UTC): Nous venons de recevoir Backdoor.Win32.Mokes.imw. C’est la première fois que nous trouvons une version de Mokes où le module d’enregistrement audio est activé. Le malware crée un fichier audio toutes les 5 minutes.
IOCs
Backdoor.Linux.Mokes.a
c9e0e5e2aeaecb232120e8573e97a6b8
$HOME/$QT-GenericDataLocation/.mozilla/firefox/profiled
$HOME/$QT-GenericDataLocation/.dropbox/DropboxCache
$HOME/.config/autostart/profiled.desktop
$HOME/.config/autostart/DropboxCache.desktop
/tmp/ss0-$date-$time-$ms.sst
Backdoor.Win32.Mokes.imv & .imw
f2407fd12ec0d4f3e82484c027c7d149 (imw)
91099aa413722d22aa50f85794ee386e (imv)
%AppData%\Skype\SkypeHelper.exe
%AppData%\Skype\version
%AppData%\Dropbox\bin\DropboxHelper.exe
%AppData%\Dropbox\bin\version
%AppData%\Google\Chrome\nacl32.exe
%AppData%\Google\Chrome\version
%AppData%\Google\Chrome\nacl64.exe
%AppData%\Google\Chrome\version
%AppData%\Mozilla\Firefox\mozillacache.exe
%AppData%\Mozilla\Firefox\version
%AppData%\Hewlett-Packard\hpqcore.exe
%AppData%\Hewlett-Packard\version
%AppData%\Hewlett-Packard\hpprint.exe
%AppData%\Hewlett-Packard\version
%AppData%\Hewlett-Packard\hpscan.exe
%AppData%\Hewlett-Packard\version
%AppData%\Adobe\Acrobat\AcroBroker.exe
%AppData%\Adobe\Acrobat\version
%TEMP%\aa$n-$date-$time-$ms.aat (imw)
où $n représente un hash décimal calculé au départ du nom de la carte son
%TEMP%\ss0-$date-$time-$ms.sst
%TEMP%\dd0-$date-$time-$ms.ddt
%TEMP%\kk$date.kkt
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run « %PERSISTENT-FILENAME% », « %PERSISTENT-FILEPATH% »
où %PERSISTENT-FILENAME% est le nom d’un des noms de fichier ci-dessus
et %PERSISTENT-FILEPATH%, le chemin correspondant.














