Des fuites de journaux de discussion internes révèlent une stratégie coordonnée dans laquelle Black Basta utilisent des certificats Extended Validation (EV) pour signer des fichiers malveillants. Cette tactique tire parti de la confiance accrue généralement associée aux applications signées EV. Les organisations qui s'appuient uniquement sur la confiance basée sur la signature deviennent vulnérables, car ces binaires certifiés échappent facilement aux mécanismes d'analyse conventionnels. Les conversations expliquent en détail comment les attaquants acquièrent, gèrent et automatisent le processus de contournement de la détection en signant des malware, ce qui souligne le degré de discipline organisationnelle qui sous-tend les opérations des groupes de ransomware.
Qu'est-ce qu'un certificat EV et comment Black Basta l'a-t-il obtenu ?
Les certificats Extended Validation (EV) sont des certificats numériques spéciaux qui témoignent d'un niveau élevé de confiance dans une application ou un site web. L'autorité de certification (AC) émettrice effectue des vérifications supplémentaires sur l'entreprise ou la personne qui demande le certificat, afin de s'assurer qu'elle est bien celle qu'elle prétend être. Dans la pratique, les utilisateurs et de nombreuses solutions de sécurité font davantage confiance aux logiciels signés EV parce qu'ils sont "vérifiés" par une autorité officielle..
Alors que certains cybercriminels sont connus pour usurper l'identité d'entreprises fermées, les journaux confirment que Black Basta n'a pas non plususurpé l'identité d'entreprises fermées:
1. Certificats EV achetés directement
BlackBasta a acheté des certificats EV pour 4 000 à 4 500 dollars sur des forums clandestins ou auprès de courtiers.
"по $4000 каждый" ("$4000 chacun")
"таких у нас еще не было" ("nous n'en avons jamais eu de pareils auparavant")
"сейчас возьму пару штук про запас" ("Je vais en prendre deux de plus au cas où")
"скидоссс))" ("j'ai eu une réduction haha")
Ces messages étaient généralement accompagnés de fichiers .rar contenant des certificats EV, souvent accompagnés de noms de sociétés (par exemple, EV56wallfort [SSL.com].rar, EV4Avikser-llc2023-10-27 [GlobalSign].rar).
Ils ont également établi des liens avec des plateformes d'hébergement telles que : https://send[.]exploit[.]in/download/... https://transfer[.]sh/... Ces plateformes hébergeaient les paquets de certificats volés/obtenus frauduleusement.
2. Infrastructures de signature à distance compromises
Le groupe a utilisé les outils VirtualHere et YubiKey Minidriver pour accéder à distance aux jetons EV qui étaient physiquement branchés sur des appareils compromis.
**"Vous avez besoin du Token17, double-cliquez pour vous connecter. Mot de passe : ******. Token PIN is 123456" "Exécutez certmgr.msc et vérifiez si le certificat a été ajouté" "Signez vos fichiers avec signtool.exe"
Lors d'un chat critique, un utilisateur déclare :
"я переезжаю с той рдп - она в блеках" "Je me retire de ce RDP - il est sur liste noire."
Il s'agit d'un serveur RDP qui hébergeait auparavant une infrastructure de signature sensible (probablement des jetons EV) et qui a été placé sur liste noire. Ces jetons sont généralement stockés sur du matériel (par exemple, YubiKeys), mais ils étaient accessibles et utilisés à distance via des outils tels que VirtualHere et signtool.exe, comme indiqué dans d'autres messages. Cela implique que le certificat EV n'a pas été acheté anonymement - il a été volé à une entreprise ou à un développeur réel, probablement par le biais d'une compromission RDP.
Les conversations de Black Basta qui ont fait l'objet d'une fuite identifient deux autorités de certification EV spécifiques (émetteurs) qui ont été utilisées de manière abusive pour la signature de malware : SSL.com et GlobalSign.
Le flux opérationnel de l'EV de Black Basta
Les fichiers MSI (Windows Installer) et VBS (Visual Basic scripts) ont été utilisés comme vecteurs d'infection initiale. Ces chargeurs déposaient ou lançaient la charge utile du malware (par exemple, ransomware, PikaBot, Cobalt Strike). En les signant à l'aide d'un certificat EV, les filtres de messagerie, les antivirus ou Windows SmartScreen ont moins de chances de les bloquer.
Une fois en possession des certificats EV, les attaquants :
- Les données utiles ne sont signées qu'après le cryptage afin d'éviter les erreurs de hachage.
- Ils se sont avertis mutuellement de ne pas modifier les fichiers après la signature, car cela invalide la signature EV.
- Il a utilisé ces certificats pour signer des installateurs PikaBot reconditionnés, des chargeurs MSI et VBS, ainsi que d'autres stubs de malware . Les conversations révèlent des instructions détaillées utilisées par les affiliés de Black Basta pour signer leurs malware à l'aide de certificats EV, qu'il s'agisse de certificats basés sur des fichiers .pfx ou de certificats EV basés sur des jetons matériels (par exemple, YubiKey). Vous trouverez ci-dessous la procédure de signature exacte extraite et l'utilisation de la ligne de commande :
Signature avec des certificats EV basés sur .pfx
Exigences en matière d'outillage
- Microsoft Windows SDK (fournissant signtool.exe)
- Fichier de certificat .pfx valide et mot de passe Exemple de script de signature (sign.cmd)
Exemple de script de signature (sign.cmd)
@echo off
set SIGNTOOL="C:\NProgram Files (x86)\NWindows Kits\N10bin\N10.0.22000.0\Nx64\Nsigntool.exe"
set CERT=cert.pfx
set PASSWORD=********
set FILE=calc.exe
set TIMESTAMP=http://timestamp.digicert.com
%SIGNTOOL%sign /f %CERT% /p %PASSWORD% /fd SHA256 /tr %TIMESTAMP% %FILE%Ce script garantit que le binaire est horodaté, ce qui empêche l'invalidation de la signature après l'expiration du certificat. Les attaquants ne signent qu'après le chiffrement afin de préserver l'intégrité de la signature. Tout changement de binaire après la signature invalide la marque EV.
Certificats EV basés sur des jetons matériels (YubiKey et VirtualHere)
Configuration de l'accès à distance
- Les attaquants installent VirtualHere à la fois sur le client et sur le serveur pour transférer la connexion du jeton USB à travers une session RDP.
- Le mini-pilote de carte à puce YubiKey est chargé sur la machine distante, ce qui permet à Windows de reconnaître le certificat dans certmgr.msc.
Commande de signature
signtool.exe sign /sha1 <certificate_thumbprint> /tr http://timestamp.digicert.com /td SHA256 /fd SHA256 <payload.exe>L'empreinte du certificat est obtenue via les propriétés du certificat Windows ou certmgr.msc. Les attaquants soulignent que l'ajustement du binaire après la signature détruit la validité de la signature EV, c'est pourquoi ils signent strictement en dernier.
Autres informations sur le processus de l'EV Black Basta
- Certains affiliés ont créé des scripts d'automatisation pour signer en masse plusieurs fichiers à l'aide de modèles sign.cmd prédéfinis.
- Les journaux de conversation indiquent que plusieurs certificats EV étaient stockés dans un référentiel central. Un événement documenté de "défaillance du stockage" a provoqué des troubles parce que "toutes nos clés" se trouvaient sur un seul SDV compromis.
- Les références à certaines archives (fichiers .rar) contenant des certificats EV (par exemple, EV56wallfort[SSL.com].rar) confirment la pratique du groupe consistant à conserver plusieurs certificats en vue d'une utilisation à la demande.
- Le groupe surveillait systématiquement les certificats révoqués et passait rapidement à un nouveau certificat EV en cas de détection ou lorsque l'autorité de signature bloquait le certificat volé connu.
Qu'est-ce que cela signifie pour votre entreprise ?
Lorsqu'malware se présente avec l'insigne d'une entreprise de confiance (via un certificat EV), c'est comme si un criminel portait un uniforme de police convaincant. De nombreux contrôles automatisés risquent de le laisser entrer. Cela érode la fiabilité des certificats numériques, rend plus difficile la détection des malware et peut entraîner des dommages très réels, comme le chiffrement des données d'une organisation par un ransomware ou le vol d'informations par des attaquants.
Si vos systèmes s'appuient uniquement sur des listes d'autorisation basées sur des signatures ou s'ils ne font confiance qu'à des codes signés EV, vous courez un risque. Les malware signés EV contournent initialement la plupart des contrôles conventionnels et le scepticisme des utilisateurs.
La stratégie des "socks bots" des attaquants complique également la détection ou le blocage basés sur l'IP. Même si un nœud est fermé, ils peuvent passer à un nouveau nœud proxy et maintenir une distribution continue.
Que devez-vous faire pour vous défendre contre les exploits des EV certs ?
Les certificats EV volés en possession des acteurs de la menace servent d'outil de camouflage puissant, améliorant le taux de réussite de leurs infections. Les journaux de discussion de Black Bastaconfirment un schéma récurrent : une fois que les seuils de détection augmentent pour une charge utile donnée, le groupe la modifie et la signe à nouveau avec un autre certificat EV, perpétuant ainsi un cycle de distribution de fichiers malveillants à haut volume. Cette approche systématique exploite les vulnérabilités dans la façon dont de nombreux contrôles de sécurité interprètent le code signé, ce qui rend crucial le déploiement de stratégies de défense plus avancées, axées sur le comportement.
Les outils qui vont au-delà de la signature et qui surveillent les comportements suspects constituent votre meilleure défense. Même si un fichier a une signature apparemment légitime, un produit comme Vectra AI Platform peut signaler des actions anormales au sein de votre réseau. En l 'associant à votre solution de détection et de réponse (EDR endpoint existante, vous pourrez isoler ou contenir rapidement les exécutables suspects et les empêcher de se propager, même s'ils sont signés EV.
Vous voulez voir Vectra AI en action ? Demandez une démonstration dès aujourd'hui!