PolySécure Podcast volet Teknik

Nicolas-Loïc Fortin et tous les collaborateurs

Podcast francophone sur la cybersécurité. Pour professionels.

  1. 5d ago

    Teknik - De Nessus à Bromure (SSTIC)

    Parce que… c’est l’épisode 0x31D! Shameless plug 19 septembre 2026 - Bsides Montréal 20 au 26 septembre 2026 - BruCON 13 novembre 2026 - DEATHCon 16 au 19 novembre - European Cyber Week 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026 24 et 25 février 2027 - SéQCure 2027 Description De Nessus à Tenable : les débuts d’une légende Dans cet épisode spécial de Polysécure, l’animateur reçoit Renaud Deraison, créateur de Nessus, le scanner de vulnérabilités développé il y a près de 30 ans, et cofondateur de Tenable où il a occupé le poste de CTO jusqu’à son départ il y a environ cinq ans. Deraison raconte la genèse de Nessus : à 16 ans, passionné par le réseau internet naissant, il découvre l’univers de la sécurité informatique à une époque où les failles étaient publiées sur la mailing list Bugtraq, suivie par une communauté restreinte d’environ 20 000 abonnés. Insatisfait des outils existants comme Satan, jugés trop complexes et peu accessibles, il développe Nessus en 1998 avec une cinquantaine de tests de sécurité au départ. Le succès est immédiat et inattendu, poussant Deraison à poursuivre le projet, d’abord en open source, puis en produit commercial via Tenable, qui étendra la portée de l’outil de la simple DMZ à l’ensemble de l’infrastructure numérique des entreprises. Le retour à la technique et la leçon de l’éloignement du clavier Un thème central de la discussion est l’importance de rester connecté à la pratique technique concrète. Deraison explique qu’en grandissant chez Tenable, il a dû délaisser le code pour devenir « plus stratégique », perdant ainsi une compréhension viscérale de la technologie au profit d’une compréhension purement intellectuelle. Il souligne l’écart immense, en cybersécurité, entre comprendre un concept en théorie et l’expérimenter réellement : c’est en manipulant les outils qu’on découvre les vrais problèmes de sécurité et les idées de produits pertinentes. Cette réflexion mène à une critique plus large de l’industrie de la cybersécurité, jugée parfois arrogante et déconnectée du vécu des utilisateurs, prompte à distribuer des leçons sans empathie pour les contraintes opérationnelles réelles (comme l’impossibilité de patcher immédiatement une machine critique sans interrompre un service). Bromure : le navigateur jetable réinventé Après son départ de Tenable, Deraison reprend goût au code, épaulé par les assistants IA, en commençant par ChatGPT puis Claude. L’élément déclencheur d’un nouveau projet est presque anecdotique : recevant de nombreux SMS frauduleux (offres de crédit douteuses, généré désormais dans un français impeccable et localisé grâce à l’IA), il souhaite savoir qui se cache derrière ces arnaques sans s’exposer lui-même. Il se remémore alors Bromium, une entreprise des années 2010 qui isolait Internet Explorer dans un hyperviseur, avec l’idée qu’il était inutile de patcher puisqu’il suffisait de fermer et rouvrir un environnement neuf en cas de compromission. Inspiré par ce concept, Deraison développe Bromur (bromur.io), un navigateur jetable pour Mac fonctionnant sous Linux dans une VM, avec une expérience utilisateur quasi native : glisser-déposer de fichiers entre le Mac et la VM, support webcam, contrôle fin des téléchargements et téléversements. Une version serveur permet aussi de faire travailler des contractants externes dans un environnement streamé et surveillé, où impression, captures d’écran et téléchargements peuvent être bloqués. Le projet intègre également un module (désactivé par défaut) utilisant un LLM pour analyser les pages visitées et détecter le phishing, en repérant par exemple des incohérences entre le contenu affiché et l’URL réelle, ou des tromperies visuelles comme l’usage de caractères d’un autre alphabet imitant des lettres latines. Deraison estime que le phishing reste un vaste chantier négligé par l’industrie, qui se contente trop souvent de solutions de formation jugées insuffisantes face à des attaques de plus en plus sophistiquées, y compris par deepfake vidéo. Bromure Agentic : sécuriser les développeurs sans les freiner Le second volet du projet, Bromure Agentic, s’attaque aux attaques de la chaîne d’approvisionnement logicielle (supply chain attacks), un risque majeur lorsqu’un package npm ou Python compromis vole les clés SSH, tokens d’authentification et autres identifiants sensibles présents sur la machine d’un développeur. Plutôt que d’imposer des restrictions punitives comme le font certaines sandboxes existantes, Bromure propose une VM Linux complète où l’utilisateur dispose de faux tokens et fausses clés SSH. Un mécanisme de type « man in the middle » observe le trafic sortant et substitue à la volée les vrais identifiants aux faux, uniquement au moment nécessaire. Ainsi, même en cas de compromission, aucun secret n’est réellement exposé sur la machine. L’outil ajoute aussi des alertes en cas de mauvaise configuration et permet désormais de restreindre les droits (par exemple en lecture seule) sur les accès Kubernetes ou Git, sans exiger du développeur qu’il devienne expert en administration système. Repenser des dogmes établis La conversation aborde aussi la remise en question de certains dogmes de sécurité, comme le caractère « intouchable » du trafic SSL, que Deraison juge paradoxal : on surveille tout le comportement d’une machine, sauf le trafic chiffré sortant. L’inspection de ce trafic ouvre selon lui de nouvelles possibilités, comme bloquer les téléchargements de packages npm en version « latest », souvent les plus vulnérables au piratage. Les deux interlocuteurs concluent sur une analogie automobile : de même que les usagers n’ont pas à comprendre le fonctionnement d’un moteur pour conduire, les utilisateurs et développeurs ne devraient pas avoir à devenir des experts en sécurité pour travailler efficacement. La responsabilité doit se déplacer vers des outils qui protègent sans punir, permettant à chacun de rester concentré sur son métier. Notes Bromure Collaborateurs Nicolas-Loïc Fortin Renaud Deraison Crédits Montage par Intrasecure inc Locaux réels par SSTIC

  2. 6d ago

    Teknik - La curiosité source de toutes les croissances en cybersécurité

    Parce que… c’est l’épisode 0x31C! Shameless plug 19 septembre 2026 - Bsides Montréal 20 au 26 septembre 2026 - BruCON 13 novembre 2026 - DEATHCon 16 au 19 novembre - European Cyber Week 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026 24 et 25 février 2027 - SéQCure 2027 Description Une conversation sur une terrasse, un sujet qui mijotait depuis longtemps L’épisode s’ouvre de façon informelle, en terrasse, un lundi ensoleillé. L’animateur et Martin Dubé annoncent qu’ils allaient enfin aborder un sujet qu’ils repoussaient depuis longtemps : un mandat de test d’intrusion que Martin avait réalisé sur un réseau LTE (4G) privé, à une époque où il n’avait qu’une connaissance limitée de cette technologie. Le fil conducteur de la discussion est la curiosité comme moteur de croissance professionnelle en cybersécurité, illustré par ce mandat devenu un succès marquant dans sa carrière. Se lancer dans l’inconnu : du pentest classique au LTE Martin explique que son parcours en test d’intrusion a toujours été motivé par la curiosité plutôt que par une expertise préalable. Il rappelle ses débuts chez Gocker, où une jeune équipe sans expérience formelle a appris « sur le tas ». Cette philosophie l’a suivi tout au long de sa carrière : il se dit attiré par les mandats qui le poussent hors de sa zone de confort. Le LTE constitue un univers à part, très différent du monde informatique traditionnel (Windows, Linux) : des protocoles propriétaires, complexes, empilés au fil des générations (3G, 4G, 5G) par l’organisme 3GPP, chaque itération apportant son lot de nouveaux acronymes déconnectés des précédents. Le mandat portait spécifiquement sur un réseau LTE privé, avec ses propres mécanismes de contrôle d’accès (notamment le verrouillage IMEI, qui lie une carte SIM à un appareil précis), absents des réseaux cellulaires publics. Une préparation intensive Pour se qualifier, Martin s’est procuré une carte Blade RF, a étudié le fonctionnement du matériel, préparé des payloads jusque dans sa chambre d’hôtel et dans l’avion, et a visionné une quinzaine de présentations DEF CON sur les attaques LTE. Il en retient que malgré la complexité apparente, les mêmes patterns d’attaque reviennent constamment : injections, services exposés, adresses IP mal protégées. Il livre un message clé aux auditeurs : ne pas laisser le syndrome de l’imposteur freiner les décisions. Selon lui, un « expert » est simplement quelqu’un qui a travaillé fort et qui continue d’apprendre ; s’accrocher au statut d’expert peut au contraire limiter la capacité à sortir de sa zone de confort. Martin insiste sur l’accumulation d’expérience comme capital réutilisable : après une quinzaine d’années en test offensif, il reconnaît que les fondamentaux (penser comme un attaquant) restent transférables d’une technologie à l’autre, seuls les acronymes changent. Il souligne aussi que l’accès à l’information (recherche en ligne, outils d’IA comme Copilot) a rendu l’apprentissage de nouveaux domaines beaucoup plus rapide qu’auparavant. Concrètement, pour écrire ses payloads en C, il a utilisé le framework open source srsRAN, qui permet de simuler un réseau LTE complet, et s’est appuyé sur Copilot pour comprendre le code et cibler les modifications nécessaires. Une soirée d’hôtel a suffi pour obtenir un premier résultat fonctionnel. Le pouvoir du threat modeling La deuxième moitié de l’échange se concentre sur la méthodologie du mandat. Le client, relativement mature, exigeait un atelier de modélisation des menaces (threat modeling) avant même la rédaction du plan de test, lequel devait ensuite être approuvé par les parties prenantes. L’équipe a suivi une approche inspirée de l’OWASP, réunissant plusieurs intervenants pour déterminer ce qu’il fallait sécuriser en priorité. Le sujet retenu a été le provisionnement des cartes SIM, élément central de l’accès au réseau LTE (les clés de chiffrement intégrées aux cartes, non extractibles, et leur copie détenue par le fournisseur). Cet atelier d’une semaine a permis de faire émerger, avant même les tests techniques, plusieurs hypothèses de vulnérabilités fondées sur les risques réels plutôt que sur un périmètre imposé arbitrairement. Martin partage un exemple marquant : lors des discussions, un accès jugé initialement comme « lecture seule » sur un système de surveillance des cartes SIM s’est révélé être un accès administrateur complet, supposément atténué par des règles de pare-feu… qui, après vérification, n’avaient en réalité jamais été mises en place. Ce test, qui n’a demandé que cinq minutes, a révélé un manque de communication majeur entre les équipes du client et son fournisseur. Les deux interlocuteurs comparent cette dynamique aux défaillances observées dans les grandes organisations complexes, où plusieurs fournisseurs interviennent sans coordination claire. L’animateur cite en parallèle l’incident de la porte de l’avion Boeing, causé par une rupture de communication entre le fournisseur et le fabricant plutôt que par une seule erreur isolée — illustrant que les systèmes complexes multiplient les angles morts. Les résultats techniques du mandat Une fois le plan de test bâti sur les risques identifiés, Martin a pu tester des contrôles précis : usurpation d’IMEI, mouvements latéraux via des réseaux industriels mal segmentés (FTP non sécurisés, plusieurs sauts de jump host), et surtout des attaques par déni de service. Il détaille l’attaque par injection sur la « tracking area update » : contrairement au Wi-Fi, où l’appareil mesure lui-même la force du signal, un appareil LTE fait confiance à la force annoncée par l’antenne, ce qui permet à un attaquant de se faire passer pour une tour plus puissante sans nécessiter une grande puissance d’émission. Cette faille est reconnue comme un compromis de conception du 3GPP entre sécurité et fiabilité du roaming. Dans le cas testé, la vulnérabilité existait bel et bien, mais un mécanisme de type « watchdog » redémarrait automatiquement les appareils affectés, limitant l’impact réel grâce à un contrôle compensatoire. Conclusion L’épisode se termine sur une note d’enthousiasme partagé : les deux interlocuteurs concluent que la curiosité, la volonté d’expérimenter dans l’inconnu et la capacité à capitaliser sur une expérience accumulée sont les véritables leviers de progression en cybersécurité, bien plus que la spécialisation figée dans un domaine unique. Collaborateurs Nicolas-Loïc Fortin Martin Dubé Crédits Montage par Intrasecure inc Locaux réels par Intrasecure inc

  3. Jul 14

    Teknik - Posture de l'IA défensif ou comment nous apprenons de l'IA offensif

    Parce que… c’est l’épisode 0x31B! Shameless plug 19 septembre 2026 - Bsides Montréal 20 au 26 septembre 2026 - BruCON 13 novembre 2026 - DEATHCon 16 au 19 novembre - European Cyber Week 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026 24 et 25 février 2027 - SéQCure 2027 Description Un an de progrès vertigineux Dans cet épisode spécial de Polysécure, l’animateur reçoit Mickael Nadeau pour discuter de l’évolution de l’intelligence artificielle entre deux éditions du concours NorthSec (NSec). Le point de départ est frappant : il y a environ un an et demi, lors de l’avant-dernier NorthSec, les participants commençaient tout juste à expérimenter l’IA en mode « full force », mais les capacités restaient limitées à un simple chatbot capable, au mieux, de générer un script rapide pour automatiser une tâche SSH. Aujourd’hui, le paysage est méconnaissable : les agents autonomes, les architectures de type RAG et les compétences (« skills ») spécialisées ont complètement transformé la façon dont les équipes offensives opèrent. Le point de vue privilégié d’une entreprise défensive Mickael explique que son entreprise, active en cyberdéfense, occupe une position d’observation unique. Grâce à un « mode surveillance » qui laisse les systèmes clients actifs sans bloquer les attaques (plutôt que de les stopper), l’équipe peut observer en temps réel les nouveaux outils et méthodologies utilisés par les équipes de pentest lors de leurs tests d’intrusion. Cette visibilité lui permet presque de dresser un classement informel des équipes selon leur niveau, un peu à la manière d’un « wall of shame » inspiré de DEF CON : certaines équipes s’appuient sur leur réputation sans se renouveler, utilisant des outils et méthodologies dépassés, tandis que d’autres repoussent les limites grâce à une utilisation avancée de l’IA. Du couteau suisse au tireur d’élite spécialisé Un des axes centraux de la discussion porte sur le passage d’agents génériques (le « couteau suisse ») à des sous-agents hautement spécialisés. Mickael illustre ce changement avec l’exemple des injections SQL : au lieu d’utiliser un outil bruyant comme SQLMap qui teste systématiquement toutes les possibilités, on peut désormais entraîner un agent dédié, nourri de toute la documentation existante sur les failles SQL connues, capable de reconnaître un scénario familier et d’aller directement à la solution avec un minimum de requêtes. Le résultat est un attaquant beaucoup plus silencieux, difficile à repérer avec les mécanismes de détection traditionnels basés sur le volume de bruit réseau. Ce changement de paradigme complique considérablement le travail défensif. Les équipes de sécurité, historiquement habituées à trier les faux positifs et à repérer les comportements bruyants et erratiques, doivent maintenant chasser des signaux beaucoup plus subtils, dans une fenêtre de temps réduite à quelques secondes plutôt qu’à plusieurs jours. L’apprentissage machine au service de la défense Contrairement à l’approche probabiliste des grands modèles de langage utilisés côté offensif, l’entreprise de Mickael s’appuie depuis longtemps sur l’apprentissage machine plus déterministe pour détecter les menaces. Ce socle a permis d’atteindre un certain niveau de précision, mais un nouveau défi émerge : la gestion des modèles frontières et des agents eux-mêmes. Beaucoup de clients sont, selon ses mots, « hystériques » face à cette nouvelle réalité, car la majorité des solutions du marché n’ont pas encore intégré une stratégie pour encadrer les agents IA, que ce soit du côté de leurs propres outils ou de ceux fournis par des tiers (pare-feu, plateformes de sécurité, etc.). Des gains opérationnels concrets Au-delà de la détection, les agents transforment aussi les tâches opérationnelles quotidiennes : renouvellement de certificats, requêtes de cache, diagnostics de configuration client complexes — autant d’opérations qui pouvaient auparavant nécessiter plusieurs appels et une expertise pointue peuvent maintenant être gérées via une simple conversation avec un agent, même depuis un téléphone. Mickael raconte un cas concret où un agent a diagnostiqué un problème de pare-feu propre à un client en quelques requêtes, un problème qu’il n’aurait pas su résoudre lui-même immédiatement malgré sa connaissance approfondie du produit. L’avenir des services MDR et la montée des benchmarks La conversation aborde également l’impact sur le marché des services MDR (Managed Detection and Response). Selon Mickael, l’automatisation permise par les agents va permettre à ces équipes de gérer un nombre de clients beaucoup plus important avec les mêmes ressources humaines, tout en relevant le niveau minimal de qualité du secteur. Il prédit également l’émergence de benchmarks formels pour évaluer non seulement les modèles d’IA, mais aussi les fournisseurs de services de sécurité eux-mêmes — un peu comme les leaderboards actuels qui comparent les performances des différents modèles de langage face à des scénarios d’attaque réels. Ces chiffres deviendront un argument de vente central, remplaçant progressivement les discours marketing par des données concrètes et vérifiables. Vers l’automatisation de la conformité Enfin, les deux interlocuteurs discutent du potentiel des agents pour transformer les processus de conformité (comme PCI-DSS), aujourd’hui perçus comme une lourde corvée administrative. Mickael envisage un futur où des « skills » standardisés permettront d’appliquer automatiquement les bonnes pratiques de conformité, réduisant la tentation de sauter des étapes. Il conclut en mentionnant qu’il prépare une présentation avec démonstration en direct pour partager plus en détail cette évolution avec la communauté, dans le but de sensibiliser les organisations à moderniser leur posture défensive à l’ère des agents IA. Collaborateurs Nicolas-Loïc Fortin Mickael Nadeau Crédits Montage par Intrasecure inc Locaux virtuels par Riverside.fm

  4. Jul 9

    Teknik - Génération des mots de passe par LLM

    Parce que… c’est l’épisode 0x319! Shameless plug 19 septembre 2026 - Bsides Montréal 20 au 26 septembre 2026 - BruCON 13 novembre 2026 - DEATHCon 16 au 19 novembre - European Cyber Week 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026 24 et 25 février 2027 - SéQCure 2027 Description Contexte de la recherche Dans cet épisode de Polysécure, l’animateur reçoit Gaëtan Ferry, chercheur en sécurité chez GitGuardian, pour discuter d’une recherche originale sur la génération de mots de passe par les grands modèles de langage (LLM). Le point de départ est un article publié début 2026 par Irregular, une entreprise israélienne, qui avait démontré que les mots de passe générés par les LLM présentaient des biais statistiques importants, variables selon les modèles. Cette découverte a poussé l’équipe de GitGuardian à se demander si ces mots de passe biaisés se retrouvaient réellement « dans la nature », c’est-à-dire utilisés par de vraies personnes sur de vrais systèmes. GitGuardian dispose d’un avantage unique pour répondre à cette question : son activité principale consiste à détecter des secrets (mots de passe, clés API, etc.) exposés publiquement, notamment sur GitHub. L’entreprise possède donc une base de données massive de secrets, dont une catégorie dite « générique » — des chaînes de caractères qui ressemblent à des mots de passe mais ne suivent aucun format standardisé identifiable. Méthodologie : les chaînes de Markov Pour détecter automatiquement si un mot de passe avait été généré par un LLM, l’équipe a eu l’idée de reconstruire une structure statistique classique : les chaînes de Markov, l’ancêtre technique des LLM, utilisées par exemple dans la prédiction de texte sur les claviers de téléphone. Ces chaînes excellent à capturer des biais statistiques dans une séquence de caractères. La méthode a consisté à interroger 40 modèles de LLM différents, en leur demandant de générer des centaines de mots de passe chacun. À partir de ces échantillons, plusieurs types de chaînes de Markov ont été construits, prenant en compte (ou non) la position des caractères dans le mot de passe. Ces structures permettent ensuite, face à un mot de passe arbitraire, d’estimer la probabilité qu’il ait été généré par un LLM, un peu comme une mesure d’entropie relative à une base de référence précalculée. Des biais spectaculaires Les résultats ont confirmé, voire amplifié, les observations d’Irregular. L’exemple le plus frappant concerne un modèle (Opus, à l’époque de l’étude) qui ne générait des mots de passe uniques que dans 35 % des cas — autrement dit, il répétait le même mot de passe dans 65 % des requêtes. Un modèle de Mistral faisait encore pire : il ne générait qu’un seul et unique mot de passe, toujours identique, laissant penser qu’il se contentait de restituer une valeur mémorisée durant son entraînement plutôt que d’en générer une nouvelle. Gaëtan Ferry explique ce phénomène par la tokenisation : certains modèles (comme GPT, étudié par Irregular) découpent le mot de passe en plusieurs tokens indépendants, ce qui introduit une certaine variabilité, alors que d’autres semblent traiter le mot de passe comme un token unique, menant à une quasi-absence de diversité. Un biais récurrent, observé sur presque tous les modèles, est l’alternance rigide entre catégories de caractères (minuscule, majuscule, chiffre, symbole) selon un schéma répétitif — un pattern idéal à capturer dans une chaîne de Markov. Sur un modèle donné, par exemple, un symbole « # » est suivi d’un « 8 » dans 90 % des cas. Ce comportement s’explique par la nature même des LLM : entraînés à reproduire des régularités linguistiques, ils sont fondamentalement conçus pour être prévisibles — l’exact opposé de ce qu’exige une bonne génération de mot de passe, qui requiert une forte entropie. Résultats sur les données réelles En appliquant cette classification à un échantillon d’environ 3 millions de secrets génériques collectés entre janvier et mars 2026, l’équipe a identifié environ 28 000 mots de passe présentant une très forte probabilité d’avoir été générés par un LLM, avec un seuil de confiance élevé. Bien que ce nombre représente une fraction modeste de l’échantillon total, la tendance est constante : environ 1 500 à 2 500 nouveaux mots de passe générés par LLM apparaissent chaque semaine sur GitHub, un rythme jugé préoccupant compte tenu qu’il ne s’agit que du sous-ensemble visible publiquement — la réalité en environnements privés étant probablement plus large encore. L’analyse du contexte d’apparition de ces mots de passe révèle deux scénarios typiques : soit un humain a manifestement demandé au LLM de générer un mot de passe pour l’insérer dans un fichier de configuration (par exemple une base de données), soit — plus troublant — un agent de développement autonome a lui-même pris la décision de générer et d’intégrer le mot de passe dans du code, comme dans un fichier de configuration Terraform observé par l’équipe, le tout dans un commit signé par l’agent d’IA lui-même, sans intervention humaine apparente. Une anecdote marquante Lors d’une présentation de ces résultats en conférence, Gaëtan Ferry a vu une personne quitter précipitamment la salle en voyant une diapositive listant des exemples de mots de passe faibles générés par un LLM. Cette même personne est revenue lui expliquer qu’elle avait justement demandé, ce matin-là, à un LLM de générer un mot de passe pour un service en ligne — et qu’elle venait de réaliser qu’il s’agissait exactement du même mot de passe affiché à l’écran. Un exemple frappant, selon lui, du fait que même des publics avertis en sécurité adoptent ce genre de pratique risquée. Conclusion Gaëtan Ferry conclut que le problème dépasse la simple question de la qualité du mot de passe généré : demander à un LLM hébergé chez un tiers de générer un secret expose potentiellement ce secret avant même qu’il n’apparaisse à l’écran de l’utilisateur, via les journaux et infrastructures du fournisseur. Il y voit une incompréhension plus profonde de la nature du LLM et des bonnes pratiques de gestion des secrets, et espère que ce partage contribuera à faire évoluer les pratiques des développeurs. Collaborateurs Nicolas-Loïc Fortin Gaetan Ferry Crédits Montage par Intrasecure inc Locaux réels par SSTIC

  5. Jul 8

    Teknik - A Needle in a Haystack - Identifying an Infostealer Attack Through Trillions of Events in a Large-scale Modern SOC

    Parce que… c’est l’épisode 0x318! Shameless plug 19 septembre 2026 - Bsides Montréal 20 au 26 septembre 2026 - BruCON 13 novembre 2026 - DEATHCon 16 au 19 novembre - European Cyber Week 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026 24 et 25 février 2027 - SéQCure 2027 Description Contexte Dans cet épisode spécial, l’animateur reçoit François Labrèche, scientifique de données, pour discuter de la façon dont son entreprise traite l’immense volume de signaux de sécurité générés par son SOC à grande échelle (managed XDR). Contrairement à un SOC traditionnel, François travaille en back-end et a accès aux données de tous les clients, ce qui lui permet de construire des modèles et des filtres globaux applicables à l’ensemble des alertes. L’objectif de l’épisode est double : expliquer le pipeline de filtrage des données, puis illustrer son fonctionnement à l’aide d’un cas réel. Le pipeline de filtrage Étape 1 — Les détecteurs Le point de départ, ce sont des billions d’événements bruts. La première étape repose sur des règles de détection simples et peu coûteuses en calcul : correspondances avec des IOC (indicateurs de compromission), domaines ou IP malveillants, ainsi que des règles de corrélation basiques détectant des anomalies (par exemple, un utilisateur qui se connecte pour la première fois à une machine de développement). Ces règles ne prouvent rien de malveillant en soi, mais elles servent à isoler tout ce qui sort de l’ordinaire pour l’envoyer plus loin dans le pipeline. Après cette étape, il ne reste que 0,03 % des données initiales — un filtre énorme, mais qui représente encore 2,6 milliards d’événements sur deux semaines, un volume toujours impossible à traiter manuellement. Étape 2 — Déduplication et corrélation La deuxième étape combine deux mécanismes. La déduplication regroupe les alertes générées en grand nombre par une même attaque (comme un déni de service ou un scan) visant la même cible, réduisant ainsi des dizaines de milliers d’alertes en une seule. La corrélation, elle, relie des alertes distinctes provenant de détecteurs différents mais concernant la même activité (par exemple, plusieurs signaux liés à un même utilisateur et une même machine). Pour rendre ce travail possible, une équipe dédiée normalise en amont tous les signaux — qu’ils proviennent des senseurs propriétaires ou de fournisseurs tiers — dans un format standardisé, en capturant les éléments clés (nom de l’alerte, entités impliquées, IP, nom d’hôte, etc.). La corrélation s’appuie sur une fenêtre d’analyse fixe (environ un mois) et sur des bases de données de comptage historique, sans recours au machine learning à ce stade. Étape 3 — La suppression Cette étape cible des cas précis, propres à un client ou une situation donnée. Certaines alertes sont bénignes uniquement dans un contexte particulier : par exemple, un client qui effectue des scans de vulnérabilité hebdomadaires de façon planifiée, ou du trafic DNS provenant de Cloudflare, connu comme légitime. Ces règles de suppression sont paramétrées en collaboration avec le client ou l’ingénieur qui le supporte, et nécessitent une connaissance fine de son environnement. Des règles similaires sont aussi créées lorsque les équipes de recherche de menaces identifient des indicateurs malveillants publiés par erreur, afin de bloquer ces faux indicateurs pour l’ensemble des clients. Étape 4 — La priorisation C’est ici qu’intervient le machine learning. Les alertes sont divisées en deux groupes selon leur sévérité : haute et moyenne/basse. Un modèle supervisé, entraîné chaque semaine sur des données historiques (les décisions passées des analystes), est appliqué aux alertes de sévérité élevée pour prédire une probabilité de menace réelle. Ce modèle sert à deux fins : fermer automatiquement les alertes jugées très peu probables (réduisant le bruit pour les analystes), ou ajuster la sévérité des alertes jugées menaçantes. Les alertes de sévérité plus basse ne sont pas ignorées : elles sont réutilisées pour enrichir le contexte autour d’une menace identifiée par le modèle, en allant chercher toutes les alertes liées au même utilisateur et à la même machine durant la même période. Un point important soulevé dans la discussion concerne la dégradation des modèles : si un modèle supervisé était réentraîné sur ses propres prédictions (sans validation humaine), il se dégraderait progressivement, un peu comme les modèles de langage qui s’effondrent lorsqu’ils apprennent sur leurs propres données. Pour éviter ce piège, l’équipe conserve un échantillon de 5 à 10 % des données sur lequel le modèle n’agit jamais automatiquement — ces alertes sont envoyées aux analystes pour un triage normal, ce qui permet de mesurer en continu la performance réelle du modèle (faux négatifs, dérive) et de générer des données d’entraînement non biaisées pour les futurs modèles. Étude de cas : détection d’un info stealer Pour illustrer concrètement le pipeline, François présente un cas réel portant sur deux semaines de données : à partir de 9,7 billions d’événements, le filtrage complet aboutit à seulement 81 000 alertes, soit environ 50 par client. Pour le client étudié, seulement sept alertes émergent — deux de haute sévérité liées à un vol de mot de passe, et cinq autres jugées bénignes (vol d’identifiants légitime confirmé par le client). Grâce au modèle de priorisation, les deux alertes à forte probabilité de menace sont sélectionnées, puis l’analyste ramène toutes les alertes liées au même utilisateur et à la même machine, incluant trois alertes de sévérité plus basse. L’ensemble reconstitue une chronologie claire : un exécutable déguisé en éditeur PDF s’exécute, établit une connexion réseau anormale vers un serveur de commande, puis déclenche des détections successives de vol de mots de passe et de données de navigateur — signature typique d’un info stealer. Isolément, chaque alerte de type « info stealer » génère énormément de faux positifs ; c’est la combinaison de plusieurs signaux corrélés dans le temps, pour la même entité, qui permet à l’analyste de conclure avec confiance à une véritable compromission et de recommander la réimagerie de la machine du client. L’épisode se conclut sur l’idée que ce type de pipeline permet non seulement de filtrer efficacement le bruit à très grande échelle, mais aussi de reconstruire, a posteriori, une histoire cohérente de l’attaque à partir des données brutes. Notes A Needle in a Haystack - Identifying an Infostealer Attack Through Trillions of Events in a Large-scale Modern SOC Collaborateurs Nicolas-Loïc Fortin François Labrèche Crédits Montage par Intrasecure inc Locaux réels par nsec

  6. Jul 2

    Teknik - Living Off The Pipeline - Defensive Research, Weaponized

    Parce que… c’est l’épisode 0x315! Shameless plug 19 septembre 2026 - Bsides Montréal 20 au 26 septembre 2026 - BruCON 13 novembre 2026 - DEATHCon 16 au 19 novembre - European Cyber Week 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026 24 et 25 février 2027 - SéQCure 2027 Description Un rendez-vous annuel sur la sécurité de la chaîne d’approvisionnement logicielle Ce podcast fait le point sur la présentation de François Proulx à NorthSec, où il aborde depuis quatre ans la sécurité de la chaîne d’approvisionnement logicielle (supply chain security). Chaque année a marqué une étape : la première présentait une vue d’ensemble du problème; la deuxième introduisait Poutine, un outil d’analyse statique open source destiné aux équipes défensives pour détecter les vulnérabilités dans les pipelines CI/CD; la troisième présentait les règles internes développées par son employeur, Boost Security, pour réduire les faux positifs de Poutine à grande échelle. La découverte troublante : les attaquants ont pris de l’avance Le tournant de cette année vient d’un constat inquiétant. Fin 2024, François a découvert sur Breach Forums (un forum cybercriminel aujourd’hui disparu ou renommé) des mentions du mot « Poutine » associées au nom de son employeur. Un utilisateur anonyme, visiblement non anglophone, discutait ouvertement de l’exploitation de pipelines de build et partageait des vulnérabilités zero-day encore non exploitées au moment de la publication. Quelques heures plus tard, le projet Python très populaire Ultralytics (des millions de téléchargements hebdomadaires) était compromis. Le même compte est revenu peu après pour se plaindre du faible gain obtenu (quelques bitcoins via un mineur rapidement neutralisé), puis n’a plus jamais été réutilisé. Cet épisode a révélé que certains attaquants surveillaient activement les publications de l’équipe et exploitaient les vulnérabilités presque en temps réel — un comportement inhabituel, car les attaquants sont généralement en retard sur les chercheurs. L’entreprise de François a elle-même été victime d’une attaque similaire (un employé compromis), ce qui a servi de signal d’alarme interne, même si l’incident a été contenu sans dommage. Pourquoi la chaîne logicielle est si vulnérable François explique que l’effet multiplicateur des dépendances transitives (parfois des milliers, même pour une application simple utilisant React et quelques librairies npm) crée une surface d’attaque énorme. Beaucoup de ces micro-projets sont maintenus par des développeurs isolés, parfois inactifs, épuisés, ou disparus, ce qui laisse des vulnérabilités non corrigées, parfois même non divulguées publiquement. GitHub Actions, utilisé par environ 90 % des projets open source sur GitHub, est identifié comme un vecteur clé. Bien que sa conception initiale limitait l’impact d’un code malveillant exécuté via une pull request (aucun accès aux secrets de publication), l’ajout progressif de fonctionnalités plus puissantes a ouvert la porte à des scénarios où des tiers non-mainteneurs peuvent déclencher l’accès à des secrets sensibles. De Poutine à Smoke Meat : automatiser l’exploitation Face à ce constat, François a pris la décision — difficile pour lui, davantage orienté « blue team » — de créer un outil offensif : Smoke Meat. Il le compare à Metasploit, créé par HD Moore au début des années 2000, qui a démocratisé l’exploitation de vulnérabilités classiques. Smoke Meat vise à faire de même pour les vulnérabilités des pipelines CI/CD : rendre leur exploitation accessible à tous, pas seulement aux experts, afin de forcer une prise de conscience collective. L’outil combine l’analyse statique de Poutine avec un moteur qui filtre les vulnérabilités les plus fiables et à fort impact (« blast radius »), génère automatiquement les payloads d’attaque, puis permet une exploitation réelle et un pivot latéral — comme un « meterpreter » adapté au contexte CI/CD. La terminologie choisie file la métaphore du barbecue : le « counter » (interface de l’opérateur), le « kitchen »/C2 (serveur de commande), et le « brisket » (l’implant qui s’exécute chez la victime, le « smoker »). Une fois actif, le brisket collecte rapidement (en une fraction de seconde) les secrets disponibles en mémoire, les trie selon leur potentiel de pivot, puis peut soit se retirer immédiatement, soit maintenir un tunnel pour une exploration plus poussée. Des zero-days accessibles à grande échelle Contrairement à Metasploit qui exploite généralement des vulnérabilités connues, Smoke Meat cible des zero-days présents dans une infrastructure publique que n’importe qui peut découvrir en scannant des dépôts GitHub. François souligne que les dépôts privés, souvent perçus comme moins exposés que les dépôts publics (vitrines soignées des entreprises), contiennent en réalité davantage de négligences : clés temporaires oubliées, projets expérimentaux mal sécurisés, etc. L’exemple concret : Team PCP et Trivy L’attaque du groupe Team PCP, discutée dans de précédents épisodes du podcast, illustre parfaitement ce mécanisme. Le groupe a exploité une vulnérabilité connue depuis longtemps dans l’outil populaire Trivy (développé par Aqua), infectant les utilisateurs consommant automatiquement les dernières versions. Le malware exfiltrait ensuite les secrets des nouveaux environnements infectés, permettant de répéter l’opération ailleurs — une propagation quasi-autonome, proche d’un ver informatique, bien que semi-manuelle. Un appel à l’action pour les défenseurs François conclut sur un ton presque désabusé : après quatre ans à répéter le même message, seuls les attaquants semblent l’avoir vraiment entendu. Il insiste sur le caractère déterministe de Smoke Meat — aucun recours à des modèles de langage, uniquement des payloads fiables et reproductibles — et sur la simplicité des correctifs, souvent limités à quelques lignes dans un fichier YAML plutôt qu’à des refontes architecturales majeures. L’objectif de l’outil est de rendre le danger tangible et immédiat pour les équipes qui, autrement, resteraient indifférentes, en reproduisant l’esprit des débuts du hacking où la démonstration technique primait sur le simple discours théorique. Notes Living Off The Pipeline - Defensive Research, Weaponized Collaborateurs Nicolas-Loïc Fortin François Proulx Crédits Montage par Intrasecure inc Locaux réels par nsec

  7. Jul 1

    Teknik - Au-delà des identifiants - le profilage des victimes dans l'économie des cleptogiciels

    Parce que… c’est l’épisode 0x314! Shameless plug 19 septembre 2026 - Bsides Montréal 20 au 26 septembre 2026 - BruCON 13 novembre 2026 - DEATHCon 16 au 19 novembre - European Cyber Week 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026 24 et 25 février 2027 - SéQCure 2027 Description Dans cet épisode de Polysécure, l’animateur reçoit Andréanne Bergeron et Olivier Bilodeau, chercheurs chez Flare, pour discuter d’une recherche sur le profilage des victimes de kleptogiciels (infostealers). L’objectif de cette recherche n’était pas de blâmer les individus, mais bien d’identifier de grandes tendances comportementales afin de bâtir des campagnes de sensibilisation mieux ciblées, plutôt que des messages génériques auxquels personne ne s’identifie. Méthodologie L’équipe s’est appuyée sur un échantillon représentatif tiré d’une année complète de compromissions (2025), afin d’éviter tout biais lié à des campagnes ponctuelles. Les données proviennent de tout ce qu’un kleptogiciel peut dérober : cookies de session, mots de passe, identifiants, liste des logiciels installés, documents personnels et historique de navigation. À partir de ces informations, les chercheuses ont codifié une série de variables binaires (présence ou absence d’un élément donné : outils techniques, jeux, sites à risque, indices démographiques comme la localisation ou l’âge probable) pour ensuite dégager des profils types par recoupement statistique. Le travail s’est fait en va-et-vient : Olivier explorait manuellement les journaux pour repérer des motifs intéressants, qu’Andréanne validait ensuite statistiquement. Les grands profils de victimes Plusieurs profils récurrents ont émergé de l’analyse : Les utilisateurs de divertissement : joueurs qui téléchargent des jeux piratés, des mods ou des « cheats » (l’exemple de Roblox est cité), ainsi que les consommateurs de contenu pornographique, une catégorie quasi systématiquement présente dans ce type d’échantillon. Les ordinateurs partagés en famille : des cas où plusieurs identifiants portant le même nom de famille apparaissent dans un même journal, suggérant qu’un parent prête son ordinateur de travail à ses enfants pour jouer. Les profils techniques : de façon contre-intuitive, 82 % de l’échantillon présente des compétences techniques (présence d’IDE comme VS Code, historique GitHub/GitLab, etc.), après élimination des faux positifs comme les runtimes C++ préinstallés. Les chercheuses insistent sur la distinction entre « technique » et « conscient des enjeux de cybersécurité » : de nombreuses personnes maîtrisent l’informatique sans connaître l’écosystème des logiciels malveillants qui les cible spécifiquement. Un exemple concret est donné : un développeur de Flare a failli installer une fausse version de Slack trouvée via une publicité Google malveillante, ne s’en rendant compte qu’après avoir reçu un avertissement de signature invalide. Le risque de chaîne d’approvisionnement (supply chain) : certaines victimes ont accès, via leur poste, à de multiples systèmes cloud de tiers (l’exemple donné est un consultant en marketing numérique avec accès à plusieurs comptes cloud de clients). Les chercheurs évoquent la brèche historique de Target, qui aurait pu être causée par un incident de type infostealer chez un fournisseur de climatisation. Les acteurs de la menace eux-mêmes : certains cybercriminels se font voler leurs propres outils en utilisant des « crypters » gratuits piégés (backdoorés), exposant du même coup leur infrastructure (comptes Cloudflare, hébergement à l’épreuve des balles, etc.). Le « Capitaine Get Things Done » : profil moins technique cherchant désespérément à résoudre un problème ponctuel (ex. : réinitialiser une imprimante Epson) et téléchargeant un utilitaire douteux trouvé en ligne, parfois repérable via l’historique de traductions Google Translate. L’« Unlocky Executive » : cadre ayant accès à des systèmes RH ou comptables, généralement infecté via une version piratée de logiciels bureautiques comme PowerPoint. Interprétation criminologique Andréanne, dont la formation est en criminologie, explique la surreprésentation des profils techniques par la combinaison de deux mécanismes classiques en victimologie : se trouver dans un environnement à risque (fréquenter des sites de jeux, télécharger des bibliothèques de code, etc.) et adopter un comportement à risque (cliquer, télécharger, faire confiance à des sources non vérifiées). Les deux facteurs doivent être réunis pour qu’il y ait victimisation — un joueur de cartouches Genesis hors ligne ne court aucun risque, contrairement à quelqu’un qui télécharge régulièrement des modules Python ou des jeux piratés. Vers une sensibilisation adaptée Plutôt que de produire une campagne complète, l’équipe a créé des affiches-exemples destinées à inspirer les organisations à concevoir leurs propres campagnes, fondées sur des statistiques réelles issues de la recherche plutôt que sur du marketing générique. Parmi les exemples cités : 26 % des victimes de kleptogiciels ont accès à de l’infrastructure d’entreprise, illustrant qu’un usage personnel d’un ordinateur professionnel peut faire basculer toute une organisation. Le principe clé avancé est qu’être exposé à un patron de fraude constitue la meilleure protection contre celui-ci — d’où l’importance de raconter des anecdotes concrètes et « relatables » (par exemple, un cas vécu par un collègue) plutôt que des modules de formation génériques et vite oubliés, comme les anciens modules chez Bell surnommés « le petit chevalier ». Prochaines étapes Andréanne travaille désormais avec sa collègue Estelle Ruellan à essayer de prédire l’apparition de nouvelles campagnes de kleptogiciels afin d’alerter les gens en amont. Olivier, de son côté, développe un outil de réponse aux incidents assisté par IA qui analyse les journaux de vol de données pour identifier le vecteur d’infection probable et évaluer le « rayon d’explosion » (blast radius) d’une compromission, tout en gardant un analyste humain aux commandes. Vu la sensibilité de l’outil, son accès sera limité aux praticiens vérifiés de la communauté Discord éducative Flare Academy, avant une mise en ligne publique prévue dans les prochaines semaines. Notes What Infostealer Victims Have In Common: 2 Behavioral Patterns That Should Reshape Cybersecurity Training Collaborateurs Nicolas-Loïc Fortin Andréanne Bergeron Olivier Bilodeau Crédits Montage par Intrasecure inc Locaux réels par Cybereco

  8. Jun 25

    Teknik - Sold to the highest bidder - the escalation of ADINT from geolocation tracking to intrusion vector (nsec)

    Parce que… c’est l’épisode 0x311! Shameless plug 26 et 27 juin 2026 - leHACK 30 juin au 2 juillet 2026 - Pass the SALT 19 septembre 2026 - Bsides Montréal 20 au 26 septembre 2026 - BruCON 13 novembre 2026 - DEATHCon 16 au 19 novembre - European Cyber Week 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026 24 et 25 février 2027 - SéQCure 2027 Description Introduction Cet épisode spécial, enregistré à Montréal lors de la conférence NorthSec, réunit Coline Chavane et Maxime Arquillière, venus de France présenter leur recherche sur l’ADINT (advertisement-based intelligence). Leur équipe CTI, spécialisée dans le suivi des fournisseurs privés de logiciels espions (spyware) et membre de l’initiative Pall contre les abus de ces technologies, a identifié cette tendance émergente en cherchant à documenter les nouveaux vecteurs d’intrusion utilisés par ces entreprises, au-delà des exploits « zero-click » déjà connus (comme ceux exposés par Citizen Lab ou Amnesty International sur WhatsApp). Comment fonctionne la publicité en ligne Coline explique le mécanisme du real-time bidding : en moins de 100 millisecondes, chaque fois qu’un espace publicitaire s’affiche dans une application, un système d’enchères se déclenche. Les données de l’utilisateur (type d’appareil, identifiant publicitaire mobile, centres d’intérêt) sont transmises à de multiples annonceurs qui enchérissent pour diffuser leur publicité. Fait crucial : même les annonceurs qui perdent l’enchère reçoivent ces données, sans qu’aucun contrôle ne soit possible sur leur usage ultérieur. Cet identifiant publicitaire mobile (MAID), censé être pseudo-anonymisé, permet en réalité un suivi cross-plateforme très précis, exploitable à grande échelle pour désanonymiser les individus. Maxime souligne que ce système est mondialement fragmenté par des cadres légaux disparates (RGPD en Europe basé sur l’opt-in, régimes opt-out ailleurs), créant des zones grises que certaines entreprises exploitent. Les trois catégories d’ADINT Les intervenants ont catégorisé les usages détournés de ces données en trois types : ADINT passif : collecte massive de données publicitaires (directement ou via des data brokers) pour établir des profils. Exemple donné : identifier les employés d’un site sensible (agence de renseignement, site de défense) en observant les téléphones qui s’y rendent quotidiennement, puis recouper avec leur domicile et leurs fréquentations pour du profilage. ADINT actif : au lieu d’observer passivement, l’acteur configure une alerte déclenchée dès qu’un identifiant mobile spécifique participe à une enchère publicitaire dans un périmètre donné, permettant un suivi quasi temps réel d’une cible précise. Ces données sont ensuite revendues à des gouvernements, forces de police ou entreprises privées. ADINT offensif : le plus préoccupant, il utilise le processus d’enchère lui-même comme vecteur d’intrusion, en délivrant une publicité vérolée à une cible spécifique pour compromettre son appareil. Documenté notamment par Amnesty International dans les dossiers Intellexa, ce vecteur « stratégique » complète les vecteurs « tactiques » nécessitant une proximité physique. Un écosystème sophistiqué et concentré Maxime explique que cette diversification des vecteurs d’intrusion est stratégiquement vitale pour les fournisseurs de spyware, surtout après la condamnation de NSO Group aux États-Unis lui interdisant de cibler WhatsApp — une décision qui menace la viabilité économique d’entreprises dépendantes d’un vecteur unique. Fait notable révélé par Recorded Future : au sein du consortium lié à Intellexa figure une entreprise publicitaire propriétaire d’un SSP (plateforme utilisée par les éditeurs d’applications), directement intégrée au processus d’enchères. Cela confirme que l’ADINT offensif reste réservé à des acteurs sophistiqués et bien financés, souvent israéliens ou américains, employant d’anciens membres de services de renseignement en cyberintrusion. Ces sociétés se déploient notamment en Asie, marché en expansion, comme l’ont découvert Coline et Maxime via des brochures commerciales trouvées en source ouverte — notamment celles de la société « Patterns », qui vante la désanonymisation à partir d’un simple numéro de téléphone. Usages à grande échelle et actualité Interrogés sur des attaques plus larges que le ciblage individuel, les invités distinguent l’ADINT du malvertising (opportuniste et large). Ils citent toutefois un cas documenté en Syrie (2015-2016) où le ciblage publicitaire a servi à comptabiliser et suivre les déplacements de réfugiés fuyant une zone de guerre. Plus actuel : aux États-Unis, l’agence ICE figure parmi les clients confirmés de solutions incluant des capacités ADINT — une utilisation désormais assumée publiquement, contrairement à des pratiques plus discrètes par le passé. Protections limitées pour les utilisateurs Coline note que certaines initiatives existent côté fabricants (comme le Lockdown Mode d’Apple, limitant les permissions de suivi GPS), mais que les utilisateurs disposent de peu de moyens concrets au-delà de l’hygiène numérique de base (refus des cookies, etc.) pour se protéger de ce profilage à grande échelle. Conclusion Cette recherche met en lumière un angle mort de la surveillance numérique : un écosystème publicitaire légitime, mondial et extrêmement efficace pour capter des données comportementales, détourné par une industrie grise et bien financée à des fins de renseignement, de profilage et, dans les cas les plus sophistiqués, d’intrusion informatique ciblée. Notes Sold to the highest bidder - the escalation of ADINT from geolocation tracking to intrusion vector Collaborateurs Nicolas-Loïc Fortin Maxime Arquillière Coline Chavane Crédits Montage par Intrasecure inc Locaux réels par Northsec

See All (226)

About

Podcast francophone sur la cybersécurité. Pour professionels.

Information

  • Creator
    Nicolas-Loïc Fortin et tous les collaborateurs
  • Years Active
    2025 - 2026
  • Episodes
    226
  • Rating
    Clean
  • Copyright
    © CC BY-NC-ND 4.0
  • Show Website
    PolySécure Podcast volet Teknik