Début octobre, Flashpoint a publié une analyse d’une annonce sur un forum clandestin concernant une nouvelle famille de malwares baptisée FlokiBot. Il a fallu un certain temps pour qu’un exemple soit identifié sur Internet, mais une chercheuse appelée hasherezade en a signalé un sur VirusTotal début novembre. Elle a également rédigé une analyse concernant son dropper, disponible ici.
Cet article dresse un premier bilan de l’analyse technique de FlokiBot par Dennis Schwarz de Arbor Networks.
Une variante de Zeus
Comme indiqué dans l’annonce sur le forum, FlokiBot est une nouvelle variante du célèbre cheval de Troie bancaire, développée à l’aide du code source de Zeus 2.0.8.9 ayant fuité, comme le confirme un rapide coup d’œil au code binaire. Cet exemple inclut même quelques instructions de débogage pour faciliter l’ingénierie inverse :
- Core::init() called
- initOsBasic() failed
- initBaseConfig() failed
Par ailleurs, la connexion au panneau de commande et contrôle (C2) rappelle fortement Zeus :
Version
Les malwares reposant sur Zeus ont tendance à inclure un extrait de code qui facilite l’identification de leur numéro de version :
Ici, la version de l’exemple est la 12. Le contrôle de version de FlokiBot diffère des autres variantes en ce qu’il ne convertit pas au format classique a.b.c.d, par exemple 0x02000809 en 2.0.8.9.
Base Config
Dans le jargon propre à Zeus, l’élément « base config » d’un exemple renvoie à sa configuration statique intégrée à chaque code binaire. Il s’agit d’une structure cryptée qui contient généralement plusieurs éléments. Toutefois, dans le cas de FlokiBot, celle-ci ne contient qu’une clé de cryptage et une URL de centre C2. Elle utilise la méthode classique propre à Zeus consistant à décrypter l’élément base config, qui se résume à une simple fonction OU exclusif (XOR) :
L’élément base config décrypté de cet exemple affiche une longueur de 1 076 octets et ressemble à ceci :
La partie C2 est encadrée en rouge. L’autre bloc de données non \x00 correspond à une clé de cryptage 258 octets utilisée pour protéger les communications C2.
Étude des communications C2 de Zeus
Zeus utilise une structure de données appelée « binstorage » dans ses communications C2. Celle-ci se compose d’un en-tête et d’un nombre de sections variable. L’en-tête mesure 48 octets et peut être représenté dans cette structure :
- 20 octets aléatoires
- Longueur (DWORD)
- Flags (DWORD)
- Nombre de sections (DWORD)
- Fonction MD5 16 octets relative aux données de section
Une section varie en longueur et peut être représentée dans cette structure :
- Type (DWORD)
- Flags (DWORD)
- Taille compressée (DWORD)
- Taille non compressée (DWORD)
- Données (longueur variable)
Pour les communications C2, les données binstorage sont cryptées deux fois : une première à l’aide d’un algorithme reposant sur une fonction XOR appelée « visual encrypt » par Zeus :
La deuxième phase de cryptage utilise la clé 258 octets de base config. Cette clé est en réalité une valeur « S » générée par l’algorithme de préparation des clés (key-scheduling algorithm, KSA) de RC4. Elle est utilisée avec l’algorithme PRGA (pseudo-random generation algorithm) de RC4 pour crypter les données via visual encrypt. Normalement, Zeus envoie l’élément binstorage crypté au centre C2 via des requêtes HTTP POST, mais dans le cas de FlokiBot, la situation est quelque peu différente.
Les communications C2 de FlokiBot
D’après l’annonce publiée sur le forum, nous nous attendions à ce que le protocole de communication présente quelques modifications :
« La charge utile emploie un protocole de communication différent, impossible à détecter à l’aide de la technique deep packet inspection, contrairement à Zeus (les paquets ne ressemblent pas à ceux de Zeus). La configuration est transférée au bot directement via un fichier gate.php crypté. Tous les rapports sont écrits sur disque dur, puis transférés dans une seule requête au centre de commande et contrôle. » (sic)
D’après notre analyse, ces modifications se résument à deux points : l’ajout d’un en-tête supplémentaire et, selon le type de communication, l’utilisation de base64 pour coder les données. Aussi simples semblent-ils, ces changements mettent effectivement en œuvre les caractéristiques évoquées ci-dessus, ce qui permet d’obtenir une application malveillante qui ne ressemble pas à Zeus, et peut être transférée via une seule requête.
L’en-tête supplémentaire peut être divisé en un sous-en- tête et un nombre variable de sections binstorage. Le sous-en- tête se présente ainsi :
- Cinq octets magiques : \x00\x08\x00\x00\x00
- Un chiffre aléatoire compris entre 111 111 et 999 999 (DWORD)
- Nombre de sections binstorage (DWORD)
Chaque section binstorage inclut deux sous-en- têtes. Le premier se présente ainsi :
- 1 codé (BYTE)
- Longueur des données binstorage data + longueur du second en-tête (12 octets)
Le second en-tête se présente ainsi :
- Même chiffre aléatoire que ci-dessus
- Numéro d’index du bloc binstorage, base zéro (DWORD)
- Longueur des données binstorage
- Données binstorage telles que décrites ci-dessus
Cet élément binstorage d’apparence inédite est ensuite crypté comme indiqué ci-dessus, avec visual encrypt et RC4. Selon le type de communication, les données cryptées sont aussi codées via base64 avant d’être envoyées au centre C2 dans une requête HTTP POST. Toujours selon le type de communication, la réponse du centre C2 est gérée différemment. Ce point est développé plus bas.
À la date de rédaction de cet article, toutes les URL C2 que nous avons identifiées utilisaient HTTPS. Par ailleurs, un code est utilisé pour rechercher les URL C2 reposant sur .onion. Le cas échéant, le trafic C2 est acheminé via un proxy TOR local.
Dynamic Config
Dans le jargon propre à Zeus, « dynamic config » est un fichier de configuration récupéré sur le serveur C2. En général, il contient notamment des URL C2 supplémentaires et des logiciels WebInject (les éléments de base des chevaux de Troie bancaires). FlokiBot emploie deux chemins de code pour récupérer dynamic config. Le premier fait appel à une méthode classique, consistant à demander la configuration en envoyant des informations système au serveur C2. Voici un aperçu des informations recueillies et des types de section binstorage utilisés :
- SBCID_BOT_ID (10001) : identifiant du bot
- 10021 : dimensions de la fenêtre du bureau
- 10022 : fonction hexadécimale MD5 de l’exemple de malware original
- 10023 : valeur codée hexadécimale 16 octets inconnue, issue du registre
- SBCID_BOT_VERSION (10003) : version du bot
- SBCID_TIME_SYSTEM (10009) : heure du système
- SBCID_TIME_LOCALBIAS (10011) : décalage GMT
- SBCID_TIME_TICK (10010) : nombre de cycles
- SBCID_OS_INFO (10012) : version de Windows
- SBCID_LANGUAGE_ID (10013) : identifiant de la langue
- SBCID_IPV4_ADDRESSES (10016) : adresse IPv4
- SBCID_IPV6_ADDRESSES (10017) : adresse IPv6
- SBCID_NET_LATENCY (10005) : latence
- SBCID_TCPPORT_S1 (10006) : port SOCKS
La plupart de ces informations (SBCID_X) sont de type Zeus générique, et des informations supplémentaires sont disponibles dans le code source ayant fuité. Ces données sont regroupées en paquet de la manière décrite ci-dessus, puis envoyées au centre C2 sans codage base64 supplémentaire.
Lors de la réponse, les données sont d’abord décryptées via RC4 et visual decrypt. Ensuite, un bloc de données est extrait de l’en-tête récemment ajouté (comme décrit ci-dessus). Ces données peuvent être séparées en deux éléments : un octet de commande et des données de commande.
Un octet de commande égal à zéro signale un fichier dynamic config mis à jour. Les données de commande restantes sont décryptées via RC4 et visual decrypt, et le texte simple est une structure binstorage contenant dynamic config. Voici un exemple et une analyse plus compréhensible de l’apparence de dynamic config :
Un second chemin de code est disponible dans FlokiBot via la fonction DynamicConfig::updateConfig de Zeus (voir le code source ayant fuité), mais celui-ci ne semble pas finalisé. Il s’agit sans doute d’un élément toujours en cours de développement. Il crée une section binstorage de type 11003 qui stocke un « 1 » dans un DWORD. Celle-ci est placée dans un paquet et cryptée comme indiqué ci-dessus, à ceci près que les données cryptées sont codées via base64 avant d’être envoyées au serveur C2.
À la réponse du centre C2, les données sont décryptées et extraites du paquet comme indiqué ci-dessus. À la date de rédaction de cet article, la seule réponse que nous ayons observée est un octet de commande « 2 » et un élément binstorage vide en texte simple en guise de données de commande.
WebInject
De façon surprenante, on ne trouve aucune trace de WebInject dans l’exemple de fichier dynamic config fourni ci-dessus. Si aucune étude approfondie de l’implémentation man-in- the-browser (MITB) n’a été effectuée dans le cadre de cette analyse, un rapide coup d’œil au code laisse penser qu’il s’agit de l’implémentation standard de Zeus. L’absence de WebInject dans cet exemple est vraisemblablement due au fait que la campagne/version donnée que nous avons analysée ne les utilise pas encore. Si l’on s’appuie sur les tendances relatives à d’autres variantes de Zeus, il y a fort à parier que des WebInject seront présents, le cas échéant, lors de l’apparition de nouvelles campagnes/versions de FlokiBot sur Internet.
Les commandes de bot
FlokiBot contient des chaînes cryptées. Il utilise la méthode classique de Zeus pour les décrypter. La liste complète des chaînes décryptées sera disponible ici. Parmi celles-ci, on trouve 26 commandes de bot, qui offrent un aperçu de certaines des autres fonctionnalités disponibles dans FlokiBot :
- os_shutdown
- os_reboot
- bot_uninstall
- bot_update
- bot_update_exe
- bot_bc_add
- bot_bc_remove
- bot_httpinject_disable
- bot_httpinject_enable
- bot_ddos_start
- bot_ddos_stop
- fs_path_get
- fs_search_add
- fs_search_remove
- user_destroy
- user_logoff
- user_execute
- user_cookies_get
- user_cookies_remove
- user_certs_get
- user_certs_remove
- user_url_block
- user_url_unblock
- user_homepage_set
- user_flashplayer_get
- user_flashplayer_remove
Fonctionnalité DDoS
Les commandes bot_ddos_start et bot_ddos_stop sont intéressantes. En effet, si d’autres variantes de Zeus incluaient une fonctionnalité DDoS, la plus célèbre étant Zeus Gameover, celle-ci demeure plutôt rare. Trois attaques DDoS élémentaires sont implémentées :
- UDP Flood
- TCP Connection Flood
- HTTP GET Flood
Les études effectuées sur Zeus Gameover suggèrent que les pirates utilisaient la fonctionnalité DDoS pour attaquer les banques pendant qu’ils leur dérobaient de l’argent afin de détourner leur attention. Il est trop tôt pour déterminer si la fonctionnalité DDoS de FlokiBot a la même raison d’être. Quoi qu’il en soit, les clients d’Arbor disposent de contre-mesures pour neutraliser cette attaque s’ils venaient à être ciblés.
Capture des données de mémoire de piste 2 de carte bancaire
Comme indiqué dans l’annonce et constaté dans ses chaînes décryptées, FlokiBot inclut également une fonctionnalité de capture de mémoire pour récupérer les données de piste 2 de carte bancaire. Comme pour la fonctionnalité DDoS, l’implémentation est assez rudimentaire.
La mémoire des processus infectés est analysée pour rechercher les blocs de données dont le format est semblable à celui de données de piste 2. L’opération consiste essentiellement à rechercher si le numéro d’identification bancaire potentiel du numéro de compte principal commence par un 3, un 4, un 5 ou un 6, puis à le mettre en correspondance avec les types de carte suivants :
- American Express, Dinners, JP
- VISA
- Mastercard
- Discovery
Quelques vérifications supplémentaires sont effectuées au niveau des données afin de s’assurer que les nombres et le séparateur de champ « = » sont à la bonne place. Si de possibles données de piste 2 sont identifiées, elles sont renvoyées au centre C2 via la fonction Report::writeStringFormat de Zeus (voir le code source ayant fuité) et une chaîne de format se présentant comme suit :
Enregistreur de frappe : %s
Piste 2 : %s
Conclusion
FlokiBot est une nouvelle variante du cheval de Troie bancaire Zeus vendue sur des forums clandestins à un prix conséquent (1 000 $) qui a récemment fait surface sur Internet. Ses caractéristiques les plus dangereuses semblent être un protocole C2 légèrement modifié, une fonctionnalité d’attaque DDoS rudimentaire et une capacité de capture de données de mémoire de carte bancaire également rudimentaire. Il est trop tôt pour déterminer le degré potentiel d’activité et de diffusion de cette nouvelle variante mais, par coïncidence, pendant la rédaction de cet article, une nouvelle version (numéro 13) est apparue sur Internet. ASERT garde un œil sur cette menace afin de déterminer si FlokiBot deviendra ou non un véritable flot de bots.