SectopRat : Analyse d’un stealer déployé en multistager MSI

Le format MSI est depuis longtemps détourné comme stager : il supporte nativement des Custom Actions (DLL, PowerShell, JScript) exécutées à l’installation, souvent dans un contexte de privilèges élevés, et sa structure interne complique l’analyse statique. Surtout, il ne déclenche pas les mêmes réflexes de méfiance qu’un exécutable brut , il installe, il exécute, il disparaît dans les logs comme n’importe quel logiciel.

L’échantillon analysé ici exploite cette surface à deux niveaux : un MSI parent qui pose les bases, et un MSI secondaire qui déploie SectopRAT.

Le fichier MSI analysé (0cfcfac10d0a3fa907498667a7b8057d0e95c5f6fd40d0de07452914178f0e71) se présente comme un installeur Windows classique, construit avec Advanced Installer 17.1.2. Ses métadonnées internes indiquent un auteur nommé « Burning Secrets » et un sujet : « EarlyLifeCrisis ». Ce fichier se fait donc passer pour un installateur de jeu pour adulte. Il ne comporte pas de signature numérique. Sa date de création interne, au 11/12/2009, semble manifestement falsifiée : il s’agit de la valeur par défaut d’Advanced Installer.

Le MSI embarque 78 fichiers, dont plusieurs DLL légitimes signées par Caphyon SRL, l’éditeur d’Advanced Installer.

Ce qui rend ce MSI efficace comme stager, c’est qu’il se comporte comme un installeur légitime.

Un fichier MSI, construit avec Advanced Installer, est susceptible d’embarquer des DLL signées valides, avec différentes fonctionnalités comme SoftwareDetector.dll pour l’inventaire des logiciels installés ou encore PowerShellScriptLauncher.dll pour l’exécution de scripts PS1 lors de l’installation. Ces composants ne sont pas systématiquement présents, mais leur apparition dans un MSI n’a rien de surprenant : ils font partie du framework de l’outil et correspondent à des usages courants.

De la même façon, un installeur qui télécharge des composants distants et enchaîne des installations secondaires n’est pas, en soi, un signal d’alerte. C’est un pattern répandu dans la distribution logicielle : récupérer des prérequis, déployer des modules complémentaires… etc.

L’attaquant tire parti de cette banalité. Les comportements malveillants, téléchargement des payloads, déchiffrement, persistance, sont enveloppés dans un packaging qui correspond à ce qu’on peut raisonnablement attendre d’une installation logicielle.

Le MSI s’appuie sur un script Powershell identifié sur notre plateforme GLIMPS Malware.

Ce script télécharge et met en place deux payloads en parallèle :

MSI parent
├── Voie 1 , Frappe immédiate (fileless)
│   └── Téléchargement d'un assembly .NET chiffré en AES-256-CBC ```new30h.jar```
│       └── Chargement en mémoire → stealer de credentials navigateur
│
└── Voie 2 , Implant persistant
    └── Téléchargement d'un MSI secondaire ```MicrosoftEdgeUpdateTaskMachineCoreC.msi```
        └── Tâche planifiée → rundll32 → XOR decrypt → SectopRAT

Le premier payload arrive déguisé en fichier .jar. Il n’a de Java que l’extension : c’est un assembly .NET chiffré en AES-256-CBC, clé et IV hardcodés dans le script PowerShell du MSI.

Une fois déchiffré en mémoire et chargé via [Reflection.Assembly]::Load(), il se révèle :

• WbElevation.BrowserKeyDecryptor (we4ftg.exe). C’est un stealer .NET asynchrone entièrement fileless, il ne touche jamais le disque sous sa forme lisible.

Ses cibles sont les navigateurs. Chrome, Chromium, Firefox : credentials, cookies, données de paiement. Il embarque SharpInjector, un framework d’injection de processus complet, et utilise rstrtmgr.dll (Windows Restart Manager) pour déverrouiller les bases de données navigateur en cours d’utilisation.

L’exfiltration se fait vers dns-providersa2.com, domaine enregistré le 12 mars 2026, soit, cinq jours avant l’analyse. Hébergé derrière Njalla reposant sur un enregistrement orienté anonymat avec un WHOIS masqué; les pays déclarés étants Saint Kitts et Nevis. Le domaine imite un fournisseur DNS légitime. L’URI de callback https://dns-providersa2[.]com/check redirige vers un domaine dom.top1vpn[.]ru dont le certificat généré via Let’s Encrypt semble renouvelé souvent.

Ce payload est conçu pour une frappe rapide et silencieuse : il s’exécute, collecte, exfiltre, disparaît. On peut imaginer que c’est un fichier de premier effet, au cas ou l’autre charge ne peut être implantée.

La deuxième voie installe un MSI secondaire téléchargé depuis main45.b-cdn.net, présenté sous le nom MicrosoftEdgeUpdateTaskMachineCoreC.msi qui imite un mécanisme de mise à jour de Microsoft Edge. Les métadonnées internes « MpAsDesc » faisant référence à Microsoft Malware Protection. Au passage, lui aussi a comme « last_saved_date » le 11/12/2009 ce qui i

ndique aussi la valeur par défaut du packager MSI. Ce qui est incohérent avec la date de la mise à jour de ses streams…

Ce MSI dépose deux fichiers dans C:\ProgramData\Microsoft\NetFramework\ :

• olecli32ba_Win.dll , loader .NET de 10 Ko, compilé le 26 février 2026, se présentant comme « igfxCUIServiceN » (imitation Intel Graphics CUI Service). Une petite erreur de SECOPS qui pointe l’environnement de build : C:\Users\Ardor\AppData\Local\Temp\DllExporter\olecli32.pdb.

• cmiaisupportSYS.dll , conteneur chiffré de 1,6 Mo, déguisé en DLL PE32. Timestamp COFF falsifié à ~1982. DllMain zeroed. Imports et exports chiffrés. Le fichier est inutilisable par le loader Windows standard , il n’est pas conçu pour être chargé via LoadLibrary. Sa section .debug2 est artificiellement gonflée (technique de zip bomb) pour entraver l’analyse par certains outils statiques mais cette heuristique est identifiée par notre plateforme d’analyse.

La persistance est assurée par un script PowerShell embarqué dans les tables MSI (!_StringData). Plutôt que de réutiliser le nom « Edge », le malware crée une tâche planifiée qui imite le processus OneDrive légitime, avec un SID Windows valide hardcodé et un suffixe numérique aléatoire pour contourner les détections par nom fixe :

La tâche se déclenche à chaque ouverture de session (AtLogOn). Un délai aléatoire de 2 à 3 secondes précède l’exécution immédiate post-installation.

XorExtract : le loader reconstitué

La classe principale du loader s’appelle XorExtract. Son algorithme a été entièrement reconstitué par décompilation manuelle du bytecode IL .NET.

Le loader lit cmiaisupportSYS.dll comme données brutes

puis il effectue les opérations suivantes :

1. Lit un entier 32-bit à l’offset 0x5FE → longueur du payload (913 408 bytes)

2. Extrait le blob chiffré à partir de l’offset 0x602

3. Vérifie le marqueur 0xDEADC0DE après le blob

4. Applique un XOR cyclique avec la clé {0, 1, 2, ..., 31}

La vérification confirme le résultat : les premiers octets déchiffrés donnent 4D 5A 90 00..., l’en-tête MZ d’un exécutable Windows. L’assembly résultant est chargé en mémoire via Assembly.Load(). Aucun fichier déchiffré n’est écrit sur le disque.

Avant d’exécuter ce déchiffrement, le loader s’impose une routine anti-sandbox (DelayExecutor) : calcul de 100 000 racines carrées pour saturer le CPU, suivi d’un sleep aléatoire de 1 à 3 secondes. Ces deux mécanismes combinés visent à dépasser les timeouts des environnements d’analyse automatisée.

SectopRAT / ArechClient2 : le payload principal

Le payload déchiffré (fdhfghfghfgh.exe, sha256 2c1630f00a7903d2895e648571a5e302475ef1ca56daa862050ae298c06d0309) est détecté en statique comme SectopRAT, alias ArechClient2, un RAT/infostealer .NET.

Dans GLIMPS Malware Expert, le Deep Engine nous précise les éléments ayant participé à sa décision de classer ce fichier comme malveillant :

Afin d’essayer de qualifier cette menace, nous décidons d’effectuer le reverse de ce fichier .NET.

Point d’entrée , boucle principale (wh.a())

Capacités stealer

La configuration est pilotée par StealerSettingConfigParce (DataContract JSON, reçu du C2. On notera l’appellation « Parce » et non « Parse », caractéristique d’un SectopRat) :

Structure du résultat (ScanResult) envoyé au C2 :

Capacités RAT

Observables et indicateurs de compromission

Indicateurs de compromission

Observables

Artefacts observés mais non spécifiques à cette menace, à contextualiser avec d’autres signaux.

Cartographie MITRE ATT&CK

Annexes

Nœuds RPC BSC utilisés comme dead-drop resolvers

Le payload effectue un round-robin sur les 12 nœuds suivants pour interroger le contrat 0x67b4af41467a51e0816752a6b223c7c55ae71957 via eth_call() :

Extensions de navigateur ciblées, portefeuilles crypto

24 extensions Chrome/Edge/Firefox ciblées pour l’extraction de seeds phrases et clés privées :

Auteurs : Sylvio Hoarau et Caroline Fernandez