Malva.RE décompile le VB5/VB6 avec VBReFormer Gen 2

Les exécutables Visual Basic 5 et 6 n’ont pas disparu des files de triage. Ils sont petits, faciles à produire avec un builder, et un simple extracteur de chaînes en donne une image trompeuse : des adresses, des mots de passe et des marqueurs @Placeholder mélangés, sans indication de ce que le programme utilise réellement.

Malva.RE prend désormais en charge ces exécutables. Le rapport présente le projet reconstruit par VBReFormer Gen 2 (7.x), lisible procédure par procédure, et, pour la famille DarkCloud, une configuration d’exfiltration établie à partir du code. Le cas DarkCloud 4.9 sert d’exemple ; son analyse technique complète est publiée séparément.

Ce que montre le rapport

Un projet, pas une liste de chaînes. Pour un exécutable VB5/VB6, l’arbre de l’échantillon contient une entrée [VB6 project] : le fichier de projet, le ou les formulaires avec leurs propriétés et leurs gestionnaires d’événements, les modules, les ressources et les notes d’export. Ces notes signalent ce que la reconstruction n’a pas restitué, plutôt que de le remplacer par une valeur plausible. Chaque module s’ouvre dans le lecteur de code ; on peut partir d’un événement de formulaire et suivre les appels jusqu’aux routines qui préparent et envoient les données.

Pour DarkCloud, une configuration lue dans le code. Lorsque la règle Hunt_DarkCloud_Stealer_Variants, publiée par Evelyne Diaz Araque chez Stairwell (règle et contexte), identifie un exécutable VB5/VB6, le rapport présente les transports d’exfiltration que le programme contient et distingue ceux que ce build active de ceux qu’il laisse désactivés. Pour la branche active, les paramètres sont donnés avec leur rôle : destinataire, serveur, compte, mot de passe, port, réglage SSL, mode d’authentification. Pour les branches désactivées, les marqueurs de builder restent des marqueurs, pas des indicateurs réseau. Le répertoire de staging est conservé sous forme symbolique, avec ses variables d’environnement.

Le point qui compte pour l’analyste est la traçabilité : chaque valeur renvoie à la procédure et à l’argument qui l’utilisent, et, quand le code reconstruit ne suffit pas, au désassemblage qui la corrobore. Une valeur affichée sans son contexte est une affirmation ; une valeur rattachée à une instruction est vérifiable.

Pourquoi un décompilateur dédié

VB5/VB6 classique, VBA et VB.NET partagent une partie de leur syntaxe, pas leur format d’exécution.

Dans un programme VB6 natif, le sens des instructions x86 dépend en grande partie des conventions du runtime : chaînes BSTR portant leur longueur, valeurs VARIANT portant leur type, appels COM tardifs dont la primitive ne dit pas quel objet ni quelle propriété sont visés. C’est ce rapprochement entre instructions, structures du projet et conventions du runtime qui transforme un désassemblage en procédures lisibles. La sortie reste une reconstruction : les noms de procédures comme proc_46CD10 servent à naviguer, ce ne sont pas les noms d’origine. L’analyse technique détaille ces difficultés et ce que VBReFormer Gen 2 (7.x) apporte pour les surmonter.

Le parcours de l’analyste

1. Identifier. Le fichier est reconnu comme exécutable VB5/VB6 ; s’il correspond à la règle DarkCloud, la lecture de configuration s’ajoute à la décompilation.
2. Ouvrir les sources. Sous [VB6 project], formulaires et modules se lisent dans le rapport ; les ressources restent des ressources, les notes d’export restent lisibles à part.
3. Suivre le programme. Depuis l’événement de chargement du formulaire vers l’initialisation, puis vers les routines de collecte et le dispatcher d’envoi.
4. Lire la configuration. Les transports, leur état dans ce build, les valeurs de la branche active et les marqueurs non remplacés des autres.
5. Vérifier. Chaque conclusion renvoie à une procédure, un argument ou une instruction ; une valeur indéterminée reste indéterminée.

DarkCloud 4.9, en bref

L’échantillon étudié, SHA-256 367383cfaa2ffc1404ba4ac1364a96992d78e036a0a67c994fbd6686f636474e, est un PE x86 de 460 Kio compilé en VB6 natif, qui s’identifie par la chaîne interne Agent: DARKCLOUD V4.9. La règle Stairwell y trouve 14 indicateurs $s* sur 14, pour un seuil de 6 sur cette branche. Il n’a jamais été exécuté : décompilation, vérification YARA et lecture de configuration ont porté uniquement sur ses octets.

VBReFormer Gen 2 (7.x) en a produit un export de 11 fichiers, dont huit vues de code : cinq modules applicatifs, un formulaire et deux aides générées.

La configuration se lit dans un dispatcher d’exfiltration à quatre branches, dont les conditions sont constantes : 0 = -1 pour FTP, HTTP et Telegram, -1 = -1 pour SMTP. Dans ce build, seul le transport SMTP est activé : serveur mail[.]mokasco[.]com cité sous forme désarmée, port 587, réglage SSL à false, authentification smtpauthenticate=1, soit cdoBasic. Les trois autres branches existent dans le code mais ne reçoivent que des marqueurs, @GateUrl, @StrBotToken, @ChatID : ce ne sont pas des IOC réseau. Le répertoire de staging est %AppData%\Microsoft\Windows\Templates\%COMPUTERNAME%-%USERNAME%, conservé avec ses variables.

Ce dispatcher est consultable publiquement : Module7.proc_46CD10 dans la démonstration VBReFormer. Le formulaire Form1 permet de partir du point d’entrée. L’authentification SMTP illustre la démarche : le code reconstruit signale un appel __vbaLateCallSt non restitué, et c’est la lecture du VARIANT dans les instructions x86 du malware qui établit la valeur 1.

Le rapport Malva.RE de l’échantillon montre le projet reconstruit et la configuration telles qu’elles apparaissent à l’analyste.

Le dispatcher dans la démonstration VBReFormer Online, lignes 15 à 30 : la condition constante 0 = -1 neutralise la branche FTP, -1 = -1 active la branche SMTP. Capture retouchée : variables porteuses d’identifiants renommées, valeurs remplacées par <masqué>, hôte désarmé.

Les comptes, le destinataire et le mot de passe SMTP, présents en clair dans le fichier, sont masqués dans cette publication. Le nom d’hôte est une valeur du fichier : il ne dit rien du statut actuel du serveur et n’attribue pas le malware à l’organisation dont il porte le nom. Le réglage SSL à false décrit une configuration, pas une observation du trafic.

Ce que ce support ne promet pas

La décompilation est une reconstruction, avec ses diagnostics. Les noms locaux et les commentaires d’origine ne sont pas dans l’exécutable ; certaines expressions ou appels peuvent rester partiels et sont signalés comme tels. Ce cas documente un VB6 natif : le P-code relève du même outil, mais pas de cette étude.

Le code du malware n’est jamais exécuté. Aucune connexion au serveur extrait, aucun essai des identifiants, aucun envoi de message n’ont été réalisés ; les conclusions décrivent le code et sa configuration statique.

Ce cas n’est ni un benchmark ni une comparaison avec d’autres outils ou d’autres générations de VBReFormer. Une configuration en clair dans ce build ne signifie pas que toutes les versions de DarkCloud stockent leurs paramètres ainsi, et un match YARA reste un point de départ que le code doit corroborer.

Les exécutables compressés passent d’abord par les étapes de dépackage de Malva.RE, comme le dépackage statique d’UPX.

Pour aller plus loin

• DarkCloud 4.9 décompilé avec VBReFormer Gen 2 (7.x), l’étude complète avec extraits VB6 et x86.
• Les formats pris en charge par Malva.RE, où les exécutables VB5/VB6 rejoignent les PE, documents Office, scripts et installeurs.
• L’extraction de configuration pour les autres familles prises en charge.
• VBReFormer, le décompilateur VB5/VB6.