BlackByte combine des techniques éprouvées avec des vulnérabilités récemment divulguées pour soutenir ses attaques en cours

• Le groupe de ransomware BlackByte continue d’exploiter des tactiques, techniques et procédures (TTP) qui ont formé la base de ses méthodes depuis sa création, en adaptant continuellement son utilisation des pilotes vulnérables pour contourner les protections de sécurité et en déployant un ransomware capable de se propager de manière autonome, semblable à un ver.
  
• BlackByte utilise des techniques qui s’écartent de ses méthodes établies, telles que l’exploitation de la vulnérabilité CVE-2024-37085 – une faille de contournement d’authentification dans VMware ESXi – peu après sa divulgation, et l’utilisation du mécanisme d’accès distant autorisé d’une victime plutôt que le déploiement d’un outil d’administration à distance commercial comme AnyDesk.
  
• Une nouvelle itération de l’encryptage BlackByte qui ajoute l’extension de fichier « blackbytent_h » aux fichiers chiffrés, dépose quatre fichiers de pilotes vulnérables par rapport aux trois observés précédemment, et utilise les identifiants Active Directory de la victime pour se propager.
  
• Le groupe BlackByte est plus actif que ce que son site de fuite de données pourrait laisser penser, où seulement 20 à 30 % des attaques réussies se traduisent par un message d’extorsion.

BlackByte est un groupe de ransomware-as-a-service (RaaS) que l’on pense être une branche du tristement célèbre groupe de ransomware Conti. Observé pour la première fois entre la mi- et la fin de l’année 2021, leur mode opératoire comprend l’utilisation de pilotes vulnérables pour contourner les contrôles de sécurité, le déploiement de ransomware capables de se propager de manière autonome avec des capacités similaires à celles des vers, et l’utilisation de binaires système connus (LoLBins) ainsi que d’autres outils commerciaux légitimes dans leur chaîne d’attaque.

BlackByte a réécrit son binaire de ransomware au fil du temps, avec des versions programmées en Go, .NET, C++, ou une combinaison de ces langages. Les efforts apparents du groupe pour améliorer en permanence ses outils, ses opérations et même son site de fuite de données sont bien documentés.

Accès initial

Lors d’une récente attaque de ransomware BlackByte, l’acteur de la menace a obtenu un accès initial en utilisant des identifiants valides pour accéder au VPN de l’organisation victime. Les limites de la télémétrie et la perte de preuves après l’événement de chiffrement du ransomware ont empêché les Team IR de déterminer si les identifiants avaient été obtenus par brute-force sur l’interface VPN ou étaient déjà connus de l’adversaire avant l’attaque. Cependant, Les équipes IR a une confiance modérée dans le fait que l’authentification par brute-force facilitée par le balayage internet était le vecteur d’accès initial, basé sur les observations suivantes :

• Le compte initialement compromis par l’adversaire avait une convention de nommage basique et, selon les informations, un mot de passe faible.
• L’interface VPN pourrait avoir permis à un compte de domaine de s’authentifier sans authentification multi-facteurs (MFA) si le compte cible avait une configuration spécifique dans Active Directory.
• BlackByte a un historique de recherche et d’exploitation de vulnérabilités accessibles au public, telles que la vulnérabilité ProxyShell dans Microsoft Exchange Server.

Étant donné l’historique de BlackByte en matière d’exploitation de vulnérabilités accessibles au public pour un accès initial, l’utilisation du VPN pour un accès distant peut représenter un léger changement de technique ou pourrait être opportuniste. L’utilisation du VPN de la victime pour l’accès distant offre également à l’adversaire d’autres avantages, y compris une visibilité réduite depuis l’EDR (détection et réponse des endpoints) de l’organisation

Reconnaissance et énumération

Après avoir obtenu un accès initial à l’environnement, l’adversaire a réussi à élever ses privilèges en compromettant deux comptes au niveau Domain Admin. L’un de ces comptes a été utilisé pour accéder au serveur VMware vCenter de l’organisation et, peu après, créer des objets de domaine Active Directory pour des hyperviseurs VMware ESXi individuels, les intégrant ainsi au domaine.

Le même compte a ensuite été utilisé pour créer et ajouter plusieurs autres comptes à un groupe Active Directory appelé « ESX Admins ». Les équipes IR estime que ce groupe d’utilisateurs a été créé pour exploiter la vulnérabilité CVE-2024-37085 , un contournement d’authentification dans VMware ESXi connu pour être utilisé par plusieurs groupes de ransomware. L’exploitation réussie de cette vulnérabilité accorde aux membres d’un groupe Active Directory spécifique des privilèges élevés sur un hôte ESXi, permettant le contrôle des machines virtuelles (VM), la modification de la configuration du serveur hôte, et l’accès aux journaux système, aux outils de diagnostic et de surveillance des performances.

Les équipes IR a observé que l’acteur de la menace exploitait cette vulnérabilité, qui a initialement reçu une attention limitée de la part de la communauté de la cybersécurité, dans les jours suivant sa publication. Cela met en évidence la rapidité avec laquelle des groupes de ransomware comme BlackByte peuvent adapter leurs TTPs pour intégrer des vulnérabilités nouvellement divulguées, ainsi que le temps et les efforts investis dans l’identification de pistes potentielles pour faire avancer une attaque

L’acteur de la menace a accédé à d’autres systèmes, répertoires et fichiers au sein de chaque environnement victime en utilisant des protocoles tels que Server Message Block (SMB) et Remote Desktop Protocol (RDP). L’analyse des journaux d’événements système et des journaux d’authentification a révélé un modèle cohérent où l’acteur de la menace utilisait principalement NT LAN Manager (NTLM) pour l’authentification, tandis que les utilisateurs de l’organisation utilisaient principalement Kerberos. Cette activité précoce liée à NTLM pourrait refléter des attaques d’authentification telles que « pass the hash » pour le mouvement latéral. L’analyse dynamique du binaire du ransomware a ensuite révélé une utilisation cohérente de NTLM pour l’authentification par ce fichier également

Talos IR a également observé l’exécution d’un fichier nommé “atieclxx.exe” depuis le répertoire “C:\temp\sys\” sur l’un des serveurs de fichiers. La version légitime de “atieclxx.exe” se trouve normalement dans le répertoire “C:\Windows\System32” , Où elle prend en charge les processus système associés aux cartes graphiques AMD. Cependant, lors de l’enquête sur une attaque de BlackByte, “atieclxx.exe” a été exécuté depuis le répertoire “C:\temp\sys” avec la commande atieclxx.exe P@$$w0rd123!!!. Étant donné que les acteurs de BlackByte sont connus pour privilégier la chaîne de caractères “P@$$w0rd” lors de la définition de mots de passe de comptes et comme paramètres d’entrée pour des outils personnalisés, cette syntaxe pourrait indiquer des tentatives de déguiser des logiciels malveillants – comme leur outil personnalisé d’exfiltration de données, ExByte – en un fichier connu ou légitime. Les équipes IR n’a pas pu obtenir une copie du fichier pour analyse.

Enfin, l’acteur de la menace a été observé en train de manipuler les configurations des outils de sécurité via des modifications du registre système, de désinstaller manuellement l’EDR de plusieurs systèmes clés, et, lors d’une enquête, de changer le mot de passe racine des hôtes ESXi de l’organisation. Immédiatement avant le premier signe de chiffrement de fichiers, des volumes accrus de tentatives d’authentification NTLM et de connexions SMB ont été observés entre des dizaines de systèmes dans l’environnement. Cette activité a ensuite été comprise comme étant caractéristique du mécanisme d’auto-propagation du ransomware.

Exfiltration de données

Les limitations de la télémétrie disponible, l’effet du processus de chiffrement du ransomware et le lieu de staging hors réseau de l’adversaire pendant l’enquête de équipes IR ont empêché une évaluation avec un haut degré de confiance des méthodes d’exfiltration de données et de déterminer si une exfiltration a eu lieu. Comme mentionné dans les sections précédentes, l’utilisation possible de l’outil personnalisé d’exfiltration de données de BlackByte, ExByte, a été observée, mais n’a pas pu être confirmée.

Exécution du Ransomware

Similarités avec les Rapports Précédents

Dans les cas récents, le binaire du ransomware BlackByte, “host.exe” , a été exécuté depuis le même répertoire – “C:\Windows” – sur toutes les victimes investiguées par équipesIR. La syntaxe de commande utilisée par l’adversaire lors de chaque attaque – C:\Windows\host.exe -s [chaîne numérique à 8 chiffres] svc – et le comportement du binaire du ransomware sont cohérents avec les analyses précédentes du binaire BlackByteNT par Microsoft, DuskRise, Acronis et d’autres. Les similarités observées incluent :

• Le binaire du ransomware ne s’exécutera pas sans la chaîne numérique correcte à huit chiffres passée au paramètre “-s”. Cette chaîne numérique à huit chiffres était le seul élément de la syntaxe de commande qui variait entre les victimes. Lors d’une attaque, l’adversaire a utilisé deux encryptors différents de manière séquentielle, chacun avec sa propre valeur de paramètre “-s” , bien qu’il ne soit pas clair pourquoi plusieurs encryptors ont été employés

• Le paramètre “svc” entraîne l’installation du ransomware en tant que service, ce qui semblait transformer un système infecté en un propagateur supplémentaire dans le cadre du comportement de propagation par ver du ransomware. Des authentifications SMB et NTLM ont été observées contre des hôtes accessibles après la création du service ransomware, entraînant plusieurs vagues de chiffrement des heures après l’événement initial

• Le binaire du ransomware crée et fonctionne principalement à partir du répertoire “C:\SystemData”. Plusieurs fichiers communs sont créés dans ce répertoire sur toutes les victimes de BlackByte, y compris un fichier texte appelé “MsExchangeLog1.log”, qui semble être un journal de suivi des processus où les étapes d’exécution sont enregistrées sous forme de valeurs séparées par des virgules “q”, “w” et “b”, comme le montre la capture d’écran suivante.

• Après une exécution réussie, le binaire du ransomware a exécuté la commande :

‘/c ping 1.1.1[.]1 -n 10 > Nul & fsutil file setZeroData offset=0 length=503808 c:\windows\host.exe & Del c:\windows\host.exe /F /Q ‘  ,qui, après un délai, met à zéro le contenu du fichier et se supprime lui-même. Cette structure générale de commande a été observée dans divers outils BlackByte depuis 2022.

Observations Novatrices

Les équipes IR a observé certaines différences dans les récentes attaques de BlackByte. Plus particulièrement, les fichiers chiffrés sur toutes les victimes ont été réécrits avec l’extension de fichier “blackbytent_h” , qui n’est pas encore apparue dans les rapports publics.

Cette version plus récente de l’encryptor dépose également quatre pilotes vulnérables dans le cadre de la technique habituelle de BlackByte appelée Bring Your Own Vulnerable Driver (BYOVD).

Les quatre pilotes ont été déposés par le binaire de l’encryptor dans toutes les attaques de BlackByte examinées par équipes IR, chacun avec une convention de nommage similaire – huit caractères alphanumériques aléatoires suivis d’un underscore et d’une valeur numérique itérative. En utilisant “AM35W2PH” comme exemple fictif, les pilotes vulnérables apparaîtraient dans le même ordre que :

• “AM35W2PH” – RtCore64.sys, un pilote utilisé à l’origine par MSI Afterburner, un utilitaire d’overclocking système.
• “AM35W2PH_1” – DBUtil_2_3.sys, un pilote faisant partie de l’utilitaire de mise à jour du firmware Dell Client.
•  “AM35W2PH_2” – zamguard64.sys, un pilote faisant partie de l’application Zemana Anti-Malware (ZAM).
• “AM35W2PH_3” – gdrv.sys, un pilote faisant partie du package logiciel GIGABYTE Tools pour les cartes mères GIGABYTE.

L’inclusion du fichier “zamguard64.sys” , également connu sous le nom de “Terminator” , est particulièrement intéressante en raison des rapports récents d’autres chercheurs en sécurité sur sa prévalence, et aussi parce que le binaire du ransomware a créé deux clés de registre liées aux services associées à ce fichier pendant l’exécution, puis les a supprimées plus tard dans le processus d’exécution. En utilisant la même chaîne fictive ci-dessus, ces clés de registre seraient :   

• HKLM\SYSTEM\CONTROLSET001\SERVICES\AM35W2PH_2
• HKLM\SYSTEM\CONTROLSET001\SERVICES\AM35W2PH_2\SECURITY

Lors de l’analyse dynamique de plusieurs binaires de ransomware BlackByte, les Équipes IR a découvert que le fichier tentait une énumération de partages réseau via la fonction NetShareEnumAll du pipe nommé ‘SRVSVC’ en utilisant des comptes utilisateur spécifiques associés à la victime. Étant donné que cette analyse a été effectuée dans un environnement contrôlé et sandboxé, ces comptes n’auraient pu apparaître dans le trafic réseau que s’ils étaient intégrés dans le binaire du ransomware lui-même. Cette découverte donne aux équipes IR une grande confiance dans le fait que la personnalisation par victime de l’encryptor de ransomware de BlackByte inclut l’incorporation de certaines formes de credentials volés dans le binaire pour soutenir sa capacité de propagation en ver.

Autres comportements d’intérêt observés

D’autres comportements intéressants observés lors de l’analyse dynamique de cette version du binaire du ransomware incluent :

• Communication avec msdl.microsoft[.]com via l’adresse IP 204.79.197[.]219 au début du processus d’exécution. Ce site est associé au Microsoft Public Symbol Server. Les outils de BlackByte ont depuis longtemps été observés en train de télécharger et de sauvegarder des symboles de débogage directement depuis Microsoft.
  
• Désactivation des protections antivirus et anti-spyware via la clé de registre HKLM\SOFTWARE\MICROSOFT\WINDOWS DEFENDER et ajout de la valeur “*.exe” à la clé de registre HKLM\SOFTWARE\MICROSOFT\WINDOWS DEFENDER\EXCLUSIONS\EXTENSIONS.
  
• Suppression des binaires système du répertoire “C:\Windows\System32”, y compris “taskmgr.exe”, “perfmon.exe”, “shutdown.exe” et “resmon.exe”

Vue d’ensemble de l’utilisation de BYOD et de la victimologie de BlackByte

La victimologie de BlackByte est en accord avec cette évaluation, avec plus de 32 % des victimes connues provenant du secteur industriel (fabrication).

Ces chiffres sont probablement conservateurs, compte tenu de la différence entre le nombre de victimes publiées sur le site de fuite de données de BlackByte au cours des six à neuf derniers mois et le nombre de victimes identifiées via la télémétrie et divulguées dans les rapports publics. Il n’est pas clair pourquoi seul un sous-ensemble limité – estimé entre 20 et 30 % – des victimes de BlackByte est finalement publié.

Implications pour les défenseurs

La progression de BlackByte dans les langages de programmation, passant de C# à Go, puis plus récemment à C/C++ dans la dernière version de son crypteur – BlackByteNT – reflète un effort délibéré pour renforcer la résilience du malware contre la détection et l’analyse. Des langages complexes comme C/C++ permettent l’incorporation de techniques avancées d’anti-analyse et d’anti-debugging, observées dans les outils de BlackByte lors d’analyses détaillées menées par d’autres chercheurs en sécurité.

La nature auto-propagatrice du crypteur BlackByte présente des défis supplémentaires pour les défenseurs. L’utilisation de la technique BYOVD (Bring Your Own Vulnerable Driver) accentue ces difficultés, car elle peut limiter l’efficacité des contrôles de sécurité lors des efforts de confinement et d’éradication. Cependant, étant donné que cette version actuelle du crypteur semble s’appuyer sur des identifiants intégrés volés dans l’environnement de la victime, une réinitialisation des identifiants d’utilisateurs à l’échelle de l’entreprise et des tickets Kerberos serait très efficace pour le confinement. Une révision du trafic SMB émanant du crypteur pendant l’exécution révélera également les comptes spécifiques utilisés pour propager l’infection à travers le réseau.

D’un point de vue plus large sur le mode opératoire des ransomwares, la flexibilité inhérente au modèle RaaS (Ransomware-as-a-Service) permet aux acteurs de la menace de contrer rapidement les nouvelles stratégies défensives développées par les experts en cybersécurité, en adaptant et en mettant à jour leurs outils. Cela crée une course perpétuelle entre les cybercriminels et les défenseurs. Alors que BlackByte et d’autres groupes de ransomwares continuent d’évoluer, les organisations devront investir dans des contrôles de sécurité adaptatifs et résilients, ainsi que développer des mesures capables de suivre le rythme d’un paysage de menaces dynamique et diversifié

Recommandations pour les défenseurs

• Implémenter l’authentification multi-facteurs (MFA) pour tous les accès distants et connexions cloud. Prioriser la méthode « push vérifiée » comme méthode MFA par rapport aux options moins sécurisées telles que les SMS ou les appels téléphoniques.
  
• Auditer la configuration VPN. Confirmer que les politiques VPN obsolètes sont supprimées et que les tentatives d’authentification ne correspondant pas à une politique VPN actuelle sont rejetées par défaut. Restreindre l’accès VPN uniquement aux segments de réseau et services nécessaires, limitant ainsi l’exposition des actifs critiques tels que les contrôleurs de domaine.
  
• Mettre en place des alertes pour tout changement dans les groupes privilégiés, comme la création de nouveaux groupes d’utilisateurs ou l’ajout de comptes aux administrateurs de domaine. Assurer que les privilèges administratifs sont accordés uniquement lorsque nécessaire et régulièrement audités par la suite. Une solution de Gestion des Accès Privilégiés (PAM) peut être utilisée pour rationaliser le contrôle et la surveillance des comptes privilégiés.
  
• Limiter ou désactiver l’utilisation de NTLM lorsque cela est possible et imposer des méthodes d’authentification plus sécurisées telles que Kerberos à la place. Limiter le taux de tentatives et d’échecs d’authentification sur les interfaces exposées publiquement et internes pour prévenir les scans d’authentification automatisés.
  
• Désactiver SMBv1 et imposer la signature et le cryptage SMB pour se protéger contre le mouvement latéral et la propagation de logiciels malveillants.
  
• Déployer des clients EDR sur tous les systèmes de l’environnement. Configurer un mot de passe administrateur sur les clients EDR pour prévenir la manipulation ou la suppression non autorisée du client.
  
• Désactiver les comptes fournisseurs et les capacités d’accès à distance lorsqu’ils ne sont pas activement utilisés.
  
• Créer des détections pour les modifications de configuration non autorisées qui pourraient être apportées sur divers systèmes de l’environnement, y compris les changements dans les politiques Windows Defender, les modifications non autorisées des Objets de Stratégie de Groupe, et la création de tâches planifiées et de services installés inhabituels.
  
• Développer et documenter les procédures de réinitialisation de mot de passe de l’entreprise pour garantir que toutes les informations d’identification des utilisateurs peuvent être réinitialisées rapidement et complètement. Inclure des procédures pour le renouvellement des tickets Kerberos critiques dans cette documentation.
  
• Renforcer et patcher les hôtes ESX pour réduire la surface d’attaque de ces serveurs critiques autant que possible et garantir que les vulnérabilités nouvellement découvertes sont corrigées aussi rapidement que possible.

Cartographie MITRE ATT&CK des Nouvelles TTP

IOCs

NOTE : Certains IOCs ont été retenus pour éviter l’identification potentielle des victimes.

RtCore64.sys – 01aa278b07b58dc46c84bd0b1b5c8e9ee4e62ea0bf7a695862444af32e87f1fd
DBUtil_2_3.sys – 0296e2ce999e67c76352613a718e11516fe1b0efc3ffdb8918fc999dd76a73a5
zamguard64.sys – 543991ca8d1c65113dff039b85ae3f9a87f503daec30f46929fd454bc57e5a91
gdrv.sys – 31f4cfb4c71da44120752721103a16512444c13c2ac2d857a7e6f13cb679b427