Dans le premier article de cette série en plusieurs parties, les chercheurs en logiciels malveillants de l'équipe Elastic Security Labs présentent brièvement la menace REMCOS et se penchent sur la première moitié de son flux d'exécution, depuis le chargement de sa configuration jusqu'au nettoyage des navigateurs web des machines infectées.
Introduction
Elastic Security Labs poursuit son examen des menaces à fort impact, en se concentrant sur les complexités internes de REMCOS version 4.9.3. Pro (novembre 26, 2023).
Développé par Breaking-Security, REMCOS est un logiciel qui a d'abord été un outil de red teaming, mais qui a depuis été adopté par des menaces de toutes sortes visant pratiquement tous les secteurs.
Lorsque nous avons effectué notre analyse à la mi-janvier, il s'agissait de la famille de logiciels malveillants la plus répandue signalée par ANY.RUN. En outre, il est toujours en cours de développement, comme en témoigne l'annonce récente de la sortie de la version 4.9.4 par l'entreprise sur le site 9, 2024.
Tous les échantillons que nous avons analysés provenaient du même REMCOS 4.9.3. Pro x86 build. Le logiciel est codé en C++ avec une utilisation intensive de la classe std::string pour les opérations liées aux chaînes de caractères et aux octets.
REMCOS est doté d'un large éventail de fonctionnalités, notamment des techniques d'évasion, l'élévation des privilèges, l'injection de processus, des capacités d'enregistrement, etc.
Cette série d'articles propose une analyse approfondie des éléments suivants :
- Exécution et capacités
- Stratégies de détection et de chasse utilisant les requêtes ES|QL d'Elastic
- Récupération d'environ 80% de ses champs de configuration
- Récupération d'environ 90% de ses commandements C2
- Exemples d'adresses virtuelles sous chaque capture d'écran d'IDA Pro
- Et bien plus encore !
Pour toute question ou commentaire, n'hésitez pas à nous contacter sur les médias sociaux @elasticseclabs ou dans le Slack de la communauté Elastic.
Chargement de la configuration
La configuration REMCOS est stockée dans un blob crypté au sein d'une ressource nommée SETTINGS. Ce nom apparaît de manière cohérente dans les différentes versions de REMCOS.
Le logiciel malveillant commence par charger le blob de configuration crypté à partir de sa section de ressources.
Pour charger la configuration chiffrée, nous utilisons le script Python suivant et le module Lief.
import lief
def read_encrypted_configuration(path: pathlib.Path) -> bytes | None:
if not (pe := lief.parse(path)):
return None
for first_level_child in pe.resources.childs:
if first_level_child.id != 10:
continue
for second_level_child in first_level_child.childs:
if second_level_child.name == "SETTINGS":
return bytes(second_level_child.childs[0].content)Nous pouvons confirmer que la version 4.9.3 conserve la même structure et le même schéma de décryptage que ceux décrits précédemment par les chercheurs de Fortinet:
Nous appelons "configuration chiffrée" la structure qui contient la clé de déchiffrement et le bloc de données chiffrées, qui se présente comme suit :
struct ctf::EncryptedConfiguration
{
uint8_t key_size;
uint8_t key[key_size];
uint8_t data
};La configuration est toujours décryptée à l'aide de l'algorithme RC4, comme le montre la capture d'écran suivante.
Pour décrypter la configuration, nous utilisons l'algorithme suivant.
def decrypt_encrypted_configuration(
encrypted_configuration: bytes,
) -> tuple[bytes, bytes]:
key_size = int.from_bytes(encrypted_configuration[:1], "little")
key = encrypted_configuration[1 : 1 + key_size]
return key, ARC4.ARC4Cipher(key).decrypt(encrypted_configuration[key_size + 1 :])La configuration est utilisée pour initialiser un vecteur global que nous appelons g_configuration_vector en le divisant avec la chaîne \x7c\x1f\x1e\x1e\x7c comme délimiteur.
Vous trouverez une explication détaillée de la configuration plus loin dans cette série.
Contournement de l'UAC
Lorsque l'adresse enable_uac_bypass_flag (index 0x2e) est activée dans la configuration, REMCOS tente de contourner l'UAC à l'aide d'une technique COM connue.
Au préalable, le REMCOS masque son processus afin d'éviter d'être détecté.
REMCOS modifie la structure PEB du processus en cours en remplaçant le chemin d'accès à l'image et la ligne de commande par la chaîne explorer.exe tout en sauvegardant les informations originales dans des variables globales pour une utilisation ultérieure.
La technique bien connue exploite l'API CoGetObject pour transmettre l'identifiant Elevation:Administrator!new:, ainsi que les identifiants CMSTPLUA CLSID et ICMLuaUtil IID, afin d'instancier une interface COM élevée. REMCOS utilise ensuite la méthode ShellExec() de l'interface pour lancer un nouveau processus avec des privilèges d'administrateur et quitter.
Cette technique a été précédemment documentée dans un article d'Elastic Security Labs datant de 2023 : Exploration des contournements de l'UAC de Windows : Techniques et stratégies de détection.
Vous trouverez ci-dessous une capture d'écran récente de la détection de cet exploit à l'aide de l'agent Elastic Defend.
Désactivation de l'UAC
Lorsque l'adresse disable_uac_flag est activée dans la configuration (index 0x27), REMCOS désactive l'UAC dans le registre en définissant la valeur HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\SystemEnableLUA sur 0 à l'aide du binaire Windows reg.exe."
Installation et persistance
Lorsque enable_install_flag (index 0x3) est activé dans la configuration, REMCOS s'installe sur la machine hôte.
Le chemin d'installation est construit en utilisant les valeurs de configuration suivantes :
install_parent_directory(index0x9)install_directory(0x30)install_filename(0xA)
Le binaire du logiciel malveillant est copié sur {install_parent_directory}/{install_directory}/{install_filename}. Dans cet exemple, il s'agit de %ProgramData%\Remcos\remcos.exe.
Si l'adresse enable_persistence_directory_and_binary_hiding_flag (index 0xC) est activée dans la configuration, le dossier d'installation et le binaire du logiciel malveillant sont définis comme super cachés (même si l'utilisateur active l'affichage des fichiers ou dossiers cachés, le fichier est maintenu caché par Windows pour protéger les fichiers avec des attributs système) et en lecture seule en leur appliquant des attributs en lecture seule, cachés et système.
Après l'installation, REMCOS établit la persistance dans le registre en fonction des drapeaux suivants activés dans la configuration :
enable_hkcu_run_persistence_flag(index0x4)HKCU\Software\Microsoft\Windows\CurrentVersion\Run\enable_hklm_run_persistence_flag(index0x5)HKLM\Software\Microsoft\Windows\CurrentVersion\Run\enable_hklm_policies_explorer_run_flag(index0x8)HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run\
Le logiciel malveillant est ensuite relancé à partir du dossier d'installation à l'aide de ShellExecuteW, puis le processus initial est interrompu.
Injection de processus
Lorsque l'option enable_process_injection_flag (index 0xD) est activée dans la configuration, REMCOS s'injecte dans un processus spécifié ou dans un processus Windows choisi dans une liste codée en dur afin d'échapper à la détection.
L'adresse enable_process_injection_flag peut être soit une valeur booléenne, soit le nom d'un processus cible. Lorsqu'il est défini sur true (1), le processus injecté est choisi de la manière la plus efficace parmi les options suivantes :
iexplorer.exeieinstal.exeielowutil.exe
Note : il n'y a qu'une seule méthode d'injection disponible dans REMCOS, lorsque nous parlons d'injection de processus, nous nous référons spécifiquement à la méthode décrite ici.
REMCOS utilise une technique classique ZwMapViewOfSection + SetThreadContext + ResumeThread pour l'injection de processus. Il s'agit de se copier dans le binaire injecté via la mémoire partagée, cartographiée à l'aide de ZwMapViewOfSection, puis de détourner son flux d'exécution vers le point d'entrée REMCOS à l'aide des méthodes SetThreadContext et ResumeThread.
Il commence par créer le processus cible en mode suspendu à l'aide de l'API CreateProcessW et récupère son contexte d'exécution à l'aide de l'API GetThreadContext.
Ensuite, il crée une mémoire partagée à l'aide de l'API ZwCreateSection et l'affecte au processus cible à l'aide de l'API ZwMapViewOfSection, avec l'identifiant du processus distant.
Le binaire est ensuite chargé dans le processus distant en copiant son en-tête et ses sections dans la mémoire partagée.
Des déplacements sont effectués si nécessaire. Ensuite, le PEB ImageBaseAddress est corrigé à l'aide de l'API WriteProcessMemory. Ensuite, le contexte du thread est défini avec un nouveau point d'entrée pointant vers le point d'entrée REMCOS, et l'exécution du processus reprend.
Vous trouverez ci-dessous la détection de cette technique d'injection de processus par notre agent :
Configuration du mode d'enregistrement
REMCOS dispose de trois valeurs de mode d'enregistrement qui peuvent être sélectionnées dans le champ logging_mode (index 0x28) de la configuration :
- 0 : Pas d'enregistrement
- 1 : Démarrage minimisé dans l'icône de la barre des tâches
- 2 : Consignation de la console
En définissant ce champ sur 2 , vous activez la console, même si l'injection de processus est activée, et vous obtenez des informations supplémentaires.
Nettoyage des navigateurs
Lorsque l'option enable_browser_cleaning_on_startup_flag (index 0x2B) est activée, REMCOS supprime les cookies et les informations de connexion des navigateurs web installés sur l'hôte.
Selon la documentation officielle, l'objectif de cette fonctionnalité est d'accroître la sécurité du système contre le vol de mots de passe :
Actuellement, les navigateurs pris en charge sont Internet Explorer, Firefox et Chrome.
Le processus de nettoyage consiste à supprimer les cookies et les fichiers de connexion des répertoires connus des navigateurs à l'aide des API FindFirstFileA, FindNextFileA et DeleteFileA:
Lorsque le travail est terminé, REMCOS imprime un message sur la console.
Il convient de mentionner deux champs connexes dans la configuration :
enable_browser_cleaning_only_for_the_first_run_flag(index0x2C)browser_cleaning_sleep_time_in_minutes(index0x2D)
La valeur de configuration browser_cleaning_sleep_time_in_minutes détermine la durée de sommeil de REMCOS avant l'exécution de la tâche.
Lorsque l'option enable_browser_cleaning_only_for_the_first_run_flag est activée, le nettoyage ne se produit qu'à la première exécution de REMCOS. Ensuite, la valeur de registre HKCU/SOFTWARE/{mutex}/FR est définie.
Lors des exécutions suivantes, la fonction renvoie directement si la valeur existe et est définie dans le registre.
C'est la fin du premier article. La deuxième partie couvrira la seconde moitié du flux d'exécution de REMCOS, depuis son chien de garde jusqu'à la première communication avec son C2.