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

Parce que… c’est l’épisode 0x310! 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 Dans cet épisode spécial de la série Cybereco, l’animateur Nicolas reçoit Florian Le Mouël, doctorant à Polytechnique travaillant depuis cinq ans avec Kelvin Zero sur la cryptographie distribuée, et Thierry St-Jacques-Gagnon. La discussion porte sur un concept encore peu répandu mais prometteur : la cryptographie à seuil (threshold cryptography), une alternative à la cryptographie conventionnelle où une seule clé protège l’ensemble des données. Le principe de base Plutôt que de reposer sur une clé unique, la cryptographie distribuée découpe la clé en plusieurs fragments répartis entre différents acteurs. Un seuil (par exemple deux fragments sur trois) suffit pour reconstituer la capacité de déchiffrer ou signer des données, sans qu’il soit nécessaire de disposer de tous les morceaux. Cette redondance offre une résilience accrue en cas de perte d’un fragment et facilite les mécanismes de récupération. Mathématiquement, le système s’appuie sur des polynômes. Avec un seuil de deux clés, on utilise un polynôme de degré 1, c’est-à-dire une ligne : un seul point ne permet pas de retrouver la ligne (une infinité de droites peut passer par ce point), mais deux points suffisent à la déterminer de façon unique. Cette propriété se généralise à des degrés supérieurs, permettant de distribuer autant de points que souhaité tout en fixant le nombre minimal nécessaire à la reconstruction. Cas d’usage principaux Le cas le plus fréquent évoqué est le stockage de données chez des fournisseurs infonuagiques étrangers. Dans un contexte géopolitique où plusieurs organisations cherchent à réduire leur dépendance envers des acteurs comme Microsoft, Amazon ou Google, la cryptographie à seuil permet de conserver les avantages de ces plateformes (puissance de calcul, redondance géographique) tout en limitant les risques liés à la souveraineté des données, sans devoir développer des compétiteurs locaux à court terme. Un second cas concerne les équipements IoT ou industriels, souvent limités en stockage et en puissance de calcul, où la gestion classique de clés prépartagées pose un problème logistique et de sécurité au moment des rotations. La cryptographie à seuil permet d’abaisser le niveau de risque toléré sur l’équipement lui-même, puisqu’une opération sensible nécessitera toujours la combinaison avec des fragments gérés dans des environnements plus sécurisés, comme des HSM en centre de données. Fonctionnement opérationnel Chaque acteur impliqué (par exemple le fournisseur cloud, l’utilisateur, un administrateur) détient un fragment de clé, appelé « point » sur la ligne ou le polynôme. Point essentiel : la génération de la clé doit elle-même être un processus distribué, afin qu’aucun acteur ne puisse créer la clé complète puis prétendre n’en avoir conservé qu’un fragment. Chaque participant génère sa propre part de façon isolée, en utilisant des preuves à divulgation nulle de connaissance (zero-knowledge), ce qui ancre le modèle dans une logique de confiance zéro : même un acteur malveillant ne peut ni obtenir le résultat final seul, ni empêcher les autres d’y parvenir, sauf en cas de collusion majoritaire (atteinte du quorum contre l’utilisateur). Lors d’une requête, le fournisseur applique d’abord son propre « masque » sur les données chiffrées, une opération réversible qui ne révèle jamais le contenu en clair de son côté. Les données, toujours chiffrées, sont ensuite transmises au demandeur, qui applique à son tour son propre fragment. Une fois le quorum atteint, les données apparaissent en clair uniquement du côté du dernier participant, sans qu’aucun acteur n’ait eu accès au contenu déchiffré à un moment intermédiaire. Ce mécanisme assure une protection à la fois au repos et en transit, indépendamment de protocoles comme TLS. La propriété homomorphique L’un des éléments les plus originaux du système est le caractère homomorphique appliqué aux clés (et non aux données, comme c’est plus souvent le cas). Cela permet d’effectuer des opérations mathématiques sur les fragments sans jamais reconstituer la clé complète, notamment pour mettre à jour un quorum (changer le nombre de participants requis ou remplacer un participant) sans avoir à déchiffrer et rechiffrer l’ensemble des données. Cette flexibilité facilite grandement la gestion du cycle de vie des clés, un enjeu particulièrement coûteux en cryptographie classique. Configurations observées chez les clients Les configurations les plus courantes en pratique sont de type « 2 de 3 » ou « 3 de 5 ». Des cas plus complexes existent, comme des systèmes de gouvernance d’entreprise avec des seuils variables selon le type de ressource (par exemple 8 de 15), mais cela implique une gestion plus lourde des autorisations. Pour des cas d’usage asymétriques, comme les signatures sur blockchain, les paramètres peuvent grimper à plusieurs centaines de participants. Le système permet également une récursivité : un fragment peut lui-même être repartagé en sous-quorum, une technique utile notamment pour la gestion des sauvegardes. Vers la post-quantique Les invités soulignent que ce modèle décentralisé est particulièrement pertinent dans la perspective d’une migration vers la cryptographie post-quantique, puisque les protocoles d’échange de clés symétriques actuels seront vulnérables aux attaques quantiques. Le NIST (l’organisme américain de certification) vient justement de lancer son tout premier appel à candidatures pour des schémas de cryptographie à seuil. Kelvin Zero prépare une soumission qui se distinguerait en proposant un schéma hybride combinant cryptographie classique et post-quantique — une première québécoise et canadienne dans ce domaine encore very jeune. Collaborateurs Nicolas-Loïc Fortin Florian Le Mouël Thierry St-Jacques-Gagnon Crédits Montage par Intrasecure inc Locaux réels par Cybereco

Parce que… c’est l’épisode 0x30D! Shameless plug 24 et 25 juin 2026 - Troopers 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 Résumé du panel Polysécure — nsec 2026 Présentation des panélistes Cet épisode spécial du podcast Polysécure réunit cinq invités aux profils variés : François Labrèche, principal data scientist chez Sophos travaillant avec le machine learning et les LLM dans un contexte XDR; François Proulx, VP recherche en sécurité chez Boost Security, spécialisé dans l’exploitation des build pipelines et la chaîne d’approvisionnement logiciel; Charles F. Hamilton, qui fait du red team chez Cyber; Christian Paquin, développeur cryptographique chez Microsoft Research; et Philippe Pépos Petitclerc, étudiant au doctorat et fondateur d’une petite compagnie de pentest, amateur de CTF. Le « Magic AI » et le phénomène Mythos La discussion s’ouvre sur l’éléphant dans la pièce : l’intelligence artificielle. Le sujet central est Mythos, présenté comme une démonstration marketing spectaculaire qui a semé la panique dans le milieu de la cybersécurité. Les panélistes s’entendent toutefois pour relativiser : ce modèle n’est pas fondamentalement plus dangereux que les autres. Labrèche rappelle qu’en tant que data scientist côtoyant les LLM chaque semaine, il observe une amélioration continue. Les travaux de Nicolas Carlini (Anthropic) montraient déjà des vulnérabilités trouvées dans le kernel Linux avant Mythos. Le succès de Mythos tiendrait surtout à son bon nom, plus effrayant que « vulnerability scanning ». Plusieurs nuances sont apportées sur le cas BSD choisi pour la démonstration : ce système représente moins de 1 % du marché, donc son code est peu analysé et offre peu de surface d’attaque intéressante. De plus, la vulnérabilité « découverte » serait en réalité déjà connue (un correctif raté de 2007) et présente dans les données d’entraînement. L’attaquant dans l’équation Un point récurrent : on oublie souvent l’attaquant dans l’équation. Pépos Petitclerc, ayant analysé les attaques sur son blog, constate des comportements « brain dead » — des attaquants peu qualifiés qui dépensent des tokens pour n’aller nulle part. Proulx, early adopter du vulnerability research par LLM depuis 2022, insiste sur le principe garbage in, garbage out : la qualité du prompt et l’expertise humaine font toute la différence. Les vulnérabilités récentes dans Linux ont d’ailleurs été trouvées par des humains extrêmement compétents (l’exemple de Copy-on-write/Splice est cité), pas par des agents autonomes. Le coût constitue un frein majeur : peu d’attaquants peuvent se permettre de dépenser 20 000 $ pour une vulnérabilité sans valeur réelle. Trouver une vulnérabilité ne signifie pas qu’elle soit exploitable en pratique, ni qu’on puisse la patcher plus vite — le problème du patching demeure (référence au drama MITRE/NVD de l’année précédente). La question du volume et de la visibilité Labrèche observe que les alertes clients n’ont pas explosé depuis trois mois, ce qui contredit la rhétorique d’une démocratisation massive des attaques. Les panélistes déboulonnent aussi le mythe des agents « autonomes » dotés d’une volonté propre : ces systèmes sont inertes sans humain pour les diriger. Une métaphore des fourmis illustre toutefois le danger : même inefficaces, des milliers de tentatives en parallèle finiront par faire tomber des cibles. Le vrai problème reste la visibilité réseau, inchangé depuis dix ans. Dette technique et nouvelles surfaces d’attaque Les LLM introduisent aussi des vulnérabilités. Proulx évoque des attaques de supply chain où du code généré est exploité quelques heures après son merge, et critique la prolifération de micro-librairies npm non maintenues (proposition humoristique de « tuer JavaScript »). Pépos Petitclerc signale une tendance : des secrets d’application Azure leakés sur GitHub, reconnaissables à leur signature (emojis, Unicode), avec 124 000 commits du type « remove client secret ». Le bandwidth humain pour réviser tout ce code généré devient le plus grand risque. L’écosystème criminel et la curiosité Une longue digression porte sur le disconnect entre l’industrie et les attaquants. Les criminels sont opportunistes : pourquoi dépenser des tokens quand le spray gratuit fonctionne ? Fait savoureux, les forums criminels eux-mêmes se plaignent du slop généré par les LLM. Deux « criminels » de la salle (clins d’œil humoristiques) racontent leurs débuts : cabines téléphoniques trafiquées, cartes d’arcade éditées en hexadécimal, disquettes de Doom copiées. Le message : tout part de la curiosité, et la ligne grise de la légalité est ce qui a mené plusieurs vers la défense des systèmes. On rappelle aussi que dans certains pays défavorisés, le cybercrime est une option de survie, parfois sous forme de travail forcé industrialisé — ce qui explique en partie l’absence d’explosion des attaques sophistiquées. Conclusion Le panel se termine sur des questions ouvertes : génère-t-on de la dette technologique trop vite pour pouvoir la corriger (réponse : oui, aucune chance de patcher à cette vitesse)? La rareté des vulnérabilités forcerait les attaquants vers des chemins connus, plus détectables, tout en augmentant la valeur des zero-days et de la main-d’œuvre hautement spécialisée. L’exemple de Metasploit illustre comment un outil peut rendre triviale une exploitation complexe, érodant l’expertise. Sur une analogie finale — une vulnérabilité non découverte fait-elle du bruit? — l’animateur clôt la discussion. Collaborateurs Nicolas-Loïc Fortin François Labrèche François Proulx Charles F. Hamilton Christian Paquin Philippe Pépos Petitclerc Crédits Montage par Intrasecure inc Locaux réels par Northsec

Parce que… c’est l’épisode 0x308! Shameless plug 24 et 25 juin 2026 - Troopers 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 Dans cet épisode spécial enregistré en marge de la conférence NorthSec, Christian Paquin, cryptographe chez Microsoft Research et ancien étudiant de Gilles Brassard à l’Université de Montréal, présente ses travaux sur la provenance des actifs numériques et sur une approche permettant de concilier authenticité du contenu et protection de l’identité de son créateur. Le problème : désinformation et perte de confiance Avec la prolifération de l’intelligence artificielle générative, il devient de plus en plus difficile de distinguer le contenu authentique du contenu fabriqué. Pour répondre à ce défi, l’industrie s’est rassemblée autour de la C2PA (Coalition for Content Provenance and Authenticity), un protocole qui permet de signer numériquement images, vidéos, fichiers audio et même textes afin d’en tracer l’origine et toutes les transformations subies. Le principe repose sur la cryptographie à clé publique, la même que celle utilisée pour sécuriser le web (HTTPS). Une caméra signe une photo avec une clé privée intégrée à l’appareil ; chaque transformation ultérieure (retouche, redimensionnement, republication sur un réseau social) invalide la signature précédente et nécessite une nouvelle signature de la part de l’éditeur responsable. On obtient ainsi un historique complet, dit « écran à écran », de la création jusqu’à la consommation du contenu. Si seule la dernière signature est généralement vérifiée, l’historique des transformations antérieures peut être conservé, soit en clair, soit de façon compressée grâce à des preuves à divulgation nulle de connaissance (zero-knowledge proofs). Cette norme est déjà largement adoptée : OpenAI signe ses images générées, Sony intègre la fonctionnalité dans certains appareils photo, Google l’offre sur ses téléphones Pixel, et Adobe ainsi que Microsoft l’intègrent à leurs outils. Le dilemme : authenticité contre anonymat Le problème, souligne Christian Paquin, est que cette forte authentification crée un lien direct entre le contenu et l’identité de son auteur. Or, dans plusieurs contextes, cette traçabilité pose un risque réel : journalistes couvrant des zones de conflit qui pourraient être identifiés et visés par un régime hostile, lanceurs d’alerte révélant des pratiques répréhensibles, ou artistes souhaitant publier anonymement tout en prouvant que leur œuvre leur appartient bel et bien. Dans ces cas, on souhaite prouver qu’un contenu provient d’une source légitime (par exemple, un journaliste affilié à une organisation reconnue) sans révéler de quel individu précis il s’agit. Deux solutions simples, mais limitées Deux approches rudimentaires existent déjà dans l’écosystème C2PA. La première consiste à utiliser un certificat auto-émis, à la manière de PGP : on publie sa propre clé publique pour que d’autres puissent vérifier le contenu, mais cela ne permet pas à un tiers de valider une affiliation institutionnelle (par exemple, confirmer qu’une personne travaille bien pour telle agence de presse). La seconde consiste à utiliser des certificats à très courte durée de vie, voire à usage unique, comme le fait Google sur ses téléphones Pixel, qui émet un nouveau certificat pour chaque photo prise. Cette méthode empêche les plateformes de lier différentes publications à un même utilisateur, mais exige de faire confiance à l’émetteur (ici Google) pour ne pas conserver de journal reliant les certificats entre eux. Les techniques cryptographiques avancées Pour résoudre ce dilemme sans dépendre de la confiance envers un tiers, Christian Paquin a développé un prototype open source combinant deux techniques. La première remplace les signatures classiques (RSA, ECDSA) par des signatures dites « randomisables », notamment l’algorithme BBS, actuellement en voie de standardisation à l’IETF. Ces signatures permettent de prouver qu’un certificat appartient bien à une hiérarchie de confiance donnée (par exemple, celle de Google ou de Radio-Canada) sans révéler les éléments uniques qui permettraient de relier plusieurs signatures à une même personne. La deuxième technique utilise des preuves à divulgation nulle de connaissance. Plutôt que d’inclure le certificat directement dans le fichier signé, on y insère une preuve démontrant que la signature a été générée correctement, que le certificat utilisé a bien été émis par une autorité reconnue, et qu’il était valide au moment de la signature, tout cela sans révéler la valeur exacte du certificat (qui pourrait servir d’identifiant indirect, par exemple via sa date d’expiration unique). Ces techniques, longtemps trop lourdes pour un usage pratique, sont devenues envisageables grâce aux avancées en efficacité des protocoles de preuves à divulgation nulle, largement stimulées par les investissements massifs dans l’écosystème des cryptomonnaies et des contrats intelligents (notamment Ethereum). Les défis du déploiement Christian Paquin compare ce chantier à la transition historique vers HTTPS, qui a pris plus d’une décennie et continue de poser des défis d’interface et de gestion de la confiance. Le déploiement de la provenance des contenus sera toutefois plus complexe encore : il touchera un nombre d’acteurs bien plus large (médias, fabricants d’appareils, éditeurs de logiciels, industries du cinéma et de la publicité, secteurs médical et militaire) et un volume de données incomparablement plus élevé, chaque photo prise pouvant nécessiter son propre certificat. Malgré ces défis, l’urgence est réelle : selon Christian Paquin, sans déploiement substantiel de ces mécanismes dans les deux prochaines années, l’érosion de la confiance envers le contenu numérique, déjà bien engagée dans la sphère politique, pourrait devenir difficile à renverser. À terme, le contenu dépourvu de marque d’authenticité pourrait être désavantagé par les algorithmes des plateformes, un peu comme les sites non sécurisés en HTTPS ont fini par être pénalisés par les moteurs de recherche. L’épisode se conclut sur une note encourageante : cette participation demeure volontaire, et les techniques discutées permettent d’envisager un avenir où authenticité et anonymat ne sont plus mutuellement exclusifs. Notes Doxxing-proof authentic digital media - trust the asset, protect the source Collaborateurs Nicolas-Loïc Fortin Christian Paquin Crédits Montage par Intrasecure inc Locaux réels par Northsec

Parce que… c’est l’épisode 0x304! Shameless plug 24 et 25 juin 2026 - Troopers 26 et 27 juin 2026 - leHACK 19 septembre 2026 - Bsides Montréal 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026 24 et 25 février 2027 - SéQCure 2027 Description Notes A systematic approach to evading antivirus software Collaborateurs Nicolas-Loïc Fortin Philippe Pépos Petitclerc Crédits Montage par Intrasecure inc Locaux réels par NorthSec éléments de cadrage. Premièrement, la modernité : on ne parle plus vraiment d’antivirus mais d’EDR (Endpoint Detection and Response). Selon lui, l’antivirus a été fusionné dans le concept d’EDR, qui correspond à un antivirus auquel s’ajoutent des capacités de télémétrie, de visibilité et de réponse pour les équipes de défense (Blue Team). Deuxièmement, pour rendre la recherche constructive comme première étude dans ce domaine, il a mis de côté les modèles statistiques pour se concentrer d’abord sur les moteurs déterministes, c’est-à-dire ceux dont le résultat est certain (par exemple, chercher un hash précis dans un fichier). Capacités versus signatures Pour généraliser son approche, Philippe travaille avec un « AV générique » plutôt qu’un produit en particulier, l’objectif étant de bâtir un plan d’évasion applicable à n’importe quel antivirus rencontré. Il introduit une distinction centrale : la capacité de détection, qu’il décompose en « une analyse plus une raison ou une façon de regarder ». Il compare cela aux signatures : la signature, c’est ce qu’on cherche (par exemple le hash lui-même), tandis que la capacité, c’est comment et où on le cherche. Hacher un fichier et comparer le résultat constitue une capacité ; le hash recherché est la signature. Construire l’inventaire des capacités Pour cartographier ces capacités, Philippe a combiné deux sources. D’une part, la littérature scientifique sur les techniques de détection, abondante, bien qu’on ignore lesquelles ont réellement été adoptées dans les produits commerciaux (beaucoup relèvent du secret industriel, difficile à citer en recherche académique). D’autre part, l’observation des techniques d’évasion utilisées « in the wild », même non documentées sérieusement, car leur popularité révèle indirectement quelles détections fonctionnent vraiment. Il a ensuite classifié ces capacités selon les mêmes principes que l’analyse de programme classique, produisant une arborescence où chaque technique s’inscrit dans des classes successives, ce qui permet de « couper des branches » pour identifier précisément la méthode en jeu — une démarche qu’il rapproche de la philosophie d’ATT&CK. La cartographie statique et dynamique La cartographie se divise en deux grandes catégories. Les analyses statiques examinent un fichier sur disque sans l’exécuter : hashes, recherche de séquences d’octets (avec ou sans « trous »), reconstruction d’information sémantique comme un graphe de flot de contrôle (CFG), ou simple analyse de chaînes de caractères. Ces analyses « cheap » sont fréquentes mais faciles à évader, car l’apparence d’un fichier se modifie aisément. Les analyses dynamiques se subdivisent entre le virtuel (sandbox, émulation, dans un faux système) et le concret (sur le vrai système). On y trouve le traçage d’appels de fonction, le hooking, et la réapplication de détections statiques à des moments clés — puisque scanner la mémoire est coûteux, l’antivirus utilise des déclencheurs pour choisir quand inspecter. Philippe souligne cet effort d’économie de ressources inhérent à chaque implémentation. La technique du « probing » Une contribution importante est le probing (sondage) : on teste un programme, on le modifie légèrement, puis on le reteste pour comparer les détections. Si le programme part non détecté, il peut rester non détecté ou le devenir. S’il part détecté, trois issues sont possibles : devenir non détecté, rester détecté avec le même identifiant, ou être détecté avec un nouvel identifiant. Comme les antivirus retournent des identifiants distincts plutôt qu’un simple verdict binaire, on extrait davantage d’information. En choisissant intelligemment la transformation, on isole la capacité réelle. Par exemple, ajouter un octet inoffensif casse un hash : si la détection reste identique, elle n’était pas basée sur un hash. Pour le dynamique, utiliser un packer (crypter) qui chiffre le payload et le déchiffre à l’exécution permet de révéler la présence d’une sandbox. Différences entre moteurs et stratégie d’évasion Tous les moteurs testés possèdent une sandbox détectable, mais leur usage varie énormément : certains détectent beaucoup via leur sandbox, d’autres presque rien. Philippe note que la capacité marketing (« on a du behavior, du sandboxing ») peut exister tout en ayant une banque de signatures si mince qu’elle ne se déclenche presque jamais. Les philosophies d’implémentation diffèrent : chaque éditeur capitalise sur sa technologie de prédilection. Sa méthode d’évasion consiste à « blinder » chaque capacité détectée : une fois la présence d’un unpacker ou d’une sandbox identifiée, il associe les techniques d’évasion connues qui neutralisent spécifiquement chacune, construisant un ensemble minimal couvrant toutes les capacités trouvées. L’objectif n’est pas une évasion universelle unique, mais un flowchart indiquant quoi faire et quoi éviter — ajouter du code inutile risquant de se faire repérer. Les résultats détaillés figureront dans sa thèse, le protocole étant maintenant stable et prêt à être lancé à grande échelle. Le volet CTF et l’intelligence artificielle L’équipe montréalaise de Philippe, active depuis une dizaine d’années, monte presque toujours sur le podium au Nordsec et vise une qualification au DEF CON. Leur distinction : une propension à sortir des sentiers battus et à trouver des solutions « weird », parfois des bypass transformant un défi de six heures en trente minutes. Sur l’IA, le Nordsec a levé cette année ses restrictions. L’équipe constate que le harnessing et le prompting ont moins d’impact que de simplement relancer le modèle plusieurs fois : la température et la répétition comptent davantage. Les modèles plus puissants, surchargés d’outils, « se creusent des trous » en polluant leur contexte. L’IA réussit aujourd’hui environ 95 % des défis sauvegardés, ce qui soulève des questions sur le plaisir et l’avenir des CTF — un défi que Philippe fait confiance aux organisateurs du DEF CON pour relever. Notes A systematic approach to evading antivirus software Collaborateurs Nicolas-Loïc Fortin Philippe Pépos Petitclerc Crédits Montage par Intrasecure inc Locaux réels par NorthSec

Parce que… c’est l’épisode 0x303! Shameless plug 3 au 5 juin 2026 - SSTIC 2026 24 et 25 juin 2026 - Troopers 26 et 27 juin 2026 - leHACK 19 septembre 2026 - Bsides Montréal 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026 24 et 25 février 2027 - SéQCure 2027 Description Dans cet épisode spécial Cybereco, Cédric Thibault partage un retour d’expérience sur le développement d’une plateforme d’automatisation de workflows de cybersécurité utilisant réellement l’IA générative. Sa motivation : il existe beaucoup de discours sur l’IA, mais peu de retours concrets de bâtisseurs qui ont fait des choix, commis des erreurs et obtenu des succès. Le problème : des analystes noyés Le constat de départ est partagé par toutes les entreprises qu’il côtoie. Face à la montée réelle des attaques — ce n’est pas qu’un argument marketing — les moyens humains restent très limités. Paradoxalement, ajouter des outils, même justifié, produit souvent l’effet inverse : cela noie davantage les équipes et réduit la capacité humaine en bout de chaîne. Son objectif est de redonner de la capacité aux clients et de remettre les analystes dans un véritable poste d’analyste. Un analyste devrait faire de l’analyse et exercer son esprit critique, pas exécuter des clics séquencés en suivant un playbook. Beaucoup de processus de sécurité existent d’ailleurs en dehors du SOC. L’exemple récurrent est le triage des courriels signalés comme hameçonnage par les utilisateurs : ces signalements s’accumulent dans une boîte cyber partagée, et les analystes valident les indicateurs, lisent les courriels et jugent leur caractère malicieux. Additionné, cet effort représente des heures, pour une tâche répétitive sans réelle valeur ajoutée — comparable à la roue d’un hamster, puisque le flux de courriels malicieux est infini. L’approche : déterminisme d’abord, IA aux points clés Cédric insiste sur le mot clé du déterminisme. Par nature, un agent IA ne sera jamais pleinement déterministe : on peut maximiser sa fiabilité sans jamais la garantir totalement. Face à la pression marketing qui promet de remplacer des équipes entières par un agent, son retour d’expérience est différent : il faut utiliser l’IA là où elle est réellement utile, et s’appuyer sur des bases solides et déterministes — du procode ou du low-code via des plateformes d’automatisation. Ces plateformes existent depuis des années, et la cybersécurité connaît bien les SOAR, mais ceux-ci sont restés cantonnés à l’univers du SOC. L’avantage de l’IA est qu’en mêlant les deux technologies — automatisation robuste et agents IA très ponctuels à des endroits clés — on obtient une valeur maximale : interaction intelligente avec les utilisateurs d’un côté, garantie que la prise d’action est exécutée par des scripts de l’autre. Bloquer le port 80 doit signifier exactement le port 80, pas une approximation. Cette fiabilité est indispensable, car aucune équipe cyber n’adoptera des processus qui ne sont pas fiables à 100 %. Cédric rappelle un constat partagé deux ou trois ans plus tôt par David Gérard : en cybersécurité, la tolérance à la déviation est nulle, et dès qu’un analyste constatait une hallucination, c’était l’abandon systématique de toute la solution. Ces abandons sont dommageables, car la technologie bien employée apporte beaucoup de valeur. Le mode « yolo » n’est pas recommandé : déployer des workflows IA en production exige une démarche très structurée et beaucoup d’ingénierie, un aspect trop peu évoqué face aux vidéos YouTube spectaculaires. L’ingénierie et l’équipe hybride Un conseil fort : ne jamais confier un projet d’ingénierie IA uniquement à des ingénieurs IA. Il faut des spécialistes de domaine. Pour un workflow anti-hameçonnage dans M365, un spécialiste M365 est nécessaire, car les API ne sont pas si simples. Cédric recommande une équipe hybride en binôme : un ingénieur IA qui maîtrise la plateforme d’automatisation et l’invocation optimale du LLM (tokens, coûts, garde-fous), et un spécialiste de contenu qui choisit le meilleur flow et la bonne façon de travailler avec les outils tiers. Concrètement, dans ce type de workflow, environ 90 % des nodes sont purement déterministes et seulement 10 % relèvent d’agents IA — mais placés au bon endroit, ils servent de « colle » permettant de finaliser le processus de bout en bout. Il déconseille d’utiliser des agents pour prendre des actions en console quand un simple script déterministe fait l’affaire, sans risque ni coût en tokens. Gestion du risque et amélioration continue Le niveau d’acceptation du risque varie selon les clients. Certains gardent un human in the loop — une alerte Teams avec un bouton « approve » ou « reject » avant toute action. D’autres, après une preuve de concept concluante, acceptent une automatisation complète, mais toujours avec des actions déterministes qui réduisent le risque sans le supprimer. Une fois les premiers résultats observés, l’effet est impressionnant : les clients veulent enrichir leurs workflows et améliorer des processus qu’ils n’optimisaient pas faute de temps. L’analyste passe alors en mode amélioration et critique. Mais il faut stabiliser des versions, car l’observabilité et l’évaluation de performance exigent des jeux de tests roulés en permanence pour garantir la stabilité, tout en développant les versions suivantes en parallèle. L’automatisation génère aussi de nombreux KPI, impossibles à obtenir dans des processus manuels, formant une boucle de rétroaction continue. Comme le reporting des plateformes low-code/no-code est souvent pauvre, son équipe exporte les logs des agents vers les SIEM des clients pour créer des tableaux de bord. Ce qu’on ne peut mesurer, on ne peut le faire évoluer. Une évolution nécessaire Cédric reprend une formule tirée d’un papier de la CSA lié à Mythos : ne pas faire évoluer ses processus de cybersécurité aujourd’hui revient à préparer ses équipes au burnout. Il ne s’agit pas que l’IA fasse tout, mais qu’elle améliore des points critiques pour décharger les analystes face à l’alert fatigue déjà bien présente. Les premiers retours clients sont très positifs. Il anticipe une adoption plus large et précise qu’il n’a pas abordé le sujet des agents personnels, un autre enjeu dont on parlera beaucoup en 2026. Collaborateurs Nicolas-Loïc Fortin Cédric Thibault Crédits Montage par Intrasecure inc Locaux réels par Cybereco

Parce que… c’est l’épisode 0x301! Shameless plug 3 au 5 juin 2026 - SSTIC 2026 24 et 25 juin 2026 - Troopers 26 et 27 juin 2026 - leHACK 19 septembre 2026 - Bsides Montréal 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026 24 et 25 février 2027 - SéQCure 2027 Description Dans cet épisode, Georges Badro, consultant chez Mandiant à Paris spécialisé dans les infrastructures critiques et les systèmes industriels, explique le fonctionnement et la sécurisation des sous-stations électriques. Architecture du réseau électrique Le réseau électrique se décompose en trois zones : la génération (centrales hydrauliques, nucléaires, thermiques, renouvelables), le transport et la distribution. Le réseau de transmission permet de limiter les pertes d’énergie et surtout d’équilibrer production et consommation afin de maintenir une fréquence stable. Contrairement à un réseau d’eau, un réseau électrique exige un équilibre permanent entre ce qui est produit et ce qui est consommé, sous peine de l’endommager. Les sous-stations sont les nœuds névralgiques de ce réseau de transmission : ces grands parcs clôturés que l’on aperçoit au bord des routes centralisent et redistribuent l’électricité. On y trouve des transformateurs et des disjoncteurs, ces derniers permettant d’ouvrir ou de fermer le courant. Aujourd’hui, ces équipements ne sont plus opérés manuellement mais via du contrôle numérique : interfaces homme-machine (IHM), contrôle à distance, RTU (Remote Terminal Units servant de passerelle vers le centre de contrôle), relais de protection et de contrôle (qui lisent tension, intensité et fréquence pour automatiser des décisions), postes d’ingénierie et équipements réseau. Interconnexion croissante et surface d’attaque Badro insiste sur la disparition de l’« air gap » d’autrefois. Les sous-stations sont désormais interconnectées avec les centres de contrôle, des tiers, des partenaires, parfois directement à internet, voire avec le cloud pour la maintenance prédictive. L’architecture type comprend un réseau IT, une DMZ séparant l’IT des systèmes industriels (OT), un centre de contrôle régional ou national (avec historians, serveurs SCADA, bases de données) relié aux sous-stations via VPN ou MPLS. Chaque sous-station est configurée différemment. Certaines connexions exploitent le Powerline Communication (PLC), qui utilise les câbles électriques existants pour transmettre des paquets TCP/IP. Cette multiplication des accès distants, justifiée par la difficulté d’intervenir physiquement dans des zones rurales, augmente considérablement le risque. Les protocoles courants incluent IEC 104, DNP3 et GOOSE. Scénario d’attaque en Red Team Badro détaille l’approche Red Team de Mandiant, précisant qu’un véritable attaquant ne prendrait pas les mêmes précautions. L’attaque commence généralement par un accès initial à l’IT via phishing ou exploitation de vulnérabilités. Suit une phase de reconnaissance : énumération du domaine, recherche de documentation sur les partages réseau et wikis, fichiers de configuration aux extensions spécifiques, mots de passe en clair (notamment de VPN) et schémas d’architecture. L’accès au réseau OT s’obtient ensuite via un VPN, l’exploitation de flux autorisés au firewall, ou la compromission d’hyperviseurs hébergeant des VM IT et OT. Plutôt qu’un scan NMAP destructeur, l’équipe privilégie une reconnaissance furtive : écoute passive du trafic, analyse des adresses IP et MAC, utilisation de logiciels légitimes d’opérateurs et de scripts spécialisés (Modbus, DNP3). Les vulnérabilités exploitées sont souvent basiques : mots de passe par défaut sur interfaces web, SSH ou Telnet, parfois sur des fonctionnalités cachées utilisées par les fournisseurs et inconnues des équipes. À partir d’une IHM, l’attaquant remonte vers les relais de protection, cibles plus insidieuses permettant des dégâts coûteux. Compromissions réelles Badro compare deux attaques réelles. En Ukraine en 2015, l’attaque a démarré sur l’IT par phishing (malware Black Energy via macro), récupéré des mots de passe VPN, accédé aux IHM, RTU et switchs Moxa, puis ouvert les disjoncteurs et déployé des firmwares corrompus pour empêcher la reprise de contrôle. En Pologne en décembre 2025, l’attaque a ciblé directement l’OT en exploitant une CVE connue mais non corrigée pendant plusieurs semaines sur des firewalls exposés à internet. L’attaquant s’est étendu aux RTU, relais, IHM et convertisseurs série-Ethernet via des comptes par défaut, a lancé des scans locaux, uploadé des firmwares corrompus, supprimé des fichiers système des relais et déployé des wipers sur les IHM. Le constat marquant : malgré dix ans d’écart, les mêmes vulnérabilités basiques persistent. Si l’entrée dans les réseaux IT s’est durcie, le côté OT reste comme l’IT « d’il y a très longtemps » — peu de mots de passe robustes, peu de contrôles — par préjugé d’isolement et par des pratiques de maintenance figées. Attaques avancées et défense Au-delà de la simple ouverture d’un disjoncteur, des attaques plus subtiles ciblent la logique des relais : modifier des valeurs de déclenchement, fausser une LED, ou altérer la fonction de réenclenchement automatique. Ces manipulations restent invisibles jusqu’à une condition rare (un arbre tombant sur une ligne) et sont très difficiles à diagnostiquer sans journalisation. Côté défense, Badro recommande : changer les mots de passe par défaut (et alerter si l’ancien est réutilisé), maintenir à jour les systèmes exposés à internet, restreindre les accès SSH/HTTP à des points spécifiques, contrôler les flux PLC venant des centrales, et surtout établir une visibilité réseau et événementielle à tous les niveaux. La prévisibilité des réseaux OT facilite la définition d’une baseline et la détection d’anomalies. L’approche consiste à décomposer chaque système, comprendre les fonctions et leurs interfaces internes/externes (par exemple le GPS spoofing), puis concevoir protections et détections adaptées — en protégeant avant tout le disjoncteur, élément le plus critique. Collaborateurs Nicolas-Loïc Fortin Georges Badro Crédits Montage par Intrasecure inc Locaux réels par Google Paris

Parce que… c’est l’épisode 0x300! Shameless plug 3 au 5 juin 2026 - SSTIC 2026 24 et 25 juin 2026 - Troopers 26 et 27 juin 2026 - leHACK 19 septembre 2026 - Bsides Montréal 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026 24 et 25 février 2027 - SéQCure 2027 Description Dans cet épisode du podcast Polysécure enregistré au NorthSec, Gaëtan Ferry et Guillaume Valadon, tous deux cyber security researchers chez GitGuardian depuis deux ans, présentent une recherche consacrée aux fuites de clés privées cryptographiques. Guillaume est par ailleurs mainteneur du logiciel Scapy et rédacteur en chef du magazine MISC. Le problème de l’attribution Contrairement à des secrets classiques comme les clés AWS, dont on peut retrouver le propriétaire en interrogeant les services associés, une clé privée cryptographique (RSA par exemple) ne se rattache à aucune identité. C’est un simple objet mathématique aux propriétés cryptographiques, utilisable pour de multiples usages : connexion SSH, protection d’un site web en TLS, etc. En regardant la clé seule, impossible de savoir à quoi elle sert ou à qui elle appartient. Quelques indices existent parfois — le nom de fichier (norssec.io.key) — mais souvent on tombe sur des private.key inexploitables. L’enjeu de la recherche était donc de trouver une technique générique de catégorisation. La méthode : Certificate Transparency La solution repose sur les Certificate Transparency logs, un mécanisme de l’infrastructure X.509 datant de 2015. Chaque fois qu’une autorité de certification émet un certificat, elle doit le journaliser dans ces registres publics, souvent opérés par d’autres autorités. Ces journaux contiennent donc l’historique de tous les certificats émis. Le principe du matching est le suivant : une clé privée contient des informations sur sa partie publique (le module, dans le cas de RSA). On extrait cette partie publique, on calcule une empreinte SHA-256, et on fait de même pour les certificats. Comme un certificat TLS associe une clé publique à une identité (généralement le nom du site protégé), une simple jointure entre les deux bases d’empreintes permet de relier une clé privée à un site et à son propriétaire. La recherche s’est accélérée lors de la conférence Pass the SALT à Lille, où des contacts chez Google les ont alertés : les anciens logs de Certificate Transparency, coûteux à opérer, allaient être mis hors ligne. Or c’était précisément la dimension historique du dataset qui les intéressait. Un partenariat s’est noué : GitGuardian a fourni une liste d’empreintes, et Google a effectué la correspondance dans sa base propriétaire, renvoyant les certificats associés. Les chiffres Le dataset de fin 2025 comptait un million de clés privées distinctes, collectées via l’activité historique de GitGuardian — le public monitoring qui scanne GitHub, Docker Hub et d’autres sources à la recherche de secrets codés en dur, puis avertit les victimes en mode « bon samaritain ». Sur ce million, 42 000 clés correspondaient à des certificats émis par des autorités. Le chiffre peut sembler modeste, mais la majorité des clés ne servent jamais au TLS (projets personnels, SSH, autorités privées d’entreprise absentes des logs publics). Ces 42 000 clés étaient liées à plus de 140 000 certificats, signe que certaines avaient servi à émettre plusieurs certificats successifs, prolongeant d’autant la durée d’exposition. Après vérification, 2 600 clés restaient associées à un certificat valide en septembre 2025. Grâce à des techniques d’OSINT, 1 300 certificats ont pu être rattachés à environ 600 entités. La divulgation responsable, un parcours décevant L’équipe a entrepris un responsible disclosure en envoyant environ 4 300 emails à ces 600 entreprises. Résultat : seulement 54 réponses, soit environ 9 %. Même en se limitant aux adresses certaines à près de 100 %, le taux ne dépassait pas 36 %. Pour gérer un envoi aussi massif sans être bloqués comme spam, ils ont dû collaborer avec leurs collègues du marketing, rompus aux techniques de délivrabilité. Plus frappant que le silence : l’incompréhension des répondants. Beaucoup confondaient clé privée et certificat. Certains ont répondu avoir « changé le certificat », croyant le problème réglé. Une équipe de réponse à incident d’une grande entreprise a même produit une analyse détaillée pour conclure que l’endpoint utilisait désormais un autre certificat, refusant toute révocation — alors qu’un attaquant peut toujours mener une attaque man-in-the-middle avec l’ancien certificat non révoqué. Le certificat a fini par expirer un mois plus tard. Fait notable, 19 entités gouvernementales étaient concernées, et aucune n’a répondu. Comprendre TLS Le malentendu de fond tient au fonctionnement de TLS. On génère sa clé privée chez soi, puis on signe une demande de certificat (CSR) envoyée à l’autorité avec la clé publique. L’autorité vérifie les informations, journalise dans CT et renvoie le certificat. Le certificat n’est qu’une partie publique : il associe une clé publique à une identité, sans contenir le secret. Changer de certificat sans changer de clé n’invalide donc rien : l’ancien certificat reste exploitable pour usurper le service tant qu’il n’est pas révoqué. Forcer la révocation et la vraie solution Face au silence, l’équipe a contacté directement les autorités de certification pour demander la révocation, en fournissant les preuves de possession. Cette voie autoritative s’est révélée plus efficace, mais a généré des réactions parfois hostiles — dont un individu insultant expliquant que sa clé était « volontairement publique » pour permettre l’interception (cas d’usage type Burp), sans que le site l’indique clairement. Les chercheurs avouent un moment de doute, au point de vérifier auprès d’anciens collègues de l’ANSSI : le problème est bien systémique. La solution qu’ils privilégient n’est pas seulement l’éducation, mais l’automatisation. La réduction drastique de la durée de vie des certificats (vers 47 jours) imposera des outils comme Certbot, qui renouvelle déjà la clé privée en même temps que le certificat. Or 20 % des clés trouvées avaient fui plus de deux ans avant l’expiration du certificat le plus récent : des clés compromises réutilisées sur de nouveaux certificats pendant des années. Renouveler systématiquement la clé aurait éliminé ce cinquième des compromissions. Notes Private Key Leaks in the Wild: Insights from Certificate Transparency Collaborateurs Nicolas-Loïc Fortin Guillaume Valadon Gaetan Ferry Crédits Montage par Intrasecure inc Locaux réels par NorthSec

Parce que… c’est l’épisode 0x2FF! Shameless plug 3 au 5 juin 2026 - SSTIC 2026 24 et 25 juin 2026 - Troopers 26 et 27 juin 2026 - leHACK 19 septembre 2026 - Bsides Montréal 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026 24 et 25 février 2027 - SéQCure 2027 Description Le défi fondamental : le volume dépasse les humains Jonathan Marcil part d’un constat simple mais vertigineux : l’IA génère du code à une vitesse que les équipes de sécurité ne peuvent plus suivre humainement. Le volume de code produit est tel qu’il devient impossible de tout réviser avec rigueur sans y perdre sa santé mentale. Cette réalité impose une réponse stratégique, et c’est précisément l’objet de sa présentation à Cybereco : proposer des stratégies qui utilisent l’IA pour répondre aux problèmes que l’IA elle-même crée. L’humain reste une variable limitante Même si l’IA ne connaît pas de fatigue propre, les humains qui travaillent avec elle, eux, s’épuisent. Jonathan illustre ce point avec l’exemple du programme de bug bounty de cURL, qui a dû être fermé parce que les participants utilisaient l’IA pour générer des rapports de bogues en masse. Le résultat : une surcharge humaine impossible à gérer, même pour des experts qui connaissent le système depuis des dizaines d’années. L’IA peut amplifier le bruit autant que le signal. Le prompting : une compétence éphémère Un thème central de la discussion est la nature instable de la compétence en prompt engineering. Chaque nouveau modèle frontier réagit différemment, ce qui rend les techniques de prompting acquises partiellement obsolètes à chaque mise à jour majeure. Jonathan voit néanmoins une vertu dans cette diversité des modèles : elle empêche une standardisation totale et maintient une forme de compétition saine entre les fournisseurs. Cela dit, il met en garde contre la tentation de consacrer trop d’énergie à suivre chaque lancement au détriment des compétences fondamentales en sécurité. Le vibe coding et la perte de compétences L’un des points les plus préoccupants soulevés par Jonathan est le risque de dépendance cognitive. Le « vibe coding » — cette pratique de générer du code sans vraiment le comprendre — crée une illusion de productivité. Tant que tout fonctionne, personne ne pose de questions. Mais le jour où un bug survient ou qu’une faille est découverte, si les développeurs n’ont plus les compétences fondamentales pour diagnostiquer le problème, ils se retrouvent à demander à l’IA de corriger ce qu’elle a elle-même mal produit. Jonathan cite un exemple personnel : il a demandé à un modèle de réviser ses diapositives, et le modèle a omis un élément important — sans le signaler spontanément. L’autocritique reste un angle mort des LLM. Les stratégies proposées La réponse de Jonathan à ces défis repose sur plusieurs axes concrets : 1. Diversifier les modèles. Utiliser plusieurs IA en parallèle — demander à l’un de valider ce que l’autre a produit — est une pratique simple mais efficace pour introduire un regard critique dans le processus. Il suggère aussi de soumettre d’anciens travaux aux nouvelles versions des modèles, qui peuvent en faire de meilleures révisions. 2. Charger les bonnes pratiques de l’entreprise dans le LLM. Plutôt que d’utiliser un modèle générique, Jonathan propose d’alimenter le LLM avec la gouvernance, les politiques et les standards de sécurité propres à l’organisation. Les résultats, selon son expérience avec une formation Cybereco l’année précédente, peuvent être spectaculaires : des équipes ont corrigé des vulnérabilités réelles en moins de 15 minutes après avoir simplement fourni au modèle les bonnes pratiques contextuelles. 3. Combiner petits et grands modèles. Pour gérer les coûts et la vitesse, il propose d’utiliser des modèles légers (souvent locaux) pour les tâches d’exploration — par exemple, repérer les zones d’authentification dans une base de code — puis de faire traiter les résultats par un modèle plus puissant. Cette architecture en pipeline est à la fois économique et efficace. 4. Explorer les modèles open weight. Les modèles à poids ouverts, notamment ceux optimisés par des contributeurs chinois pour tourner sur du matériel modeste, offrent une flexibilité précieuse. Ils permettent de ne pas être entièrement dépendant des fournisseurs cloud et d’adapter l’usage à la tolérance au risque propre à chaque organisation. Le problème systémique : insécure par défaut La conversation se clôt sur une observation structurelle importante : les infrastructures cloud sont historiquement configurées pour maximiser l’adoption, c’est-à-dire ouvertes par défaut. Jonathan constate que les LLM ont reproduit ce même réflexe — livrer vite, livrer simple, quitte à négliger la sécurité. La sécurité applicative, qui arrive toujours en fin de processus, paie le prix de cette course à l’adoption. Il plaide pour inverser cette logique : partir d’une posture fermée et sécurisée par défaut, puis ouvrir ce qui est nécessaire, plutôt que l’inverse. Collaborateurs Nicolas-Loïc Fortin Jonathan Marcil Crédits Montage par Intrasecure inc Locaux réels par Cybereco

Parce que… c’est l’épisode 0x2FC! Shameless plug 3 au 5 juin 2026 - SSTIC 2026 24 et 25 juin 2026 - Troopers 26 et 27 juin 2026 - leHACK 19 septembre 2026 - Bsides Montréal 1 au 3 décembre 2026 - Forum INCYBER - Canada 2026 24 et 25 février 2027 - SéQCure 2027 Description Dans cet épisode spécial de Polysécure consacré à Cybereco, Charles F. Hamilton présente son analyse annuelle de l’état de la menace cyber en 2026. Comme chaque année, il s’efforce de distinguer le discours marketing des vendeurs de la réalité observée sur le terrain, fort de son expérience quotidienne en tests d’intrusion offensifs. Azure et Entra ID : des failles par défaut Une large partie de la discussion porte sur l’environnement Microsoft Azure et Entra ID (anciennement Azure Active Directory). Charles souligne un problème fondamental : beaucoup d’entreprises partent du principe que « si c’est Microsoft, c’est sécurisé », ce qui crée une forme de déresponsabilisation dangereuse. En réalité, la configuration par défaut d’Azure offre très peu de visibilité — les logs et informations de sécurité essentiels sont verrouillés derrière un paywall, rendant la validation quasi impossible sans un intervenant offensif. Un exemple frappant illustre ce problème : lorsqu’une entreprise configure une politique d’accès conditionnel imposant le MFA pour toutes les applications mais ajoute une seule exception (par exemple pour un compte d’automatisation), Microsoft ajoutait silencieusement Microsoft Graph et Azure Active Directory dans les exceptions. Or, Microsoft Graph est le point d’entrée vers pratiquement tous les services cloud. Un attaquant disposant d’un identifiant et mot de passe pouvait donc s’authentifier via Microsoft Graph sans aucun MFA. Bien que Microsoft ait corrigé ce comportement récemment, toute exception créée avant le correctif reste active. Charles en découvre encore quotidiennement, ce qui pose un problème majeur — notamment pour les assureurs, dont les questionnaires de conformité ne détectent pas ces failles. Le décalage entre sécurité offensive et défensive Charles défend l’idée que la sécurité offensive a une longueur d’avance considérable sur la défensive. Les produits de sécurité défensive bloquent souvent des menaces qui datent de plusieurs années, pas celles d’aujourd’hui. Il prend l’exemple du device code phishing, une technique qu’il utilise depuis une dizaine d’années et que les attaquants malveillants commencent seulement à découvrir en 2026. Les entreprises qui ont investi dans des tests offensifs il y a cinq ou six ans sont déjà protégées ; les autres paniquent aujourd’hui. Il insiste sur la valeur du Red Team : contrairement à un scan automatisé qui produit des milliers de vulnérabilités toutes marquées « critiques », un Red Team raconte une histoire — il identifie le chemin qu’un attaquant emprunterait pour atteindre ce qui a réellement de la valeur pour l’entreprise. Charles mentionne également le score EPSS (Exploit Prediction Scoring System), encore trop méconnu, qui permet de prioriser les vulnérabilités en fonction de leur probabilité réelle d’exploitation plutôt que de leur sévérité théorique. Infostealers et ClickFix : les menaces du quotidien La conversation aborde ensuite les infostealers, des logiciels malveillants qui récupèrent les mots de passe stockés dans les navigateurs. Leur efficacité tient à leur discrétion : ils ne touchent pas aux processus surveillés par les EDR/XDR et sont donc très peu détectés. Pire, ils se propagent souvent via des installeurs gratuits pour des jeux populaires comme Roblox ou Minecraft, ciblant les enfants. Quand un parent prête son ordinateur professionnel à son enfant, les identifiants corporatifs se retrouvent compromis. Charles rapporte des chiffres vertigineux : un de ses contacts dans le domaine possède des logs provenant de 600 millions de postes uniques infectés par des infostealers. Quant aux attaques ClickFix, Charles se dit fasciné qu’elles fonctionnent, car elles demandent à l’utilisateur d’exécuter une série d’étapes complexes — copier du PowerShell dans une invite de commande, par exemple. Mais l’utilisateur moyen ne comprend tout simplement pas ce qu’il fait : les extensions de fichiers, les commandes, tout cela n’a aucun sens pour lui. Le succès du phishing repose uniquement sur l’expérience utilisateur : plus c’est simple, plus ça marche. Supply chain et cas extrêmes Charles partage des histoires marquantes de sa carrière. Il a testé la sécurité d’avions dont les interfaces pilotes tournaient sous Flash et Windows embarqué. Bien que l’avion soit physiquement déconnecté d’internet, le laptop de mise à jour, lui, y passait — ouvrant la porte à des attaques de supply chain. Il raconte aussi le cas de guichets ATM dont le système de gestion acceptait des mises à jour non signées, permettant l’injection de code malveillant. Plus récemment, il a travaillé sur des cas d’infiltration d’employés nord-coréens se faisant passer pour des développeurs. Fait surprenant : ces individus étaient de bons ingénieurs et se faisaient toujours démasquer par des anomalies humaines (incohérences de localisation), jamais par leur code. IA, vibe coding et secrets exposés L’essor du vibe coding assisté par IA aggrave un problème existant : des développeurs qui ne comprennent pas ce qu’ils produisent. Charles a trouvé plus de 124 000 résultats sur GitHub pour « remove client secret » — des commits où des développeurs retirent des secrets Azure (tenant ID, application ID, client secret) sans jamais les révoquer. Beaucoup de ces commits portent les traces caractéristiques de code généré par IA, avec des emojis dans les commentaires. Le paradoxe de l’industrie cyber En conclusion, Charles soulève un paradoxe central : on n’a jamais eu autant de produits de sécurité, de solutions et de technologies pour prévenir les brèches, et pourtant on n’a jamais eu autant de brèches. Les entreprises s’étouffent sous les abonnements coûteux et les promesses marketing, mais négligent l’hygiène de base — segmentation réseau, gestion des correctifs, inventaire des systèmes. L’industrie souffre aussi d’un manque de conséquences réelles pour les entreprises négligentes, ce qui pousse beaucoup d’entre elles à faire le strict minimum. Le vrai travail reste à faire, et il commence par les fondamentaux. Collaborateurs Nicolas-Loïc Fortin Charles F. Hamilton Crédits Montage par Intrasecure inc Locaux réels par Intrasecure inc