Laboratoire de forensique des malwares Office — Analyse statique sous REMnux

Analyse statique de deux fichiers Office malveillants, réalisée entièrement dans une VM REMnux isolée. Rien n'a jamais été exécuté — seulement inspecté.

Configuration

• VM REMnux, aucun dossier partagé avec l'hôte
• Outils : sha256sum, file, unzip, et la suite oletools (oleid, olevba, oledump, mraptor)
• Les deux échantillons récupérés depuis MalwareBazaar (abuse.ch)

Échantillon 1 : Document Word malveillant (.docx)

SHA-256 : 68e82279bff55cf3b9f1f22ec4a165b1b1245a359f7e8d86664b2541d8f8d3fe

Ce que j'ai trouvé :

• Un fichier à l'intérieur du docx (nste.xml) était en réalité des données au format Rich Text Format se faisant passer pour du XML — une incohérence qui constitue à elle seule un signal d'alarme
• Un objet intégré était un exécutable VBS de 196 Ko (419876.vbs)
• Un autre objet intégré correspondait à CVE-2017-11882 — un exploit connu de l'Éditeur d'équations qui s'exécute à la simple ouverture du fichier, sans aucune macro nécessaire

Verdict : Malveillant. Il s'agit d'un véritable document weaponisé exploitant une RCE connue pour déposer un exécutable.

Échantillon 2 : Fichier Excel malveillant (.xlsx)

SHA-256 : dc65419ba5d83b980d7018198a14209fa2f5ebf6f99d47bfe9f586852087befe

Ce que j'ai trouvé :

• Le fichier était chiffré (protégé par mot de passe), ce qui masque normalement le contenu des macros aux scanners antivirus
• Il contenait 4 modules VBA, mais tous les 4 sont revenus vides — mraptor a renvoyé « Macro OK » sans aucun indicateur AutoExec/Write/Execute
• Une feuille de calcul était masquée
• Des chaînes encodées en hexadécimal se trouvaient dans un flux de macro XLM de style ancien, distinct de la couche VBA
• Le décodage de ces chaînes n'a révélé ni shellcode ni URL de téléchargement — juste quelques identifiants de bibliothèque de types

Verdict : Suspect, mais non concluant. Le chiffrement, la feuille masquée et les chaînes obfusquées ressemblent tous à des tactiques d'évasion, mais je n'ai pas pu confirmer la présence d'une charge utile réellement active dans la couche VBA. La véritable charge utile réside peut-être dans la couche de macro XLM héritée (que je n'ai pas entièrement rétro-ingénierée), ou il peut s'agir d'un échantillon incomplet/en cours de préparation.

Étapes suivies

1. Calculer le hash de chaque fichier (SHA-256) pour la chaîne de possession
2. Vérifier le type réel du fichier avec file, le comparer à l'extension
3. Exécuter oleid pour un premier aperçu du chiffrement/des macros/des liens externes
4. Exécuter oledump pour lister chaque objet intégré
5. Exécuter olevba pour extraire et décoder tout code source VBA
6. Exécuter mraptor pour vérifier le comportement d'exécution automatique des macros

Ce que cela démontre

• Comment repérer une incohérence de type de fichier utilisée pour échapper à la détection
• Comment fonctionne CVE-2017-11882 sans avoir besoin de macros
• Comment vérifier réellement le comportement d'une macro au lieu de le supposer à partir d'indicateurs superficiels
• Pourquoi chiffrement + feuilles masquées + chaînes obfusquées ne signifient pas automatiquement « malveillant confirmé » — parfois les preuves sont non concluantes, et cela vaut la peine de le dire clairement

Sources

• CVE-2017-11882 : RCE de l'Éditeur d'équations Microsoft
• oletools : https://github.com/decalage2/oletools
• MalwareBazaar : https://bazaar.abuse.ch
• Documentation REMnux : https://docs.remnux.org

Auteur

Mofolorunsho Adeleke GitHub : https://github.com/Mo200909