NANOREMOTE, cousin de FINALDRAFT

Introduction

En octobre 2025, Elastic Security Labs a découvert une nouvelle porte dérobée Windows dans la télémétrie. La porte dérobée complète que nous appelons NANOREMOTE partage des caractéristiques avec les logiciels malveillants décrits dans REF7707 et est similaire à l'implant FINALDRAFT.

L'une des principales fonctionnalités du logiciel malveillant est centrée sur l'envoi de données dans les deux sens à partir du point de terminaison de la victime à l'aide de l'API Google Drive. Cette fonction finit par fournir un canal pour le vol de données et la mise en place de charges utiles qui sont difficiles à détecter. Le logiciel malveillant comprend un système de gestion des tâches utilisé pour les fonctions de transfert de fichiers, notamment la mise en file d'attente des tâches de téléchargement et d'upload, la mise en pause et la reprise des transferts de fichiers, l'annulation des transferts de fichiers et la génération de jetons d'actualisation.

Ce rapport vise à sensibiliser les défenseurs et les organisations aux acteurs de la menace que nous surveillons et à l'évolution de leurs capacités.

Principaux points abordés dans cet article

• Elastic Security Labs découvre une nouvelle porte dérobée pour Windows
• NANOREMOTE a probablement été développé par un acteur de menace d'espionnage lié à FINALDRAFT et REF7707.
• NANOREMOTE comprend des capacités d'exécution de commandes, de découverte/énumération et de transfert de fichiers à l'aide de l'API Google Drive.
• La porte dérobée intègre des fonctionnalités issues de projets open-source tels que Microsoft Detours et libPeConv.
• Elastic Defend prévient la chaîne d'attaque NANOREMOTE grâce à des règles comportementales, un classificateur d'apprentissage automatique et des fonctions de protection de la mémoire.

Analyse NANOREMOTE

WMLOADER

La chaîne d'attaque observée se compose de deux éléments principaux, un chargeur (WMLOADER) et une charge utile (NANOREMOTE). Bien que ce rapport se concentre sur NANOREMOTE, nous décrirons le chargeur afin de fournir un contexte sur le flux global de l'infection.

WMLOADER se fait passer pour un programme de sécurité Bitdefender (BDReinit.exe) avec une signature numérique invalide.

Après son exécution, le programme fait un grand nombre d'appels aux fonctions Windows (VirtualAlloc / VirtualProtect), préparant ainsi le processus à héberger le shellcode intégré stocké dans le fichier. Le shellcode est situé à RVA (0x193041) et décrypté à l'aide d'un algorithme XOR roulant.

Ce shellcode recherche un fichier nommé wmsetup.log dans le même chemin de dossier que WMLOADER, puis commence à le décrypter en utilisant AES-CBC avec une clé ASCII de 16 octets (3A5AD78097D944AC). Après le décryptage, le shellcode exécute la porte dérobée en mémoire, NANOREMOTE.

Sur la base de la routine de décryptage du shellcode précédente, nous pouvons identifier d'autres échantillons connexes ciblant les produits Bitdefender et Trend Micro lors d'une recherche dans VirusTotal.

NANOREMOTE

NANOREMOTE est une porte dérobée complète qui peut être utilisée pour effectuer une reconnaissance, exécuter des fichiers et des commandes, et transférer des fichiers vers et depuis les environnements des victimes. L'implant est un exécutable Windows 64 bits écrit en C++ sans obscurcissement.

NANOREMOTE Configuration

L'échantillon NANOREMOTE que nous avons observé était préconfiguré pour communiquer avec une adresse IP non routable codée en dur. Nous pensons que le programme a été généré à partir d'un constructeur, car nous ne voyons aucune référence croisée indiquant un paramètre de configuration.

Pour l'authentification de l'API Google Drive, NANOREMOTE utilise une configuration séparée par un tuyau qui peut utiliser plusieurs clients. Le séparateur |*| sépare les champs utilisés par un seul client et le |-| est utilisé comme marqueur pour séparer les clients. Il y a trois champs par structure client :

• Identifiant du client
• Secret du client
• Jeton de rafraîchissement

Vous trouverez ci-dessous un exemple de format :

Client_ID_1|*|Client_Secret_1|*|Refresh_Token_1|-|Client_ID_2|*|Client_Secret_2|*|Refresh_Token_2

Le développeur dispose d'un mécanisme de repli pour accepter cette configuration par le biais d'une variable d'environnement nommée NR_GOOGLE_ACCOUNTS.

Interface/blocage

NANOREMOTE fournit une console détaillée affichant l'activité en temps réel de l'application, y compris les horodatages, les emplacements du code source et les descriptions de ses comportements.

Un nouveau répertoire Windows est créé à l'endroit où NANOREMOTE a été exécuté, le dossier s'appelle Log.

Un fichier journal nouvellement créé (pe_exe_run.log) est déposé dans ce dossier et contient la même sortie que celle imprimée à partir de la console.

Configuration

NANOREMOTE effectue une routine d'installation initiale avant que la boucle de travail principale ne démarre. Le logiciel malveillant génère un GUID unique via CoCreateGuid, puis le chiffre à l'aide de la fonction Fowler-Noll-Vo (FNV). Ce GUID est utilisé par l'opérateur pour identifier les machines individuelles lors de chaque requête.

Le développeur du logiciel malveillant dispose d'un gestionnaire de plantage à l'échelle du processus pour créer un minidump Windows du processus en cours d'exécution lorsqu'une exception non gérée se produit, ce qui est très probablement utilisé pour trier les plantages de programme.

L'exception produira le dump avant de mettre fin au processus. Il s'agit d'une pratique assez courante, bien que le site MiniDumpWithFullMemory puisse être considéré comme moins courant dans les logiciels légitimes, car il pourrait produire des vidages de grande taille et contenir des données sensibles.

Une recherche rapide sur Google utilisant le même format de chaîne pour le fichier dump (%d%02d%02d%02d%02d%02d_sv.dmp) n'a permis de trouver que le résultat 1 provenant d'un site web de développement de logiciels basé en Chine.

Communication en réseau

Comme indiqué précédemment, le C2 de NANOREMOTE communique avec une adresse IP codée en dur. Ces demandes sont effectuées via HTTP, les données JSON étant soumises par le biais de demandes POST qui sont compressées par Zlib et cryptées avec AES-CBC à l'aide d'une clé de 16 octets (558bec83ec40535657833d7440001c00). L'URI pour toutes les demandes utilise /api/client avec User-Agent (NanoRemote/1.0).

Vous trouverez ci-dessous la recette CyberChef utilisée pour le cryptage/compression de C2 :

Chaque demande, avant d'être cryptée, suit un schéma composé des éléments suivants :

• ID de la commande: ID du gestionnaire de la commande associée
• Données: Objet spécifique à la commande contenant les paires clé/valeur requises par le gestionnaire correspondant.
• ID: Identifiant unique de la machine attribué à l'hôte infecté

Vous trouverez ci-dessous un exemple de requête qui déclenche l'exécution de whoami via la clé de commande à l'intérieur de l'objet de données :

{
    "cmd": 21,
    "data": {
        "command": "whoami"
    },
    "id": 15100174208042555000
}

Chaque réponse suit un format similaire en utilisant les champs précédents ainsi que deux champs supplémentaires.

• Sortie: Contient toute sortie du gestionnaire de commande demandé précédemment.
• Succès: Indicateur booléen utilisé pour déterminer si la commande a réussi ou non.

Vous trouverez ci-dessous un exemple de réponse à la commande whoami précédente :

{
    "cmd": 21,
    "data": 0,
    "id": 17235741656643013000,
    "output": "desktop-2c3iqho\\rem\r\n",
    "success": true
}

Gestionnaires de commandes

La fonctionnalité principale de NANOREMOTE est pilotée par ses gestionnaires de commandes 22 . Vous trouverez ci-dessous un diagramme de flux de contrôle (CFG) illustrant l'instruction switch utilisée pour distribuer les différents gestionnaires.

Vous trouverez ci-dessous le tableau des gestionnaires de commandes :

Gestionnaire n° 1 - Collecte d'informations sur l'hôte

Ce gestionnaire énumère les détails du système et de l'utilisateur pour établir le profil de l'environnement de la victime :

• Utilise WSAIoctl avec SIO_GET_INTERFACE_LIST pour récupérer l'adresse IP interne et externe.
• Saisit le nom d'utilisateur via GetUserNameW
• Récupère le nom d'hôte via GetComputerNameW
• Vérifie si l'utilisateur actuel est membre du groupe Administrateur via IsUserAnAdmin
• Récupère le chemin d'accès au processus utilisé par le logiciel malveillant à l'aide de GetModuleFileNameW
• Récupère les informations relatives au système d'exploitation (version du produit) dans le registre à l'aide des noms de valeurs WinREVersion et ProductName.
• Obtient l'ID du processus du programme en cours d'exécution via GetCurrentProcessID

Vous trouverez ci-dessous un exemple des données envoyées au serveur C2 :

{
    "cmd": 1,
    "data": {
        "Arch": "x64",
        "ExternalIp": "",
        "HostName": "DESKTOP-2C3IQHO",
        "ID": 8580477787937977000,
        "InternalIp": "192.168.1.1",
        "OsName": "Windows 10 Enterprise ",
        "ProcessID": 304,
        "ProcessName": "pe.exe",
        "SleepTimeSeconds": 0,
        "UID": 0,
        "UserName": "REM *"
    },
    "id": 8580477787937977000
}

Gestionnaire n° 2 - Modifier le délai d'attente de la balise

Ce gestionnaire modifie l'intervalle de temporisation de la balise pour la communication C2 de NANOREMOTE, le logiciel malveillant dormira en fonction du nombre de secondes fourni par l'opérateur.

Voici un exemple de cette requête où NANOREMOTE utilise la clé (interval) avec une valeur (5) pour modifier le délai d'attente de la balise à 5 secondes.

{
    "cmd": 2,
    "data": {
        "interval": 5
    },
    "id": 15100174208042555000
}

Manipulateur n° 3 - Auto-terminaison

Ce gestionnaire est responsable de la mise en place d'une variable globale à 0 signalant effectivement le démantèlement et la sortie du processus pour NANOREMOTE.

Gestionnaire #4 - Lister le contenu d'un dossier par son chemin d'accès

Ce gestionnaire énumère le contenu du dossier en utilisant le chemin d'accès fourni par l'opérateur. La liste de chaque article comprend

• Si l'élément est un répertoire ou non
• Si l'élément est marqué comme étant caché
• Date de la dernière modification
• Nom du fichier
• Taille

Gestionnaire n° 5 - Lister le contenu des dossiers et définir le répertoire de travail

Ce gestionnaire utilise le même code que le gestionnaire précédent (#4), la seule différence étant qu'il définit le répertoire de travail actuel du processus au chemin fourni.

Gestionnaire n° 6 - Obtenir des informations sur le disque de stockage

Ce gestionnaire utilise les fonctions suivantes de l'API Windows pour collecter des informations sur le disque de stockage de la machine :

• GetLogicalDrives
• GetDiskFreeSpaceExW
• GetDriveTypeW
• GetVolumeInformationW

Vous trouverez ci-dessous un exemple de la requête en JSON montrant les données renvoyées :

{
    "cmd": 6,
    "data": {
        "items": [
            {
                "free": 26342813696,
                "name": "C:",
                "total": 85405782016,
                "type": "Fixed"
            }
        ]
    },
    "id": 16873875158734957000,
    "output": "",
    "success": true
}

Gestionnaire #7 - Créer un nouveau répertoire de dossiers

Ce gestionnaire de commandes crée un nouveau répertoire sur la base d'un chemin d'accès fourni.

Gestionnaire #8, #9 - Supprimer un fichier, un répertoire

Ce gestionnaire prend en charge les identifiants de commande #8 et #9, le branchement est choisi dynamiquement en fonction du chemin d'accès au fichier fourni. Il permet de supprimer des fichiers ou un dossier spécifique.

Manutentionnaire #10, #11 - Démontage/nettoyage

Ces deux gestionnaires appellent la même fonction "teardown" en utilisant des arguments différents pour libérer de manière récursive les allocations du tas, les objets C++ internes et les données mises en cache associées à l'exécution du logiciel malveillant. L'objectif est de nettoyer les structures de commande et d'éviter les fuites de mémoire ou l'instabilité.

Handler #12 - Custom PE Loader - Exécuter le PE à partir du disque

Ce gestionnaire inclut une capacité de chargement PE personnalisée pour les fichiers qui existent sur le disque. Cette fonctionnalité exploite les API standard de Windows ainsi que le code d'aide de la bibliothèque libPeConv pour charger les fichiers PE à partir du disque sans utiliser le chargeur Windows traditionnel.

En bref, il lira un fichier PE sur le disque, copiera le fichier dans la mémoire, mappera manuellement les sections/en-têtes, préparera le fichier avant de l'exécuter en mémoire. Cette mise en œuvre est une technique délibérée de furtivité et d'évasion qui permet de contourner l'accrochage en mode utilisateur et la visibilité traditionnelle. Par exemple, lorsqu'un fichier est exécuté par le biais de cette technique, il n'y a aucune trace du lancement de cet exécutable à l'aide de procmon.

Vous trouverez ci-dessous l'entrée suivante pour ce gestionnaire où le chemin d'accès au fichier local est fourni sous la clé (args) :

{
    "cmd": 12,
    "data": {
        "args": "C:\\tmp\\mare_test.exe"
    },
    "id": 15100174208042555000
}

La capture d'écran suivante montre l'exécution réussie de notre exécutable de test à l'aide de cette technique :

Au cours de cette analyse, il est intéressant de noter l'adoption de la bibliothèque libPeConv. Il s'agit d'un projet important et utile que nous utilisons nous-mêmes en interne pour diverses tâches liées aux logiciels malveillants. Le développeur de NANOREMOTE utilise plusieurs fonctions de cette bibliothèque pour simplifier les tâches courantes liées au chargement manuel et à l'exécution des fichiers PE en mémoire. Vous trouverez ci-dessous les fonctions utilisées par la bibliothèque de NANOREMOTE :

• default_func_resolver : Résout les fonctions dans un fichier PE en chargeant dynamiquement les DLL et en récupérant les adresses des fonctions exportées.

• hooking_func_resolver : Récupérer l'adresse virtuelle d'une fonction par son nom à partir d'une DLL chargée.

• FillImportThunks : Remplit la table d'importation en résolvant chaque fonction importée à son adresse réelle dans la mémoire.

• ApplyRelocCallback : Applique les relocalisations de base lorsqu'un fichier PE est chargé à une adresse différente de sa base préférée.

Une autre observation notable dans ce gestionnaire est l'utilisation de la bibliothèque d'accrochage open-source, Microsoft Detours. Cette bibliothèque est utilisée pour intercepter les fonctions Windows suivantes :

• GetStdHandle
• RtlExitUserThread
• RtlExitUserProcess
• FatalExit
• ExitProcess

Cette routine d'accrochage intercepte les fonctions liées à la terminaison afin d'imposer un comportement contrôlé et d'améliorer la résilience. Par exemple, NANOREMOTE évite qu'une défaillance d'un seul thread de travail ne mette fin à l'ensemble du processus NANOREMOTE.

Gestionnaire #13 - Définir le répertoire de travail

Ce gestionnaire définit le répertoire de travail à un répertoire spécifique en utilisant la clé (path). Vous trouverez ci-dessous un exemple de demande :

{
    "cmd": 13,
    "data": {
        "path": "C:\\tmp\\Log"
    },
    "id": 15100174208042555000
}

Gestionnaire #14 - Obtenir le répertoire de travail

Ce gestionnaire récupère le répertoire de travail actuel. Vous trouverez ci-dessous un exemple de réponse après avoir défini le répertoire à l'aide du gestionnaire précédent (#13).

{
    "cmd": 14,
    "data": 0,
    "id": 11010639976590963000,
    "output": "[+] pwd output:\r\nC:\\tmp\\Log\r\n",
    "success": true
}

Gestionnaire #15 - Déplacer un fichier

Ce gestionnaire permet à l'opérateur de déplacer des fichiers sur la machine victime en utilisant MoveFileExW avec deux arguments (old_path, new_path) pour déplacer le fichier dans un dossier différent en effectuant une opération de copie et de suppression de fichier.

Gestionnaire #16 - Tâche de téléchargement de la file d'attente

Ce gestionnaire crée un objet de tâche de téléchargement avec un identifiant de tâche fourni, puis met la tâche en file d'attente de téléchargement. Cette implémentation utilise des jetons OAuth 2.0 pour authentifier les demandes adressées à l'API Google Drive. Cette fonctionnalité est utilisée par l'acteur de la menace pour télécharger des fichiers sur la machine de la victime. La communication cryptée avec les serveurs de Google donne à ce trafic une apparence légitime, ce qui empêche les organisations de l'inspecter ou de le différencier d'une utilisation normale.

Dans le fil d'exécution principal, une variable globale est utilisée pour suivre les objets de la file d'attente et traiter les tâches attendues par le logiciel malveillant.

Une tâche est traitée à l'aide de différents champs fournis par le serveur C2 :

• type
• numéro d'identification de la tâche
• file_id
• chemin_cible
• taille_du_fichier
• md5

Lorsqu'une tâche de téléchargement est traitée, NANOREMOTE récupère la taille du fichier hébergé sur Google Drive en utilisant l'identifiant du fichier (1BwdUSIyA3WTUrpAEEDhG0U48U9hYPcy7). Ensuite, le logiciel malveillant télécharge le fichier via WinHttpSendRequest, puis utilise WinHttpWriteData pour écrire le fichier sur la machine.

Vous trouverez ci-dessous la sortie de la console montrant le processus de téléchargement :

Cette caractéristique des logiciels malveillants représente un défi unique pour les organisations, car les groupes de menace continuent d'abuser des plateformes cloud de confiance pour l'exfiltration de données et l'hébergement de charges utiles. Ce trafic sans contexte peut facilement se fondre dans le trafic légitime, ce qui rend la détection difficile pour les défenseurs qui s'appuient sur la visibilité du réseau.

Gestionnaire #17 - Tâche de chargement de la file d'attente

Ce gestionnaire fonctionne de la même manière que le gestionnaire précédent (#16), mais il crée une tâche de file d'attente de téléchargement et la met en file d'attente dans la file d'attente de téléchargement. Ce gestionnaire est utilisé par l'acteur de la menace pour télécharger des fichiers de la machine de la victime vers le compte Google Drive contrôlé par l'adversaire.

Les champs suivants sont fournis par l'opérateur via le serveur C2 :

• type
• task_id
• upload_name
• source_path
• file_size
• md5

Vous trouverez ci-dessous le trafic réseau généré par le logiciel malveillant lors du téléchargement d'un fichier de test via l'API Google Drive (/upload/drive/v3/files).

La figure ci-dessous montre la console pendant le processus de téléchargement.

Vous trouverez ci-dessous une capture d'écran de la démonstration précédente utilisant la fonction de téléchargement de fichiers avec notre propre compte de test Google Drive.

Vous trouverez ci-dessous la réponse de ce gestionnaire :

{
    "cmd": 17,
    "data": {
        "file_id": "1qmP4TcGfE2xbjYSlV-AVCRA96f6Kp-V7",
        "file_name": "meow.txt",
        "file_size": 16,
        "md5": "1e28c01387e0f0229a3fb3df931eaf80",
        "progress": 100,
        "status": "uploaded",
        "task_id": "124"
    },
    "id": 4079875446683087000,
    "output": "",
    "success": true
}

Gestionnaire #18 - Pause du transfert de téléchargement/upload

Ce gestionnaire permet à l'opérateur de mettre en pause les tâches de téléchargement et d'envoi gérées par NANOREMOTE en passant l'identifiant de la tâche.

Gestionnaire #19 - Transfert de curriculum vitae par téléchargement/upload

Ce gestionnaire permet à l'opérateur de reprendre les tâches de téléchargement ou d'envoi gérées par NANOREMOTE en utilisant l'identifiant de la tâche.

Gestionnaire #20 - Annuler le transfert de fichiers

Ce gestionnaire permet à l'opérateur d'annuler toute tâche de téléchargement ou d'upload gérée par NANOREMOTE via l'identifiant de la tâche.

Gestionnaire #21 - Exécution de la commande

Il s'agit du principal gestionnaire utilisé par l'adversaire pour l'exécution de commandes sur la machine victime. Il fonctionne en créant de nouveaux processus et en renvoyant la sortie par l'intermédiaire de tuyaux Windows. Il s'agit d'une caractéristique essentielle de la plupart des portes dérobées utilisées par les adversaires pour obtenir un accès direct afin d'énumérer l'environnement, d'effectuer des mouvements latéraux et d'exécuter des charges utiles supplémentaires.

La figure ci-dessous montre l'arbre des processus de NANOREMOTE lorsque ce gestionnaire est invoqué. Le logiciel malveillant génère cmd.exe, qui lance à son tour la commande spécifiée - dans ce cas, whoami.exe.

Gestionnaire #22 - Exécuter un PE encodé à partir de la mémoire

Ce gestionnaire charge et exécute un fichier PE encodé en Base64 à l'intérieur du processus NANOREMOTE existant. Le fichier PE encodé est fourni par le serveur C2 à l'aide du champ pe_data. Si le programme nécessite des arguments de ligne de commande, la clé (arguments) est utilisée.

Vous trouverez ci-dessous un exemple montrant la sortie de la console à l'aide du programme de test :

Similitude avec FinalDraft

Il existe un chevauchement entre FINALDRAFT et NANOREMOTE, tant du point de vue de la similarité des codes que du point de vue du comportement.

De nombreuses fonctions présentent une réutilisation claire du code entre les deux implants. Par exemple, les deux suivent la même séquence de génération d'un GUID via CoCreateGuid, de hachage avec la fonction Fowler-Noll-Vo (FNV) et d'exécution de contrôles identiques de validation du tas avant de libérer la mémoire tampon.

Une bonne partie du code HTTP utilisé pour envoyer et recevoir des requêtes présente également des similitudes. Vous trouverez ci-dessous un exemple de diagramme de flux de contrôle montrant la configuration d'une requête HTTP utilisée par les deux familles de logiciels malveillants.

Au cours de notre analyse, nous avons observé que WMLOADER décrypte la charge utile correspondante à partir d'un fichier codé en dur nommé wmsetup.log - le même nom de fichier que celui utilisé par PATHLOADER pour déployer FINALDRAFT que nous avons publié plus tôt dans l'année.

Une autre découverte intéressante est celle d'un échantillon (wmsetup.log) de VirusTotal qui a été récemment téléchargé des Philippines le 2025-10-03.

Nous avons téléchargé le fichier, l'avons placé à côté de WMLOADER, puis avons exécuté le chargeur. Il a réussi à décrypter le fichier wmsetup.log, révélant un implant FINALDRAFT.

Vous trouverez ci-dessous un graphique comparatif montrant que la même clé AES est utilisée pour décrypter avec succès FINALDRAFT et NANOREMOTE.

Notre hypothèse est que WMLOADER utilise la même clé codée en dur parce qu'il fait partie du même processus de construction/développement qui lui permet de travailler avec différentes charges utiles. On ne sait pas exactement pourquoi le groupe de menace à l'origine de ces implants ne fait pas tourner la clé, peut-être pour des raisons de commodité ou de test. Il s'agit là d'un autre signal fort suggérant que FINALDRAFT et NANOREMOTE partagent une base de code et un environnement de développement.

NANOREMOTE par l'intermédiaire de MITRE ATT&CK

Elastic utilise le cadre MITRE ATT& CK pour documenter les tactiques, techniques et procédures communes que les menaces utilisent contre les réseaux d'entreprise.

Tactiques

Les tactiques représentent le pourquoi d'une technique ou d'une sous-technique. Il s'agit de l'objectif tactique de l'adversaire : la raison pour laquelle il effectue une action.

• Collecte
• Commande et contrôle
• Évasion par la défense
• Découverte
• Exécution
• Exfiltration

Techniques

Les techniques représentent la manière dont un adversaire atteint un objectif tactique en effectuant une action.

• Account Discovery
• Découverte du stockage local
• Exfiltration via un service Web : exfiltration vers un stockage cloud
• Mascarade : Signature de code invalide
• Interprète de commandes et de scripts : Shell de commande Windows

Atténuer les effets de la NANOREMOTE

Dans un environnement de laboratoire exécutant NANOREMOTE, de nombreuses alertes différentes ont été déclenchées à l'aide d'Elastic Defend.

L'un des principaux comportements à valider pour les défenseurs est l'utilisation abusive de services légitimes tels que l'API Google Drive. Vous trouverez ci-dessous un exemple d'alerte déclenchée avec la règle "Connection to Commonly Abused Webservices" lors d'une interaction avec l'API de Google pour le téléchargement et l'envoi de fichiers à l'aide de NANOREMOTE.

La technique de chargement PE utilisant le fichier encodé en Base64 du serveur C2 a également été détectée via l'alerte Memory Threat Detection Alert: Shellcode Injection.

Détection/prévention

• Evasion potentielle avec les points d'arrêt matériels
• Evasion potentielle via une signature de code invalide
• Shellcode non sauvegardé provenant d'un module non signé
• Exécution d'un shellcode à partir d'un module à faible réputation
• Image creuse de Unusual Stack
• Connexion à des services web couramment utilisés
• Alerte de détection des menaces sur la mémoire : Injection de shellcode

YARA

Elastic Security a créé des règles YARA pour identifier cette activité.

rule Windows_Trojan_NanoRemote_7974c813 {
    meta:
        author = "Elastic Security"
        creation_date = "2025-11-17"
        last_modified = "2025-11-19"
	 license = "Elastic License v2"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.NanoRemote"

    strings:
        $str1 = "/drive/v3/files/%s?alt=media" ascii fullword
        $str2 = "08X-%04X-%04x-%02X%02X-%02X%02X%02X%02X%02X%02X" ascii fullword
        $str3 = "NanoRemote/" wide
        $str4 = "[+] pwd output:" wide
        $str5 = "Download task %s failed: write error (wrote %llu/%zu bytes)"
        $seq1 = { 48 83 7C 24 28 00 74 ?? 4C 8D 4C 24 20 41 B8 40 00 00 00 BA 00 00 01 00 48 8B 4C 24 28 FF 15 ?? ?? ?? ?? 85 C0 }
        $seq2 = { BF 06 00 00 00 89 78 48 8B 0D ?? ?? ?? ?? 89 48 ?? FF D3 89 78 78 8B 0D ?? ?? ?? ?? 89 48 7C FF D3 89 78 18 8B 0D }
    condition:
        4 of them
}

rule Windows_Trojan_WMLoader_d2c7b963 {
    meta:
        author = "Elastic Security"
        creation_date = "2025-12-03"
        last_modified = "2025-12-03"
       license = "Elastic License v2"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.WMLoader"
        reference_sample = "fff31726d253458f2c29233d37ee4caf43c5252f58df76c0dced71c4014d6902"

    strings:
        $seq1 = { 8B 44 24 20 FF C0 89 44 24 20 81 7C 24 20 01 30 00 00 }
        $seq2 = { 41 B8 20 00 00 00 BA 01 30 00 00 48 8B 4C C4 50 FF 15 }
    condition:
        all of them
}

Observations

Les observables suivants ont été examinés dans le cadre de cette recherche.