Base de clé

Nous avons trouvé (enfin reçu dans notre boite) une menace qui nous change des désormais fades rançongiciels : Dans ce cas, l’habituelle macro dropper n’existe pas : le fichier Microsoft Word est le dropper.

Ceci se veut être le résumé de notre présentation lors du premier rendez-vous SecParis mi décembre.

Sans plus tarder, regardons tout cela de façon progressive :

Et commençons par le message en lui même : Toujours basé sur un prétexte fallacieux, nous sommes invités à ouvrir une pièce jointe au nom évocateur.

mail

La pièce jointe est un fichier Word banale sans métadata intéressante, la taille fait un peu sourciller.  Dans le contexte actuel, le contenu du fichier ne choque pas plus que cela : Une image indiquant qu’il est nécessaire d’activer les macros pour accéder au « vrai » contenu :

doc

On remarque cependant que le fichier est anormalement long : Plus de neuf cents pages (qui par ailleurs semblent blanches) et la langue par défaut est le polonais.

Pour notre plus grand bonheur (ou pas), l’accès aux macros n’est pas protégé par mot de passe : nous n’aurons pas besoin cette fois d’avoir recours à OleDump et OleTools. Un simple Alt-F8 nous conduit à pouvoir accéder au code. Là, nous constatons de l’obfuscation avec des noms de variables barbares et un lot de fonctions inutiles.  Nous faisons un rapide tri et nous nous rendons rapidement compte que les 900 pages blanches ne sont pas si vides qu’elles laissent à penser : simplement le texte est en blanc sur fond blanc. Le rôle de la fonction principale est d’extraire de ce texte en le « xorant », un premier binaire et de l’exécuter dans l’environnement utilisateur.

macro

La charge extraite est alors renommer en ID.exe. Une fois ce premier binaire extrait, il est bien évidemment exécuté. Cacher le binaire dans le corps du fichier texte n’est pas nouveau, nous avions déjà rencontré ce mode de dissimulation en début d’année lors d’une campagne « Petya ».

Essayons maintenant de voir ce qu’on peut y trouver en analyse statique. Nous commençons par les habituels file, strings et hexdump -C.

idfile
Le strings ne donne rien d’intéressant. A contrario lors du parcours rapide du fichier avec le hexdump, nous remarquons ce qui semblent être des caractères encodés sur 16 bits : « strings -e l » vous connaissez ? Cela peut être utile parfois…

iddump

Directement dans le code hexadécimal, nous remarquons un marqueur MSCF, ce qui ressemble fort au numéro magique des fichiers cabinets de Microsoft : Et si nos attaquants avaient utilisés ce format pour dissimuler leur charge ?

Nous pouvons essayer d’extraire ce cabinet file à l’aide de la technique du « File Carving » (technique qui consiste à rechercher des structures de formats connus pour extraire/reconstruire des fichiers à partir de données brutes (une copie de disque dur par exemple) : c’est typiquement ce qui est utilisé pour récupérer les fichiers effacés d’un disque). Nous utilisons l’outil foremost disponible sur la majorité des grandes distributions Linux.

Cependant, petit problème : par défaut foremost ne recherche pas les fichiers CAB, mais bon comme on vient de l’écrire, c’est un « petit » problème : on édite rapidement le fichier /etc/foremost pour y rajouter la ligne suivante et le tour est joué.

foremost_conf

Voici alors le résultat de notre recherche :

foremost

Nous avons bien récupéré un fichier png et cab. Reste à vérifier que ce dernier est bien un fichier Microsoft Cabinet valide :

cabextract

Cela semble tout à fait correct : Nous pouvons donc poursuivre notre analyse avec ce fichier fraichement extrait. Pour ce nouveau binaire nous adoptons la même stratégie : file, strings et hexdump.

mefile
Nous avons bien un fichier PE32 valide. Mais le plus intéressant vient du résultat de la commande strings. En effet le fichier contient une chaîne très longue (plus d’un million de caractères) et qui ressemble fortement à du base64. En particulier, on note en fin de la chaîne la présence de bourrage XPADDINGX. Après un rapide petit nettoyage, on décode la chaîne et on récupère non pas un mais deux fichiers.

Le premier est un fichier binaire et en consultant les propriétés du fichier, nous apprenons que  c’est un interpréteur du langage de script autoIT (Lien vers autoIT) et il semble tout à fait légitime : Les recherches de son condensat sur VirusTotal n’indiquent rien de malveillant. Nous avons donc affaire à l’interpréteur officiel du langage AutoIT.

clll
Le second est un fichier texte et n’est autre que le script qui sera exécuté grâce à cette interpréteur.

script

Vous noterez au passage la concordance des temps (de modification) entre ces deux fichiers.

Le binaire étant légitime, concentrons-nous sur le script !

En aparté, sachez qu’AutoIT est très puissant et visiblement les auteurs de logiciel malveillant l’apprecient comme en témoigne ce lien.

Ce script est particulièrement intéressant et c’est d’ailleurs sur ce dernier que nous avons passé la plus longue partie de notre analyse, d’abord parce qu’il utilise un langage qui nous était certes inconnu, mais ça reste du langage scripté donc pas de décompilation. Ensuite il fait des choses assez originales : Comprendre que c’est la première fois que dans notre très jeune expérience d’analyse de virus, nous rencontrons un truc autant tiré par les cheveux.

L’avantage d’un script est qu’on peut le lire sans décompilation. Mais cela se révèle sensiblement plus compliqué que prévu : Les attaquants redoublent d’effort pour rendre le code le moins intelligible possible et ralentir l’analyse.

Tout d’abord nous constatons quelques petites mesures de détection d’antivirus et de sandboxing

testav_vm

Notons tout de même que les trois derniers tests ne sont jamais vrais : la $var1 est initialisée à 0.
Ensuite, le virus cherche à passer sous le radar des antivirus et autres possibilités de détection fortuite en créant un sous-répertoire dans le répertoire utilisateur et en s’y copiant lui-même ainsi que cLLL.exe (l’interpréteur).

hide_files

L’option « +SH » donne les attributs System et Hidden au répertoire et ses fichiers : permettant de rendre ce sous-répertoire quasi-invisible. Notons que dans ces conditions, ce répertoire n’est par exemple plus scanné par défaut par Avast. Les éditeurs d’antivirus n’aiment pas trop scanner les fichiers systèmes : cela garantit un certain niveau de persistance sur le poste.

Ensuite, le code est truffé de tests conditionnels sur des variables statiques : cela rend la lecture difficile mais des CTRL-F et autre chercher/remplacer nous permettent rapidement de faire le ménage dans le code.

Nous tombons sur des morceaux de code comme celui-ci que nous pourrions qualifier de « Third layer of Inception » :

inception

On vous laisse apprécier : Avez vous noté le « TVq » en base64 ?

Bref au final, nous découvrons que le script contient encore un binaire caché dans les commentaires : le 3eme depuis le début, ça commence à devenir une habitude.

Ce binaire que nous appellerons pudiquement charge.exe est un executable PE32 valide, mais il n’est jamais exécuté directement par le script. Et c’est là que ça devient un peu ésotérique pour nous. En effet, au lieu d’extraire charge.exe et de l’exécuter directement, le script préfère se lancer dans une entreprise beaucoup plus complexe :

Notons l’utilisation de code compilé directement dans le script :

"0xC81000005356578365F800E8500000003EFFFFFF3F3435363738393A3B3C3DFFFFFF00FFFFFF000102030405060708090A0B0C0D0E0F10111213141516171819FFFFFFFFFFFF1A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132338F45F08B7D0C8B5D0831D2E9910000008365FC00837DFC047D548A034384C0750383EA033C3D75094A803B3D75014AB00084C0751A837DFC047D0D8B75FCC64435F400FF45FCEBED6A018F45F8EB1F3C2B72193C7A77150FB6F083EE2B0375F08A068B75FC884435F4FF45FCEBA68D75F4668B06C0E002C0EC0408E08807668B4601C0E004C0EC0208E08847018A4602C0E00624C00A46038847028D7F038D5203837DF8000F8465FFFFFF89D05F5E5BC9C21000"

Une fois la chaîne décompilée en assembleur, cela ressemble à un « base64 -d »  qui permettra de décoder le commentaire/charge en mémoire.

Parser le contenu du binaire pour en extraire les différentes fonctions et les charger via des appels à des DLL  (entre autre kernel32.dll, user32.dll, avdapi32.dll) et  ainsi les injecter dans un process qui semble légitime : RegSvcs.exe est ici visé en priorité.

Ainsi, alors que les premières variables ont des noms très aléatoires, ici on observe une certaine « rigueur » dans le nommage des variables

dllstruct

Ces noms de variables ne sont pas sans rappeler les sections d’un fichier exécutable.

Résultat des courses : ce code est injecté en mémoire et se lance alors dans l’espionnage de l’activité sur le poste.

Lorsque nous nous penchons plus attentivement sur cette charge, nous nous apercevons qu’elle n’est pas packé et est semble-t-il codé en « Microsoft Visual C# / Basic .Net » si on en croit PEiD. Le résultat de la commande file nous met aussi sur la piste d’un fichier .NET.

charge

Aussi pour une fois, le code binaire ne sonne pas le glas de notre analyse. Nous pouvons utiliser l’outil de RedGate Reflector pour décompiler. Nous découvrons alors le coeur du logiciel malveillant.

Il y a quelques fonctions au nom plus qu’évocateur:

functionnames

On retrouve aussi des informations intéressantes :

Il communique avec un CC via des requêtes HTTP : les communications ne sont pas chiffrées, le canal de communication passe sur de l’http simple (sans surcouche SSL/TLS) et les requêtes HTTP sont globalement explicites.

L’objectif de ce malware semble surtout de voler des identifiants de messageries et de comptes internet ; il se concentre en effet sur les navigateurs et les clients lourds de messagerie.

Nous remarquons enfin qu’il contient encore trois blops binaires. A la lecture du code, on se rend compte que ces données sont chiffrées en AES mais avec une fonction assez simple.

Outre son nom étrange « RSMDecrypt », elle utilise la fonction de dérivation Rfc2898DeriveBytes avec une itération au lieu des mille recommandées.

public static byte[] RSMDecrypt(byte[] ƈƖƻƨÔ, byte[] ƄƏƵÉ)
{
    Rfc2898DeriveBytes bytes = new Rfc2898DeriveBytes(ƄƏƵÉ, new byte[8], 1);
    RijndaelManaged managed = new RijndaelManaged {
        Key = bytes.GetBytes(0x10),
        IV = bytes.GetBytes(0x10)
    };
    byte[] src = managed.CreateDecryptor().TransformFinalBlock(ƈƖƻƨÔ, 0, ƈƖƻƨÔ.Length);
    byte[] dst = new byte[(src.Length - 0x11) + 1];
    Buffer.BlockCopy(src, 0x10, dst, 0, src.Length - 0x10);
    return dst;
}

Bref, une fois déchiffrés, les blops se révelent être des nouveaux binaires ; Ils confirment notre première analyse de code. Ainsi le premier n’est autre que « WebBrowserPassView » et le second se revèle être « Email Password-Recovery ».

webrecover

Enfin le dernier blop binaire n’est semble-t-il jamais utilisé dans le code et ressemble à ce qui pourrait être du chinois… Un début d’attribution ?

Et voici un petit schéma qui récapitule tout cela à regarder en écoutant Fred Kal (qui a inspiré le nom d’une des charges.)

resume

Mais prenons un peu de recul par rapport à ce démontage et concentrons nous sur ce que nous avons pu apprendre des attaquants :

Tout d’abords les technologies utilisées : on remarque pour quasiment toutes les étapes une forte adhérence à l’écosystème Microsoft : Macro, Cabinet Files, Script AutoIT et binaire .Net.

Ensuite, il n’y a pas de métadonnées intéressantes dans les différents niveaux excepté dans la charge finale où nous trouvons des métadonnés probablement forgées par les attaquants mais qui donnent une idée de l’origine géographique.

Sur l’origine géographique des attaquants, on remarque la présence récurrente d’encode en UTF-16. De plus bien que la langue par défaut du binaire final ait été écrasée (langID=0), certains noms de variable ou fonction paraissent très abscons en alphabet latin.

Un troisième point aiguise notre curiosité : la fameuse fonction RSMDecrypt. Ce nom de fonction semble sortir de nulle part et ne fait pas référence a priori à un chiffrement particulier. Après avoir creusé le sujet sur internet, on se rend compte qu’il y a 3 types de ref à cette fonction :

  • Des dumps de la fonctions sur divers forums et blogs
  • PasteBin avec du code malveillant
  • Des sites d’analyse de code malveillant

Il est par contre intéressant de regarder la chronologie de ces diverses apparitions : la première d’entre elle date de 2012 sur un forum francophone.

Nous sommes dans un cul de sac : on appelle alors un ami qui nous parle d’une protection contre les attaques par canaux cachés : Rotating S-box Masking. Bref, il semble bien que les attaquants s’inspirent de truc qu’ils ne comprennent pas forcément.

Enfin, une autre fonction de chiffrement (cette fois-ci un simple XOR) est présente dans le code. Mais c’est la clé qui pour ainsi dire nous donnera la clé pour avancer.

xor.png

Ainsi déchiffrés nous obtenons :

  • CreateProcessA             ‘ĈőŘĝŏŒįķŎŖġŎŠĠz’
  • GetThreadContext         ‘ŝƕƸšƔưƕŷƔƇżƚƲƕƎƤË’
  • GetThreadContext        ‘ķůƒĻŮƊůőŮšŖŴƌůŨž¥’
  • SetThreadContext         ‘ńŰƓļůƋŰŒůŢŗŵƍŰũſ¦’
  • Wow64SetThreadContext     ‘ŨƚƶľśƌƐƅſƧźƌƚƏŔƚƭżƌƱƟÆ’
  • ReadProcessMemory         ‘ĴšűĽňżūŅšƃŌŅůũőŮƉ\x97’
  • WriteProcessMemory         ‘ŇżƇśūŨżşŭƃŚŹťůŝŹƐŠ¥’
  • NtUnmapViewOfSection     ‘ıűŦňŦŬŭĹŦŶőňűŐňŠƅŃŨŹ\x98’
  • VirtualAllocEx             ‘ńűƎřŹŷŴįŴƈŔŧśƀ£’
  • ResumeThread             ‘ŵƢDŽƏƦưƑƋƯƶŻƝØ’

La clé de chiffrement est « KeyBase » et cela nous fait vite faire le lien avec cette mire d’authentification trouvée sur le site compromis :

mire.png

A partir de là, nous obtenons beaucoup d’information sur notre logiciel malveillant. Notamment Palo Alto a fait une analyse très intéressante sur le sujet

Publicités

A propos JoMendes

Amateur de mathématiques et d'hexadécimal. Je m'intéresse de près ou de loin suivant mon niveau à tous les sujets de sécurité de l'information.
Cet article, publié dans Analyse, Malware, Sensibilisation, est tagué , , , . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s