Les menaces UEFI se déplacent vers l'ESP avec le bootkit ESPecter

Les chercheurs d'ESET analysent un bootkit UEFI précédemment non documenté et réel qui persiste sur la partition système EFI (ESP). Le bootkit, que nous avons nommé ESPecter, peut contourner l'application de la signature des pilotes de Windows pour charger son propre pilote non signé, ce qui facilite ses activités d'espionnage. Outre la découverte récente par Kaspersky du bookit FinSpy, qui n'a rien à voir avec ce dernier, on peut désormais affirmer que les menaces UEFI réelles ne se limitent plus aux implants flash SPI, comme ceux utilisés par Lojax.

L'époque où l'UEFI (Unified Extensible Firmware Interface) vivait dans l'ombre des anciens BIOS est définitivement révolue. En tant que technologie de pointe intégrée dans les puces des ordinateurs et des appareils modernes, elle joue un rôle crucial dans la sécurisation de l'environnement pré-OS et le chargement du système d'exploitation. Et il n'est pas surprenant qu'une technologie aussi répandue soit également devenue une cible tentante pour les acteurs de la menace dans leur quête de persistance ultime.Ces dernières années, nous avons vu des exemples de preuves de concept de bootkits UEFI (DreamBoot, EfiGuard), de documents ayant fait l'objet de fuites (DerStarke, QuarkMatter) et même de code source ayant fait l'objet de fuites (Hacking Team Vector EDK), suggérant l'existence de véritables logiciels malveillants UEFI sous la forme d'implants flash SPI ou d'implants ESP. Malgré tout ce qui précède, seuls trois cas réels de logiciel malveillant UEFI ont été découverts jusqu'à présent (LoJax, découvert par notre équipe en 2018, MosaicRegressor, découvert par Kaspersky en 2019, et plus récemment le bootkit FinSpy, dont l'analyse vient d'être publiée par Kaspersky). Si les deux premiers appartiennent à la catégorie des implants flash SPI, le dernier appartient à la catégorie des implants ESP, et étonnamment, il n'y est pas seul.

Aujourd'hui, nous décrivons notre récente découverte d'ESPecter, qui n'est que le deuxième cas réel d'un bootkit UEFI persistant sur l'ESP sous la forme d'un gestionnaire de démarrage Windows patché à analyser. ESPecter a été rencontré sur une machine compromise avec un composant client en mode utilisateur doté de fonctionnalités de keylogging et de vol de documents, ce qui explique pourquoi nous pensons qu'ESPecter est principalement utilisé pour l'espionnage. Il est intéressant de noter que les racines de cette menace remontent au moins à 2012, et qu'elle fonctionnait auparavant comme un kit de démarrage pour les systèmes dotés d'anciens BIOS. Malgré la longue existence d'ESPecter, ses opérations et sa mise à niveau vers UEFI sont passées inaperçues et n'ont pas été documentées jusqu'à présent. Notez que la seule similitude entre ESPecter et la découverte de Kaspersky FinSpy est qu'ils partagent l'approche de compromission du gestionnaire de démarrage UEFI.

Figure 1. Comparaison du flux de démarrage hérité (à gauche) et du flux de démarrage UEFI (à droite) sur les systèmes Windows (Vista et plus récents)

En appliquant un correctif au gestionnaire d'amorçage de Windows, les attaquants parviennent à l'exécution dans les premières étapes du processus d'amorçage du système (voir Figure 1), avant que le système d'exploitation ne soit entièrement chargé. Cela permet à ESPecter de contourner la fonction DSE (Driver Signature Enforcement) de Windows afin d'exécuter son propre pilote non signé au démarrage du système. Ce pilote injecte ensuite d'autres composants en mode utilisateur dans des processus système spécifiques afin de lancer la communication avec le serveur C&C d'ESPecter et de permettre à l'attaquant de prendre le contrôle de la machine compromise en téléchargeant et en exécutant des logiciels malveillants supplémentaires ou en exécutant des commandes C&C.

Même si Secure Boot empêche l'exécution de binaires UEFI non fiables à partir de l'ESP, ces dernières années, nous avons été témoins de diverses vulnérabilités du micrologiciel UEFI affectant des milliers de dispositifs et permettant de désactiver ou de contourner Secure Boot (par exemple VU#758382, VU#976132, VU#631788, etc.). Cela montre que la sécurisation du firmware UEFI est une tâche difficile et que la manière dont les différents fournisseurs appliquent les politiques de sécurité et utilisent les services UEFI n'est pas toujours idéale.

Auparavant, nous avons signalé plusieurs échantillons EFI malveillants sous la forme d'applications UEFI simples, à usage unique et sans fonctionnalité étendue. Ces observations, ainsi que la découverte simultanée des bootkits ESPecter et FinFisher, deux bootkits UEFI entièrement fonctionnels, montrent que les acteurs de la menace ne s'appuient pas uniquement sur les implants de micrologiciels UEFI lorsqu'il s'agit de la persistance du pré-système d'exploitation, mais qu'ils tentent également de tirer parti de la désactivation de Secure Boot pour exécuter leurs propres implants ESP.

Nous n'avons pas été en mesure d'attribuer ESPecter à un acteur connu, mais les messages de débogage en chinois dans le composant client en mode utilisateur associé (comme le montre la Figure 2) nous incitent à penser, avec un faible degré de confiance, qu'un acteur inconnu parlant chinois est derrière ESPecter. À ce stade, nous ne savons pas comment il a été distribué.

Figure 2. Exemple de messages de débogage en chinois dans le composant client en mode utilisateur

Évolution du bootkit ESPecter

En examinant notre télémétrie, nous avons pu dater les débuts de ce bootkit au moins en 2012. À ses débuts, il utilisait la modification du MBR (Master Boot Record) comme méthode de persistance et ses auteurs ajoutaient continuellement la prise en charge des nouvelles versions du système d'exploitation Windows. Ce qui est intéressant, c'est que les composants du logiciel malveillant ont à peine changé pendant toutes ces années et que les différences entre les versions 2012 et 2020 ne sont pas aussi importantes qu'on pourrait le penser.

Après toutes ces années de changements insignifiants, ceux qui se cachent derrière ESPecter ont apparemment décidé de faire passer leur logiciel malveillant des anciens systèmes BIOS aux systèmes modernes UEFI. Ils ont décidé d'y parvenir en modifiant un binaire légitime du gestionnaire de démarrage de Windows (bootmgfw.efi) situé sur l'ESP tout en prenant en charge plusieurs versions de Windows allant de Windows 7 à Windows 10 inclus. Comme nous l'avons mentionné précédemment, cette méthode présente un inconvénient : elle nécessite la désactivation de la fonction Secure Boot afin de pouvoir démarrer avec un gestionnaire de démarrage modifié. Toutefois, il convient de mentionner que la première version de Windows prenant en charge Secure Boot était Windows 8, ce qui signifie que toutes les versions précédentes sont vulnérables à cette méthode de persistance.

Pour les versions de Windows OS qui prennent en charge Secure Boot, l'attaquant devra le désactiver. Pour l'instant, on ne sait pas comment les opérateurs d'ESPecter y sont parvenus, mais quelques scénarios sont possibles :

• L'attaquant a un accès physique à l'appareil (historiquement connu sous le nom d'attaque "evil maid") et désactive manuellement Secure Boot dans le menu de configuration du BIOS (il est courant que le menu de configuration du micrologiciel soit encore étiqueté et appelé "menu de configuration du BIOS", même sur les systèmes UEFI).
• Secure Boot était déjà désactivé sur la machine compromise (par exemple, l'utilisateur peut faire un double démarrage de Windows et d'autres systèmes d'exploitation qui ne prennent pas en charge Secure Boot).
• Exploitation d'une vulnérabilité inconnue du firmware UEFI qui permet de désactiver Secure Boot.
• Exploitation d'une vulnérabilité connue du micrologiciel UEFI dans le cas d'une version obsolète du micrologiciel ou d'un produit qui n'est plus pris en charge.

Analyse technique

Au cours de notre enquête, nous avons découvert plusieurs composants malveillants liés à ESPecter :

• Des installateurs, uniquement pour les anciennes versions MBR du bootkit, dont le but était de mettre en place une persistance sur la machine en réécrivant le MBR du périphérique de démarrage.
• Code de démarrage sous la forme soit d'un gestionnaire de démarrage Windows modifié (bootmgfw.efi) sur les systèmes UEFI, soit d'un MBR malveillant dans le cas des systèmes Legacy Boot.
• Un pilote en mode noyau utilisé pour préparer l'environnement pour les charges utiles en mode utilisateur et pour les charger dans les premières étapes du démarrage du système d'exploitation en les injectant dans des processus système spécifiques.
• Des charges utiles en mode utilisateur responsables de la communication avec le C&C, de la mise à jour de la configuration du C&C et de l'exécution des commandes du C&C.

Pour le schéma complet de l'infection du bootkit ESPecter, voir la Figure 3.

Figure 3. Composants du bootkit ESPecter

Obtention de la persistance - Démarrage UEFI

Sur les systèmes utilisant le mode de démarrage UEFI, la persistance de l'ESPecter est établie en modifiant le gestionnaire de démarrage Windows bootmgfw.efi et le binaire du chargeur de démarrage de secours bootx64.efi, qui sont généralement situés dans les répertoires \EFI\Microsoft\Boot\ et \EFI\Boot\, respectivement. La modification du chargeur de démarrage comprend l'ajout d'une nouvelle section appelée .efi au PE et le changement de l'adresse du point d'entrée de l'exécutable afin que le flux du programme saute au début de la section ajoutée, comme le montre la Figure 4.

Figure 4. Comparaison du gestionnaire de démarrage Windows original (en haut) et modifié (en bas) (bootmgfw.efi)

Chaîne de démarrage simplifiée

Comme le montre le schéma de gauche de la Figure 5, le processus de démarrage sur les systèmes UEFI (sans tenir compte de la partie microprogramme) commence par l'exécution de l'application bootloader située dans l'ESP. Pour le système d'exploitation Windows, il s'agit du binaire Windows Boot Manager (bootmgfw.efi), dont le but est de trouver un système d'exploitation installé et de transférer l'exécution à son chargeur de noyau - winload.efi. Comme le gestionnaire d'amorçage, le chargeur de noyau du système d’opération est responsable du chargement et de l'exécution du composant suivant de la chaîne d'amorçage : le noyau Windows (ntoskrnl.exe).

Figure 5. Flux de démarrage typique de Windows UEFI (à gauche) comparé au flux de démarrage modifié par ESPecter (à droite)

Comment ESPecter modifie-t-il le processus d'amorçage UEFI ?

Pour réussir à déposer sa charge utile malveillante, ESPecter doit contourner les contrôles d'intégrité effectués par le gestionnaire d'amorçage Windows et le noyau Windows au cours du processus d'amorçage. Pour ce faire, il recherche des modèles d'octets identifiant les fonctions souhaitées en mémoire et les modifie en conséquence.

En commençant par le chargeur de démarrage, dans notre cas le gestionnaire de démarrage Windows (bootmgfw.efi), le kit de démarrage commence par patcher la fonction BmFwVerifySelfIntegrity . Cette fonction est responsable de la vérification de la signature numérique du gestionnaire de démarrage et a pour but d'empêcher l'exécution d'un gestionnaire de démarrage modifié. Dans la Figure 6, vous pouvez voir comment ESPecter recherche BmFwVerifySelfIntegrity dans la mémoire en utilisant différents modèles d'octets (pour prendre en charge de nombreuses versions de bootmgfw.efi) et en modifiant les paramètres de la fonction de façon à ce qu’elle donne toujours zero, ce qui indique que la vérification a été un succès.

Comme mentionné précédemment, le but principal du bootloader est de trouver un système d'exploitation installé et de transférer l'exécution à son chargeur de noyau d'OS. Pour le gestionnaire d'amorçage Windows, cela se produit dans la fonction Archpx64TransferTo64BitApplicationAsm. Par conséquent, ESPecter recherche cette fonction afin d'attraper le moment où le chargeur du système d'exploitation est chargé en mémoire, mais n'a toujours pas été exécuté. S'il la trouve, ESPecter patche cette fonction pour insérer sa propre fonction de détour, qui peut facilement modifier le chargeur d'OS chargé en mémoire au bon moment.

Figure 6. Code décompilé Hex-Rays - recherche et correction de la fonction BmFwVerifySelfIntegrity

La modification du chargeur d'OS n'inclut pas la correction des contrôles d'intégrité ou d'autres fonctionnalités. À ce stade, il est important pour le kit d'amorçage de réallouer son code, car en tant qu'application UEFI, il sera déchargé de la mémoire après être revenu de sa fonction de point d'entrée. À cette fin, il utilise la fonction BlImgAllocateImageBuffer ou BlMmAllocateVirtualPages (selon le modèle trouvé). Après cette réallocation, le bootkit insère un détour (situé dans le tampon précédemment alloué) vers la fonction responsable du transfert de l'exécution vers le noyau de l'OS - OslArchTransferToKernel - afin de pouvoir patcher le noyau Windows en mémoire, une fois celui-ci chargé mais avant son exécution. La dernière étape du code de démarrage du bootkit est responsable de la désactivation de DSE en patchant la fonction noyau SepInitializeCodeIntegrity (voir la Figure 7 pour plus de détails).

Figure 7. Comparaison de la fonction SepInitializeCodeIntegritydécompilée par Hex-Rays avant (à gauche) et après (à droite) qu'elle soit corrigée en mémoire

Fait à noter : le code de démarrage corrige également la fonction du kernel MiComputeDriverProtection. Même si cette fonction n'affecte pas directement la réussite du chargement du pilote malveillant, le bootkit ne procède pas à l'abandon du pilote s'il ne trouve pas et ne corrige pas cette fonction dans la mémoire du noyau. Nous n'avons pas été en mesure d'identifier l'objectif de ce second patch, mais nous supposons que cette fonction modifiée peut être utilisée par d'autres composants d'ESPecter, encore inconnus.

• \SystemRoot\System32\null.sys (pilote)
• \SystemRoot\Temp\syslog (configuration chiffrée)

La configuration qui est utilisée par WinSys.dll est déployée par le pilote du noyau et consiste en une clé XOR d'un octet suivie des données de configuration chiffrées. Pour déchiffrer la configuration, il faut utiliser WinSys.dll :

1. Base64 décode les données de configuration
2. XORs les données grâce à la clé XOR
3. Base64 décode chaque valeur délimitée séparément par “|”.

Un exemple de configuration déposée par la version EFI d'ESPecter est présenté à la figure 8. Une liste complète des adresses IP et des domaines des configurations intégrées dans les échantillons de bootkit ESPecter que nous avons découverts (versions Legacy Boot et UEFI) est incluse dans la section Indicateurs de compromission (IoCs).

Figure 8. Déchiffrement de la configuration fournie par la version EFI du bootkit ESPecter

Obtenir la persistance - Legacy Boot

Comme nous l'avons déjà mentionné, il existe des versions d'ESPecter prenant en charge les modes UEFI et d'autres prenant en charge le mode Legacy Boot. Dans le cas du mode Legacy Boot, la persistance est obtenue par la technique bien connue qui consiste à modifier le code MBR situé dans le premier secteur physique du disque dur; nous ne l'expliquerons donc pas en détail ici, mais nous nous contenterons de la résumer.

Comment ESPecter modifie-t-il le processus de Legacy Boot?

Le MBR malveillant déchiffre d'abord le code précédemment copié dans les secteurs 2, 3 et 4 du disque par l'installateur, accroche le gestionnaire d'interruption INT13h en mode réel (services de lecture-écriture du secteur du BIOS), puis passe l'exécution au code MBR d'origine, sauvegardé dans le deuxième secteur (secteur 1) par l'installateur. Comme pour les autres bootkits MBR connus, lorsque le gestionnaire d'interruption INT13h est invoqué, le code hook (situé dans le secteur 0) vérifie que les services 0x02 (Lecture du secteur du pilote) et 0x42 (Lecture étendue du secteur du pilote) sont gérés afin d'intercepter le chargement de bootmgr - la version héritée du gestionnaire d'amorçage de Windows. Notez que les versions héritées d'ESPecter n'ont pas besoin de patcher la fonction BmFwVerifySelfIntegrity dans bootmgr, car le binaire de bootmgr n'a été modifié en aucune façon.

À partir de là, la fonctionnalité du code de démarrage est presque la même que dans la version UEFI, ce qui entraîne le dépôt du pilote malveillant (situé de manière contiguë sur la piste 0, à partir du secteur 6) dans l'un des emplacements suivants, selon l'architecture :

• \SystemRoot\System32\drivers\beep.sys (x86)
• \SystemRoot\System32\drivers\null.sys (x64)

Dans ce cas, la configuration chiffrée n'est pas déposée dans le fichier syslog mais reste cachée dans le secteur 5 du disque infecté.

Figure 9. Schéma de disque modifié utilisé par l'ancienne version d'ESPecter

Pilote en mode noyau (kernel-mode)

L'objectif principal du pilote est de charger des charges utiles en mode utilisateur, de configurer le keylogger et, finalement, de se supprimer. La configuration du keylogger se fait en deux étapes :

• Tout d'abord, il crée un périphérique nommé \Device\WebBK qui expose une fonction traitant les demandes IRP_MJ_DEVICE_CONTROL des composants du mode utilisateur. Cette fonction supporte un code IOCTL (Input/Output Control) (0x22C004), qui peut être utilisé pour déclencher l'enregistrement d'une routine d'appel de procédure asynchrone chargée de traiter les frappes clavier interceptées.
• L'interception des frappes au clavier se fait par la mise en place de CompletionRoutine pour les requêtes IRP_MJ_READ du pilote de clavier objet \Device\KeyboardClass0.

Une fois cette étape franchie, tout processus peut commencer à enregistrer les frappes interceptées en définissant sa propre routine et en la transmettant à l'objet périphérique créé à l'aide de l'IOCTL 0x22C004 personnalisé.

Par défaut, le pilote tente de charger deux charges utiles de base - WinSys.dll et Client.dll - qui ont la possibilité de télécharger et d'exécuter des charges utiles supplémentaires. La première, WinSys.dll, est une DLL packagée par MPRESS et intégrée au binaire du pilote sous une forme chiffrée. La seconde, Client.dll, est téléchargée par WinSys.dll dans le fichier \SystemRoot\Temp\memlog, également sous forme chiffrée, en utilisant la même méthode de chiffrement - un simple XOR d'un octet avec soustraction - mais pas les mêmes clés. Les deux répertoires sont déchiffrés et déposées dans le répertoire système \SystemRoot\System32\ par le pilote.

L'exécution des bibliothèques WinSys.dll et Client.dll est réalisée en les injectant respectivement dans svchost.exe et winlogon.exe. Pour ce faire, le pilote enregistre la routine de rappel de chargement d'image NotifyRoutine à l'aide de PsSetLoadImageNotifyRoutine, qui est utilisée pour exécuter :

• L'export MainThread de Client.dll, dans le contexte du processus winlogon.exe.
• L'export MainThreadde de WinSys.dll, dans le contexte du processus svchost.exe.

NotifyRoutine crochète le point d'entrée des images des processus winlogon.exe et svchost.exe en mémoire avant d'être exécuté. Ce hook est par la suite chargé de charger et d'exécuter la DLL de charge utile appropriée. Comme le montre la Figure 10, seule la première image svchost.exe ou winlogon.exe chargée est traitée par la routine.

Figure 10. NotifyRoutine décompilée par Hex-Rays vérifiant si svchost.exe ou winlogon.exe est en cours de chargement.

Composants en mode utilisateur - WinSys.dll

WinSys.dll agit comme un agent de mise à jour de base, qui contacte périodiquement son serveur C&C afin de télécharger ou d'exécuter des charges utiles supplémentaires ou d'exécuter des commandes simples. L'adresse du C&C, ainsi que d'autres valeurs comme l'ID de la campagne, la version du bootkit, le temps entre les tentatives de communication avec le C&C et la plage d'heures actives, se trouvent dans la configuration, qui peut être chargée à partir :

• de la valeur DefaultConfig dans le registre HKLM\SYSTEM\CurrentControlSet\Control
• du fichier \SystemRoot\Temp\syslog
• ou directement à partir d'un secteur spécifique du disque (dans la version Legacy Boot).

S'il existe à la fois des configurations stockées dans le registre et sur le disque, c'est celle du registre qui est utilisée.

Communication C&C

WinSys.dll communique avec son C&C en utilisant HTTPS et la communication est initiée par l'envoi d'une requête HTTP GET utilisant le format d'URL suivant :

https://<ip>/Heart.aspx?ti=<drive_ID>&tn=<campaign_ID>&tg=<number>&tv=<malware_version>

où drive_ID est le hache MD5 du numéro de série du volume principal du système et les autres paramètres sont des informations supplémentaires identifiant cette instance du logiciel malveillant.

En conséquence, le C&C peut répondre avec l'ID de la commande représentée sous forme de chaîne, éventuellement suivie de paramètres de commande. La liste complète des commandes est disponible dans le tableau 1.

Tableau 1. Commandes C&C du composant WinSys

Composants en mode utilisateur - Client.dll

La deuxième charge utile déployée par le pilote malveillant, si elle est disponible, est Client.dll. Il s'agit d'une porte dérobée qui prend en charge un riche ensemble de commandes (Tableau 2) et contient diverses capacités d'exfiltration automatique de données, notamment le vol de documents, l'enregistrement de frappe et la surveillance de l'écran de la victime par des captures d'écran périodiques. Toutes les données collectées sont stockées dans un répertoire caché, avec des sous-répertoires distincts pour chaque source de données - la liste complète des chemins de répertoire utilisés est disponible sur notre répertoire GitHub. Notez également que l'interception du clavier est gérée par le pilote et que le client doit simplement enregistrer sa fonction de journalisation en envoyant IOCTL 0x22C004 au dispositif du pilote afin d'enregistrer les frappes interceptées dans le fichier (Figure 11).

Figure 11. La charge utile du client configure la fonction de keylogger en envoyant IOCTL au pilote de périphérique du kit de démarrage.

La configuration du composant client doit se trouver sous forme chiffrée dans la couche de recouvrement du fichier. Elle contient des informations telles que l'adresse et le port C&C, des drapeaux indiquant quelles données doivent être collectées (frappes, captures d'écran, fichiers avec des extensions spécifiques), la période de temps pour le fil de capture d'écran, la taille maximale du fichier pour les données exfiltrées et une liste d'extensions de fichiers.

Communication C&C

Le client établit son propre canal de communication avec le C&C. Pour communiquer avec le C&C, il utilise le protocole TCP avec un chiffrement XOR à un octet appliqué aux octets non nuls du message qui sont différents de la clé, qui était 0x66 dans la campagne analysée ici. La communication est initiée par l'envoi de messages beacon à la paire IP:PORT spécifiée dans la configuration. Ce message contient la valeur drive_ID (le hachage MD5 du numéro de série du volume principal du système) ainsi qu'une valeur spécifiant le type de message - c'est-à-dire une demande de commande ou le téléchargement de données collectées.

Après l'exécution de la commande du C&C, le résultat est renvoyé au C&C en spécifiant le code de résultat de l'opération exécutée, l'ID de la commande et, fait intéressant, chacun de ces messages de rapport contient un filigrane/balise représentant la chaîne large WBKP située à l'offset 0x04, ce qui facilite l'identification de cette communication malveillante au niveau du réseau.

Tableau 2. Liste des commandes C&C du client

Conclusion

ESPecter montre que les acteurs de la menace ne s'appuient pas uniquement sur les implants de firmware UEFI lorsqu'il s'agit de la persistance du système d'exploitation et, malgré les mécanismes de sécurité existants comme UEFI Secure Boot, ils investissent leur temps dans la création de logiciels malveillants qui seraient facilement bloqués par ces mécanismes, s'ils étaient activés et configurés correctement.

Pour vous protéger contre des menaces similaires à celle du bootkit ESPecter, assurez-vous que :

• Vous utilisez toujours la dernière version du firmware.
• Votre système est correctement configuré et Secure Boot est activé.
• Vous appliquez une gestion appropriée des Privileged Account Management pour empêcher les adversaires d'accéder aux comptes privilégiés nécessaires à l'installation du bootkit.

Indicateurs de compromission (IoCs)

Une liste exhaustive des échantillons et IoCs est disponible sur notre répertoire GitHub.

Détection ESET

EFI/Rootkit.ESPecter
Win32/Rootkit.ESPecter
Win64/Rootkit.ESPecter

Adresses IP C&C et domaines provenant des configurations

196.1.2[.]111
103.212.69[.]175
183.90.187[.]65
61.178.79[.]69
swj02.gicp[.]net
server.microsoftassistant[.]com
yspark.justdied[.]com
crystalnba[.]com

Installers version legacy

ABC03A234233C63330C744FDA784385273AF395B
DCD42B04705B784AD62BB36E17305B6E6414F033
656C263FA004BB3E6F3EE6EF6767D101869C7F7C
A8B4FE8A421C86EAE060BB8BF525EF1E1FC133B2
3AC6F9458A4A1A16390379621FDD230C656FC444
9F6DF0A011748160B0C18FB2B44EBE9FA9D517E9
2C22AE243FDC08B84B38D9580900A9A9E3823ACF
08077D940F2B385FBD287D84EDB58493136C8391
1D75BFB18FFC0B820CB36ACF8707343FA6679863
37E49DBCEB1354D508319548A7EFBD149BFA0E8D
7F501AEB51CE3232A979CCF0E11278346F746D1F

Boot Manager Windows compromis

27AD0A8A88EAB01E2B48BA19D2AAABF360ECE5B8
8AB33E432C8BEE54AE759DFB5346D21387F26902

Techniques MITRE ATT&CK

Ce tableau a été créé en utilisant la version 9 de MITRE ATT&CK.