Le premier kit de démarrage UEFI à l'état sauvage contournant UEFI Secure Boot sur des systèmes UEFI entièrement mis à jour est désormais une réalité
Le nombre de vulnérabilités UEFI découvertes ces dernières années et les échecs à les corriger ou à révoquer les binaires vulnérables dans un délai raisonnable ne sont pas passés inaperçus auprès des acteurs de la menace. En conséquence, le premier bootkit UEFI connu du public contournant la fonction de sécurité essentielle de la plate-forme - UEFI Secure Boot - est désormais une réalité. Dans cet article de blog, nous présentons la première analyse publique de ce kit de démarrage UEFI, qui est capable de fonctionner même sur des systèmes Windows 11 entièrement à jour avec UEFI Secure Boot activé. La fonctionnalité du bootkit et ses caractéristiques individuelles nous amènent à croire que nous avons affaire à un bootkit connu sous le nom de Lotus Noir, le bootkit UEFI vendu sur les forums de piratage pour 5,000 2022 $ depuis au moins octobre XNUMX.
Les bootkits UEFI sont des menaces très puissantes, ayant un contrôle total sur le processus de démarrage du système d'exploitation et donc capables de désactiver divers mécanismes de sécurité du système d'exploitation et de déployer leurs propres charges utiles en mode noyau ou en mode utilisateur lors des premières étapes de démarrage du système d'exploitation. Cela leur permet de fonctionner très furtivement et avec des privilèges élevés. Jusqu'à présent, seuls quelques-uns ont été découverts dans la nature et décrits publiquement (par exemple, plusieurs échantillons EFI malveillants nous avons découvert en 2020, ou des bootkits UEFI complets comme notre découverte de l'année dernière - le Kit de démarrage ESPecter - ou la Kit de démarrage FinSpy découverte par des chercheurs de Kaspersky).
Les bootkits UEFI peuvent perdre en furtivité par rapport aux implants de micrologiciels - tels que LoJax; le premier implant de firmware UEFI dans la nature, découvert par notre équipe en 2018 - car les bootkits sont situés sur une partition de disque FAT32 facilement accessible. Cependant, l'exécution en tant que chargeur de démarrage leur donne presque les mêmes capacités que les implants de micrologiciels, mais sans avoir à surmonter les défenses flash SPI à plusieurs niveaux, telles que les bits de protection BWE, BLE et PRx, ou les protections fournies par le matériel (comme Intel Boot Guard ). Bien sûr, UEFI Secure Boot fait obstacle aux bootkits UEFI, mais il existe un nombre non négligeable de vulnérabilités connues qui permettent de contourner ce mécanisme de sécurité essentiel. Et le pire, c'est que certains d'entre eux sont encore facilement exploitables sur des systèmes à jour même au moment d'écrire ces lignes - y compris celui exploité par BlackLotus.
Notre enquête a commencé par quelques résultats sur ce qui s'est avéré être le composant du mode utilisateur BlackLotus - un téléchargeur HTTP - dans notre télémétrie fin 2022. Après une première évaluation, les modèles de code trouvés dans les échantillons nous ont amenés à la découverte de six BlackLotus installateurs (à la fois sur VirusTotal et dans notre propre télémétrie). Cela nous a permis d'explorer toute la chaîne d'exécution et de réaliser que ce à quoi nous avions affaire ici n'était pas seulement un malware ordinaire.
Voici les points clés concernant BlackLotus et une chronologie résumant la série d'événements qui s'y rapportent :
- Il est capable de fonctionner sur les derniers systèmes Windows 11 entièrement corrigés avec UEFI Secure Boot activé.
- Il exploite une vulnérabilité vieille de plus d'un an (CVE-2022-21894) pour contourner UEFI Secure Boot et configurer la persistance pour le bootkit. Il s'agit du premier abus publiquement connu de cette vulnérabilité.
- Bien que la vulnérabilité ait été corrigée dans la mise à jour de janvier 2022 de Microsoft, son exploitation est toujours possible car les personnes concernées, valablement signé les binaires n'ont toujours pas été ajoutés au Liste de révocation UEFI. BlackLotus en profite, apportant ses propres copies de binaires légitimes – mais vulnérables – au système afin d'exploiter la vulnérabilité.
- Il est capable de désactiver les mécanismes de sécurité du système d'exploitation tels que BitLocker, HVCI et Windows Defender.
- Une fois installé, l'objectif principal du bootkit est de déployer un pilote de noyau (qui, entre autres, protège le bootkit de la suppression) et un téléchargeur HTTP responsable de la communication avec le C&C et capable de charger des charges utiles supplémentaires en mode utilisateur ou en mode noyau. .
- BlackLotus est annoncé et vendu sur des forums clandestins depuis au moins le 6 octobreth, 2022. Dans cet article de blog, nous présentons des preuves que le bootkit est réel et que la publicité n'est pas simplement une arnaque.
- Fait intéressant, certains des programmes d'installation de BlackLotus que nous avons analysés ne procèdent pas à l'installation du bootkit si l'hôte compromis utilise l'un des paramètres régionaux suivants :
- Roumain (Moldavie), ro-MD
- Russe (Moldavie), ru-MD
- Russe (Russie), ru-RU
- Ukrainien (Ukraine), uk-UA
- Biélorusse (Biélorussie), be-BY
- Arménien (Arménie), hy-AM
- Kazakh (Kazakhstan), kk-KZ
La chronologie des événements individuels liés à BlackLotus est illustrée à la figure 1.
Comme déjà mentionné, le bootkit est vendu sur des forums underground depuis au moins le 6 octobreth, 2022. À ce stade, nous n'avons pas été en mesure d'identifier, à partir de notre télémétrie, le canal de distribution exact utilisé pour déployer le bootkit aux victimes. Le faible nombre d'échantillons de BlackLotus que nous avons pu obtenir, à la fois de sources publiques et de notre télémétrie, nous porte à croire que peu d'acteurs malveillants ont encore commencé à l'utiliser. Mais jusqu'à ce que la révocation des chargeurs de démarrage vulnérables dont dépend BlackLotus se produise, nous craignons que les choses changent rapidement si ce bootkit tombe entre les mains des groupes de logiciels criminels bien connus, sur la base du déploiement facile du bootkit et des capacités des groupes de logiciels criminels à se propager. logiciels malveillants utilisant leurs botnets.
Est-ce vraiment BlackLotus ?
Il existe plusieurs articles ou messages résumant des informations sur BlackLotus (ici, ici et le ici et bien d'autres…), tous basés sur les informations fournies par le développeur du bootkit sur des forums de piratage clandestins. Jusqu'à présent, personne n'a confirmé ou réfuté ces affirmations.
Voici notre résumé des affirmations des publications disponibles par rapport à ce que nous avons découvert lors de la rétro-ingénierie des échantillons de bootkit :
- La publicité de BlackLotus sur les forums de piratage prétend qu'elle dispose d'un contournement intégré du démarrage sécurisé. L'ajout de pilotes vulnérables à la liste de révocation UEFI est actuellement impossible, car la vulnérabilité affecte des centaines de chargeurs de démarrage encore utilisés aujourd'hui. ✅
- Vrai : Il exploite CVE-2022-21894 afin d'interrompre le démarrage sécurisé et d'obtenir la persistance sur les systèmes compatibles UEFI-Secure-Boot. Les pilotes vulnérables qu'il utilise ne sont toujours pas révoqués dans les dernières dbx, au moment de la rédaction.
- La publicité de BlackLotus sur les forums de piratage prétend que le bootkit a une protection Ring0/Kernel intégrée contre la suppression. ✅
- Vrai : son pilote de noyau protège les poignées appartenant à ses fichiers sur la partition système EFI (ESP) contre la fermeture. En tant que couche de protection supplémentaire, ces poignées sont surveillées en permanence et un écran bleu de la mort (BSOD) est déclenché si l'une de ces poignées est fermée, comme décrit dans le Protection des fichiers de bootkit sur l'ESP contre la suppression .
- La publicité de BlackLotus sur les forums de piratage affirme qu'elle est livrée avec des fonctionnalités anti-machine virtuelle (anti-VM), anti-débogage et d'obfuscation de code pour bloquer les tentatives d'analyse de logiciels malveillants. ✅
- Vrai : Il contient diverses techniques anti-VM, anti-débogage et d'obscurcissement pour rendre plus difficile la réplication ou l'analyse. Cependant, nous ne parlons certainement pas ici de techniques anti-analyse révolutionnaires ou avancées, car elles peuvent être facilement surmontées avec peu d'effort.
- La publicité de BlackLotus sur les forums de piratage prétend que son but est d'agir comme un téléchargeur HTTP. ✅
- Vrai : son composant final agit comme un téléchargeur HTTP, comme décrit dans le Téléchargeur HTTP
- La publicité de BlackLotus sur les forums de piratage affirme que le téléchargeur HTTP s'exécute sous le compte SYSTEM dans le cadre d'un processus légitime. ✅
- Vrai : son téléchargeur HTTP s'exécute dans le winlogon.exe contexte du processus.
- La publicité de BlackLotus sur les forums de piratage affirme qu'il est un petit bootkit avec une taille sur disque de seulement 80 ko. ✅
- Vrai : les échantillons que nous avons pu obtenir pèsent en réalité environ 80 ko.
- La publicité de BlackLotus sur les forums de piratage prétend qu'il peut désactivez les protections de sécurité Windows intégrées telles que HVCI, Bitlocker, Windows Defender et contournez le contrôle de compte d'utilisateur (UAC). ✅
Sur la base de ces faits, nous pensons avec une grande confiance que le bootkit que nous avons découvert dans la nature est le bootkit BlackLotus UEFI.
Aperçu des attaques
Un schéma simplifié de la chaîne de compromis BlackLotus est illustré à la figure 2. Il se compose de trois parties principales :
- Cela commence par l'exécution d'un programme d'installation (étape 1 de la figure 2), qui est chargé de déployer les fichiers du bootkit sur la partition système EFI, de désactiver HVCI et BitLocker, puis de redémarrer la machine.
- Après le premier redémarrage, exploitation de CVE-2022-21894 et enrôlement ultérieur des attaquants Clé du propriétaire de la machine (MOK) se produit, pour obtenir la persistance même sur les systèmes avec UEFI Secure Boot activé. La machine est ensuite redémarrée (étapes 2 à 4 de la figure 2).
- Lors de tous les démarrages suivants, le kit de démarrage UEFI auto-signé est exécuté et déploie à la fois son pilote de noyau et sa charge utile en mode utilisateur, le téléchargeur HTTP. Ensemble, ces composants sont capables de télécharger et d'exécuter des composants de mode utilisateur et de pilote supplémentaires à partir du serveur C&C et de protéger le bootkit contre la suppression (étapes 5 à 9 de la figure 2).
Artefacts intéressants
Même si nous pensons qu'il s'agit du bootkit BlackLotus UEFI, nous n'avons trouvé aucune référence à ce nom dans les échantillons que nous avons analysés. Au lieu de cela, le code est plein de références à la Higurashi quand ils pleurent séries animées, par exemple dans les noms de composants individuels, tels que higurashi_installer_uac_module.dll et le higurashi_kernel.sys, ainsi que dans le certificat auto-signé utilisé pour signer le binaire du bootkit (illustré à la figure 3).
De plus, le code décrypte mais n'utilise jamais diverses chaînes contenant des messages de l'auteur BlackLotus (comme illustré à la figure 4 - notez que hasherezade est un chercheur bien connu et auteur de divers outils d'analyse de logiciels malveillants), ou simplement quelques citations aléatoires de diverses chansons, jeux ou séries.
Processus d'installation
Nous commençons par l'analyse des installateurs BlackLotus. Le bootkit semble être distribué sous la forme d'installateurs qui se déclinent en deux versions - hors ligne et en ligne. La différence entre ces deux réside dans la manière dont ils obtiennent des fichiers binaires Windows légitimes (mais vulnérables), utilisés ultérieurement pour contourner le démarrage sécurisé.
- Dans les versions hors ligne, les binaires Windows sont intégrés dans le programme d'installation
- Dans les versions en ligne, les fichiers binaires Windows sont téléchargés directement à partir du magasin de symboles Microsoft. Jusqu'à présent, nous avons vu les binaires Windows suivants être abusés par le bootkit BlackLotus :
- https://msdl.microsoft.com/download/symbols/bootmgfw.efi/7144BCD31C0000/bootmgfw.efi
- https://msdl.microsoft.com/download/symbols/bootmgr.efi/98B063A61BC000/bootmgr.efi
- https://msdl.microsoft.com/download/symbols/hvloader.efi/559F396411D000/hvloader.efi
L'objectif du programme d'installation est clair : il est responsable de la désactivation des fonctionnalités de sécurité Windows telles que le chiffrement de disque BitLocker et HVCI, et du déploiement de plusieurs fichiers, y compris le bootkit malveillant, sur l'ESP. Une fois terminé, il redémarre la machine compromise pour laisser les fichiers déposés faire leur travail - pour s'assurer que le kit de démarrage UEFI auto-signé sera exécuté en silence à chaque démarrage du système, quel que soit l'état de la protection UEFI Secure Boot.
Étape 0 - Initialisation et élévation (potentielle)
Lorsque le programme d'installation est exécuté, il vérifie s'il dispose de suffisamment de privilèges (au moins administrateur requis) pour déployer le reste des fichiers sur l'ESP et effectuer d'autres actions nécessitant un processus élevé, comme désactiver HVCI ou désactiver BitLocker. Si ce n'est pas le cas, il essaie de s'élever en exécutant à nouveau le programme d'installation en utilisant la méthode de contournement UAC décrite en détail ici : Contournement UAC via l'assistant de compatibilité des programmes.
Avec les privilèges nécessaires, il continue en vérifiant l'état du démarrage sécurisé UEFI en lisant la valeur de la variable UEFI SecureBoot à l'aide d'une fonction API Windows disponible et en déterminant la version de Windows en accédant directement au KUSER_SHARED_DATA champs de structure NtMajorVersionNtMajorVersion et le NtMinorVersionNtMinorVersion en mémoire. Il le fait pour décider si le contournement de UEFI Secure Boot est nécessaire ou non pour déployer le bootkit sur le système de la victime (puisque la prise en charge de Secure Boot a été ajoutée pour la première fois dans Windows 8 et peut ne pas être activée sur une machine donnée).
Avant de passer aux étapes suivantes, il renomme le gestionnaire de démarrage Windows légitime (bootmgfw.efi) binaire situé dans le ESP :EFIMicrosoftBoot répertoire à winload.efi. Ce renommé bootmgfw.efi la sauvegarde est ensuite utilisée par le bootkit pour lancer le système d'exploitation ou pour récupérer la chaîne de démarrage d'origine si la commande "désinstaller" est reçue du serveur C&C - plus dans le Communication C&C .
Étape 1 - Déploiement des fichiers
Si UEFI Secure Boot est activé, le programme d'installation procède au dépôt de plusieurs fichiers dans le ESP :/EFI/Microsoft/Boot/ et le ESP :/system32/ répertoires. Alors que le premier est un répertoire standard utilisé par Windows, le second est un dossier personnalisé créé par le programme d'installation.
Une liste des fichiers déposés par le programme d'installation avec une brève explication du rôle de chaque fichier dans la chaîne d'exécution est fournie dans le tableau 1. Nous expliquerons en détail le fonctionnement de la chaîne d'exécution plus tard ; notez maintenant que plusieurs fichiers légitimes signés par Microsoft sont supprimés avec les fichiers malveillants.
Tableau 1. Fichiers déployés par le programme d'installation de BlackLotus sur les systèmes sur lesquels UEFI Secure Boot est activé
Dossier | Nom de fichier | Description |
---|---|---|
ESP :EFIMicrosoftBoot | grubx64.efi | Bootkit BlackLotus, application UEFI auto-signée malveillante. |
bootload.efi | Signature légitime de Microsoft cale binaire (nom temporaire, remplace plus tard bootmgfw.efi après CVE-2022-21894 exploitation). | |
bootmgfw.efi | Légitime, mais vulnérable (CVE-2022-21894) Fichier binaire du gestionnaire de démarrage Windows, intégré au programme d'installation ou téléchargé directement à partir du Microsoft Symbol Store. | |
BCD | Coutume des attaquants Boot Configuration Data (BCD) magasin utilisé dans CVE-2022-21894 chaîne d'exploitation. | |
BCDR | Sauvegarde du magasin BCD d'origine de la victime. | |
ESP : système32 | hvloader.efi | Légitime, mais vulnérable (CVE-2022-21894) Exécutable Windows Hypervisor Loader, intégré dans un programme d'installation ou téléchargé directement depuis Microsoft Symbol Store. |
bootmgr.efi | Légitime, mais vulnérable (CVE-2022-21894) Fichier binaire du gestionnaire de démarrage Windows, intégré dans un programme d'installation ou téléchargé directement depuis le Microsoft Symbol Store. | |
mcupdate_AuthenticAMD.dll | Binaire PE natif auto-signé malveillant. Ce fichier est exécuté par le hvloader.efi après une exploitation réussie de CVE-2022-21894 (sur des systèmes utilisant un processeur AMD). | |
mcupdate_GenuineIntel.dll | Binaire PE natif auto-signé malveillant. Ce fichier est exécuté par le hvloader.efi après avoir réussi CVE-2022-21894 exploitation (sur les systèmes utilisant un processeur Intel). | |
BCD | BCD personnalisé des attaquants utilisé dans CVE-2022-21894 chaîne d'exploitation. |
Dans les cas où la victime exécute une version de Windows ne prenant pas en charge le démarrage sécurisé UEFI, ou dans le cas où il est désactivé, le déploiement est assez simple. La seule chose nécessaire pour déployer le bootkit malveillant est de remplacer le gestionnaire de démarrage Windows existant (bootmgfw.efi) binaire dans le ESP :EFIMicrosoftBoot répertoire, avec la propre application UEFI malveillante auto-signée des attaquants. Étant donné que UEFI Secure Boot est désactivé (et donc aucune vérification d'intégrité n'est effectuée lors du démarrage), l'exploitation n'est pas nécessaire et le micrologiciel UEFI exécute simplement le gestionnaire de démarrage malveillant sans causer de violation de sécurité.
Étape 2 - Désactivation de l'intégrité du code protégé par l'hyperviseur (HVCI)
Pour pouvoir exécuter ultérieurement du code de noyau personnalisé non signé, le programme d'installation doit s'assurer que HVC est désactivé sur le système. Un de nos collègues d'ESET a écrit un article de blog très instructif sur ce sujet en 2022 (Pilotes de noyau signés - Passerelle non protégée vers le cœur de Windows):
La sécurité basée sur la virtualisation (VBS) offre plusieurs fonctionnalités de protection, la plus importante étant l'intégrité du code protégé par l'hyperviseur (HVCI), qui est également une fonctionnalité autonome. HVCI renforce l'intégrité du code dans le noyau et autorise uniquement l'exécution de code signé. Il empêche efficacement les pilotes vulnérables d'être abusés pour exécuter du code noyau non signé ou charger des pilotes malveillants (quelle que soit la méthode d'exploitation utilisée) et il semble que les logiciels malveillants abusant des pilotes vulnérables pour charger du code malveillant étaient l'un des principales motivations de Microsoft pour implémenter cette fonctionnalité.
Comme le montre la figure 5, pour désactiver cette fonctionnalité, le programme d'installation définit la valeur de registre Enabled sous le HyperviseurEnforcedCodeIntégrité clé de registre à zéro.
Étape 3 - Désactivation de BitLocker
La prochaine fonctionnalité désactivée par l'installateur est BitLocker Drive Encryption. La raison en est que BitLocker peut être utilisé en combinaison avec Trusted Platform Module (TPM) pour s'assurer que divers fichiers de démarrage et configurations, y compris Secure Boot, n'ont pas été falsifiés depuis que le chiffrement de lecteur BitLocker a été configuré sur le système. Étant donné que le programme d'installation modifie la chaîne de démarrage Windows sur une machine compromise, le fait de garder BitLocker activé pour les systèmes prenant en charge le TPM conduirait à un écran de récupération BitLocker au prochain démarrage et indiquerait à la victime que le système avait été compromis.
Pour désactiver cette protection, le programme d'installation de BlackLotus :
- parcourt tous les volumes sous le RacineCIMV2SécuritéMicrosoftVolumeEncryption espace de noms WMI et vérifie leur état de protection en appelant le Obtenir le statut de protection méthode de Win32_EncryptableVolume Classe WMI
- pour ceux protégés par BitLocker, il appelle le Désactiver les protecteurs de clés méthode avec le DésactiverCount paramètre mis à zéro, ce qui signifie que la protection sera suspendue jusqu'à ce qu'elle soit activée manuellement
Avec les protections nécessaires désactivées et tous les fichiers déployés, le programme d'installation s'enregistre pour être supprimé lors du prochain redémarrage du système et redémarre la machine pour procéder à l'exploitation de CVE-2022-21894.
Contournement du démarrage sécurisé et établissement de la persistance
Dans cette partie, nous examinons de plus près comment BlackLotus atteint la persistance sur les systèmes avec UEFI Secure Boot activé. Comme la chaîne d'exécution que nous allons décrire est assez complexe, nous allons d'abord expliquer les principes de base, puis approfondir les détails techniques.
En bref, ce processus se compose de deux étapes clés :
- Exploitation de CVE-2022-21894 pour contourner la fonction Secure Boot et installer le bootkit. Cela permet l'exécution de code arbitraire dans les premières phases de démarrage, où la plate-forme appartient toujours au micrologiciel et les fonctions des services de démarrage UEFI sont toujours disponibles. Cela permet aux attaquants de faire de nombreuses choses qu'ils ne devraient pas pouvoir faire sur une machine avec UEFI Secure Boot activé sans y avoir physiquement accès, comme modifier les variables NVRAM des services de démarrage uniquement. Et c'est ce dont les attaquants profitent pour configurer la persistance du bootkit à l'étape suivante. Plus d'informations sur l'exploitation peuvent être trouvées dans le Exploitation de CVE-2022-21894 .
- Définir la persistance en écrivant son propre MOK dans le MokListe, Variable NVRAM des services de démarrage uniquement. Ce faisant, il peut utiliser un compte légitime signé par Microsoft cale pour charger son auto-signé (signé par la clé privée appartenant à la clé écrite sur MokListe) Bootkit UEFI au lieu d'exploiter la vulnérabilité à chaque démarrage. Plus d'informations à ce sujet dans le Persistance du bootkit .
Pour faciliter l'analyse détaillée dans les deux prochaines sections, nous suivrons les étapes indiquées dans le diagramme d'exécution, Figure 6.
Exploitation de CVE-2022-21894
Pour contourner Secure Boot, BlackLotus utilise le baton drop (CVE-2022-21894) : Vulnérabilité de contournement de la fonction de sécurité du démarrage sécurisé. Malgré son impact élevé sur la sécurité du système, cette vulnérabilité n'a pas attiré autant l'attention du public qu'elle le méritait. Bien que la vulnérabilité ait été corrigée dans la mise à jour de janvier 2022 de Microsoft, son exploitation est toujours possible car les binaires concernés n'ont toujours pas été ajoutés au Liste de révocation UEFI. Par conséquent, les attaquants peuvent apporter leurs propres copies de binaires vulnérables sur les machines de leurs victimes pour exploiter cette vulnérabilité et contourner le démarrage sécurisé sur les systèmes UEFI à jour.
De plus, un exploit de preuve de concept (PoC) pour cette vulnérabilité est accessible au public depuis août 2022. Compte tenu de la date de la première soumission de BlackLotus VirusTotal (voir Figure 1), le développeur de logiciels malveillants vient probablement d'adapter le PoC disponible à ses besoins sans tout besoin de compréhension approfondie du fonctionnement de cet exploit.
Commençons par une brève introduction à la vulnérabilité, résumant principalement les points clés de l'article publié avec le PoC sur GitHub:
- Applications de démarrage Windows concernées (telles que bootmgr.efi, hvloader.efi, winload.efi…) permettent de supprimer une stratégie de démarrage sécurisé sérialisée de la mémoire - avant qu'elle ne soit chargée par l'application - en utilisant le tronquer la mémoire Option de démarrage BCD.
- Cela permet aux attaquants d'utiliser d'autres options BCD dangereuses comme débogage de démarrage, test de signatureou nointegritychecks, interrompant ainsi Secure Boot.
- Il existe différentes façons d'exploiter cette vulnérabilité - trois d'entre elles sont publiées dans le référentiel PoC.
- A titre d'exemple, l'un des PoCs montre comment il peut être exploité pour rendre le légitime hvloader.efi charger un arbitraire, auto-signé mcupdate_ .dll binaire (où peuvent être GenuineIntel or AuthenticAMD, basé sur le processeur de la machine.).
Maintenant, nous continuons à décrire comment BlackLotus exploite cette vulnérabilité (les numéros dans la liste ci-dessous décrivent les étapes correspondantes dans la figure 6) :
- Une fois que le programme d'installation a redémarré la machine, le micrologiciel UEFI procède au chargement d'une première option de démarrage. Pour les systèmes Windows, la première option de démarrage est par défaut bootmgfw.efi situé dans le ESP :/EFI/Microsoft/démarrage dossier sur l'ESP. Cette fois, au lieu d'exécuter la victime d'origine bootmgfw.efi (anciennement renommé winload.efi par le programme d'installation), le micrologiciel exécute le logiciel vulnérable - déployé par le programme d'installation.
- Après bootmgfw.efi est exécuté, il charge les options de démarrage de BCD, préalablement modifiées par l'installateur. La figure 7 montre une comparaison du BCD légitime et du BCD modifié.
- Comme vous pouvez le voir dans la figure 7 (chemin souligné en vert), le gestionnaire de démarrage Windows légitime charge normalement le chargeur du système d'exploitation Windows (WINDOWSsystem32winload.efi) comme application de démarrage par défaut. Mais cette fois, avec le BCD modifié, il continue avec le chargement du vulnérable ESP : system32bootmgr.efi, Avec le éviter une faible mémoire Élément BCD défini sur valeur Assistance et les terres parsemées de personnalisé : 22000023 Élément BCD pointant vers le BCD d'un autre attaquant stocké dans ESP : system32bcd. L'explication de l'utilisation de ces éléments se trouve dans la publication PoC:
L'attaquant doit s'assurer que la politique de démarrage sécurisé sérialisée est allouée au-dessus d'une adresse physique connue.
[...]
La éviter une faible mémoire L'élément peut être utilisé pour s'assurer que toutes les allocations de mémoire physique sont au-dessus d'une adresse physique spécifiée.
• Depuis Windows 10, cet élément est interdit si VBS est activé, mais comme il est utilisé lors de l'initialisation de l'application de démarrage, avant que la stratégie de démarrage sécurisé sérialisée ne soit lue à partir de la mémoire, le chargement Bootmgr et en spécifiant un chemin BCD personnalisé (en utilisant chemin du fichier bcd élément alias personnalisé : 22000023) peut être utilisé pour contourner cela.
- Dans l'étape suivante, l'exécution ESP : system32bootmgr.efi charge ce BCD supplémentaire situé dans ESP : system32bcd. Le contenu analysé de ce BCD supplémentaire est illustré à la Figure 8.
- En raison des options chargées à partir du fichier BCD illustré à la figure 8, bootmgr.efi continue avec le chargement d'une autre application de démarrage Windows vulnérable déployée par le programme d'installation - ESP : system32hvloader.efi - qui est le chargeur d'hyperviseur Windows. Plus important encore, des options BCD supplémentaires sont spécifiées dans le même fichier BCD (voir Figure 8) :
- tronquer la mémoire avec la valeur définie sur Assistance
- nointegritychecks défini sur Oui
- et le test de signature, également défini sur Oui
Et c'est là que la magie opère. Comme la stratégie de démarrage sécurisé sérialisée doit être chargée dans les adresses physiques ci-dessus Assistance (à cause de éviter une faible mémoire utilisé dans les étapes précédentes), en spécifiant tronquer la mémoire l'élément le supprimera efficacement - ainsi, cassez le démarrage sécurisé et autorisez l'utilisation d'options BCD dangereuses telles que nointegritychecks or test de signature. En utilisant ces options, les attaquants peuvent faire hvloader.efi exécuter leur propre code auto-signé.
- Pour ce faire, la même astuce que celle décrite dans le PoC est utilisé : lors de son exécution, le légitime hvloader.efi charge et exécute le mcupdate_{GenuineIntel| AuthentiqueAMD}.dll binaire natif du : system32 annuaire. Code décompilé Hex-Rays commenté de la fonction à partir de hvloader.efi responsable du chargement de ce fichier binaire mcupdate*.dll est illustré à la figure 9. Notez que hvloader.efi chargerait normalement ce légitime mcupdate*.dll binaire de la:Windowssystème32, mais cette fois, les attaquants malveillants ont auto-signé mcupdate*.dll est exécuté à partir d'un répertoire ESP personnalisé préalablement créé par le programme d'installation (ESP : système32). C'est causé par les options BCD dispositif et le systemroot utilisé dans le BCD de la Figure 8 spécifiant le périphérique actuel comme botte - c'est-à-dire l'ESP - et en spécifiant également SystemRoot comme racine () répertoire sur cet appareil.
- Maintenant, alors que les attaquants ont signé eux-mêmes mcupdate*.dll est chargé et exécuté, il continue avec l'exécution du composant final de cette chaîne - un MokInstaller intégré (application UEFI) - voir la figure 10 pour plus de détails sur la façon dont cela est fait.
Persistance du bootkit
Maintenant, le MokInstaller peut procéder à la configuration de la persistance en inscrivant le MOK des attaquants dans la variable NVRAM et en configurant le légitime signé Microsoft cale binaire comme chargeur de démarrage par défaut. Avant d'entrer dans les détails, un peu de théorie sur cale et MOK.
cale est un chargeur de démarrage UEFI de première étape développé par des développeurs Linux pour faire fonctionner diverses distributions Linux avec UEFI Secure Boot. C'est une application simple et son but est de charger, vérifier et exécuter une autre application - dans le cas des systèmes Linux, il s'agit généralement du chargeur de démarrage GRUB. Cela fonctionne de manière à ce que Microsoft ne signe qu'un caleainsi que, cale s'occupe du reste - il peut vérifier l'intégrité d'un chargeur de démarrage de deuxième étape en utilisant les clés de db Variable UEFI, et intègre également sa propre liste de clés ou de hachages « autorisés » ou « révoqués » pour s'assurer que les composants approuvés par les deux développeurs de plate-forme et de shim (par exemple, Canonical, RedHat, etc.) - sont autorisés à être exécutés. Outre ces listes, cale permet également l'utilisation d'une base de données de clés externes gérée par l'utilisateur, appelée liste MOK. La figure 11 illustre bien le fonctionnement de UEFI Secure Boot avec MOK.
Cette base de données MOK est stockée dans une variable NVRAM de démarrage uniquement nommée MokListe. Sans exploiter une vulnérabilité comme celle décrite ci-dessus, un accès physique est nécessaire pour la modifier sur un système avec UEFI Secure Boot activé (il n'est disponible qu'au démarrage, avant que le chargeur de système d'exploitation n'appelle la fonction UEFI Boot Services QuitterBootServices). Cependant, en exploitant cette vulnérabilité, les attaquants peuvent contourner UEFI Secure Boot et exécuter leur propre code auto-signé avant un appel à QuitterBootServices, afin qu'ils puissent facilement inscrire leur propre clé (en modifiant le MokListe variable NVRAM) pour que le shim exécute n'importe quelle application - signée par cette clé inscrite - sans provoquer de violation de sécurité.
- Poursuivant en décrivant le flux de la Figure 6 - étape 8… L'application MokInstaller UEFI continue avec la configuration de la persistance pour le bootkit BlackLotus UEFI et en couvrant les pistes d'exploitation en :
- Restaurer le magasin BCD d'origine de la victime à partir de la sauvegarde créée par le programme d'installation et remplacer l'efi par le shim légitime signé Microsoft, précédemment déposé dans le ESP : system32bootload.efi par l'installateur.
- Création d'un MokListe Variable NVRAM contenant le certificat de clé publique auto-signé des attaquants. Notez que cette variable est formatée de la même manière que toutes les autres variables de base de données de signature UEFI (telles que db ou dbx) et qu'elle peut consister en zéro ou plusieurs listes de signatures de type EFI_SIGNATURE_LIST – tel que défini dans la spécification UEFI.
- Suppression de tous les fichiers impliqués dans l'exploitation des attaquants ESP : système32 dossier.
- En fin de compte, il redémarre la machine pour que le shim déployé exécute le bootkit auto-signé déposé sur EFIMicrosoftBootgrubx64.efi par l'installateur (grubx64.efi est généralement le chargeur de démarrage de deuxième étape par défaut exécuté par un cale sur les systèmes x86-64).
Le code effectuant les actions décrites dans les deux dernières étapes est illustré à la figure 12.
Kit de démarrage BlackLotus UEFI
Une fois la persistance configurée, le bootkit BlackLotus est exécuté à chaque démarrage du système. L'objectif du bootkit est de déployer un pilote de noyau et un composant final en mode utilisateur - le téléchargeur HTTP. Au cours de son exécution, il essaie de désactiver les fonctionnalités de sécurité Windows supplémentaires - Virtualization-Based Security (VBS) et Windows Defender - pour augmenter les chances de déploiement réussi et d'opération furtive. Avant de passer aux détails sur la façon dont cela est fait, résumons les bases du pilote du noyau et du téléchargeur HTTP :
- Le pilote du noyau est responsable de
- Déploiement du composant suivant de la chaîne - un téléchargeur HTTP.
- Garder le chargeur en vie en cas de résiliation.
- Protection des fichiers de bootkit contre la suppression d'ESP.
- Exécuter des charges utiles de noyau supplémentaires, si cela est demandé par le téléchargeur HTTP.
- Désinstallation du bootkit, si cela est demandé par le téléchargeur HTTP.
- Le téléchargeur HTTP est responsable de :
- Communiquer avec son C&C.
- Exécuter les commandes reçues du C&C.
- Téléchargement et exécution des charges utiles reçues du C&C (prend en charge les charges utiles du noyau et les charges utiles en mode utilisateur).
Le flux d'exécution complet (simplifié), du programme d'installation au téléchargeur HTTP, est illustré à la figure 13. Nous décrivons ces étapes individuelles plus en détail dans la section suivante.
Flux d'exécution de BlackLotus
Les étapes d'exécution sont les suivantes (ces étapes sont illustrées à la Figure 13) :
- Dans un premier temps, le micrologiciel UEFI exécute l'option de démarrage Windows par défaut, qui est le fichier généralement stocké dans EFIMicrosoftBootbootmgfw.efi. Comme nous l'avons décrit précédemment (Section de persistance du bootkit, 8 .a), le binaire MokInstaller a remplacé ce fichier par un fichier légitime signé cale.
- When the cale est exécuté, il lit le MokListe variable NVRAM et utilise le certificat précédemment stocké à l'intérieur par les attaquants pour vérifier le chargeur de démarrage de deuxième étape - le bootkit BlackLotus UEFI auto-signé situé dans EFIMicrosoftBootgrubx64.efi.
- Une fois vérifié, le cale exécute le bootkit.
- Le bootkit commence par créer le Boot-only VbsPolicyDisableVbsPolicyDisable Variable NVRAM. Comme décrit ici, cette variable est évaluée par le chargeur du système d'exploitation Windows lors du démarrage et, si elle est définie, les fonctionnalités principales de VBS, telles que HVCI et Credential Guard, ne seront pas initialisées.
- Dans les étapes suivantes (5. a–e), le bootkit continue avec un modèle commun utilisé par les bootkits UEFI. Il intercepte l'exécution des composants inclus dans le flux de démarrage Windows typique, tels que le gestionnaire de démarrage Windows, le chargeur de système d'exploitation Windows et le noyau du système d'exploitation Windows, et accroche certaines de leurs fonctions en mémoire. En prime, il tente également de désactiver Windows Defender en corrigeant certains de ses pilotes. Tout cela pour réaliser l'exécution de sa charge utile dans les premières étapes du processus de démarrage du système d'exploitation et pour éviter la détection. Les fonctions suivantes sont accrochées ou patchées :
- ImgArchStartBootApplicationImgArchStartBootApplication in bootmgfw.efi or bootmgr.efi:
Cette fonction est généralement accrochée par les bootkits pour saisir le moment où le chargeur du système d'exploitation Windows (winload.efi) est chargé dans la mémoire mais n'a toujours pas été exécuté - ce qui est le bon moment pour effectuer plus de patchs en mémoire. - BlImgAllocateImageBuffer in winload.efi:
Utilisé pour allouer une mémoire tampon supplémentaire pour le pilote du noyau malveillant. - OslArchTransferToKernel in winload.efi:
Accroché pour saisir le moment où le noyau du système d'exploitation et certains des pilotes système sont déjà chargés dans la mémoire, mais n'ont toujours pas été exécutés - ce qui est un moment idéal pour effectuer davantage de correctifs en mémoire. Les pilotes mentionnés ci-dessous sont corrigés dans ce crochet. Le code de ce hook chargé de trouver les pilotes appropriés en mémoire est illustré à la figure 14. - WdBoot.sys et le WdFilter.sys:
BlackLotus corrige le point d'entrée de WdBoot.sys et le WdFilter.sys – le pilote Windows Defender ELAM et le pilote de filtre du système de fichiers Windows Defender, respectivement – pour revenir immédiatement. - disk.sys:
Le bootkit accroche le point d'entrée du disk.sys pilote pour exécuter le pilote du noyau BlackLotus dans les premières étapes de l'initialisation du système.
- ImgArchStartBootApplicationImgArchStartBootApplication in bootmgfw.efi or bootmgr.efi:
- Ensuite, lorsque le noyau du système d'exploitation exécute le disk.sys point d'entrée du pilote, le crochet installé saute au point d'entrée du pilote du noyau malveillant. Le code malveillant restaure à son tour l'original disk.sys pour permettre au système de fonctionner correctement et attend que le winlogon.exe processus démarre.
- Lorsque le pilote malveillant détecte que le winlogon.exe a démarré, il injecte et exécute le dernier composant en mode utilisateur - le téléchargeur HTTP - dedans.
Pilote du noyau
Le pilote du noyau est responsable de quatre tâches principales :
- Injecter le téléchargeur HTTP dans winlogon.exe et le réinjecter au cas où le fil se terminerait.
- Protection des fichiers de bootkit déployés sur l'ESP contre la suppression.
- Désarmement du processus Windows Defender en mode utilisateur MsMpEngine.exe.
- Communiquer avec le téléchargeur HTTP et, si nécessaire, exécuter des commandes.
Regardons-les un par un.
Persistance du téléchargeur HTTP
Le pilote du noyau est responsable du déploiement du téléchargeur HTTP. Lorsque le pilote démarre, il attend que le processus nommé winlogon.exe démarre, avant d'entreprendre toute autre action. Une fois le processus démarré, le pilote déchiffre le binaire du téléchargeur HTTP, l'injecte dans winlogon.exede l'espace d'adressage et l'exécute dans un nouveau thread. Ensuite, le pilote continue de vérifier périodiquement si le thread est toujours en cours d'exécution et répète l'injection si nécessaire. Le téléchargeur HTTP ne sera pas déployé si un débogueur du noyau est détecté par le pilote.
Protection des fichiers de bootkit sur l'ESP contre la suppression
Pour protéger les fichiers du bootkit situés sur l'ESP, le pilote du noyau utilise une astuce simple. Il ouvre tous les fichiers qu'il veut protéger, duplique et enregistre leurs descripteurs, et utilise le ObSetHandleAttributesObSetHandleAttributes fonction noyau spécifiant la ProtégerDeFermer drapeau à l'intérieur PoignéeDrapeaux (OBJECT_HANDLE_FLAG_INFORMATION) paramètre à 1 - protégeant ainsi les poignées d'être fermées par d'autres processus. Cela empêchera toute tentative de suppression ou de modification des fichiers protégés. Les fichiers suivants sont protégés :
- ESP :EFIMicrosoftBootwinload.efi
- ESP :EFIMicrosoftBootbootmgfw.efi
- ESP :EFIMicrosoftBootgrubx64.efi
Si un utilisateur essaie de supprimer ces fichiers protégés, quelque chose comme ce qui est montré dans la figure 15 se produira.
En tant qu'autre couche de protection, au cas où l'utilisateur ou le logiciel de sécurité serait en mesure de désactiver l'indicateur de protection et de fermer les descripteurs, le pilote du noyau les surveille en permanence et provoque un BSOD en appelant le KeBugCheck(INVALID_KERNEL_HANDLE) fonction si l'une des poignées n'existe plus.
Désarmer le processus principal de Windows Defender
Le pilote du noyau essaie également de désarmer le processus principal de Windows Defender - MsMpEng.exe. Il le fait en supprimant tous les privilèges de jeton du processus en définissant le SE_PRIVILEGE_REMOVED attribuer à chacun d'eux. Par conséquent, le processus Defender ne devrait pas être en mesure de faire correctement son travail, comme l'analyse des fichiers. Cependant, comme cette fonctionnalité est mal implémentée, elle peut être rendue inefficace en redémarrant le MsMpEng.exe processus.
Communication avec le téléchargeur HTTP
Le pilote du noyau est capable de communiquer avec le téléchargeur HTTP en utilisant un événement et une section nommés. Les noms des objets nommés utilisés sont générés en fonction de l'adresse MAC de l'adaptateur réseau de la victime (ethernet). Si une valeur d'un octet est inférieure à 16, alors 16 lui est ajouté. Le format des noms d'objets générés peut varier selon les échantillons. A titre d'exemple, dans l'un des échantillons que nous avons analysés, pour l'adresse MAC 00-1c-0b-cd-ef-34, les noms générés seraient :
- BaseNamedObjects101c1b: pour la section nommée (seuls les trois premiers octets du MAC sont utilisés)
- BaseNamedObjectsZ01c1b: pour l'événement nommé - identique à la section, mais le premier chiffre de l'adresse MAC est remplacé par Z
Si le téléchargeur HTTP souhaite transmettre une commande au pilote du noyau, il crée simplement une section nommée, écrit une commande avec les données associées à l'intérieur et attend que la commande soit traitée par le pilote en créant un événement nommé et en attendant que le conducteur le déclenche (ou le signale).
Le pilote prend en charge les commandes explicites suivantes :
- Installer le pilote du noyau
- Désinstaller BlackLotus
Un lecteur attentif remarquera peut-être ici le point faible de BlackLotus - même si le bootkit protège ses composants contre la suppression, le pilote du noyau peut être trompé pour désinstaller complètement le bootkit en créant les objets nommés susmentionnés et en lui envoyant la commande de désinstallation.
Téléchargeur HTTP
Le composant final est responsable de la communication avec un serveur C&C et de l'exécution de toutes les commandes C&C reçues de celui-ci. Toutes les charges utiles que nous avons pu découvrir contiennent trois commandes. Ces commandes sont très simples et, comme le nom de la section l'indique, il s'agit principalement de télécharger et d'exécuter des charges utiles supplémentaires à l'aide de diverses techniques.
Communication C&C
Pour communiquer avec son C&C, le chargeur HTTP utilise le protocole HTTPS. Toutes les informations nécessaires à la communication sont intégrées directement dans le binaire du téléchargeur, y compris les domaines C&C et les chemins de ressources HTTP utilisés. L'intervalle de communication par défaut avec un serveur C&C est défini sur une minute, mais peut être modifié en fonction des données du C&C. Chaque session de communication avec un C&C commence par l'envoi d'un message balise HTTP POST vers celui-ci. Dans les exemples que nous avons analysés, les chemins de ressources HTTP suivants peuvent être spécifiés dans les en-têtes HTTP POST :
- /réseau/API/hpb_gate[.]php
- /API/hpb_gate[.]php
- /porte[.]php
- /hpb_gate[.]php
Les données du message de balise sont précédées d'un enregistrement= chaîne, contenant des informations de base sur la machine compromise - y compris un identifiant de machine personnalisé (appelé largeur de la route), l'état du démarrage sécurisé UEFI, diverses informations sur le matériel et une valeur qui semble être un numéro de build BlackLotus. largeur de la route est généré à partir de l'adresse MAC de la machine (Ethernet) et d'un numéro de série de volume système. Le format du message avant cryptage est comme illustré à la figure 16
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
{ “HWID”:“%s”, “Session”:“%lu”, “Owner”:“%s”, “IP”:“%s”, “OS”:“%s”, “Edition”:“%s”, “CPU”:“%s”, “GPU”:“%s”, “RAM”:“%lu”, “Integrity”:“%lu”, “SecureBoot”:“%i”, “Build”:“%lu” } |
Figure 16. Format du message de balise
Avant d'envoyer le message au C&C, les données sont d'abord chiffrées à l'aide d'une clé RSA intégrée, puis encodées en base64 sécurisée par URL. Au cours de l'analyse, nous avons trouvé deux clés RSA différentes utilisées dans les échantillons. Un exemple d'une telle demande de balise HTTP est illustré à la figure 17.
Les données reçues du C&C en réponse au message de balise doivent commencer par la valeur magique à deux octets HP ; sinon, la réponse n'est pas traitée davantage. Si la valeur magique est correcte, les données qui suivent la valeur magique sont déchiffrées à l'aide d'AES 256 bits en mode CBC avec la chaîne HWID susmentionnée utilisée comme clé.
Après déchiffrement, le message est similaire à la balise, une chaîne au format JSON, et spécifie un identifiant de commande (appelé Type) et divers paramètres supplémentaires tels que :
- Intervalle de communication C&C
- Méthode d'exécution à utiliser
- Nom du fichier de charge utile
- Type de charge utile basé sur l'extension de fichier (.sys, .exeou . Dll prise en charge)
- Jeton d'authentification censé être utilisé pour demander le téléchargement des données utiles
- Clé AES utilisée pour déchiffrer les données utiles
Toutes les commandes prises en charge et leurs descriptions sont répertoriées dans le tableau 2.
Tableau 2. Commandes C&C
Type de commande | Description de la commande |
---|---|
1 | Téléchargez et exécutez un pilote de noyau, une DLL ou un exécutable standard |
2 | Téléchargez une charge utile, désinstallez le bootkit et exécutez la charge utile - probablement utilisée pour mettre à jour le bootkit |
3 | Désinstallez le bootkit et quittez |
Dans ces commandes, le C&C peut spécifier si la charge utile doit d'abord être déposée sur le disque avant de l'exécuter, ou être exécutée directement en mémoire. Dans les cas impliquant de déposer le fichier sur le disque, le ProgramData dossier sur le volume du système d'exploitation est utilisé comme dossier de destination et le nom de fichier et l'extension sont spécifiés par le serveur C&C. Dans le cas de l'exécution de fichiers directement en mémoire, svchost.exe est utilisé comme cible d'injection. Lorsque le C&C envoie une commande nécessitant la coopération du pilote du noyau, ou qu'un opérateur veut exécuter du code en mode noyau, le mécanisme décrit dans le Communication avec le téléchargeur HTTP section est utilisée.
Astuces anti-analyse
Pour rendre la détection et l'analyse de ce logiciel malveillant plus difficiles, son auteur a tenté de limiter au minimum la visibilité des artefacts de fichiers standard, tels que les chaînes de texte, les importations ou d'autres données intégrées non chiffrées. Vous trouverez ci-dessous un résumé des techniques utilisées.
- Cryptage des chaînes et des données
- Toutes les chaînes utilisées dans les échantillons sont chiffrées à l'aide d'un chiffrement simple.
- Tous les fichiers intégrés sont cryptés à l'aide d'AES 256 bits en mode CBC.
- Les clés de chiffrement des fichiers individuels peuvent varier d'un échantillon à l'autre.
- En plus du cryptage AES, certains fichiers sont également compressés à l'aide de LZMS.
- Résolution d'API d'exécution uniquement
- Dans tous les exemples (le cas échéant), les API Windows sont toujours résolues exclusivement pendant l'exécution et les hachages de fonction au lieu des noms de fonction sont utilisés pour trouver les adresses de fonction API souhaitées en mémoire.
- Dans certains cas, un direct appel système l'invocation d'instruction est utilisée pour invoquer la fonction système souhaitée.
- Communication réseau
- Communique via HTTPS.
- Tous les messages envoyés au C&C par le téléchargeur HTTP sont chiffrés à l'aide d'une clé publique RSA intégrée.
- Tous les messages envoyés du C&C au téléchargeur HTTP sont cryptés à l'aide d'une clé dérivée de l'environnement de la machine de la victime ou à l'aide d'une clé AES fournie par le C&C.
- Astuces anti-débogage et anti-VM - si elles sont utilisées, elles sont généralement placées juste au début du point d'entrée. Seules des astuces occasionnelles de détection de bac à sable ou de débogueur sont utilisées.
Atténuations et remédiation
- Tout d'abord, bien sûr, il est indispensable de maintenir à jour votre système et son produit de sécurité - pour augmenter les chances qu'une menace soit arrêtée dès le début, avant qu'elle ne puisse atteindre la persistance pré-OS.
- Ensuite, l'étape clé qui doit être prise pour empêcher l'utilisation de binaires UEFI vulnérables connus pour contourner UEFI Secure Boot est leur révocation dans la base de données de révocation UEFI (dbx) – sur un système Windows, dbx les mises à jour doivent être distribuées à l'aide des mises à jour Windows.
- Le problème est que la révocation de fichiers binaires Windows UEFI largement utilisés peut empêcher le démarrage de milliers de systèmes obsolètes, d'images de récupération ou de sauvegardes. Par conséquent, la révocation prend souvent trop de temps.
- Notez que la révocation des applications Windows utilisées par BlackLotus empêcherait l'installation du bootkit, mais comme le programme d'installation remplacerait le chargeur de démarrage de la victime par celui révoqué, cela pourrait rendre le système impossible à démarrer. Pour récupérer dans ce cas, une réinstallation du système d'exploitation ou simplement une récupération ESP résoudrait le problème.
- Si la révocation se produisait après la définition de la persistance BlackLotus, le bootkit resterait fonctionnel, car il utilise un shim légitime avec une clé MOK personnalisée pour la persistance. Dans ce cas, la solution d'atténuation la plus sûre serait de réinstaller Windows et de supprimer la clé MOK inscrite des attaquants en utilisant le mokutil utilitaire (une présence physique est requise pour effectuer cette opération en raison de l'interaction nécessaire de l'utilisateur avec le gestionnaire MOK lors du démarrage).
Points clés à retenir
De nombreuses vulnérabilités critiques affectant la sécurité des systèmes UEFI ont été découvertes au cours des dernières années. Malheureusement, en raison de la complexité de l'ensemble de l'écosystème UEFI et des problèmes de chaîne d'approvisionnement associés, bon nombre de ces vulnérabilités ont laissé de nombreux systèmes vulnérables même longtemps après que les vulnérabilités ont été corrigées - ou du moins après qu'on nous a dit qu'elles étaient corrigées. Pour une meilleure image, voici quelques exemples d'échecs de correctif ou de révocation permettant des contournements de démarrage sécurisé UEFI uniquement depuis l'année dernière :
- Tout d'abord, bien sûr, CVE-2022-21894 – la vulnérabilité exploitée par BlackLotus. Un an après la correction de la vulnérabilité, les binaires UEFI vulnérables ne sont toujours pas révoqués, permettant à des menaces telles que BlackLotus d'opérer furtivement sur des systèmes avec UEFI Secure Boot activé, offrant ainsi aux victimes un faux sentiment de sécurité.
- Début 2022, nous avons dévoilé plusieurs vulnérabilités UEFI qui permettent, entre autres, de désactiver UEFI Secure Boot. De nombreux appareils concernés ne sont plus pris en charge par l'OEM, donc non réparés (même si ces appareils n'étaient pas si vieux - comme 3 à 5 ans au moment de la divulgation de la vulnérabilité). En savoir plus dans notre article de blog : Lorsque "sécurisé" n'est pas du tout sécurisé : vulnérabilités UEFI à fort impact découvertes dans les ordinateurs portables grand public Lenovo
- Plus tard en 2022, nous avons découvert un quelques autres vulnérabilités UEFI, dont l'exploitation permettrait également à des attaquants de désactiver très facilement UEFI Secure Boot. Comme l'ont souligné d'autres chercheurs de binaire, plusieurs appareils répertoriés dans le consultatif n'ont pas été patchés, ou n'ont pas été patchés correctement, même quelques mois après l'avis, laissant les appareils vulnérables. Inutile de dire que, comme dans le cas précédent, certains appareils resteront vulnérables pour toujours, car ils ont atteint leur date de fin de support.
Ce n'était qu'une question de temps avant que quelqu'un profite de ces échecs et crée un bootkit UEFI capable de fonctionner sur des systèmes avec UEFI Secure Boot activé. Comme nous l'avons suggéré l'année dernière dans notre Présentation RSA, tout cela rend le passage à l'ESP plus faisable pour les attaquants et une voie à suivre possible pour les menaces UEFI - l'existence de BlackLotus le confirme.
IoCs
Fichiers
SHA-1 | Nom de fichier | Détection | Description |
---|---|---|---|
05846D5B1D37EE2D716140DE4F4F984CF1E631D1 | N/D | Win64/BlackLotus.A | Installateur de BlackLotus. |
A5A530A91100ED5F07A5D74698B15C646DD44E16 | N/D | Win64/BlackLotus.A | Installateur de BlackLotus. |
D82539BFC2CC7CB504BE74AC74DF696B13DB486A | N/D | Win64/BlackLotus.A | Installateur de BlackLotus. |
16B12CEA54360AA42E1120E82C1E9BC0371CB635 | N/D | Win64/BlackLotus.A | Installateur de BlackLotus. |
DAE7E7C4EEC2AC0DC7963C44A5A4F47D930C5508 | N/D | Win64/BlackLotus.A | Installateur de BlackLotus. |
45701A83DEC1DC71A48268C9D6D205F31D9E7FFB | N/D | Win64/BlackLotus.A | Installateur de BlackLotus. |
2CE056AE323B0380B0E87225EA0AE087A33CD316 | N/D | EFI/BlackLotus.B | Kit de démarrage BlackLotus UEFI. |
5A0074203ABD5DEB464BA0A79E14B7541A033216 | N/D | EFI/BlackLotus.B | Kit de démarrage BlackLotus UEFI. |
5DC9CBD75ABD830E83641A0265BFFDDD2F602815 | N/D | EFI/BlackLotus.B | Kit de démarrage BlackLotus UEFI. |
97AEC21042DF47D39AC212761729C6BE484D064D | N/D | EFI/BlackLotus.B | Kit de démarrage BlackLotus UEFI. |
ADCEEC18FF009BED635D168E0B116E72096F18D2 | N/D | EFI/BlackLotus.B | Kit de démarrage BlackLotus UEFI. |
DBC064F757C69EC43517EFF496146B43CBA949D1 | N/D | EFI/BlackLotus.B | Kit de démarrage BlackLotus UEFI. |
06AF3016ACCDB3DFE1C23657BF1BF91C13BAA757 | N/D | Win64/BlackLotus.B | Téléchargeur HTTP BlackLotus. |
0C0E78BF97116E781DDE0E00A1CD0C29E68D623D | N/D | Win64/BlackLotus.B | Téléchargeur HTTP BlackLotus. |
6D8CEE28DA8BCF25A4D232FEB0810452ACADA11D | N/D | Win64/BlackLotus.B | Téléchargeur HTTP BlackLotus. |
74FF58FCE8F19083D16DF0109DC91D78C94342FA | N/D | Win64/BlackLotus.B | Téléchargeur HTTP BlackLotus. |
ACC74217CBE3F2E727A826B34BDE482DCAE15BE6 | N/D | Win64/BlackLotus.B | Téléchargeur HTTP BlackLotus. |
111C4998F3264617A7A9D9BF662D4B1577445B20 | N/D | Win64/BlackLotus.B | Téléchargeur HTTP BlackLotus. |
17FA047C1F979B180644906FE9265F21AF5B0509 | N/D | Win64/BlackLotus.C | Pilote du noyau BlackLotus. |
1F3799FED3CF43254FE30DCDFDB8DC02D82E662B | N/D | Win64/BlackLotus.C | Pilote du noyau BlackLotus. |
4B882748FAF2C6C360884C6812DD5BCBCE75EBFF | N/D | Win64/BlackLotus.C | Pilote du noyau BlackLotus. |
91F832F46E4C38ECC9335460D46F6F71352CFFED | N/D | Win64/BlackLotus.C | Pilote du noyau BlackLotus. |
994DC79255AEB662A672A1814280DE73D405617A | N/D | Win64/BlackLotus.C | Pilote du noyau BlackLotus. |
FFF4F28287677CAABC60C8AB36786C370226588D | N/D | Win64/BlackLotus.C | Pilote du noyau BlackLotus. |
71559C3E2F3950D4EE016F24CA54DA17D28B9D82 | N/D | EFI/BlackLotus.C | Magasin de données de configuration de démarrage BlackLotus (BCD) supprimé par le programme d'installation de BlackLotus. |
D6D3F3151B188A9DA62DEB95EA1D1ABEFF257914 | N/D | EFI/BlackLotus.C | Magasin de données de configuration de démarrage BlackLotus (BCD) supprimé par le programme d'installation de BlackLotus. |
547FAA2D64B85BF883955B723B07635C0A09326B | N/D | EFI/BlackLotus.A | Chargeur de charge utile d'exploitation BlackLotus CVE-2022-21894. |
D1BBAA3D408E944C70B3815471EED7FA9AEE6425 | N/D | EFI/BlackLotus.A | Chargeur de charge utile d'exploitation BlackLotus CVE-2022-21894. |
0E6DD7110C38464ECAA55EE4E2FA303ADA0EDEFB | N/D | EFI/BlackLotus.A | Charge utile d'exploitation BlackLotus CVE-2022-21894 - Application MokInstaller EFI. |
D6BB89D8734B3E49725362DAE9A868AE681E8BD6 | N/D | EFI/BlackLotus.A | Charge utile d'exploitation BlackLotus CVE-2022-21894 - Application MokInstaller EFI. |
164BB587109CFB20824303AD1609A65ABB36C3E9 | N/D | Win64/BlackLotus.D | Module de contournement UAC de l'installateur BlackLotus. |
Certificats
Numéro de série | 570B5D22B723B4A442CC6EEEBC2580E8 |
Empreinte | C8E6BF8B6FDA161BBFA5470BCC262B1BDC92A359 |
Sujet NC | Quand ils pleurent CA |
Sujet O | N/D |
Sujet L | N/D |
Sujets | N/D |
Sujet C | N/D |
Valide à partir de | 2022-08-13 17:48:44 |
Valable pour | 2032-08-13 17:58:44 |
Réseau
IP | Domaine | Fournisseur d'hébergement | Vu la première fois | Détails |
---|---|---|---|---|
N/D | xrepositoryx[.]nom | N/D | 2022-10-17 | BlackLotus C&C. https://xrepositoryx[.]name/network/API/hpb_gate.php |
N/D | mondépôtx[.]com | N/D | 2022-10-16 | BlackLotus C&C. https://myrepositoryx[.]com/network/API/hpb_gate.php |
104.21.22[.]185 | erdjknfweklsgwfmewfgref[.]com | Cloud Flare, Inc. | 2022-10-06 | BlackLotus C&C. https://erdjknfweklsgwfmewfgref[.]com/API/hpb_gate.php |
164.90.172[.]211 | harrysucksdick[.]com | Digital Ocean, LLC | 2022-10-09 | BlackLotus C&C. https://harrysucksdick[.]com/API/hpb_gate.php |
185.145.245[.]123 | heikickg[.]com frassirishiproc[.]com |
SIA VEESP | 2022-10-12 | BlackLotus C&C. https://heikickgn[.]com/API/hpb_gate.php https://frassirishiproc[.]com/API/hpb_gate.php |
185.150.24[.]114 | mondépôt[.]nom | Centre de données SkyLink BV | 2022-10-14 | BlackLotus C&C. mondépôt[.]nom/réseau/API/hpb_gate.php |
190.147.189[.]122 | egscorp[.]net | Telmex Colombie SA | 2022-08-24 | BlackLotus C&C. https://egscorp[.]net/API/hpb_gate.php |
Techniques d'ATT&CK D'ONGLET
Ce tableau a été construit avec Version 12 du cadre MITRE ATT&CK.
Tactique | ID | Nom | Description |
---|---|---|---|
Développement des ressources | T1587.002 | Développer des capacités : certificats de signature de code | Certains échantillons BlackLotus sont signés avec un certificat auto-signé. |
T1588.005 | Obtenir des capacités : exploits | BlackLotus a utilisé un exploit connu du public pour contourner UEFI Secure Boot. | |
Internationaux | T1203 | Exploitation pour l'exécution du client | Les installateurs de BlackLotus peuvent exploiter CVE-2022-21894 pour réaliser l'exécution de code arbitraire sur les systèmes avec UEFI Secure Boot activé. |
T1559 | Communication interprocessus | Le téléchargeur HTTP BlackLotus utilise la section nommée pour transmettre des commandes au composant en mode noyau. | |
T1106 | API native | Le téléchargeur HTTP BlackLotus utilise diverses API Windows natives pour réaliser l'exécution de code sur la machine compromise. | |
T1129 | Modules partagés | Le téléchargeur HTTP BlackLotus peut charger et exécuter les DLL reçues du serveur C&C. | |
Persistence | T1542.003 | Démarrage pré-OS : Bootkit | Le bootkit BlackLotus est déployé sur la partition système EFI et exécuté pendant le démarrage. |
Elévation de Privilèges | T1548.002 | Mécanisme de contrôle d'élévation des abus : contournement du contrôle de compte d'utilisateur | Le programme d'installation de BlackLotus tente d'augmenter les privilèges en contournant le contrôle de compte d'utilisateur. |
T1134.002 | Manipulation de jeton d'accès : créer un processus avec un jeton | Le téléchargeur HTTP BlackLotus peut utiliser WTSQueryUserToken et CreateProcessAsUserW pour exécuter les charges utiles téléchargées dans un nouveau processus avec les privilèges du système local. | |
Évasion défensive | T1622 | Évasion du débogueur | Les composants BlackLotus utilisent diverses techniques pour détecter si un débogueur en mode noyau ou en mode utilisateur est en cours d'exécution sur une victime. |
T1574 | Flux d'exécution de piratage | Le bootkit BlackLotus détourne divers composants inclus dans les premières étapes du processus de démarrage de Windows (Gestionnaire de démarrage Windows, chargeur de système d'exploitation Windows, noyau Windows et pilotes spécifiques) pour éviter la détection en désactivant diverses fonctionnalités de sécurité Windows (VBS, Windows Defender) et exécuter furtivement son mode noyau et composants en mode utilisateur | |
T1562 | Altérer les défenses | Les composants BlackLotus peuvent désactiver BitLocker et Windows Defender pour éviter la détection. | |
T1070.004 | Suppression de l'indicateur : suppression de fichier | Le programme d'installation de BlackLotus se supprime après avoir déployé avec succès des fichiers sur la partition système EFI. De plus, après une exploitation réussie de CVE-2022-21894, BlackLotus supprime les traces d'exploitation en supprimant tous les fichiers inclus dans la chaîne d'exploitation de la partition système EFI. | |
T1070.009 | Suppression de l'indicateur : Effacer la persistance | BlackLotus peut se désinstaller en supprimant tous les fichiers de démarrage de l'ESP et en restaurant le gestionnaire de démarrage Windows de la victime d'origine. | |
T1036.005 | Masquage : correspond à un nom ou à un emplacement légitime | BlackLotus tente de masquer ses fichiers déployés sur l'ESP en utilisant des noms de fichiers légitimes, tels que grubx64.efi (si UEFI Secure Boot est activé sur la machine compromise) ou bootmgfw.efi (si UEFI Secure Boot est désactivé sur la machine compromise). | |
T1112 | Modifier le registre | Le programme d'installation de BlackLotus modifie le registre Windows pour désactiver la fonction de sécurité Windows HVCI. | |
T1027 | Fichiers ou informations obscurcis | Presque toutes les chaînes intégrées dans les composants BlackLotus sont cryptées à l'aide d'un chiffrement combiné personnalisé et décryptées uniquement lorsque cela est nécessaire. | |
T1027.007 | Fichiers ou informations masqués : résolution d'API dynamique | Les composants BlackLotus utilisent une résolution d'API dynamique tout en utilisant des hachages de noms d'API au lieu de noms. | |
T1027.009 | Fichiers ou informations obscurcis : charges utiles intégrées | Presque tous les fichiers intégrés dans les composants BlackLotus sont cryptés à l'aide d'AES. | |
T1542.003 | Démarrage pré-OS : Bootkit | Le bootkit BlackLotus est déployé sur la partition système EFI et exécuté au cours des premières étapes de démarrage du système d'exploitation, et est donc capable de contrôler le processus de démarrage du système d'exploitation et d'échapper à la détection. | |
T1055.012 | Injection de processus : injection de bibliothèque de liens dynamiques | Le téléchargeur HTTP BlackLotus peut injecter une DLL dans un nouveau svchost.exe processus utilisant le processus d'évidement. | |
T1055.002 | Injection de processus : injection d'exécutables portables | Le pilote BlackLotus injecte l'exécutable portable du téléchargeur HTTP dans un winlogon.exe processus. | |
T1014 | Rootkit | Le pilote du noyau BlackLotus protège les fichiers de bootkit sur l'ESP contre la suppression. | |
T1497.001 | Virtualisation/sandbox évasion : vérifications du système | BlackLotus utilise diverses vérifications du système, notamment la vérification des valeurs de registre spécifiques au bac à sable, pour détecter et éviter les environnements de virtualisation et d'analyse. | |
Découverte | T1622 | Évasion du débogueur | Les composants BlackLotus utilisent diverses techniques pour détecter si un débogueur en mode noyau ou en mode utilisateur est en cours d'exécution sur une victime. |
T1082 | Découverte des informations système | BlackLotus collecte des informations système (IP, GPU, CPU, mémoire, version du système d'exploitation) sur un hôte compromis. | |
T1614 | Découverte de l'emplacement du système | BlackLotus peut se fermer si l'un des paramètres régionaux système suivants est identifié sur l'hôte compromis : ro-MD, ru-MD, ru-RU, royaume-uni-UA, be-BY, hy-AM, kk-KZ. | |
T1016 | Découverte de la configuration réseau du système | Le téléchargeur HTTP BlackLotus peut déterminer l'adresse IP publique d'un hôte compromis en demandant api.ipify[.]org après-vente. | |
T1016.001 | Découverte de la configuration réseau du système : découverte de la connexion Internet | Le téléchargeur HTTP BlackLotus vérifie la connexion Internet en interrogeant Microsoft www.msftncsi[.]com/ncsi[.]txt | |
T1497.001 | Virtualisation/sandbox évasion : vérifications du système | BlackLotus utilise diverses vérifications du système, notamment la vérification des valeurs de registre spécifiques au bac à sable, pour détecter et éviter les environnements de virtualisation et d'analyse. | |
Commander et contrôler | T1071.001 | Protocole de couche d'application : protocoles Web | BlackLotus utilise HTTPS pour communiquer avec son C&C. |
T1132.001 | Codage des données : Codage standard | BlackLotus encode les données cryptées dans la communication C&C avec base64 URL-safe. | |
T1573.001 | Canal crypté : cryptographie symétrique | BlackLotus utilise AES 256 bits en mode CBC pour décrypter les messages reçus de son C&C. | |
T1573.002 | Canal crypté : cryptographie asymétrique | BlackLotus utilise une clé publique RSA intégrée pour chiffrer les messages envoyés à C&C. |
- Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
- Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
- La source: https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/
- 000
- 1
- 10
- 11
- 2018
- 2020
- 2022
- 7
- 9
- a
- Capable
- A Propos
- au dessus de
- abus
- accès
- accessible
- accès
- Compte
- atteindre
- Atteint
- Agis
- actes
- acteurs
- actes
- ajoutée
- ajout
- Supplémentaire
- propos
- adresses
- admin
- Avancée
- Avantage
- Publicité
- consultatif
- AES
- affectant
- Après
- à opposer à
- aka
- Tous
- consacrée
- allocations
- Permettre
- permet
- déjà
- Bien que
- toujours
- AMD
- parmi
- selon une analyse de l’Université de Princeton
- il analyse
- et le
- Anime
- Une autre
- api
- Apis
- appli
- en vigueur
- Application
- applications
- approprié
- APT
- Archive
- autour
- sur notre blog
- Évaluation de risque climatique
- associé
- Tentatives
- précaution
- Août
- auteur
- disponibles
- sauvegarde
- sauvegardes
- basé
- Essentiel
- Basics
- pour
- car
- before
- Début
- derrière
- va
- La Biélorussie
- CROYONS
- ci-dessous
- Améliorée
- jusqu'à XNUMX fois
- BleepingComputer
- Block
- Bleu
- Bonus
- Bottes
- botnets
- Pause
- Rupture
- percée
- apporter
- Apporter
- largement
- Apporté
- tampon
- construire
- construit
- intégré
- Appelez-nous
- appel
- Appels
- capacités
- capable
- les soins
- prudent
- maisons
- cas
- occasionnel
- Attraper
- causé
- les causes
- causer
- Canaux centraux
- certificat
- chaîne
- Chance
- Change
- Développement
- vérification
- Contrôles
- zéro
- prétentions
- clair
- client
- Fermer
- fonds à capital fermé
- plus
- fermeture
- code
- collègues
- Colombie
- combinaison
- combiné
- comment
- commenté
- Commun
- communément
- communiquer
- communicant
- Communication
- par rapport
- Comparaison
- compatibilité
- complètement
- complexe
- complexité
- composant
- composants électriques
- compromis
- Compromise
- concept
- concerné
- confiance
- configuration
- CONFIRMÉ
- connexion
- considérant
- consommateur
- contiennent
- contient
- contenu
- continuer
- continue
- continuellement
- des bactéries
- contrôle
- coopération
- Core
- Correspondant
- pourriez
- Cours
- couvrant
- engendrent
- créée
- crée des
- La création
- CRÉDENTIEL
- critique
- Courant
- Lecture
- Customiser
- dangereux
- données
- Centre de données
- Base de données
- Date
- désactiver
- traitement
- Décès
- Décrypter
- profond
- profond
- Réglage par défaut
- défini
- certainement, vraiment, définitivement
- dépend
- déployer
- déployé
- déployer
- déploiement
- déploie
- Dérivé
- décrire
- décrit
- voulu
- Malgré
- destination
- détail
- détaillé
- détails
- détecté
- Détection
- Déterminer
- détermination
- développé
- Développeur
- mobiles
- dispositif
- Compatibles
- DID
- différence
- différent
- DIG
- directement
- répertoires
- handicapé
- divulgation
- découvrez
- découvert
- découverte
- distribué
- distribution
- distributions
- faire
- domaines
- Ne pas
- download
- motivation
- driver
- conducteurs
- Goutte
- chuté
- Goutte
- doublons
- pendant
- Dynamic
- chacun
- "Early Bird"
- plus facilement
- même
- risque numérique
- édition
- de manière efficace
- effort
- éléments
- LE NIVEAU SUPÉRIEUR
- élevée
- intégré
- emploie
- activé
- crypté
- chiffrement
- ENGINEERING
- assez
- inscrit
- assurer
- entrée
- Environment
- environnements
- essential
- établissement
- etc
- évalué
- Pourtant, la
- événement
- événements
- Chaque
- preuve
- exemple
- exemples
- uniquement au
- exécuter
- Exécute
- exécution
- exécution
- existant
- Sortie
- Expliquer
- explication
- Exploiter
- exploitation
- Exploités
- exploits
- explorez
- extension
- externe
- réalisable
- Fonctionnalité
- en vedette
- Fonctionnalités:
- compagnon
- few
- Des champs
- Figure
- Déposez votre dernière attestation
- Fichiers
- une fonction filtre
- finale
- Trouvez
- trouver
- Prénom
- fixé
- Flash
- flux
- suivre
- Abonnement
- suit
- toujours
- formulaire
- le format
- Ancien
- forums
- Avant
- trouvé
- De
- plein
- d’étiquettes électroniques entièrement
- fonction
- fonctionnel
- fonctions
- plus
- Games
- porte
- généré
- obtenez
- donné
- donne
- objectif
- GPU
- Vert
- Groupes
- Garde
- piratage
- Poignées
- Mains
- arriver
- arrive
- Matériel
- ayant
- têtes
- ici
- Cacher
- Haute
- Hits
- Crochets
- hôte
- Comment
- Cependant
- HTTPS
- Des centaines
- identifié
- identifiant
- identifier
- image
- satellite
- immédiatement
- Impact
- mis en œuvre
- la mise en œuvre
- importations
- impossible
- in
- inclus
- Y compris
- individuel
- d'information
- informatif
- initiale
- installer
- Installé
- plutôt ;
- des services
- intégrité
- Intel
- Intelligence
- l'interaction
- Internet
- connexion Internet
- Introduction
- enquête
- impliqué
- IP
- aide
- IT
- lui-même
- Janvier
- Emploi
- sauts
- Kaspersky
- Kazakhstan
- en gardant
- ACTIVITES
- clés
- connu
- Nom
- L'année dernière
- En retard
- Nouveautés
- lancer
- couche
- conduire
- Conduit
- départ
- Lenovo
- Li
- Bibliothèque
- Probable
- LIMIT
- linux
- Liste
- Listé
- Liste
- peu
- charge
- chargeur
- chargement
- charges
- locales
- situé
- emplacement
- Location
- Longtemps
- Style
- perdre
- Faible
- mac
- click
- Les machines
- LES PLANTES
- la magie
- Entrée
- majeur
- a prendre une
- FAIT DU
- Fabrication
- malware
- gérés
- manager
- Manipulation
- manuellement
- de nombreuses
- Match
- Matière
- largeur maximale
- sens
- mécanisme
- Mémoire
- mentionné
- seulement
- message
- messages
- méthode
- Microsoft
- pourrait
- minimum
- minute
- atténuation
- Mode
- modifié
- modifier
- Module
- moment
- surveillé
- moniteurs
- mois
- PLUS
- (en fait, presque toutes)
- motivations
- Bougez
- plusieurs
- prénom
- Nommé
- noms
- indigène
- nécessaire
- Besoin
- Inutile
- Besoins
- réseau et
- Nouveauté
- next
- normalement
- nombre
- numéros
- objets
- obtenir
- octobre
- Offres Speciales
- direct
- Vieux
- ONE
- en ligne
- ouvre
- fonctionner
- d'exploitation
- opération
- opérateur
- Option
- Options
- de commander
- original
- OS
- Autre
- autrement
- Overcome
- vue d'ensemble
- propre
- propriété
- propriétaire
- paramètre
- paramètres
- partie
- les pièces
- Pièce
- Patches
- patcher
- chemin
- Patron de Couture
- motifs
- parfaite
- Effectuer
- effectuer
- persistance
- Physique
- pièce
- plateforme
- Platon
- Intelligence des données Platon
- PlatonDonnées
- PoC
- Point
- des notes bonus
- politique
- possible
- Post
- Poteaux
- défaillances
- solide
- présence
- représentent
- empêcher
- précédent
- précédemment
- principes
- Privé
- Clé privée
- privilèges
- Problème
- d'ouvrabilité
- produit
- processus
- Traité
- les process
- Produit
- Programme
- important
- preuve
- preuve de concept
- correctement
- protéger
- protégé
- L'utilisation de sélénite dans un espace est un excellent moyen de neutraliser l'énergie instable ou négative.
- protection
- protocole
- à condition de
- aportando
- public
- Clé publique
- publications
- publiquement
- publié
- but
- augmenter
- RAM
- aléatoire
- rapidement
- atteint
- Lire
- Reader
- en cours
- réal
- Réalité
- réaliser
- raison
- raisonnable
- reçu
- récent
- Récupérer
- récupération
- visée
- Indépendamment
- registres
- enregistrement
- Standard
- en relation
- rester
- enlèvement
- supprimez
- Supprimé
- enlever
- remplacer
- remplacé
- Rapports
- dépôt
- nécessaire
- conditions
- un article
- chercheur
- chercheurs
- Résolution
- résolu
- ressource
- réponse
- responsables
- REST
- restauration
- résultat
- retourner
- inverser
- Rôle
- racine
- rsa
- conférence rsa
- Courir
- pour le running
- Russie
- plus sûre
- même
- tas de sable
- Arnaque
- balayage
- programme
- pour écran
- recherche
- Deuxièmement
- secondes
- Section
- les sections
- sécurisé
- sécurité
- semble
- envoi
- sens
- en série
- Série
- service
- Services
- Session
- set
- Sets
- mise
- plusieurs
- Partager
- Shorts
- devrait
- montré
- Spectacles
- signer
- signaux
- signé
- signature
- Signes
- similaires
- étapes
- simplifié
- simplement
- depuis
- SIX
- Taille
- So
- jusqu'à présent
- Soft
- Logiciels
- vendu
- sur mesure
- quelques
- Quelqu'un
- quelque chose
- Sources
- Space
- groupe de neurones
- spécification
- spécifié
- Diffusion
- Étape
- étapes
- autonome
- Standard
- peuplements
- Commencer
- j'ai commencé
- départs
- Commencez
- Statut
- rester
- étapes
- Étapes
- Encore
- arrêté
- Boutique
- stockée
- simple
- structure
- Soumission
- ultérieur
- réussi
- Avec succès
- tel
- Suggère
- résumé
- RÉSUMÉ
- Support
- Appareils
- Appuyer
- Les soutiens
- supposé
- suspendu
- symbole
- syntaxe
- combustion propre
- Système
- table
- Prenez
- prend
- prise
- parlant
- Target
- tâches
- équipe
- Technique
- techniques
- temporaire
- La
- Les bases
- les informations
- leur
- donc
- chose
- des choses
- milliers
- menace
- acteurs de la menace
- des menaces
- trois
- Avec
- fiable
- calendrier
- pointe
- à
- aujourd'hui
- ensemble
- jeton
- trop
- les outils
- sujet
- déclenché
- confiance
- TOUR
- Tourné
- Tournant
- débutante
- Ukraine
- sous
- compréhension
- mise à jour
- Mises à jour
- a actualisé
- Actualités
- us
- Utilisation
- utilisé
- Utilisateur
- d'habitude
- utilitaire
- Plus-value
- Valeurs
- divers
- Vérification
- vérifié
- vérifier
- version
- via
- Victime
- victimes
- VIOLATION
- Violations
- définition
- le volume
- volumes
- vulnérabilités
- vulnérabilité
- Vulnérable
- Attendre
- façons
- web
- bien connu
- Quoi
- Qu’est ce qu'
- que
- qui
- tout en
- la totalité
- large
- Wikipédia
- Sauvage
- sera
- fenêtres
- fenêtres 11
- dans les
- sans
- activités principales
- vos contrats
- pire
- pourra
- écriture
- code écrit
- an
- années
- Vous n'avez
- Votre
- zéphyrnet
- zéro