La stratégie Shelby

Principaux points abordés dans cet article

• La famille de logiciels malveillants SHELBY exploite GitHub à des fins de commande et de contrôle, en volant des données et en récupérant des commandes.
• La conception du C2 de l'attaquant présente une faille critique : toute personne possédant le jeton PAT peut contrôler les machines infectées, ce qui expose à une vulnérabilité importante en matière de sécurité.
• Le code inutilisé et le chargement dynamique des charges utiles suggèrent que le logiciel malveillant est en cours de développement, ce qui indique que de futures mises à jour pourraient résoudre les problèmes rencontrés dans les versions contemporaines.

Résumé

Dans le cadre de nos recherches sur les menaces émergentes, nous avons analysé un courriel de phishing potentiel envoyé à partir d'une adresse électronique appartenant à une société de télécommunications irakienne et envoyé à d'autres employés de cette même société.

L'e-mail de phishing repose sur le fait que la victime ouvre le fichier Details.zip joint et exécute le binaire contenu, JPerf-3.0.0.exe. Ce binaire utilise le système d'installation par script, Inno setup, qui contient l'application malveillante :

• %AppData%\Local\Microsoft\HTTPApi:
  • HTTPApi.dll (SHELBYC2)
  • HTTPService.dll (SHELBYLOADER)
  • Microsoft.Http.Api.exe
  • Microsoft.Http.Api.exe.config

Le site Microsoft.Http.Api.exe installé est un exécutable .NET bénin. Son objectif principal est de charger latéralement le site malveillant HTTPService.dll. Une fois chargé, HTTPService.dll joue le rôle de chargeur, initiant la communication avec GitHub pour son commandement et contrôle (C2).

Le chargeur récupère une valeur spécifique du C2, qui est utilisée pour décrypter la charge utile de la porte dérobée, HTTPApi.dll. Après le décryptage, la porte dérobée est chargée dans la mémoire sous la forme d'un assemblage géré utilisant la réflexion, ce qui lui permet de s'exécuter sans écrire sur le disque et d'échapper aux mécanismes de détection traditionnels.

Au moment de la rédaction de cet article, le backdoor et le loader ont tous deux un faible taux de détection sur VirusTotal.

Analyse du code SHELBYLOADER

Obfuscation

Le chargeur et la porte dérobée sont obscurcis par l'outil open-source Obfuscar, dont l'une des fonctionnalités est le chiffrement des chaînes de caractères. Pour contourner cette obfuscation, nous pouvons utiliser de4dot avec des paramètres personnalisés. Obfuscar remplace les chaînes par des appels à une fonction de décryptage de chaînes, mais en fournissant le jeton de cette fonction à de4dot, nous pouvons effectivement désobfusquer le code. En utilisant les paramètres --strtyp (le type de décrypteur de chaîne, dans notre cas delegate) et --strtok (le jeton de la méthode de décryptage de chaîne), nous pouvons remplacer ces appels de fonction par les valeurs en clair correspondantes, révélant ainsi les chaînes de caractères originales dans le code.

Détection du bac à sable

SHELBYLOADER utilise des techniques de détection en bac à sable pour identifier les environnements virtualisés ou surveillés. Une fois exécuté, il renvoie les résultats à C2. Ces résultats sont présentés sous forme de fichiers journaux, qui indiquent si chaque méthode de détection a permis d'identifier un environnement de type "bac à sable", par exemple :

Technique 1 : Requête WMI pour obtenir des informations sur le système

Le logiciel malveillant exécute une requête WMI (Select * from Win32_ComputerSystem) pour récupérer les détails du système. Il vérifie ensuite les champs Manufacturer (fabricant) et Model (modèle) à la recherche d'indicateurs d'une machine virtuelle, tels que "VMware" ou "VirtualBox."

Technique 2 : Enumération des processus

Le logiciel malveillant analyse les processus en cours d'exécution à la recherche de services connus liés à la virtualisation, notamment :

• vmsrvc
• vmtools
• xenservice
• vboxservice
• vboxtray

La présence de ces processus indique au logiciel malveillant qu'il peut s'exécuter dans un environnement virtualisé.

Technique 3 : Contrôles du système de fichiers

Le logiciel malveillant recherche l'existence de fichiers de pilotes spécifiques généralement associés à des logiciels de virtualisation, tels que :

• C:\Windows\System32\drivers\VBoxMouse.sys
• C:\Windows\System32\drivers\VBoxGuest.sys
• C:\Windows\System32\drivers\vmhgfs.sys
• C:\Windows\System32\drivers\vmci.sys

Technique 4 : Analyse de la taille du disque

Le logiciel malveillant vérifie la taille du volume C:. Si la taille est inférieure à 50 Go, on peut en déduire que l'environnement fait partie d'un bac à sable, car de nombreuses machines virtuelles sont configurées avec des disques de taille inférieure à des fins de test.

Technique 5 : Vérification du processus parental

Le logiciel malveillant examine le processus parent. Si le processus parent n'est pas explorer.exe, cela peut indiquer une exécution dans un environnement d'analyse automatisé plutôt qu'un scénario typique piloté par l'utilisateur.

Technique 6 : Détection de l'écart de temps de sommeil

Le logiciel malveillant utilise des contrôles de synchronisation pour détecter si ses fonctions de mise en veille ou de retard sont accélérées, une technique couramment utilisée par les bacs à sable pour accélérer l'analyse. Des écarts importants par rapport aux heures de sommeil prévues peuvent révéler un environnement en bac à sable.

Technique 7 : Requête WMI pour le contrôleur vidéo

Le logiciel malveillant exécute une requête WMI (SELECT * FROM Win32_VideoController) pour récupérer des informations sur le contrôleur vidéo du système. Il compare ensuite le nom du contrôleur vidéo aux valeurs connues associées aux machines virtuelles : virtual ou vmware ou vbox.

Fonctionnalité de base

Le code de chargement du logiciel malveillant commence par initialiser plusieurs variables dans le constructeur de sa classe principale. Ces variables sont les suivantes

• Un nom de compte GitHub
• Un nom de dépôt privé
• un jeton d'accès personnel (PAT) pour l'authentification et l'accès au référentiel

En outre, le logiciel malveillant met en place deux minuteries, qui sont utilisées pour déclencher des actions spécifiques à des intervalles prédéfinis.

L'une des minuteries est configurée pour déclencher une méthode spécifique 125 secondes après l'exécution. Lorsqu'elle est invoquée, cette méthode établit une persistance sur le système infecté en ajoutant une nouvelle entrée à la clé du registre Windows SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Une fois que la méthode est déclenchée et que le mécanisme de persistance est exécuté avec succès, la minuterie est arrêtée et ne peut plus être déclenchée.

Cette méthode utilise une variable entière pour indiquer le résultat de son opération. Le tableau suivant décrit chaque valeur possible et sa signification :

Cette valeur entière est communiquée au C2 lors de son premier enregistrement au C2, ce qui permet aux attaquants de surveiller le succès ou l'échec du mécanisme de persistance sur le système infecté.

La deuxième minuterie est configurée pour déclencher une méthode responsable du chargement de la porte dérobée, qui s'exécute 65 secondes après le démarrage du logiciel malveillant. Tout d'abord, le logiciel malveillant génère un hachage MD5 basé sur une combinaison d'informations spécifiques au système. Les données utilisées pour créer le hachage sont formatées comme suit, chaque élément étant séparé par une barre oblique ( / ) :

• Nombre de processeurs disponibles sur le système.
• Le nom de la machine (nom d'hôte).
• Le nom de domaine associé au compte utilisateur.
• Le nom d'utilisateur de l'utilisateur actuellement connecté.
• Nombre total de lecteurs logiques présents sur le système.

Un sous-ensemble de ce hachage est ensuite extrait et utilisé comme identifiant unique de la machine infectée. Cet identifiant permet aux attaquants de suivre et de gérer les systèmes compromis au sein de leur infrastructure.

Après avoir généré l'identifiant unique, le logiciel malveillant insère un nouveau commit dans le dépôt myToken à l'aide d'une requête HTTPS. La livraison comprend un répertoire nommé d'après l'identifiant unique, qui contient un fichier nommé Info.txt. Ce fichier contient les informations suivantes sur le système infecté :

• Le nom de domaine associé au compte utilisateur.
• Le nom d'utilisateur de l'utilisateur actuellement connecté.
• Le journal des résultats de la détection du bac à sable détaillant les techniques qui ont réussi ou échoué.
• L'indicateur de persistance (tel que décrit dans le tableau ci-dessus) indique le résultat du mécanisme de persistance.
• Date et heure actuelles de l'événement de balisage

Le logiciel malveillant tente d'abord d'envoyer un commit au dépôt sans utiliser de proxy. Si cette première tentative échoue, il se rabat sur l'utilisation du proxy configuré par le système pour ses communications.

Après le premier beaconing et l'enregistrement réussi de la victime, le logiciel malveillant tente d'accéder au même répertoire de dépôt GitHub que celui qu'il a créé précédemment et de télécharger un fichier nommé License.txt (nous n'avons pas observé de décalage dans l'intervalle de vérification, mais le serveur pouvait le gérer). S'il est présent, ce fichier contient une valeur de 48 octets, qui est utilisée pour générer une clé de décryptage AES. Ce fichier n'est téléchargé par le backend de l'attaquant qu'après validation que le logiciel malveillant n'est pas exécuté dans un environnement sandbox. Cela permet de s'assurer que seules les infections validées reçoivent la clé et escaladent la chaîne d'exécution jusqu'à la porte dérobée.

Le logiciel malveillant génère une clé AES et un vecteur d'initialisation (IV) à partir du contenu de License.txt. Il commence par hacher la valeur de 48 octets à l'aide de SHA256, puis utilise le hachage résultant comme clé et les premiers 16 octets comme IV.

Il procède au décryptage du fichier HTTPApi.dll, qui contient la charge utile de la porte dérobée. Après le décryptage, le logiciel malveillant utilise la méthode Assembly.Load pour charger par réflexion la porte dérobée dans la mémoire. Cette technique permet au logiciel malveillant d'exécuter directement la porte dérobée décryptée sans l'écrire sur le disque.

Mécanisme de clé basé sur le DNS

Une autre variante de SHELBYLOADER utilise une approche différente pour l'enregistrement et la récupération de la séquence d'octets utilisée pour générer la clé AES et l'IV.

Tout d'abord, le logiciel malveillant exécute les mêmes méthodes anti-sandboxing, créant une chaîne de 1 ou 0 selon qu'une sandbox est détectée ou non pour chaque technique.

Pour son enregistrement C2, le logiciel malveillant crée un sous-domaine sous arthurshelby.click avec trois parties : le premier sous-domaine est une chaîne statique (s), le deuxième sous-domaine est l'identifiant unique encodé en Base32, et le troisième sous-domaine est une chaîne concaténée au format DomainName\HostName >> Anti-Sandboxing Results >> Persistence Flag encodé en Base32.

Par exemple, un domaine complet peut ressembler à s.grldiyrsmvsggojzmi4wmyi.inevyrcfknfvit2qfvcvinjriffe6ib6hyqdambqgaydambahy7cama.arthurshelby.click

Ensuite, le logiciel malveillant exécute plusieurs requêtes DNS vers des sous-domaines de arthurshelby.click. Les adresses IP renvoyées par ces requêtes sont concaténées en une séquence d'octets, qui est ensuite utilisée pour générer la clé AES permettant de décrypter la porte dérobée, en suivant le même processus que celui décrit précédemment.

Les sous-domaines suivent ce format :

• Le premier sous-domaine est l<index>, où l'index correspond à l'ordre des appels DNS (par exemple, l1, l2, etc.), ce qui garantit que la séquence d'octets est assemblée correctement.
• Le deuxième sous-domaine est l'identifiant unique codé en Base32.

Analyse du code SHELBYC2

La porte dérobée commence par régénérer le même identifiant unique créé par le chargeur. Pour ce faire, il calcule un hachage MD5 de la chaîne de caractères spécifique au système utilisée précédemment. La porte dérobée crée ensuite un Mutex pour s'assurer qu'une seule instance du logiciel malveillant s'exécute sur la machine infectée. Le Mutex est nommé en faisant précéder l'identifiant unique de la chaîne Global\GHS.

Après 65 secondes, la porte dérobée exécute une méthode qui recueille les informations suivantes sur le système :

• l'identité de l'utilisateur actuel
• la version du système d'exploitation
• l'ID du processus du logiciel malveillant
• nom de la machine
• répertoire de travail actuel

Il est intéressant de noter que ces informations collectées ne sont ni utilisées localement ni exfiltrées vers le serveur C2. Cela suggère que le code pourrait être un code mort laissé pendant le développement ou que le logiciel malveillant est toujours en cours de développement actif, avec des plans potentiels pour utiliser ces données dans les versions futures.

Le logiciel malveillant télécharge ensuite l'horodatage actuel dans un fichier nommé Vivante.txt dans le dépôt myGit au sein de son répertoire unique (nommé à l'aide de l'identifiant unique du système). Cet horodatage sert de dernière heure de balise, ce qui permet aux attaquants de surveiller l'activité du logiciel malveillant et de confirmer que le système infecté est toujours actif. Le mot "Vivante" se traduit par "alive" en français, ce qui reflète le rôle du fichier en tant qu'indicateur du rythme cardiaque de la machine compromise.

Ensuite, le logiciel malveillant tente de télécharger le fichier Command.txt, qui contient une liste de commandes émises par l'opérateur pour être exécutées sur le système infecté.

Si Command.txt ne contient aucune commande, le logiciel malveillant recherche des commandes dans un autre fichier nommé Broadcast.txt. Contrairement à Command.txt, ce fichier est situé en dehors du répertoire du logiciel malveillant et est utilisé pour diffuser des commandes à tous les systèmes infectés simultanément. Cette approche permet à l'attaquant d'exécuter simultanément des opérations sur plusieurs machines compromises, rationalisant ainsi le contrôle à grande échelle.

Tableau de traitement des commandes :

Les commandes du fichier Command.txt peuvent être des commandes gérées ou des commandes système exécutées avec Powershell. Vous trouverez ci-dessous une description de chaque commande gérée.

/téléchargement

Cette commande télécharge un fichier d'un dépôt GitHub sur la machine infectée. Il nécessite deux paramètres :

• Le nom du fichier stocké dans le dépôt GitHub.
• Le chemin d'accès où le fichier sera enregistré sur la machine infectée.

/upload

Cette commande télécharge un fichier de la machine infectée vers le dépôt GitHub. Elle prend un paramètre : le chemin du fichier à télécharger.

/dlextract

Cette commande télécharge un fichier zip depuis le dépôt GitHub (similaire à /download), extrait son contenu et l'enregistre dans un répertoire spécifié sur la machine.

/evoke

Cette commande est utilisée pour charger un binaire .NET par réflexion ; elle prend deux paramètres : le premier paramètre est le chemin d'un binaire .NET crypté AES préalablement téléchargé sur la machine infectée, le second paramètre est une valeur utilisée pour dériver l'AES et l'IV, de la même manière que le chargeur charge la porte dérobée.

Cette commande charge par réflexion un binaire .NET de la même manière que SHELBYLOADER charge la porte dérobée. Il nécessite deux paramètres :

• Le chemin d'accès à un binaire .NET crypté AES précédemment téléchargé sur la machine infectée.
• Valeur utilisée pour dériver la clé AES et l'IV.

Commandes du système

Toute commande ne commençant pas par l'un des éléments ci-dessus est traitée comme une commande PowerShell et exécutée en conséquence.

Communication

Le logiciel malveillant n'utilise pas l'outil Git dans le backend pour envoyer des commits. Au lieu de cela, il crée des requêtes HTTP pour interagir avec GitHub. Il envoie un commit au référentiel en utilisant un objet JSON avec la structure suivante :

{
  "message": "Commit message",
  "content": "<base64 encoded content>",
  "sha": "<hash>"
}

Le logiciel malveillant définit des en-têtes HTTP spécifiques pour la requête, notamment :

• Acceptez : application/vnd.github.v3+json
• Content-Type : application/json
• Autorisation : token <PAT_token>
• User-Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

La demande est envoyée au point de terminaison de l'API GitHub, construit comme suit :

https://api.github.com/repos/<owner>/<repo>/contents/<unique identifier>/<file>

Le jeton d'accès personnel (PAT) nécessaire pour accéder au référentiel privé est intégré dans le binaire. Cela permet au logiciel malveillant de s'authentifier et d'effectuer des actions sur le référentiel sans utiliser la chaîne d'outils standard de Git.

La façon dont le logiciel malveillant est configuré signifie que toute personne possédant le PAT (Personal Access Token ) peut théoriquement récupérer les commandes envoyées par l'attaquant et accéder aux sorties de commande à partir de n'importe quel ordinateur de la victime. En effet, le jeton PAT est intégré dans le fichier binaire et peut être utilisé par quiconque l'obtient.

Conclusion de la famille SHELBY

Bien que l'infrastructure C2 soit conçue de manière exotique, l'attaquant n'a pas tenu compte des risques et des implications significatifs de cette approche.

Nous pensons que l'utilisation de ce logiciel malveillant, qu'elle soit le fait d'une équipe rouge autorisée ou d'un acteur malveillant, constituerait une faute professionnelle. Il permet à toute victime d'utiliser le PAT intégré et de prendre le contrôle de toutes les infections actives. En outre, si une victime télécharge des échantillons sur des plateformes telles que VirusTotal ou MalwareBazaar, un tiers peut accéder aux données relatives à l'infection ou s'emparer entièrement des infections.

REF8685 analyse de la campagne

Elastic Security Labs a découvert REF8685 lors d'une collecte et d'une analyse de routine de sources de données tierces. En étudiant l'intrusion REF8685, nous avons identifié un chargeur et un implant C2 que nous avons jugés nouveaux, ce qui nous a amenés à publier cette analyse détaillée des logiciels malveillants et de l'intrusion.

Les charges utiles malveillantes ont été transmises à une entreprise de télécommunications basée en Irak par le biais d'un courriel d'hameçonnage très ciblé envoyé depuis l'organisation visée. Le texte du courriel est une discussion entre ingénieurs sur les spécificités techniques de la gestion du réseau. D'après le contenu et le contexte du courriel, il est peu probable que ce leurre ait été conçu à l'extérieur, ce qui indiquerait la compromission des terminaux de l'ingénieur, des serveurs de messagerie, ou des deux.

Dears,

We would appreciate it if you would check the following alarms on Core Network many (ASSOCIATION) have been flapped.

Problem Text
*** ALARM 620 A1/APT "ARHLRF2SPX1.9IP"U 250213 1406
M3UA DESTINATION INACCESSIBLE
DEST            SPID
2-1936          ARSMSC1
END

Problem Text
*** ALARM 974 A1/APT "ARHLRF1SPX1.9IP"U 250213 1406
M3UA DESTINATION INACCESSIBLE
DEST            SPID
2-1936          ARSMSC1
END
…

Cet e-mail contient un appel à l'action pour traiter les alarmes réseau et une pièce jointe zippée nommée details.zip. Dans ce fichier zip se trouve un fichier texte contenant les journaux mentionnés dans l'e-mail et un exécutable Windows (JPerf-3.0.0.exe), qui démarre la chaîne d'exécution, aboutissant à la livraison de l'implant SHELBYC2, qui permet d'accéder à distance à l'environnement.

Bien qu'il n'ait pas été observé dans l'intrusion REF8685, il convient de noter que VirusTotal montre que JPerf-3.0.0.exe (feb5d225fa38efe2a627ddfbe9654bf59c171ac0742cd565b7a5f22b45a4cc3a) a été inclus dans une archive compressée distincte (JPerf-3.0.0.zip) et a également été envoyé d'Irak. On ne sait pas s'il s'agit de la même victime ou d'une autre dans le cadre de cette campagne. Une recherche de similarité de fichiers identifie également un deuxième implant nommé Setup.exe avec une archive compressée supplémentaire(5c384109d3e578a0107e8518bcb91cd63f6926f0c0d0e01525d34a734445685c).

L'analyse de ces fichiers (JPerf-3.0.0.exe et Setup.exe) a révélé l'utilisation de GitHub pour C2 et les mécanismes de récupération des clés AES (plus d'informations à ce sujet dans les sections consacrées à l'analyse des logiciels malveillants). Les comptes Github (arthurshellby et johnshelllby) utilisés pour le malware REF8685 étaient malveillants et ont été fermés par Github.

Arthur et John Shelby sont des personnages de la série télévisée policière britannique Peaky Blinders. La série a été produite de 2013 à 2022.

Le domaine arthurshelby[.]click pointe vers 2.56.126[.]151, un serveur hébergé par Stark Industries (AS44477). Ce fournisseur d'hébergement VPS a été utilisé pour des services de proxy dans d'autres cyberattaques de grande envergure. Ce serveur a des résolutions qui se chevauchent pour :

• arthurshelby[.]click
• [REDACTED]telecom[.]digital
• speed-test[.]click
• [REDACTED]airport[.]cloud
• [REDACTED]airport[.]pro

L'archive compressée et les domaines C2 de l'un des échantillons SHELBYLOADER portent le nom de [REDACTED] Telecom, une société de télécommunications basée en Irak. La carte de couverture de [EXPURGÉ] se concentre sur la région du Kurdistan irakien dans le nord et l'est du pays.

"Sharjaairport" indique une probable troisième victime ciblée. L'aéroport international de [EXPURGÉ] ([EXPURGÉ]) est un aéroport international spécialisé dans le fret aérien aux Émirats arabes unis. Il se trouve à 23,3 km de l'aéroport international de Dubaï (DXB).

[REDACTED]airport[.]cloud résolu vers un nouveau serveur, 2.56.126[.]157, pendant un jour, les janvier 21, 2025. Ensuite, il a pointé vers Google DNS, le serveur légitime de l'aéroport [REDACTED], et enfin, une adresse de parking Namecheap. Le serveur 2.56.126[.]157, Stark Industries (AS44477), héberge également [REDACTED]-connect[.]online, [EXPURGÉ] est le code de l'aéroport international de [EXPURGÉ].

Le domaine [REDACTED]airport[.]cloud a un sous-domaine portal.[REDACTED]airport[.]cloud qui a brièvement pointé vers 2.56.126[.]188 à partir du 23 janvier -25, 2025. Il a ensuite dirigé le trafic vers 172.86.68[.]55 jusqu'au moment de la rédaction du présent document.

Les pivots de hachage de la bannière révèlent un combo serveur-domaine supplémentaire : 195.16.74[.]138, [REDACTED]-meeting[.]online.

Le serveur 172.86.68[.].55 héberge également mail.[REDACTED]tell[.]com, un domaine d'hameçonnage apparent ciblant notre victime initiale.

Une page de connexion a été hébergée à l'adresse hxxps://portal.[REDACTED]airport[.]cloud/Login (VirusTotal).

Nous estimons que les attaquants ont utilisé ces deux sous-domaines pour hameçonner les identifiants de connexion au cloud. Une fois ces informations d'identification sécurisées (dans le cas de [REDACTED] Telecom), les attaquants ont accédé à la messagerie électronique en nuage de la victime et ont conçu un hameçonnage très ciblé en utilisant les fils de courriels internes en cours.

Ce courrier électronique interne a été utilisé pour se rendre sur les points d'accès des victimes par le biais d'un rephishing.

Tous les domaines associés à cette campagne ont utilisé les certifications ZeroSSL et se sont trouvés sur l'infrastructure de Stark Industries.

Le modèle diamant de l'analyse des intrusions

Elastic Security Labs utilise le modèle du diamant pour décrire les relations de haut niveau entre les adversaires, les capacités, l'infrastructure et les victimes des intrusions. Bien que le modèle en diamant soit le plus souvent utilisé pour des intrusions uniques et qu'il tire parti de l'enchaînement des activités (section 8) pour créer des relations entre les incidents, un modèle centré sur l'adversaire (section 7.1.4) peut également être utilisé pour créer des relations entre les incidents et les activités. permet d'obtenir un diamant unique, bien qu'encombré.

REF8685 et MITRE ATT&CK

Elastic utilise le cadre MITRE ATT& CK pour documenter les tactiques, techniques et procédures communes que les menaces persistantes avancées 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.

• Commande et contrôle
• Accès initial
• É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.

• Chargement du code réfléchissant
• Phishing
• Masquage des fichiers ou des informations
• Interprète de script et de commande
• Exfiltration par le canal C2

Règle YARA

Elastic Security a créé des règles YARA pour identifier cette activité. Vous trouverez ci-dessous les règles de YARA permettant d'identifier les logiciels malveillants SHELBYC2 et SHELBYLOADER :

rule Windows_Trojan_ShelbyLoader {
    meta:
        author = "Elastic Security"
        creation_date = "2025-03-11"
        last_modified = "2025-03-25"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "ShelbyLoader"
        threat_name = "Windows.Trojan.ShelbyLoader"
        license = "Elastic License v2"

    strings:
        $a0 = "[WARN] Unusual parent process detected: "
        $a1 = "[ERROR] Exception in CheckParentProcess:" fullword
        $a2 = "[INFO] Sandbox Not Detected by CheckParentProcess" fullword
        $b0 = { 22 63 6F 6E 74 65 6E 74 22 3A 20 22 2E 2B 3F 22 }
        $b1 = { 22 73 68 61 22 3A 20 22 2E 2B 3F 22 }
        $b2 = "Persist ID: " fullword
        $b3 = "https://api.github.com/repos/" fullword
    condition:
        all of ($a*) or all of ($b*)
}

rule Windows_Trojan_ShelbyC2 {
    meta:
        author = "Elastic Security"
        creation_date = "2025-03-11"
        last_modified = "2025-03-25"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "ShelbyC2"
        threat_name = "Windows.Trojan.ShelbyC2"
        license = "Elastic License v2"

    strings:
        $a0 = "File Uploaded Successfully" fullword
        $a1 = "/dlextract" fullword
        $a2 = "/evoke" fullword
        $a4 = { 22 73 68 61 22 3A 20 22 2E 2B 3F 22 }
        $a5 = { 22 2C 22 73 68 61 22 3A 22 }
    condition:
        all of them
}

Observations

Toutes les observables sont également disponibles au téléchargement en format ECS et STIX dans un paquet zip combiné.

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