Dans l’œil de notre CyberSOC : Campo Loader, analyse et perspectives de détection
Comment détecter et analyser Campo Loader ? Réponse de notre CyberSOC.
Campo Loader, une campagne récente
Depuis le mois de janvier 2021, notre CyberSOC a noté l’utilisation assez active d’un loader(1). Ce loader a rapidement été nommé « Campo Loader » sur Internet, en raison de patterns assez marquants dans son URL, observés lors des communications réseau.
Notamment utilisé pour « dropper » en second stage Ursnif/Gozi, un trojan bancaire, ces campagnes utilisent plusieurs techniques intéressantes et restent assez facilement détectables avec des solutions de sécurité adéquates.
Des campagnes très similaires ont également été observées depuis l’été 2020 et documentées par Morphisec en septembre.
Il semble d’ailleurs que ce loader soit toujours utilisé pour délivrer Trickbot. Nous noterons cependant quelques différences avec notre cas dans le format du maldoc ainsi que la charge finale déployée.
Vecteur d’infection : du maldoc
Sans surprise, le premier vecteur d’infection est un mail contenant une pièce jointe. Plus précisément, un document Excel XLSB (Excel Spreadsheet-Binary).
L’utilisation de ce type de fichier est assez commune pour du maldoc, car elle permet d’évader une majorité de moteurs AV (Anti-Viral). En effet, même après plusieurs jours d’existence sur VirusTotal (VT), des fichiers restent détectés par moins de 10 AV sur 64.
A son ouverture, le fichier invite l’utilisateur à activer le contenu en lui faisant croire que cette action aura pour effet de déchiffrer le document et ainsi afficher son contenu.
En termes d’analyse statique, les outils habituels comme olevba/oledump ou XLMMacroDeobfuscator ne sont pas satisfaisants. Nous adoptons donc une autre technique bien plus manuelle :
En décompressant le fichier, nous identifions une spreadsheet au format binaire (BIFF12) qui semble intéressante. En effet, un premier « Strings » sur ce fichier nous indique une routine qui semble bien malveillante :
Au premier abord, l’utilisation du binaire certutil.exe serait donc présente pour décoder le contenu de plusieurs fichiers. Ensuite les fonctions et strings « Shell32 », « rundll32.exe », ainsi que « ShellExecuteA » indiquent que le rôle de ce fichier est également d’exécuter des commandes DOS, voir une DLL.
Nous passons directement à l’analyse du document via Excel. Il s’avère que plusieurs feuilles Excel sont cachées. En démasquant les quatre feuilles masquées, la correspondance avec les strings précédemment affichés permet de faire le lien entre le fichier sheet4.bin et l’une des feuilles masquées.
Une seconde feuille s’avérera intéressante quant à la compréhension de ce fichier. En effet, la feuille 2 est en charge de l’exécution de la routine, via un Auto_Open.
Cependant, la partie la plus intéressante reste manquante. La feuille Excel associée est protégée.
Afin de contourner la protection, il suffit simplement d’enregistrer le fichier sous un autre format (ex : Xslm). Ainsi les fichiers binaires seront convertis en format XML. Ensuite, la suppression de la protection est assez aisée. En effet, une simple balise est responsable de ce mécanisme. En la supprimant, la protection de la feuille n’est plus effective.
Nous identifions par la suite plusieurs cellules contenant vraisemblablement du contenu encodé, qui s’avèrera être un PE (Portable Executable).
Ainsi, nous avons à peu près une bonne compréhension des actions de ce premier fichier xslb :
- Dépôt d’un fichier .txt contant de la donnée encodée en b64
- Décodage du fichier + dépôt d’un nouveau fichier hexa via le binaire certutil.exe
- Décodage du second fichier via certutil.exe + dépôt d’un PE.
Nous avons ensuite validé notre première analyse statique en nous basant sur une analyse dynamique via l’exécution du fichier dans la sandbox d’Orange Cyberdefense :
Trois fichiers sont bien déposés sur la machine :
Nous retombons bien sur PE « packé » (l’utilisation d’UPX a été notée sur certaines campagnes). Cette DLL est ensuite exécutée via rundll32.exe. Elle semble être le loader Campo.
Grâce à une analyse des requêtes http/https, nous avons noté une requête GET vers cette URL :
hxxp[://]172[.]104[.]129[.]156/campo/o/o
Elle redirige (307 Temporary Redirect) vers :
hxxps[://]ciudadstereo[.]com[.]ec/wp-content/plugins/wp-calculated-fields/templates/01/out[.]dll
Le rôle de cette DLL que nous rattacherons au loader Campo, est ainsi de télécharger et d’exécuter une seconde DLL.
A noter que plusieurs repository identifiés dans des campagnes similaires ont souvent des open directory, permettant ainsi d’identifier d’autres DLL malveillantes, mais également d’obtenir une idée sur la temporalité des attaques grâce au champ Last Modified.
Autre point important en lien avec la redirection temporaire : une URL « campo » permet de distribuer de nombreuses charges de façon dynamique. En effet, en analysant plusieurs fois le même échantillon, nous avons obtenu une charge finale différente.
Sans trop entrer dans le détail de l’analyse de ce dernier stage, la DLL correspond à Ursnif / Gozi, un Trojan bancaire. Une rapide analyse en sandbox nous permettra d’identifier les serveurs de contrôle et ainsi d’alimenter notre base de renseignements.
Perspectives de détection
Communications réseaux (Campo Loader)
En analysant de nombreuses campagnes, nous avons remarqué qu’un pattern revenait assez souvent dans l’URL pour être utilisé en moyen de détection/hunting.
En effet, l’uri path correspond avec cette regex : « ^\/(?:campo)\/\w{1}\/\w{1}$ ».
Voici quelques exemples d’URL que nous avons identifiées :
hxxp://172.104.143[.]130/campo/t/t
hxxp://178.62.19[.]66/campo/v/v
hxxp://pipkaboss[.]xyz/campo/b/b
Certaines campagnes plus anciennes semblent également suivre ce schéma :
^\/(?:campo)\/[a-zA-Z0-9]{1,2}\/[a-zA-Z0-9]{1,2}$, qui sera également plus flexible.
Exemple :
hxxp://androidflash[.]space/campo/DQ/s9
Comportements système
L’utilisation de « certutil.exe » afin de décoder la première charge est assez marquante et générique afin d’être utilisée comme moyen de détection. De plus, cette approche rentre dans le cadre de la matrice MITRE Att&CK, avec la technique « T1140:Deobfuscate/Decode Files or Information ».
Une règle Sigma est d’ailleurs déjà disponible sur le GitHub du même projet :
Cette règle devrait être déclenchée par les deux commandes extraites de notre analyse en sandbox (ci-dessous). Tout en étant assez générique pour y inclure la majorité des LOLBAS/LOLBINS (Living Off The Land Binaries and Scripts) relatif à ce binaire Microsoft.
Plusieurs approches peuvent également être entreprises vis-à-vis de l’exécution des DLL via « rundll32.exe ».
La première étant la détection d’exécution de DLL se faisant passer pour un fichier .png avec son extension. Cette technique est d’ailleurs de plus en plus utilisée et peut largement être abordée en reprenant de façon globale les techniques « T1036 :Masquerading » et « T1218.011 : Signed Binary Proxy Execution: Rundll32/ ».
La dernière méthode de détection pourrait se faire via l’arborescence des processus. En reprenant l’exécution de la campagne dans sa globalité, nous notons une arborescence assez marquante depuis EXCEL.EXE :
EXCEL.EXE > rundll32.exe > rundll32.exe
Conclusion
L’analyse d’anomalie dans les relations processus parent/enfant est un moyen très efficace, même en prenant en compte uniquement les processus enfants de Excel. Voici une règle Sigma qui en résume le fonctionnement :
https://github.com/Neo23x0/sigma/blob/master/rules/windows/process_creation/win_office_shell.yml
Indicateurs de compromission
Références MITRE Att&CK
Pour télécharger les IOCs et les références MITRE ATT&CK, cliquez ici.
Références :
(1)Loader : Un loader est un logiciel malveillant en charge d’exécuter une charge malveillante sur le système cible. Le loader est considéré comme la première charge. La seconde charge peut être distante (accessible depuis une IP/URL) ou alors directement incluse dans le loader. Le but d’un loader est également de proposer des méthodes d’évasion et de ciblage d’utilisateurs (chiffrement, injection mémoire, anti-vm, anti-sandbox, analyse géographique, profilage système, etc.).
