Retour sur leHACK 2026 : « Le Meilleur des Mondes »

Les 26 et 27 juin 2026, la Cité des Sciences et de l’Industrie accueillait leHACK. Pour cette édition placée sous le thème « Le Meilleur des Mondes », en référence au roman dystopique d’Aldous Huxley (Brave New World, 1932), un sujet est revenu conférence après conférence : l’arrivée des modèles de langage dans la recherche offensive.

Avec, derrière l’engouement, une question assez simple : l’attaquant de 2026 a-t-il réellement besoin d’un modèle de dernière génération pour trouver et exploiter des vulnérabilités ?

Après deux jours sur place, la réponse est beaucoup plus nuancée que ne le laissent penser certaines annonces. Retour sur l’événement et sur quatre conférences que j’en retiens particulièrement.

leHACK : la plus ancienne convention française de hacking

leHACK est l’héritier direct de La Nuit du Hack, née en 2003 dans l’esprit underground de la scène hacker. Rebaptisé en 2019, l’événement est aujourd’hui le plus ancien et le plus grand rassemblement français consacré au hacking, avec plus de 3 500 participants sur deux jours.

Sa particularité tient beaucoup à sa communauté. Organisé par l’association HackerZVoice et porté par ses bénévoles, les Goons, leHACK conserve une culture hacker que peu d’événements de cette taille arrivent encore à préserver.

L’édition 2026 faisait cohabiter plusieurs espaces : les conférences de l’amphithéâtre Gaston Berger, le village matériel leLAB avec soudure de badges, hacking NFC/RFID, piratage automobile et injection de fautes, un volet OSINT bien fourni autour des opérations d’influence, de la traque de fugitifs ou encore des investigations de RSF, ainsi que plusieurs workshops techniques.

À cela s’ajoutent tout ce qui fait l’identité du lieu : lockpicking avec la Red Team Alliance, concours « Qui Veut Gagner des Bitcoins », rumps et wargame nocturne jusqu’au dimanche matin. Le tout dans une salle plongée dans le rouge, avec écran géant et ambiance de concert davantage que de salle de conférence.

L’événement garde en parallèle un fort ancrage institutionnel : l’ANSSI, la DGSE, la DGSI, la DGA et YesWeHack figuraient parmi les sponsors. La frontière entre scène underground et cybersécurité d’État s’est, au fil des années, largement estompée.

Place aux conférences.

Entra ID & Microsoft 365 Under Siege : l’identité comme nouveau périmètre

Présentée par Hamza Kondah, Microsoft MVP Sécurité et fondateur de Hexadream Academy, cette conférence proposait un retour terrain sur les compromissions cloud modernes.

L’idée à retenir : dans Microsoft 365 et Entra ID, compromettre un mot de passe n’est souvent que le début. Tokens, applications consenties, services collaboratifs et automatisations offrent ensuite de nombreuses possibilités de déplacement latéral et de persistance. Et la MFA, à elle seule, ne suffit plus.

Cartographier un tenant avant même d’y entrer

L’attaque peut commencer sans le moindre accès.

L’identifiant du tenant, le tenant ID, est public et peut être retrouvé depuis un nom de domaine via des API ouvertes. À partir de là, un attaquant peut énumérer les utilisateurs, distinguer les domaines fédérés des domaines gérés et identifier les services exposés, le tout sans authentification et avec peu de bruit.

À cette reconnaissance active s’ajoutent les recherches passives : requêtes Google avancées sur les sites SharePoint, métadonnées de documents, fichiers exposés en partage anonyme, Blob Storage ou encore jetons récupérés « dans la nature », par exemple dans des captures d’écran ou des journaux laissés par des stealers.

Même un identifiant expiré peut parfois fournir suffisamment d’informations pour amorcer certaines attaques inter-tenants.

La « Pyramid of Tokens »

En détournant la Pyramid of Pain, un modèle de renseignement sur les menaces qui classe les indicateurs de compromission selon la difficulté qu’impose leur blocage à l’attaquant, Kondah a présenté une hiérarchie de la valeur des jetons OAuth 2.0 / OpenID Connect utilisés par les API du cloud Microsoft.

Access Token — impact faible.
Jeton de courte durée dont la portée est généralement limitée à une ressource. Une fois volé, il donne accès à cette ressource jusqu’à son expiration.

Refresh Token — impact élevé.
Il permet de générer de nouveaux access tokens sans réauthentification. Associé à la technique FOCI, il peut devenir réutilisable sur toute une famille d’applications.

Primary Refresh Token — impact critique.
Lié à l’appareil et émis lors de son enrôlement, il représente une cible particulièrement intéressante pour un attaquant et sa compromission peut donner un accès très étendu.

La conséquence côté défense est importante : changer le mot de passe d’un utilisateur compromis ne suffit pas nécessairement. Les sessions doivent également être révoquées, puisqu’un refresh token peut survivre à une simple réinitialisation du mot de passe.

FOCI et le déplacement latéral

FOCI (Family of Client IDs) permet à certains refresh tokens d’être échangés contre des jetons d’accès destinés à différentes applications Microsoft appartenant à une même famille.

Autrement dit, un seul jeton peut devenir une clé passe-partout vers une partie importante de l’écosystème Microsoft. L’outil open source OAuthBandit, dont une version 2 était démontrée pendant la conférence, exploite ce mécanisme.

Les vecteurs d’accès

Plusieurs techniques présentées provenaient directement de cas de réponse à incident.

Le Device Code Phishing, attribué notamment à Storm-2949 / Scattered Spider, consiste à pousser une victime à saisir un code d’authentification sur la véritable page Microsoft. C’est précisément ce qui rend le piège efficace : l’utilisateur se trouve sur un domaine légitime et pense valider sa propre connexion alors qu’il autorise une session initiée par l’attaquant depuis un autre appareil.

Le flux ROPC est un autre héritage problématique. Il transmet directement le couple identifiant/mot de passe au serveur, sans interface de connexion interactive, et se prête particulièrement bien au credential stuffing discret.

Le SSPR Abuse détourne quant à lui le Self-Service Password Reset. L’attaquant déclenche une réinitialisation au nom de la cible puis tente, par ingénierie sociale, de lui faire approuver des demandes MFA qui peuvent sembler légitimes.

Enfin, le contournement de l’accès conditionnel reste un sujet à part entière. En variant les user-agents et les identifiants clients, il est possible de rechercher les chemins sur lesquels MFA et Conditional Access ne s’appliquent pas. Des outils comme FindMeAccess ou MFASweep automatisent ce type d’audit.

Une fois le tenant compromis

C’est probablement la partie que je retiens le plus pour la défense : le compte compromis n’est pas nécessairement l’objectif final.

Un PIM mal configuré, par exemple sans véritable mécanisme d’approbation, peut permettre à un compte standard compromis d’activer un rôle privilégié sans validation ni contrôle renforcé. Dans ce cas, la protection est surtout cosmétique.

La couche collaborative constitue également une mine d’informations. SharePoint, OneDrive et Teams peuvent contenir des mots de passe, clés API, certificats ou chaînes de connexion en clair. La recherche via Microsoft Graph, eDiscovery ou des outils comme GraphRunner peut alors fournir un pivot beaucoup plus intéressant que le compte initial : compte de service, base de données, API tierce, voire autre tenant.

Power Automate mérite également une attention particulière. Des flux légitimes utilisant des connecteurs déjà consentis peuvent transférer automatiquement des mails, exfiltrer des fichiers ou maintenir une persistance après un changement de mot de passe, sans créer de règle Outlook visible et parfois en restant hors du périmètre surveillé par le SOC.

Dans un environnement M365, le compte initial n’est donc souvent qu’un point d’entrée vers les tokens, les données collaboratives et les mécanismes d’automatisation.

From USB to ESP : trouver des failles firmware avec de petits modèles

Changement complet de registre avec Maxime Rossi Bellom et Ramtine Tofighi Shirazi, cofondateurs de SecMate, qui présentaient leurs travaux sur les vulnérabilités du firmware Espressif.

C’est probablement la conférence qui collait le mieux au thème de cette édition, justement parce qu’elle prenait à contre-pied une partie de l’engouement actuel autour des grands modèles.

Pourquoi de petits modèles ?

La question de départ était très pragmatique : les modèles capables de trouver des vulnérabilités sont impressionnants en démonstration, mais sont-ils réellement utilisables dans les conditions rencontrées chez les clients ?

Plusieurs contraintes compliquent l’utilisation de gros modèles hébergés dans le cloud.

D’abord, la confidentialité : de nombreuses organisations refusent d’envoyer leur code source à un prestataire tiers, notamment américain.

Ensuite, la répétabilité. Deux requêtes identiques adressées à un grand modèle peuvent produire des résultats différents, ce qui devient problématique lorsque l’analyse doit être reproductible ou répondre à des exigences de conformité.

Enfin, il reste la dépendance au fournisseur : que devient le processus si l’accès au modèle est modifié ou supprimé ?

SecMate a donc choisi de mener ses recherches avec de petits modèles exécutables dans un environnement totalement déconnecté d’Internet.

La méthodologie : le Code Property Graph

La cible était la pile USB d’Espressif, fabricant de microcontrôleurs très répandus dans l’IoT — caméras, routeurs, drones ou robots — dont le SDK ESP-IDF repose sur FreeRTOS.

Donner simplement une grande quantité de code à un petit modèle ne fonctionne pas. Sa fenêtre de contexte est trop limitée et l’analyse finit rapidement par se disperser. Un simple arbre syntaxique n’est pas suffisant non plus : il ne représente pas correctement les flux de contrôle et de données.

L’équipe s’est donc appuyée sur un Code Property Graph, une représentation combinant plusieurs vues du programme :

• l’arbre de syntaxe ;
• le graphe de flot de contrôle, qui représente les différents chemins d’exécution ;
• le graphe de dépendance des données ;
• la résolution des appels de fonctions, permettant une analyse inter-fonctions et inter-fichiers.

Les nœuds du graphe sont ensuite enrichis avec les points d’entrée, les zones potentiellement faibles et un modèle de menace. Des analyses spécifiques sont ajoutées selon la classe de vulnérabilité recherchée, par exemple un dépassement mémoire ou un use-after-free.

L’objectif est d’arriver au code slicing : extraire uniquement les portions de code nécessaires pour poser au modèle une question précise, comme « cette vulnérabilité est-elle atteignable ? » ou « les conditions nécessaires à son exploitation sont-elles réunies ? ».

C’est ce découpage qui rend l’approche intéressante. Une grande partie du travail reste déterministe et sans IA ; le modèle n’intervient qu’une fois le contexte suffisamment réduit et structuré.

Des vulnérabilités bien réelles

Trois vulnérabilités ont été rapportées sur la pile USB et ont depuis été corrigées. Elles concernent les équipements supportant l’USB OTG, capables de fonctionner à la fois comme hôte et comme périphérique, et se trouvent dans l’implémentation du mode hôte.

Un élément important pour l’exploitation est le niveau de durcissement de l’ESP-IDF. Par défaut, les protections restent limitées : séparation entre données et code et canari de pile hérité de FreeRTOS, mais pas d’ASLR, de protection de pile dans les fonctions ni de PIE.

La vulnérabilité détaillée pendant la conférence était un double use-after-free dans le traitement des descripteurs USB HID.

Lorsqu’un périphérique annonce un descripteur plus grand que le tampon alloué — taille contrôlée par l’attaquant — le code libère le tampon et en alloue un nouveau, plus grand, mais continue d’utiliser l’ancien pointeur. Deux use-after-free peuvent ainsi se produire dans la même fonction.

D’après les sources publiques, ce use-after-free correspond au CVE-2025-68656, tandis qu’un double-free voisin correspond au CVE-2025-68657. Les deux ont été corrigés dans le driver ESP-IDF USB Host HID 1.1.0, et l’advisory Espressif crédite les deux chercheurs.

L’exploitation demande cependant beaucoup plus que de simplement détecter le bug. Elle nécessite du heap grooming, un contrôle précis du timing entre la libération et les accès mémoire et la recherche d’objets intéressants à superposer.

Les intervenants étaient d’ailleurs transparents sur ce point : leurs derniers essais remontaient à la veille au soir et ils n’avaient pas encore obtenu d’exécution de code sur ce chemin.

Une seconde vulnérabilité, un dépassement de pile plus classique présent dans du code de débogage désactivé par défaut, avait en revanche été exploitée jusqu’à l’écrasement de l’adresse de retour. La démonstration en direct le montrait avec l’exécution d’une fonction qui n’était jamais censée être appelée.

C’est là que le message de la conférence devient particulièrement intéressant : de petits modèles locaux peuvent participer à la découverte et à l’exploitation de vulnérabilités firmware, mais seulement si une importante couche d’ingénierie déterministe prépare le terrain.

Le modèle n’est pas la solution. C’est le dernier maillon de la chaîne.

Attacking WSO2 : quand la segmentation réseau ne suffit plus

Troisième univers : la sécurité applicative Java, avec Noel Maccary, pentester chez Ambionics Security, groupe LEXFO.

WSO2, à travers notamment API Manager et Identity Server, est largement déployé dans des secteurs comme la banque, l’assurance, la défense ou l’administration. Plusieurs de ses produits partagent un même socle de code, le Carbon kernel, ce qui crée mécaniquement une surface d’attaque importante.

Beaucoup de vulnérabilités, mais du mauvais côté du réseau

Depuis 2023, Ambionics avait accumulé plusieurs primitives intéressantes dans WSO2 : SSRF permettant de contrôler la requête émise, CSRF sur de nombreux points de terminaison et plusieurs possibilités de RCE dans les services privilégiés.

Le problème était ailleurs : ces vulnérabilités concernaient principalement des services internes, supposés ne jamais être exposés à Internet.

Sur des déploiements mal configurés, cela suffisait. Jusqu’à ce que l’équipe rencontre chez un client une architecture correctement segmentée : console d’administration derrière un pare-feu, aucun port d’administration exposé et aucune connectivité sortante.

Seule la passerelle restait accessible.

Il fallait donc trouver un moyen de traverser cette segmentation.

Sept failles pour arriver à la RCE

La chaîne construite par l’équipe est probablement l’un des meilleurs exemples de la conférence de ce qu’une vulnérabilité apparemment limitée peut permettre lorsqu’elle est combinée à plusieurs autres.

1. Une XXE aveugle sur la passerelle

Pour vérifier qu’un contenu est bien du XML, le serveur l’analyse sans protection suffisante. Le bug apparaissait initialement sur une page 404 : un paramètre invalide réfléchi dans la réponse amenait WSO2 à analyser à nouveau sa propre réponse, transformant une simple XSS en XXE.

Le même comportement existant sur des services appelables, l’équipe obtenait une première primitive : faire émettre au serveur WSO2 une requête HTTP vers des services internes.

2. Un contournement partiel de l’authentification

Une différence d’interprétation des URL entre le middleware d’authentification et le routage des servlets permettait, en manipulant le chemin, d’accéder sans authentification à certains fichiers de la console d’administration.

3. Transformer le rebond en véritable proxy

Après avoir parcouru des dizaines de fichiers JSP, l’équipe en a trouvé un particulièrement utile : un proxy HTTP capable de recevoir une URL, des en-têtes et un corps de requête avant d’émettre la requête correspondante.

Chaîné avec la XXE, ce proxy permettait désormais de cibler les services internes avec beaucoup plus de contrôle.

4. Créer un utilisateur

Un service interne permettait de créer un utilisateur à faibles privilèges, malgré une option de configuration censée désactiver cette fonctionnalité sur les versions concernées.

Restait un problème : le proxy ne permettait pas de contrôler l’en-tête d’authentification. Impossible, a priori, d’utiliser ce nouveau compte.

5. HTTP request smuggling

C’est ici que la chaîne devient particulièrement astucieuse.

L’un des paramètres du proxy n’était pas correctement validé et acceptait les retours à la ligne. En injectant la fin d’une requête puis une seconde requête complète dans la même connexion TCP, l’attaquant pouvait envoyer une nouvelle requête avec son propre en-tête d’authentification.

Le compte créé à l’étape précédente devenait enfin utilisable.

6. RCE via la définition d’une API

Une fois authentifié, l’attaquant pouvait utiliser une fonctionnalité d’API Manager permettant de définir une API et d’y héberger du code.

Ces API s’exécutent dans un moteur JavaScript intégré à la JVM et, dans le scénario présenté, pouvaient appeler des classes Java arbitraires. Il devenait alors possible d’exécuter des commandes système et d’en récupérer la sortie.

7. Une persistance discrète

L’API ainsi déployée était accessible depuis la passerelle exposée à Internet.

Plus besoin, ensuite, de rejouer toute la chaîne : un appel à cette API suffisait pour exécuter une commande. Le code tournant directement dans la JVM sans nécessairement créer un nouveau processus, cette persistance pouvait en outre rester relativement discrète en contexte red team.

La charge utile finale empilait XXE, proxy, requête injectée, XML et base64. De l’aveu de l’orateur lui-même : c’était illisible.

Côté sources publiques, la RCE Siddhi via les services d’administration SOAP a reçu le CVE-2025-5717 et la XXE de la passerelle le CVE-2025-2905. Les autres faiblesses présentées n’avaient pas été référencées par un CVE au moment de la conférence ; leur état exact selon les versions doit donc être vérifié au cas par cas. Le détail de la recherche est disponible sur le blog de LEXFO.

Ce que j’en retiens dépasse WSO2 : une segmentation réseau solide reste essentielle, mais elle ne peut pas être considérée comme une frontière de sécurité absolue. Une SSRF ou une XXE, même aveugle, peut suffire à créer le premier point de rebond. À partir de là, des vulnérabilités internes jusque-là considérées comme inaccessibles redeviennent exploitables.

De la PS Vita au Flipper Zero

Après trois conférences très orientées entreprise, l’intervention de Jérémie Amsellem au village leLAB apportait un vrai changement de ton. Salle plus petite, format plus intimiste, et surtout un projet construit par passion.

Son conseil à la salle était simple : si vous aimez une console, écrivez des homebrews pour elle.

Trouver une nouvelle faille sur une console demande un investissement considérable. Développer son propre logiciel pour une machine déjà ouverte est beaucoup plus accessible et constitue aussi une excellente façon de comprendre les homebrews que l’on utilise déjà.

Pourquoi la PS Vita ?

Sortie en 2012, la PS Vita était considérée comme l’une des consoles les plus sécurisées de sa génération, avec notamment une forte séparation noyau/utilisateur et une puce dédiée au chiffrement.

Sa sécurité a pourtant été progressivement démontée par la communauté.

Entre 2012 et 2014, les premières recherches exploitent le bac à sable PSP, dans un jeu du chat et de la souris avec Sony. En septembre 2015 arrive Rejuvenate, premier exploit natif, puis la création du VitaSDK.

En juillet 2016, HENkaku apporte une chaîne d’exploitation via le navigateur, encore non persistante. Enso règle cette question l’année suivante, tandis que les DRM tombent également en 2017.

En 2019, la clé de chiffrement de la console se révèle être seize fois le même caractère. Puis, en 2021, un chargeur permet de porter des exécutables Android sur la machine.

Le VitaSDK est particulièrement intéressant : entièrement issu de la rétro-ingénierie du firmware et de jeux existants, il documente les fonctions de la console dans un wiki et fournit des en-têtes utilisables en C.

Le travail reste toutefois incomplet. Certaines fonctions contiennent encore des paramètres baptisés simplement « unk », pour unknown.

Quark, puis Vipper Zero

Après avoir développé quelques applications graphiques à la main, Jérémie Amsellem s’est heurté à un problème très concret : dessiner chaque forme et positionner chaque texte avec SDL fonctionne, mais devient rapidement fastidieux.

D’où l’idée de décrire les interfaces en HTML et leur logique en JavaScript.

Sa première tentative consistait à écrire son propre moteur HTML. Elle s’est soldée par un échec assumé : développer un véritable analyseur HTML est un projet en soi.

Il s’est finalement appuyé sur Lexbor pour l’analyse, Duktape comme moteur JavaScript embarqué et SDL pour le rendu. De là est né Quark, un framework capable de transformer un fichier HTML et son JavaScript en application PS Vita.

Son premier vrai projet réalisé avec Quark ? Un scanner de ports, qui n’existait pas sur la console.

Puis vient Vipper Zero, avec une idée assez amusante : donner à une PS Vita une partie des fonctionnalités d’un Flipper Zero.

Une console portable dans un sac attire peu l’attention, ce qui en fait un format intéressant pour certains scénarios d’intrusion physique.

Mais le chemin jusqu’au prototype fonctionnel n’a rien eu de direct.

La pile Bluetooth de la Vita est ancienne et ne dispose pas d’une API accessible, ce qui a rapidement condamné l’idée initiale. Le module radio externe retenu, un EvilCrow RF, communique normalement en Wi-Fi plutôt que par le port de la console.

Autre problème : la PS Vita ne fournit aucune tension en sortie puisqu’elle est conçue comme périphérique et non comme hôte.

La solution finale est donc assez artisanale : réécriture du firmware de l’EvilCrow pour communiquer en USB série, puis ajout d’un Raspberry Pi Zero entre le module et la console pour relayer les échanges.

Ce n’est pas élégant. Mais ça fonctionne.

Le projet permet aujourd’hui de rejouer des fichiers sub-GHz, de faire du brouillage, de scanner des périphériques BLE et leurs services, d’écrire des charges utiles en JavaScript et de faire du BadUSB via un analyseur de duckyscripts. Quark et Vipper Zero sont tous les deux disponibles publiquement sur GitHub.

Aparté : Sighax et la Nintendo 3DS

Dans le même esprit, une autre conférence revenait sur Sighax, l’une des vulnérabilités majeures découvertes sur Nintendo 3DS.

L’architecture de la console sépare les privilèges entre deux processeurs : l’ARM11, qui exécute les jeux, et l’ARM9, chargé de la sécurité. Chacun démarre depuis sa propre bootrom, gravée en usine.

Deux défauts se combinent dans le code de vérification de signature de l’ARM9 : une validation trop permissive du padding RSA PKCS#1 v1.5 et un analyseur ASN.1 qui ne vérifie pas correctement les longueurs.

En construisant une structure dont le champ de longueur pointe en dehors de celle-ci, il devient possible d’amener l’analyseur à comparer le hash calculé du firmware avec ce même hash présent un peu plus loin sur la pile.

Seuls cinq octets restaient alors à trouver par force brute, ce qui aurait demandé environ une semaine de calcul.

Le résultat est particulièrement durable : n’importe quel firmware peut être signé et, puisque la vulnérabilité se trouve dans une bootrom non réinscriptible, elle ne peut pas être corrigée par une mise à jour classique.

Conclusion

C’était ma première venue à leHACK, et l’événement tient sa réputation. Le niveau technique est élevé sans pour autant rendre les conférences inaccessibles, avec des sujets allant de problématiques très entreprise à des projets menés simplement pour le plaisir de comprendre et de détourner du matériel.

Après deux jours, je retiens surtout que les fondamentaux bougent beaucoup moins vite que les outils.

L’IA était partout, directement ou en toile de fond, avec toujours la même question : faut-il aujourd’hui un modèle de dernière génération pour faire de l’offensif sérieux ?

Les conférences auxquelles j’ai assisté donnent plutôt envie de répondre non.

On retrouve de la mémoire mal gérée, des parseurs trop permissifs, des hypothèses de segmentation qui finissent par casser, des sessions que l’on oublie de révoquer ou des fonctionnalités légitimes détournées de leur usage initial. Certaines de ces classes de problèmes existent depuis des décennies.

Les outils changent. Les erreurs, beaucoup moins.

C’est aussi pour cela que ce type d’événement vaut le déplacement. Chez Neosoft, ces retours terrain peuvent directement nourrir les missions, du SOC à l’audit offensif, tout en rappelant une chose assez simple : les priorités de durcissement évoluent souvent beaucoup plus lentement que les annonces technologiques.

Sources et pour aller plus loin

• Blog Lexfo / Ambionics, Attacking WSO2 Products : blog.lexfo.fr/wso2.html
• Advisory Espressif esp-usb (CVE-2025-68656 et CVE-2025-68657) :
• github.com/espressif/esp-usb/security/advisories
• Quark et Vipper Zero : github.com/lp1dev
• Programme complet leHACK 2026 : lehack.org/fr/2026/

Lexique

Canari de pile (canary) : valeur sentinelle placée sur la pile avant l’adresse de retour d’une fonction. Un débordement qui l’écrase peut ainsi être détecté et provoquer l’arrêt du programme.

Credential stuffing (bourrage d’identifiants) : test automatisé de couples identifiant/mot de passe provenant de fuites de données, en pariant sur leur réutilisation sur d’autres services.

FOCI (Family of Client IDs) : ensemble d’applications Microsoft partageant certaines propriétés liées aux refresh tokens ; un jeton obtenu pour une application peut, dans certains cas, être échangé afin d’accéder à une autre application de la même famille.

Heap grooming : manipulation du tas par une succession d’allocations et de libérations afin de placer les objets mémoire de manière plus prévisible, technique souvent utilisée lors de l’exploitation de corruptions mémoire.

PIM (Privileged Identity Management) : mécanisme Entra ID permettant notamment d’attribuer temporairement et à la demande des rôles privilégiés, avec des mécanismes d’approbation et de journalisation.

Request smuggling (contrebande de requêtes) : exploitation d’une différence d’interprétation entre plusieurs composants HTTP afin d’introduire une requête supplémentaire dans une connexion.

SSRF (Server-Side Request Forgery) : vulnérabilité permettant d’amener un serveur à émettre des requêtes vers des destinations choisies par l’attaquant, notamment des services internes.

Tenant : instance isolée d’un service cloud dédiée à une organisation. Dans Microsoft 365 / Entra ID, elle regroupe notamment ses utilisateurs, identités et ressources.

Use-after-free : utilisation d’un pointeur vers une zone mémoire qui a déjà été libérée. Si cette zone est réallouée entre-temps, son nouveau contenu peut parfois être contrôlé par un attaquant.

XXE (XML External Entity) : vulnérabilité liée au traitement d’entités externes par un analyseur XML, pouvant notamment permettre la lecture de fichiers locaux ou l’émission de requêtes depuis le serveur.