Les pilotes malveillants signés montent dans la chaîne de confiance des logiciels

Alors qu’il investiguait une activité suspecte sur le réseau d’un client, Sophos X-Ops Rapid Response (RR) a découvert une paire de fichiers laissés sur certaines machines compromises. Les deux fichiers fonctionnaient ensemble pour mettre fin aux processus ou aux services utilisés par divers éditeurs de produits de sécurité endpoint.

Étant donné que l’équipe RR a réussi à expulser les attaquants des systèmes concernés, évitant ainsi d’autres dommages, il n’est pas possible de savoir avec certitude quel ransomware les attaquants avaient l’intention de déployer. Néanmoins, les techniques utilisées et les fichiers laissés sur place fournissent des informations intéressantes sur le groupe à l’origine de l’attaque.

Lors de notre analyse post-attaque, les SophosLabs ont déterminé que la paire de fichiers exécutables, à savoir un pilote Windows signé cryptographiquement (avec un certificat de signature légitime) et une application de type “chargeur” ​(loader) ​exécutable conçue pour installer le pilote, ont été utilisés ensemble lors d’une tentative infructueuse pour désactiver les outils de sécurité endpoint sur les machines ciblées.

Une analyse plus approfondie de l’application de chargement a fourni des preuves solides confirmant qu’il s’agissait bien d’une variante d’un malware nommé BURNTCIGAR par Mandiant. Des recherches antérieures menées par d’autres entreprises indiquent que les acteurs malveillants qui ont utilisé cet outil lors de précédentes attaques ont ensuite tenté de déployer un ransomware qui se fait appeler Cuba.

Sophos a signalé, de manière confidentielle, l’existence de tous les pilotes signés dans cette recherche à Microsoft qui a publié un avis dans le cadre de son Patch Tuesday régulier.

L’utilisation malveillante de pilotes en hausse

L’utilisation de pilotes de périphérique comme moyen de saboter ou de supprimer des outils de sécurité a augmenté en 2022. Certaines des précédentes attaques ont utilisé une approche “Bring Your Own Vulnerable Driver” (BYOVD), qui permet aux attaquants d’exploiter un pilote Windows d’un éditeur de logiciels légitime contenant des vulnérabilités de sécurité. Le ransomware Robinhood en 2020 et plus récemment le ransomware BlackByte ont été observés lors de deux attaques de type BYOVD. Les versions récentes du système d’exploitation exigent que les pilotes portent une signature cryptographique légitime afin de se charger correctement.

Le pilote récupéré lors de cette attaque ressemble beaucoup à celui utilisé lors d’une attaque précédemment documentée. Dans ce cas, le pilote a été signé numériquement à l’aide d’un certificat numérique NVIDIA volé (l’un des fichiers a été divulgué par des acteurs malveillants connus sous le nom de Lapsus$). Un autre pilote, étroitement lié, utilisé dans des attaques encore plus anciennes, avait été signé numériquement à l’aide de certificats d’une ou plusieurs sociétés chinoises à la réputation plutôt douteuse.

Les recherches menées par les SophosLabs indique que les acteurs malveillants gravissent l’échelle de la confiance, essayant d’utiliser de plus en plus des clés cryptographiques fiables pour signer numériquement leurs pilotes. Les signatures d’un éditeur de logiciels majeur et digne de confiance augmentent la probabilité que le pilote se charge dans Windows sans entrave, augmentant ainsi les chances que les attaquants, utilisant le ransomware Cuba, puissent mettre fin aux processus de sécurité protégeant les ordinateurs de leurs cibles.

Les attaques visant le noyau (kernel) peuvent désactiver de nombreux produits de sécurité

Dans la plupart des incidents de ransomware, les attaquants désactivent le logiciel de sécurité de la cible, via une étape préalable essentielle, avant de déployer le ransomware lui-même. Lors d’attaques récentes, certains acteurs malveillants se sont mis à utiliser des pilotes Windows pour désactiver les produits de sécurité.

Étant donné que les pilotes représentent un risque plutôt isolé pour la sécurité, Windows active l’application de la signature des pilotes (Driver Signature Enforcement) par défaut. La stratégie garantit que tous les pilotes en mode noyau doivent être signés pour être chargés. Si la politique est activée et que le pilote n’est pas signé, Windows ne chargera pas le pilote, il générera le code d’erreur 577 et affichera un message indiquant qu’il ne peut pas vérifier la signature numérique de ce fichier.

Pour contourner cette mesure de sécurité, les attaquants doivent utiliser un pilote signé, de préférence un pilote signé avec une clé actuellement valide provenant d’une source fiable. Il existe globalement deux manières d’y parvenir.

La plus facile des deux est l’attaque de type “Bring Your Own Vulnerable Driver” (BYOVD), au cours de laquelle les attaquants déploient des pilotes logiciels commerciaux légitimes qui présentent également des failles de sécurité. Cette méthode est plus facile car les attaquants n’ont pas besoin de créer le pilote à partir de zéro ou d’obtenir un certificat de signature de code préalablement divulgué : Ils leur suffit, tout simplement, d’abuser d’un pilote qui existe déjà, de préférence un pilote qui est passé par la certification Windows, signé par le certificat Microsoft Windows Hardware Compatibility Publisher (WHCP).

La méthode la plus difficile consiste pour les attaquants à trouver un moyen d’obtenir un pilote personnalisé, créé par (ou spécialement conçu pour) les attaquants, signé par un certificat de confiance. C’est justement la méthode qui a été utilisée par ces attaquants.

La plupart des attaques du pilote noyau sont généralement de type BYOVD. Dans des exemples récents, nous avons observé le ransomware BlackByte, qui utilisait un pilote d’overclocking de carte graphique vulnérable, et un autre auteur de ransomware qui abusait d’un pilote anti-triche (anti-cheat) vulnérable créé par l’éditeur de logiciels du jeu vidéo Genshin Impact.

Alors que les produits Sophos figuraient parmi les cibles du pilote, ce dernier n’a finalement pas réussi à les désactiver en raison des fonctionnalités antialtération de Sophos.

Le code signé est censé fournir une garantie

Microsoft comprend que les pilotes en mode noyau peuvent effectuer des opérations hautement privilégiées que les processus en mode utilisateur ne peuvent pas exploiter, réduisant ainsi potentiellement l’efficacité de certains produits anti-malware, de sécurité endpoint ou EDR. L’entreprise a donc créé un processus d’assurance qualité qui accorde son approbation uniquement aux logiciels que Microsoft peut examiner, et un système d’exploitation qui ne charge que les logiciels qui fournissent cette garantie.

Une signature de code cryptographique n’est pas simplement un onglet supplémentaire dans la feuille de propriétés du fichier. Son objectif est de confirmer un certain nombre de points : elle signifie principalement que le code appartient à la société nommée dans les données de signature de code, annexées au programme d’origine. C’est aussi une confirmation, à priori avec preuve à l’appui, que le programme est inchangé par rapport à ce qui a été présenté à la société de signature de code à une date et à une heure bien précises.

Les signatures numériques indiquent également un degré de sécurité et de confiance.

Les entités de signature de code telles que Microsoft peuvent également éliminer les pilotes malveillants, en utilisant diverses méthodes pour examiner les pilotes soumis à signature.

Windows vérifie la validité des signatures des pilotes avant de permettre à ces derniers de se charger sans entrave. En tant que mesure d’intégrité du code, Microsoft maintient une liste de blocage qui, lorsque l’entreprise y ajoute un pilote, “révoque [le pilote] au niveau du noyau Windows concernant les mises à jour de sécurité les plus récentes”, a expliqué un porte-parole du MSRC de Microsoft. Les pilotes révoqués de cette manière “ne seront plus approuvés par la plateforme Windows et leur exécution sera bloquée”.

Windows traite également certains logiciels plus anciens, comme les pilotes qui ont ensuite été abusés dans des attaques de type BYOVD, mais avec une signature qui était valable au début. Tout pilote au-delà de sa durée de vie peut contenir des vulnérabilités exploitables, mais Microsoft ne les recherche pas parmi les millions de pilotes tiers ayant expiré et qui existent encore. Un certificat (ou un pilote) n’est révoqué que lorsqu’une personne a remarqué un malware signé par ce dernier (ou le pilote lui-même) et a alerté Microsoft.

Ainsi, alors que les attaquants peuvent placer ce fichier de pilote sur le disque dur et créer un service associé pour le charger, Windows générera des erreurs si le pilote n’est pas signé ou est signé par un certificat révoqué.

Résultat : il est beaucoup plus difficile de faire passer le fichier au-delà de ces contrôles d’intégrité imposés par les signataires du code et d’obtenir un fichier légitimement signé, que de créer, dès le départ, le pilote malveillant sur mesure.

Bien qu’il ne fasse aucun doute que la divulgation du certificat de signature de NVIDIA ait conduit à l’utilisation de ce certificat désormais révoqué pour signer une version du pilote, le créateur du malware a réussi à faire signer d’autres versions du pilote par les autorités de signature de code pour Microsoft et d’autres éditeurs de logiciels.

L’analyse des traces laissées après le passage de BURNTCIGAR

Les fichiers exécutables récupérés suite à cette attaque comprenaient un fichier .exe (nous l’appelons le “chargeur (loader) “) et un fichier .sys (le pilote). En recherchant des pilotes associés dans des référentiels publics, nous avons également découvert une archive contenant à la fois le pilote et le chargeur, ainsi qu’un fichier texte contenant une liste de 186 noms de fichier de programmes utilisés par un grand nombre de packages logiciels de sécurité endpoint et EDR, probablement une liste de processus à cibler. Aucun fichier texte de ce type n’a été récupéré lors de l’incident que nous avons investigué.

Lorsqu’il est exécuté, le chargeur copie le pilote dans %temp%, en lui donnant un nom de fichier de cinq à sept caractères, puis crée une entrée de service pour le pilote (dans ce cas, nommé mEfEk.sys) en exécutant une commande :

Ensuite, le chargeur démarre le service :

Ce processus apparait dans un sous-programme extrait du chargeur après rétro-ingénierie, et est illustré ci-dessous.

Chargeur BURNTCIGAR créant et démarrant un service pour installer le pilote

Cette application fonctionne en collaboration avec le pilote pour ‘tuer’ tout service ou processus nommé comme l’un de ceux répertoriés dans le fichier en clair. 29 des noms de la liste concernent Sophos.

Les processus dont l’exécution tente d’être bloquée par le malware

Le pilote et le chargeur interagissent en accédant à un lien symbolique nommé “\\\\.\\KApcHelperLink1“. Le programme contient au moins deux codes IOCTL hardcodés, 0x222088 et 0x222094, utilisés pour interagir avec le pilote. Le chargeur utilise le code IOCTL 0x222094 pour transmettre le nom du processus et indiquer au pilote de tuer un processus.

La figure ci-dessous montre la fonction décompilée chargée d’interagir avec le pilote. Le chargeur BURNTCIGAR récupère d’abord un handle vers  \\\.\\KApcHelperLink1, puis il communique avec le pilote via DeviceIoControl. Le code IOCTL est passé en paramètre de la fonction. Cette chaîne “KApcHelper” distincte est apparue dans les chemins de construction (build paths) de certains des pilotes qui n’étaient pas fournis avec VMprotect. L’un des échantillons que nous avons trouvés avait été uploadé sur VirusTotal et s’appelait KApcHelper_x64.sys.

BURNTCIGAR bloque un processus

En février 2022, Mandiant a écrit que BURNTCIGAR était “un utilitaire… qui mettait fin aux processus associés aux logiciels de sécurité endpoint pour permettre à leurs ransomwares et autres outils de s’exécuter sans entrave”. Mandiant a signalé, à l’époque, que les adversaires contournaient la sécurité sur les systèmes ciblés, en utilisant un pilote légitime mais vulnérable (publié à l’origine par l’éditeur d’antivirus Avast) comme dans une approche de type BYOVD.

En août 2022, Palo Alto Networks (PAN) a remarqué un changement de tactique. Plus précisément, PAN a écrit que “le changement de tactique de Tropical Scorpius (alias UNC2596, alias” les attaquants Cuba “) consiste à utiliser, maintenant, le certificat NVIDIA légitime expiré, ainsi que leur propre pilote ciblant les produits de sécurité qu’ils souhaitent désactiver”. Au lieu du pilote Avast vulnérable, BURNTCIGAR installait maintenant le pilote ApcHelper.sys signé avec un certificat NVIDIA révoqué et divulgué.

• La rétro-chasse (retrohunt) menée par les SophosLabs pour trouver les codes des pilotes correspondant à ceux des fichiers que nous avons analysés a également révélé au moins trois variantes du pilote signées par des certificats de signature de code appartenant à des sociétés basées en Chine, et observées pour la première fois entre juillet et septembre. Dans l’un des trois cas observés, l’autorité de signature de code a révoqué le certificat utilisé pour signer le pilote.

Le certificat utilisé pour signer les deux autres n’a pas été révoqué, mais il appartient à un éditeur de logiciels prolifique que Sophos signale comme une “PUA”, ou application potentiellement indésirable (Potentially Unwanted Application). Les PUA se situent dans un entredeux plutôt flou, entre les logiciels légitimes et les malwares. Les produits Sophos détecteront tout ce qui est signé par le certificat de cet éditeur comme une PUA et empêcheront son exécution ou son installation. Sur les 41 programmes signés avec la clé de cet éditeur et uploadés au cours des 90 derniers jours sur VirusTotal, un seul n’a pas été détecté par les produits anti-malware ; 38 d’entre eux ont été classés comme malwares ou logiciels PUA par 10 sociétés de sécurité ou plus.

L’équipe derrière BURNTCIGAR a une fois de plus changé de tactique, passant de la signature de leur pilote AV-killer avec des certificats volés, à des certificats valides d’origine douteuse, puis à des certificats légitimes ayant une bonne réputation.

Liste des pilotes trouvés

Table : La liste des pilotes, triés par date d’uploading sur VirusTotal, avec leur signataire de code

Deux des pilotes que nous avons observés étaient signés avec des certificats numériques d’une société chinoise, Zhuhai Liancheng Technology Co., Ltd. Un pilote signé avec cette clé a été utilisé le 27 juillet 2022, le plus ancien de ce lot. Le certificat Zhuhai Liancheng Technology (ZLT) est différent car Sophos détecte tout fichier signé avec ce certificat comme une PUA.

En août, trois échantillons signés avec WHCP ont été uploadés sur VirusTotal à quelques semaines d’intervalle.

Le mois suivant, les attaquants ont utilisé un pilote signé avec le certificat NVIDIA divulgué et révoqué le 20 septembre, puis un pilote signé par un certificat de Beijing JoinHope Image Technology, Ltd. (alias JHI) quatre jours plus tard. Six jours après l’utilisation du pilote signé JHI, une personne a uploadé une autre version du pilote sur VirusTotal, à nouveau signée par ZLT. Notre télémétrie indique que ce même pilote a été utilisé lors d’une attaque qui a eu lieu le 21 octobre 2022, près d’un mois après avoir été uploadé pour la première fois.

Quatre pilotes différents ont été uploadés en octobre, tous signés avec le certificat WHCP.

Toutes les variantes de pilote trouvées lors de la chasse utilisent le même nom de lien symbolique, KApcHelperLink1, que le pilote trouvé dans notre incident. Les pilotes partagent également d’autres caractéristiques, telles que les plages de validité de la signature du code. Fait intéressant, tous les pilotes signés avec le certificat WHCP ont été compressés avec le packer VMProtect.

Un packer peut dissimuler un code de pilote malveillant

VMProtect est un packer d’exécution (runtime) commercial qui protège les logiciels contre la rétro-ingénierie grâce à de nombreuses techniques d’obfuscation. Bien que les packers soient utilisés de manière légitime dans les logiciels commerciaux, les exécutables de malware utilisent généralement des packers (à la fois des packers commerciaux légitimes et des packers créés spécifiquement pour les malwares) pour compliquer l’analyse. Les packers sont moins couramment utilisés dans les pilotes.

La signature du pilote

Grâce à une combinaison d’analyses statiques et dynamiques du chargeur et du pilote, nous avons pu extraire plusieurs artefacts techniques qui nous ont permis de chasser des variantes potentielles non compressées du pilote, ainsi que des versions similaires de BURNTCIGAR.

Nous avons installé le pilote sur notre système d’analyse et confirmé que le pilote a crée un lien symbolique (nommé “KApcHelperLink1”) vers le périphérique \device\KApcHelper1.

Si le nom du lien symbolique vous semble familier, c’est parce qu’il est assez proche du nom du module pilote investigué par Unit42 de PAN : ApcHelper.sys. En modifiant nos recherches pour qu’elles excluent ces termes, nous avons trouvé onze pilotes au total, signés par quatre clés de signature différentes. Le premier échantillon connu (jusqu’à présent) de pilote signé par Microsoft a été uploadé sur VirusTotal le 9 août.

Analyse du chargeur BURNTCIGAR

Dans cette capture d’écran de notre analyse du flux de code de allx7_64.exe, à savoir la variante du chargeur BURNTCIGAR que nous avons trouvée sur VirusTotal, le chargeur utilise le même code IOCTL (ainsi que le même nom de lien symbolique).

Structure de code similaire de la variante BURNTCIGAR trouvée sur VirusTotal

Dans cette capture d’écran du code de pilote décompilé, tiré du dernier pilote signé par Zhuhai Liancheng Technology Co. Ltd., la routine crée le périphérique \\device\\KApcHelper1 et le lie symboliquement à \\dosdevices\\KApcHelperLink1, le même nom de lien symbolique, utilisé par la variante BURNTCIGAR dans l’incident que nous avons investigué, pour communiquer avec le pilote.

Variante de pilote utilisant le même nom de lien symbolique et le même nom de périphérique que le pilote utilisé dans notre incident

Conclusion

Nous avons trouvé plusieurs similitudes convaincantes entre le pilote de ce dernier incident et des échantillons antérieurs référencés dans les rapports de PAN et Mandiant, ainsi que des échantillons supplémentaires trouvés grâce à des rétro-chasses (retrohunts) sur VirusTotal :

• La convention d’appellation des pilotes ainsi que les noms des liens symboliques installés sont identiques ou similaires. Dans le rapport de PAN, le pilote s’appelle ApcHelper.sys. Le pilote utilisé dans notre incident s’appelle KApcHelper.sys. Jusqu’à présent, nous n’avons trouvé aucun faux positif potentiel grâce à l’examen de la télémétrie.
• Notre incident et l’incident du rapport de PAN sont tous deux liés au ransomware Cuba, avec une fiabilité forte.
• Bien que tous les exemples n’aient pas les mêmes métadonnées au niveau du fichier PE, nous avons remarqué que le pilote signé Microsoft de l’incident que nous avons analysé (SHA256) : 8e035beb02a411f8a9e92d4cf184ad34f52bbd0a81a50c222cdd4706e4e45104) partage le même horodatage de l’en-tête PE (2022:06:02 10:09:08+00:00) que les pilotes signés par Zhuhai Liancheng Technology Co., Ltd. (ZLT) et le pilote Beijing JHI.

Lors d’incidents que Sophos a investigués, des acteurs malveillants liés au ransomware Cuba ont utilisé l’utilitaire de chargement BURNTCIGAR pour installer un pilote malveillant signé à l’aide du certificat de Microsoft. Les données de signature intégrées dans ces pilotes signés partageaient les caractéristiques communes suivantes :

• Les champs “Valid From” et “Valid To” du certificat WHCP :

Valid From: 2022-06-07 18:08:06
Valid To: 2023-06-01 18:08:06

• Le champ “Valid Usage” :

Valid Usage WHQL Crypto, 1.3.6.1.4.1.311.10.3.5.1, Code Signing

• Le certificat WHCP utilisé pour signer le pilote a été émis par une autorité appelée Microsoft Windows Third Party Component CA 2014, avec les champs “Valid To” et “Valid From” :

Valid From  2014-10-15 20:31:27
Valid To    2029-10-15 20:41:27

Sophos détecte le pilote malveillant sous le nom Troj/Agent-BJJB, Mal/Rootkit-VC ou Mal/Rootkit-VF, et le chargeur malveillant sous le nom Troj/AVKill-Q. Les indicateurs de compromission des fichiers liés à cette investigation ont été partagés avant leur publication avec Microsoft, pour les aider à se protéger, et ont été publiés sur le Github des SophosLabs.

Pour obtenir plus d’informations, il existe des recherches complémentaires menées par Mandiant et SentinelOne à partir de leurs investigations parallèles indépendantes.

Remerciements

Sophos X-Ops remercie les contributions, lors de l’analyse, des experts de l’équipe Rapid Response : Sergio Bestulic, Harinder Bhathal, Matthew Everts, Johnathan Fern, Jason Jenkins, Melissa Kelly, Elida Leite, Stephen McNally, Duke Thornley, Rajat Wason, Robert Weiland et Carlos Zena ; et les chercheurs des SophosLabs Richard Cohen, Andreas Klopsch, Prashant Kumar, Andrew Ludgate, Nathan Mante, Rajesh Nataraj, Simon Porter, Felix Weyne et Michael Wood. Sophos remercie également Microsoft d’avoir rapidement collaboré avec leurs équipes pour aider à protéger les utilisateurs d’ordinateur.

Billet inspiré de Signed driver malware moves up the software trust chain, sur le Blog Sophos.