Dans ce contexte, la principale mesure de sécurité disponible pour sécuriser les données au repos est le chiffrement complet du disque. Pour cela, la plupart des entreprises s’appuient sur l’outil de chiffrement de disque intégré de Microsoft, BitLocker. Cependant, on suppose souvent que le simple fait d’activer le chiffrement du disque suffit à protéger les données.

Bien que BitLocker soit présenté comme la solution pour garantir la confidentialité et l’intégrité des données, il peut néanmoins être contourné, à l’aide d’attaques matérielles ou logicielles peu coûteuses. De telles attaques entraînent la perte totale de confidentialité et d’intégrité sur la machine cible.

Dans cet article, nous résumons le fonctionnement de BitLocker et nous nous appuyons sur ces connaissances pour examiner les récentes attaques physiques et logiques qui continuent de menacer la sécurité des postes de travail.

Rappels sur le fonctionnement de BitLocker

BitLocker est un mécanisme de chiffrement complet du disque intégré à Windows depuis son introduction avec Windows Vista en janvier 2007, défini comme suit : « BitLocker est une fonctionnalité de sécurité Windows qui protège vos données en chiffrant vos lecteurs. Ce chiffrement garantit que si une personne tente d’accéder à un disque hors connexion, elle ne pourra pas lire son contenu. » (Vue d’ensemble de BitLocker – Support Microsoft)

Sa sécurité repose sur une hiérarchie de clés simple : la fuite d’une clé peut compromettre l’ensemble du disque.

Deux clés sont impliquées :

1. La clé de Full Volume Encryption Key (FVEK), qui chiffre les secteurs du disque
2. La clé Volume Master Key (VMK), qui chiffre la FVEK. Cette clé est stockée et protégée par le module TPM (Trusted Platform Module), un composant de sécurité conçu pour stocker des secrets cryptographiques.

La FVEK est stockée sur le disque chiffré par la VMK ; pendant le démarrage, le déchiffrement s’effectue comme ceci :

Le poste de travail utilisé comme exemple dans cet article fournit la clé VMK via le bus SPI, mais divers autres protocoles tels que LPC peuvent être observés (LPC n’implique pas davantage de fonctionnalités de sécurité que SPI).

La clé VMK est libérée pendant le démarrage via un bus SPI (protocole série à faible débit avec 4 lignes de signaux) entre la puce TPM et le processeur. Cette clé est l’élément le plus critique, car elle permet le déchiffrement de l’ensemble du disque.

Cette architecture montre qu’à un moment donné, la clé VMK est transmise en clair sur le bus SPI et que la clé FEVK est stockée sans cryptage dans la mémoire RAM. Cette configuration peut être exploitée par des attaquants à l’aide de diverses attaques physiques et logiques. Les sections suivantes décrivent comment ce comportement peut être exploité.

Attaques physiques

Les attaques physiques nécessitent un équipement physique dédié pour exploiter la vulnérabilité. Cela implique généralement l’utilisation d’outils tels que des sondes, des analyseurs logiques et des périphériques malveillants dédiés.

Contre BitLocker et la TPM, les attaques matérielles peuvent encore, avec peu de prérequis, être exploitées aujourd’hui. Cette section se concentre sur les deux principales techniques matérielles : le sniffing de TPM et les attaques DMA.

TPM sniffing

Au repos, le VMK est stocké et protégé par le TPM. Elle est libérée au démarrage et transmise au CPU. Le TPM part du principe que le canal de communication est sécurisé et ne peut être compromis. Cependant, sur la carte mère, ce canal de communication est généralement défini par un bus SPI reliant différentes puces entre elles.

Conditions préalables à l’attaque :

• 140 € de sondes et d’analyseur logique.
• Accès physique à un système éteint.
• BitLocker configuré sans code PIN de pré-boot.

L’idée principale derrière cette attaque est de localiser le bus sur lequel le VMK est transmis, de placer des sondes pour capturer les données échangées sur le bus et d’extraire le VMK au démarrage.

La première étape consiste donc à identifier la puce TPM et son interface SPI. Heureusement, les TPM sont des composants standardisés dont le brochage est connu. En examinant la disposition de la carte mère, les fiches techniques ou les informations accessibles au public, l’attaquant peut déterminer quelles broches correspondent aux signaux SPI du TPM.

Une fois le bus identifié, l’attaquant établit une connexion physique stable avec le bus en fixant des sondes sur la carte mère. Dans l’exemple actuel, les sondes utilisées sont des Sensepeek SP10, pour leur précision. En pratique, le bus SPI est souvent partagé avec d’autres composants qui reçoivent passivement le trafic sans le traiter, telle que la puce flash du BIOS. Il est souvent plus facile de renifler le bus à partir de ces composants, et c’est l’approche utilisée dans notre exemple ci-dessous :

Un analyseur logique est ensuite connecté aux sondes en mode d’écoute passive. Cet appareil permet de capturer et de décoder les signaux numériques. Il permet l’analyse et la traduction des signaux dans un protocole connu, tel que SPI. Dans l’exemple actuel, l’analyseur logique sipeed slogic16u3 est utilisé. La seule nécessité est d’utiliser un analyser logique avec un taux de capture suffisant. Celui-ci permet de capturer les signaux à 200MHz, ce qui est suffisant. Il est important de noter que l’attaquant n’a pas besoin d’injecter du trafic ou d’interférer avec le bus ; il lui suffit d’observer.

Des projets open source tels que PulseView peuvent être utilisés pour interpréter les données capturées. Des plugins accessibles au public peuvent ensuite être utilisés pour décoder les signaux électroniques et les reconvertir en protocoles de communication :

PluseView effectue plusieurs étapes dans la même analyse. Tout d’abord, les signaux détectés sont convertis en protocole SPI. Ensuite, le protocole SPI est converti en commandes TPM, qui sont documentées publiquement. Ces commandes ont des en-têtes spécifiques, telles que lecture ou écriture de la mémoire. Ces fonctions permettent d’interpréter les données transmises et de récupérer, comme le montre la capture, la VMK.

À ce stade, le secret de BitLocker a été compromis sans modifier l’état du système ni échouer aux contrôles d’intégrité.

Une fois le VMK récupéré, l’attaquant peut retirer le disque et le déchiffrer hors ligne à l’aide du projet open source Dislocker. Ce logiciel simule une utilisation légitime du VMK et trouve le secteur contenant la FVEK sur partition encore chiffrée. L’utilisation légitime du FVEK est ensuite utilisée pour déchiffrer l’intégralité de la partition Windows :

Toutes les données stockées sur le disque deviennent accessibles, y compris les fichiers système, les données utilisateur et les identifiants enregistrés. Cela entraîne une perte totale de confidentialité et d’intégrité. Contrairement aux attaques logicielles, cette technique ne laisse aucune trace forensique sur le système. Cette attaque est un vecteur d’attaque de plus en plus probable à mesure que le matériel devient plus accessible, moins cher et mieux documenté.

Il existe deux versions principales du TPM, 1.2 et 2.0 (intégrant une fonctionnalité cryptographique) : cette attaque fonctionne sur les deux versions. Le sniffing de TPM reste possible sur la plupart des postes de travail.

Toutefois, sur certains modèles d’ordinateurs portables plus récents, le TPM est directement intégré au processeur (firmware TPM). Ces firmware TPM rendent le sniffing de la TPM impossible. Cependant, ces types de TPM sont nouveaux et peu répandus.

Direct Memory Access

Direct Memory Access (DMA) est une fonctionnalité légitime qui permet à certains composants matériels, tels que les cartes réseau, les cartes graphiques ou les périphériques externes connectés via des interfaces haut débit, d’accéder directement à la mémoire vive (RAM) d’un ordinateur, sans impliquer constamment le processeur  (par synacktiv-slides-ng) :

BitLocker part du principe que les accès à la mémoire sont contrôlés et fiables, ses clés étant stockées dans la TPM ou la RAM, supposément inaccessibles à un attaquant. Mais cette hypothèse peut être remise en cause. En exploitant cette confiance au niveau matériel, les attaquants disposant d’appareils compatibles avec l’accès direct à la mémoire (DMA) peuvent lire et manipuler la mémoire, compromettant ainsi la confidentialité et l’intégrité des données du poste de travail. L’idée principale derrière cette attaque est de connecter un périphérique compatible DMA au poste de travail et de l’utiliser pour accéder directement la mémoire physique pendant que le système est en cours d’exécution.

Conditions préalables à l’attaque :

• Environ 160 € de matériel.
• Accès physique au poste de travail.
• BitLocker configuré sans code PIN de pré-boot.
• Protections DMA désactivées (IOMMU / Kernel DMA Protection) dans les paramètres du BIOS.

Les systèmes modernes s’appuient sur l’Input-Output Memory Management Unit (IOMMU, Intel VT-d ou AMD-Vi) pour assurer l’isolation de la mémoire entre les mémoires périphériques et le reste du système. La première étape consiste à s’assurer que les protections DMA sont désactivées dans le BIOS.

On suppose souvent que les mots de passe BIOS protègent ces paramètres. Cependant, dans la pratique, ils constituent un contrôle faible, et les techniques de suppression des mots de passe BIOS sont bien documentées. Par conséquent, un attaquant disposant de suffisamment de temps et d’un accès physique peut souvent désactiver les protections IOMMU.

Une fois les protections DMA désactivées, l’attaquant connecte un périphérique compatible DMA à une interface PCIe exposée. Dans l’exemple actuel, un périphérique PCI-Screamer est utilisé. Ce périphérique est utilisé comme un périphérique PCIe malveillant qui permet de communiquer en DMA et d’exécuter des commandes personnalisées sur le système cible.

À ce stade, l’attaque est orchestrée à partir du poste de travail du pirate. Le projet open source lié au PCI-Screamer, PCILeech, communique avec le PCI-Screamer via USB-C et émet des commandes qui lui demandent de lire ou de modifier des régions spécifiques de la mémoire physique sur le système cible.

Le matériel DMA lui-même sert de pont : il expose la mémoire de la cible via PCIe :

PCILeech est désormais capable de charger des drivers vulnérables afin de fournir des fonctionnalités telles que :

• Exécution de code au niveau du noyau sur le système cible
• Génération de shells SYSTEM et d’autres exécutables (Windows)
• Extraction et transfert de fichiers (Linux, FreeBSD, Windows, macOS)
• Correction ou suppression des protections par mot de passe (Windows, macOS)

L’impact va bien au-delà de la simple exposition des données. Un attaquant peut extraire les clés de chiffrement BitLocker, accéder au disque déchiffré hors ligne, voire passer directement aux privilèges SYSTEM sur la machine en cours d’exécution.

Bien que cette vulnérabilité ne cible pas directement les clés BitLocker comme le font les attaques par sniffing TPM, elle remet en cause l’hypothèse fondamentale selon laquelle l’activation du chiffrement du disque suffit à protéger le système.

Attaques logiques

Contrairement aux attaques matérielles, ces techniques reposent entièrement sur des composants Windows légitimes et des mécanismes documentés. Il s’agit le plus souvent de vulnérabilités faisant l’objet d’un correctif par Microsoft. Plusieurs attaques de ce type ont été révélées au cours des dernières années.

BitPixie

La cible de cette attaque contre BitLocker est la transition entre le processus de démarrage de Windows et l’environnement de récupération.

BitLocker part du principe qu’une fois que la séquence de démarrage passe en mode de récupération, les clés cryptographiques sont correctement effacées de la mémoire. Dans certaines conditions spécifiques, cette hypothèse ne se vérifie pas, et ce comportement est exploité par l’attaque communément appelée BitPixie (CVE 2023 21563).

Conditions préalables à l’attaque :

• Accès physique au poste de travail.
• BitLocker configuré sans code PIN de pré-boot.
• BIOS avec Secure Boot activé et accès réseau (démarrage PXE).

L’idée principale derrière cette attaque est de forcer le système à passer en mode de récupération, dans lequel les clés de chiffrement BitLocker restent présentes dans la mémoire et peuvent être extraites. Elle exploite un gestionnaire de démarrage Windows signé mais vulnérable, associé à un fichier BCD (Boot Configuration Data) spécialement conçu pour forcer le système à passer en mode de récupération, dans lequel les clés BitLocker restent en mémoire.

La première étape consiste à démarrer le système cible dans l’environnement de récupération Windows (par exemple en utilisant le mécanisme Shift+Restart). À partir de là, la machine reçoit l’instruction de démarrer en PXE. Le PXE est utilisé uniquement comme mécanisme de livraison, l’installation Windows elle-même n’est pas modifiée.

Lors du premier démarrage PXE, l’attaquant fournit un gestionnaire de démarrage Windows signé mais vulnérable. Comme le fichier binaire est correctement signé, Secure Boot l’accepte. Cela permet de passer à une version du chargeur de démarrage vulnérable à BitPixie.

Un fichier BCD personnalisé est également fourni. C’est la partie critique de l’attaque :

• Le fichier BCD définit une entrée de démarrage par défaut pointant vers une partition de disque valide, mais un point de démarrage invalide.
• L’objectif est de déclencher un échec de démarrage contrôlé après que BitLocker a libéré la VMK, mais avant la fin du processus de démarrage normal.
• Cela provoque le retour de Windows en mode de récupération sans effacer la mémoire vive contenant les clés cryptographiques.

Comme le bootloader et le BCD ne sont pas chiffrés, toute cette étape peut être effectuée sans authentification auprès de Windows.

Lors du deuxième démarrage PXE, le système démarre à nouveau dans un environnement compatible avec Secure Boot. Secure Boot reste intact tout au long du processus. L’objectif est d’accéder à la mémoire système pendant que les clés BitLocker sont encore présentes dans la RAM.

À partir de cet environnement Linux, l’attaquant exploite une vulnérabilité du noyau (CVE-2024-1086) pour obtenir la possibilité de lire la mémoire système. La clé VMK, toujours présente dans la RAM en raison du processus de récupération défectueux, peut alors être localisée et extraite. Aucune attaque cryptographique n’est nécessaire ; la clé est récupérée directement dans la mémoire.

Une fois la clé VMK obtenue, l’attaquant peut déchiffrer la clé FVEK sur le disque et monter le volume protégé par BitLocker hors ligne. Toutes les données du disque deviennent alors accessibles. Cette chaîne d’attaque peut être résumée comme ceci :

La faille principale réside dans la gestion du cycle de vie des clés BitLocker plutôt que dans le chiffrement lui-même. Le processus de récupération part du principe que le passage en mode de récupération est une opération fiable et ne parvient pas à correctement effacer les données sensibles en mémoire. Le Secure Boot garantit l’intégrité du code, mais pas la bonne gestion des clés. Étant donné que les composants de démarrage signés mais vulnérables sont toujours acceptés, l’attaquant peut légalement atteindre un état dans lequel les clés BitLocker restent accessibles dans la RAM.

L’impact de BitPixie est une perte totale de confidentialité. Le disque d’un poste de travail volé, éteint et entièrement mis à jour peut être déchiffré sans attaque matérielle, modification du micrologiciel ou identifiants valides. L’attaque ne laisse aucune trace sur l’installation Windows et utilise uniquement des composants signés et des chemins de démarrage documentés. Cette attaque a été démontrée avec succès sur un poste de travail entièrement à jour en décembre 2024 lors de la conférence CCC donnée par Thomas Lambertz : “Windows BitLocker: Screwed without a Screwdriver” (Windows BitLocker: Screwed without a Screwdriver – media.ccc.de).

Autres attaques

Au-delà de BitPixie, d’autres attaques logicielles contre BitLocker ont été révélées en 2025, notamment plusieurs vulnérabilités affectant l’environnement de récupération Windows (WinRE). Cela a été présenté en décembre 2025 lors de la conférence CCC par Alon Leview : BitUnlocker: Leveraging Windows Recovery to Extract BitLocker Secrets » (Windows BitLocker: Screwed without a Screwdriver – media.ccc.de).

La cible de ces attaques est l’environnement de récupération Windows. Il fonctionne comme un système d’exploitation de récupération fiable, entièrement chargé dans la mémoire RAM. BitLocker part du principe que l’environnement de récupération traite correctement ses clés de chiffrement. Dans certaines conditions spécifiques, ces hypothèses peuvent ne pas être valables.

Comme il peut hériter de l’accès à un volume chiffré déjà déverrouillé, les faiblesses de sa logique de démarrage, de la gestion du disque RAM ou des fichiers de configuration de récupération pourraient, dans certaines conditions, être exploitées pour influencer le flux d’exécution ou accéder aux clés de chiffrement.

Bien que corrigées, ces découvertes illustrent un thème récurrent : les mécanismes Windows légitimes conçus pour la résilience peuvent involontairement élargir la surface d’attaque.

Mesures de sécurité supplémentaires

Dans la configuration par défaut de BitLocker, un attaquant dispose de plusieurs options pour attaquer BitLocker et tenter d’accéder au disque déchiffré. Le sniffing de TPM, les exploitations DMA et les attaques logicielles telles que BitPixie montrent qu’il est dangereusement naïf de supposer que « disque chiffré = sûr ».

La mesure la plus efficace consiste à utiliser un code PIN BitLocker avant le démarrage, qui nécessite une saisie de la part de l’utilisateur avant que la VMK ne soit libérée. Cela bloque la plupart des attaques dont nous avons parlé. Mais comme l’ingénierie sociale pourrait être utilisée pour le récupérer auprès du propriétaire, ce n’est pas une solution miracle.

Les TPM firmware protègent contre le sniffing TPM et les protections DMA aident à prévenir les attaques basées sur la mémoire. Malgré tout, aucune de ces mesures de contrôle n’est suffisante à elle seule.

La véritable sécurité passe par une défense en profondeur. Combiner l’authentification avant le démarrage, les protections matérielles, les environnements de récupération renforcés et les contrôles d’accès après déverrouillage. Les données sensibles doivent être protégées par plusieurs couches afin que la compromission d’un seul mécanisme n’expose pas l’ensemble du disque :

• Appliquer l’authentification pre-boot par code PIN BitLocker avant le démarrage.
• Privilégier les postes de travail avec une fTPM (firmware du CPU) plutôt qu’une dTPM.
• Activer les protections DMA / IOMMU.
• Configurer un mot de passe BIOS.
• Limiter le démarrage PXE/réseau.

Cet article Tour d’horizon de BitLocker : comprendre les menaces actuelles est apparu en premier sur RiskInsight.

Faire vivre Responder avec son temps: le potentiel caché de l’empoisonnement de résolution de noms

Conférencier : Quentin Roland

ChatGPT said:

Dans un environnement Windows typique, l’authentification SMB est omniprésente. L’empoisonnement des requêtes SMB avec des outils comme Responder permet de capturer des identifiants, mais la plupart du temps il s’agit de comptes machine ou d’authentifications qui ne peuvent pas être relayées parce que SMB applique des contrôles stricts d’intégrités. En conséquence, beaucoup d’authentifications capturées sont en pratique inutilisables pour un attaquant.

La conférence a mis en lumière un comportement souvent négligé : Windows réessaie parfois des connexions SMB échouées en se repliant vers HTTP et en utilisant le protocole WebDAV. Cela se fait via le service WebClient, installé par défaut sur la plupart des machines. L’astuce tient à la façon dont Windows interprète certains codes d’erreur. Par défaut, lorsqu’une authentification SMB échoue, le serveur renvoie le statut « STATUS_ACCESS_DENIED » et Windows s’arrête là. Mais si le serveur renvoie à la place « STATUS_LOGON_FAILURE », le système d’exploitation interprète cela comme un problème lié au protocole plutôt qu’aux identifiants. Il retente alors la connexion via le protocole WebDAV, transformant de facto une authentification SMB en une authentification HTTP.

Ce mécanisme de repli ouvre une voie surprenante pour les attaquants. Les authentifications HTTP n’exigent pas la signature par défaut, ce qui signifie qu’elles peuvent être relayées vers des services comme LDAP sans être bloquées par les protections qui rendent SMB moins exploitables. Une requête SMB empoisonnée qui serait sinon perdue devient soudainement une authentification relayée en direct pouvant servir à énumérer Active Directory, effectuer du spray de mots de passe, ou même créer de nouveaux comptes machine.

La principale limitation est que le service WebClient doit être en cours d’exécution. Bien qu’il soit installé par défaut, il n’est pas toujours actif sauf si l’utilisateur ou un processus a accédé à un partage WebDAV. Néanmoins, lorsqu’il est activé, ce repli constitue un moyen discret mais puissant de pivoter au sein d’un réseau.

Piratage d’un ticket de métro

Conférencier : Raphael Attias (rapatt)

Cette présentation était à la fois amusante et un peu inquiétante : elle montrait à quel point il peut être facile de pirater des tickets de métro avec un Flipper Zero.

Pour ceux qui ne connaissent pas, le Flipper Zero est un outil multi-fonctions de poche capable d’interagir avec divers protocoles radio, RFID, NFC, et plus encore. Même s’il ne peut pas lire tous les types de NFC, il fonctionne avec beaucoup de cartes courantes — y compris les MiFare Ultralight utilisées dans de nombreux systèmes de métro, festivals, voire hôpitaux.

Le conférencier a commencé par expliquer l’évolution des tickets de métro : d’abord le papier perforé, puis les bandes magnétiques, et maintenant RFID/NFC. Dans la ville dans laquelle il réside, les tickets utilisent MiFare Ultralight, qui offrent entre 48 et 144 octets de mémoire et un UID de 7 octets : très petits et simples comparés aux cartes plus modernes.

Le détail clé : lors de la validation d’un ticket à une porte de métro, le système met simplement à jour un octet sur la page 3 de la carte pour le marquer comme « utilisé ». Cela signifie que si l’on peut lire et écrire dans ce secteur, il est possible de remettre le ticket à « non utilisé » et de voyager à nouveau. Le conférencier a passé neuf mois à analyser sa carte, en extrayant les données avant et après validation et en cartographiant quels octets contrôlaient quoi. Finalement, il a réussi à modifier les données pour obtenir des trajets illimités.

Mais cela ne s’est pas arrêté là. Il a même pu cloner le ticket sur son Flipper Zero, l’utiliser directement aux portillons, le montrer aux contrôleurs, et même le recharger sur les bornes officielles. Tout cela parce que le système faisait confiance aux données stockées sur la carte plutôt que de tout gérer côté serveur.

Bien sûr, cette attaque a ses limites. Elle dépend fortement du système de billetterie — toutes les villes n’utilisent pas MiFare Ultralight, et des implémentations plus avancées détecteraient ce type de manipulation. De plus, gérer des fonctionnalités comme les correspondances ou les dates d’expiration nécessite de modifier des champs supplémentaires, ce qui complique le piratage. Pourtant, dans ce cas précis, la conception faible du système rendait possible le voyage illimité.

La solution semble simple : ne conserver que l’UID sur la carte et déplacer toute la logique du ticket côté serveur. Ainsi, même si quelqu’un restaure ou clone sa carte, le système serveur saura si elle est valide ou non. Pour l’instant, la ville en question n’a pas corrigé le problème, ce qui signifie que des trajets gratuits restent techniquement possibles.

Conférencier : Yassine OUKESSOU

Un nouvel outil nommé AsRepCatcher a été développé par le SOC Team Leader de l’équipe ITrust. Comme l’auteur doit réaliser des audits internes réguliers, il se trouve confronté au problème suivant : comment compromettre un compte de domaine valide sans disposer des identifiants ?

Bien qu’il existe de nombreuses techniques pour obtenir un accès initial, les environnements deviennent de plus en plus sécurisés et les remédiations sont appliquées de manière croissante :

• EternalBlue / PrintNightmare / ZeroLogon : machines patchées
• LLMNR / NBT-NS / mDNS Poisoning : protocoles désactivés
• AsRep Roasting : pré-authentification activée par défaut sur tous les comptes
• Kerberoasting : SPN placés uniquement sur les comptes de service et utilisation de gMSA
• Partages réseau : lecture désactivée pour les comptes anonymes ou invités
• Brute force sur mots de passe faibles : politique de mot de passe forte
• Relais : protocoles signés
• Phishing : sensibilisation des utilisateurs

Bien que cette liste ne soit pas exhaustive, elle représente la majorité des tests réalisés par un auditeur interne.

Cependant, l’auteur a remarqué que l’accès réseau est toujours fourni à l’auditeur, généralement dans la zone réservée aux utilisateurs standard : le VLAN utilisateur. Dans ce VLAN, si un utilisateur capture le trafic, il pourra observer des paquets liés à l’authentification, en particulier avec les protocoles NTLM ou Kerberos.

Il se trouve qu’avec le protocole Kerberos, une dérivée du mot de passe de l’utilisateur est utilisée (appelée hash) pour créer la requête KRB_AS_REP (dans la clé de session).

Ainsi, un attaquant capable de récupérer cette requête pourrait ensuite tenter de casser le mot de passe de l’utilisateur. C’est exactement ce que tente de faire l’outil AsRepCatcher (d’où son nom).

Pour récupérer la requête KRB_AS_REP, l’outil utilise une technique bien connue appelée ARP Spoofing :

Un article de Veracode explique ce qu’est l’ARP Spoofing et comment s’en protéger : https://www.veracode.com/security/arp-spoofing/

AsRepCatcher modifie la table ARP des utilisateurs légitimes du VLAN, qui enverront désormais leurs requêtes KRB_AS_REQ vers l’attaquant. Ce dernier peut les modifier à la volée en changeant l’adresse IP source par la sienne et en ajustant également les algorithmes de chiffrement utilisés pour créer le hash.

Cette information est cruciale car elle permet à l’attaquant de récupérer des hashes chiffrés avec un algorithme faible (dans ce cas RC4, si le KDC autorise son utilisation), ce qui facilite grandement le craquage de mots de passe (quelques secondes avec RC4 contre plusieurs jours avec AES).

L’outil propose également des fonctionnalités pour rester plus discret sur le réseau, comme l’option --disable-spoofing permettant de réinitialiser les tables ARP des utilisateurs dont le hash a déjà été capturé.

Pour se protéger contre cet outil, il est donc recommandé de mettre en place des remédiations contre l’ARP Spoofing et de ne pas autoriser l’algorithme de chiffrement RC4 sur le domaine.

Lien vers l’outil : https://github.com/Yaxxine7/ASRepCatcher

Conférencier : Nidhal BEN ALOUI

Chaque année, 580 000 personnes sont inscrites dans le Fichier des Personnes Recherchées. Chaque dossier contient des informations sur l’identité de la personne (nom, prénom, âge, etc.), une photographie, le motif de la recherche et les mesures à prendre si l’individu est retrouvé.

• AL : personnes atteintes de troubles mentaux
• IT : interdites de territoire
• M : mineurs en fuite
• PJ : recherches de la police judiciaire
• R : opposition à la résidence en France
• S : sécurité de l’État
• T : débiteurs du Trésor
• V : évadés
• X : personnes disparues
• etc.

La gendarmerie française est souvent sollicitée pour rechercher les personnes figurant sur cette liste dans le cadre d’enquêtes. Pour les retrouver, elle utilise une combinaison de renseignements en source ouverte (OSINT) et de renseignements en source fermée.

Pour la partie OSINT, l’utilisation des réseaux sociaux, d’outils et de sites web publics est largement privilégiée. Une attention particulière est portée aux résultats fournis par ces outils publics, qui ne sont jamais considérés comme sûrs par la gendarmerie.

En ce qui concerne les sources fermées, la gendarmerie dispose d’outils internes, de bases de données et de registres nationaux partagés qu’elle peut consulter lors des enquêtes.

Il est également possible pour les officiers de police judiciaire (OPJ) de demander l’accès à des informations privées détenues par des entreprises via des « demandes dérogatoires », ou même de communiquer en ligne avec de potentiels suspects dans le cadre d’une « enquête sous pseudonyme ».

Cependant, la loi encadre très précisément les actions autorisées par la gendarmerie, généralement :

• Les demandes dérogatoires ne sont autorisées que dans le cadre d’enquêtes pénales.
• Les enquêtes menées sous pseudonyme nécessitent une certification du Commandement de la Cyberdéfense (ComCyber).
• Chaque pseudonyme et avatar utilisé dans le cadre d’une enquête sous pseudonyme est unique et enregistré dans une liste accessible à tous les officiers de police judiciaire, afin d’éviter qu’ils s’enquêtent mutuellement.
• Il est interdit d’inciter quelqu’un à commettre un délit (par exemple, demander à un suspect potentiel d’acheter des biens illégaux).

Purple Team: méthodologie et outillage

Conférencier: Mael Auzias

Cette présentation, réalisée par Naval Group, abordait la problématique de la création d’une méthodologie et d’outils permettant de mettre en œuvre des Purple Teams et de les intégrer dans un plan d’audit plus large, afin de suivre l’évolution du niveau de sécurité et de comparer différents périmètres audités.

En effet, dans le cadre des missions d’une équipe d’audit interne, il est essentiel de disposer de référentiels d’audit définis afin de mener correctement les évaluations et de comparer leurs résultats.

Pour cela, un membre de la Red Team a collaboré avec la Blue Team de Naval Group afin de définir un cadre spécifique de tests et de restitution des résultats, qui sera utilisé pour évaluer les capacités de détection et de réponse de chaque entité auditée.

Présentation Purple Team

Une Purple Team est un exercice au cours duquel la Red Team et la Blue Team collaborent étroitement, en partageant librement les actions malveillantes exécutées ainsi que les détections réalisées. L’objectif final est d’améliorer à la fois les capacités de détection et les réponses apportées.

Pour bien préparer un exercice Purple Team, il est donc essentiel de définir :

• Quel type de profil d’attaquant doit être simulé ?
• Quels TTPs (Techniques, Tactiques et Procédures) seront ciblées pendant l’exercice ?
• Quels sont les objectifs de la mission ?
• Quelles sont les détections et réponses attendues ?

Une fois ces éléments clarifiés, l’exercice Purple Team peut débuter.

Méthodologie et outils dédiés aux exercices internes de Purple Team

Phase de test

Tout d’abord, la méthodologie mise en place par Naval Group repose sur VECTR, un outil destiné à automatiser les tests et mesurer l’efficacité de la détection, en offrant un espace de collaboration entre les Red et Blue Teams. Dans ce cas précis, il n’est utilisé que comme interface pour lancer automatiquement des attaques spécifiques et collecter les résultats des réponses.

Système de notation

Quatre situations peuvent être identifiées :

• Si une détection observée correspond à celle attendue, l’action malveillante testée obtient la note la plus élevée (ici, 7).
• Si une détection observée est « inférieure » à celle attendue, elle reçoit une mauvaise note (entre 1 et 3 ici).
• Si une détection observée est légèrement supérieure (par exemple, le déclenchement d’une enquête d’incident plutôt qu’un simple événement), elle obtient une note plutôt élevée (entre 5 et 6 ici).
• Enfin, si une réaction observée est disproportionnée par rapport à celle attendue, elle reçoit une note faible : déclencher une crise cyber globale pour une action qui n’aurait pas dû générer d’alerte peut s’avérer très impactant pour le quotidien du système d’information.

PS : ici, les différentes catégories ne correspondent pas exactement à celles présentées lors de l’événement.

Note finale

Cette note finale permet de déduire les performances de la Blue Team, mais également de suivre l’évolution de cet indicateur dans le temps.

Conclusion

Ainsi, en définissant un cadre d’audit clair pour réaliser les exercices de Purple Team, Naval Group s’assure de pouvoir évaluer correctement les performances des détections effectuées dans les différents périmètres de l’entreprise, de les comparer et de suivre leur évolution dans le temps.

Cela s’avérera d’autant plus efficace que le nombre d’exercices de Purple Team sera élevé.

Enseignements tirés d’une intrusion cyber en milieu industriel

Conférenciers : Hack’im et Antxine

Cette présentation a été donnée par deux intervenants à propos d’un retour d’expérience post-incident.

En effet, l’un de leurs clients les a contactés après avoir branché une clé USB sur un poste de travail standard, déclenchant une alerte de l’EDR. La situation était suspicieuse, car cette clé USB n’avait jamais généré d’alerte auparavant, et elle était uniquement utilisée pour mettre à jour un serveur autonome, séparé du reste du réseau.

Démarrage de l’investigation

L’attention s’est donc portée sur le serveur, probablement infecté par un programme malveillant qui s’était propagé à la clé USB.

En utilisant des outils classiques pour récupérer les 900 Go du serveur et analyser le système de fichiers et les fichiers EVTX, les enquêteurs ont découvert un programme suspect caché dans le dossier %APPDATA%, nommé aL4N.exe. Un exécutable inconnu dans ce dossier est anormal, ce qui a attiré l’attention des enquêteurs.

aL4N.exe

En utilisant VirusTotal pour évaluer le niveau de dangerosité de l’exécutable, celui-ci a obtenu un indice de détection de 52/94, ce qui était préoccupant et a poussé les enquêteurs à poursuivre leur analyse dans cette direction.

Grâce à cette piste, ils ont découvert que ce malware était présent sur le serveur depuis sa masterisation en 2016, et avait été introduit via une clé USB.

Des traces d’investigations internes précédentes ont été retrouvées, notamment un fichier mentionnant la présence de aL4N.exe identifié par des employés.

Écrit en AutoIT, ce malware établit un tunnel de communication vers un serveur C2 (Command & Control). Cependant, dans ce cas précis, le serveur distant avait été configuré sur localhost, ce qui révèle un manque de connaissances de l’acteur malveillant.

Le système de réplication de ce malware est atypique. Dès qu’un stockage externe de plus de 1 Go est connecté à une cible infectée, aL4N.exe crée un dossier My Pictures, le cache, s’y copie lui-même, et crée un raccourci pour My Pictures qui exécute aL4N.exe lorsqu’on clique dessus.

Conclusion

Le principal enseignement de cette présentation est d’installer des mécanismes de détection sur tous les composants d’un SI, même s’ils sont séparés du réseau principal. Il est également possible de mettre en place des stations de détection et de nettoyage efficaces pour les clés USB afin de sanitiser les supports amovibles, même si, dans le cas de cette entreprise, les dispositifs existants n’avaient pas détecté aL4N.exe.

Cet article BarbHack : Ce qu’il faut en retenir est apparu en premier sur RiskInsight.