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.