PolySécure Podcast volet Teknik

Nicolas-Loïc Fortin et tous les collaborateurs

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

  1. 4d ago

    Teknik - A systematic approach to evading antivirus software

    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

    38 min

  2. 5d ago

    Teknik - GenAI en cybersécurité - cas concret d'utilisation et retour d'expérience (Cybereco)

    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

    29 min

  3. May 28

    Teknik - Sécurité des sous-stations électriques

    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

    52 min

  4. May 27

    Teknik - Private Key Leaks in the Wild - Insights from Certificate Transparency (nsec)

    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

    33 min

  5. May 26

    Teknik - Stratégie de sécurité applicative adaptée à l'IA (Cybereco)

    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

    33 min

  6. May 20

    Teknik - État de la menace en 2026 (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

    47 min

  7. May 14

    Teknik - Mythos no hype

    Parce que… c’est l’épisode 0x2F9! 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 contexte : un signal d’alarme venu de Google Next Nicolas Bédard, professionnel en cybersécurité chez Palo Alto Networks, revient de Google Next où il a tenu 16 rencontres clients. Un constat frappant : la quasi-totalité de ces clients avaient Mythos en tête de liste de leurs préoccupations. Ce modèle d’intelligence artificielle d’Anthropic, encore en phase de prévisualisation, a déclenché une vague d’inquiétude dans l’industrie. Nicolas admet lui-même qu’il avait sous-estimé l’ampleur du phénomène avant de constater, face à face, l’anxiété généralisée de ses interlocuteurs. Qu’est-ce que Mythos et pourquoi ça change la donne ? Mythos est un modèle d’IA de nouvelle génération, considérablement plus performant que les modèles précédents (comme Opus 4.7 de Claude) pour une tâche précise : trouver des vulnérabilités dans du code logiciel. Sa force ne réside pas uniquement dans sa capacité à détecter des failles individuelles, mais surtout dans son aptitude à établir des liens entre plusieurs vulnérabilités mineures. Là où deux ou trois failles de niveau faible ou moyen seraient jugées sans conséquence prises isolément, Mythos est capable de les relier pour révéler une vulnérabilité critique. C’est un changement de paradigme majeur. Le programme d’accès anticipé d’Anthropic Palo Alto Networks fait partie du programme « Class Wing » d’Anthropic, aux côtés d’autres grands acteurs du cloud et de la cybersécurité. Ces partenaires ont reçu un accès privilégié à Mythos avant son lancement public, leur permettant de scanner leur propre code à la recherche de failles inconnues. Selon Nicolas, cette démarche relève d’un geste de responsabilité corporative : Anthropic a anticipé les risques liés à la puissance de son modèle et a donné une longueur d’avance aux joueurs majeurs pour se préparer. Palo Alto a d’ailleurs lancé, en collaboration avec son équipe Unit 42, une offre d’accompagnement pour aider les clients à réaliser des analyses similaires avec des modèles déjà accessibles publiquement. La menace pour les systèmes anciens et le code ouvert L’un des aspects les plus préoccupants concerne les systèmes hérités. Historiquement, un vieux programme en COBOL sur AS/400 ou un mainframe oublié bénéficiait d’une forme de sécurité par l’obscurité : personne ne s’intéressait à y chercher des failles parce que c’était trop coûteux et peu rentable. Seuls les acteurs étatiques avaient les moyens de développer des exploits sophistiqués. Avec Mythos et ses futurs équivalents, cette barrière financière disparaît. N’importe qui pourra potentiellement analyser du code ancien et y trouver des failles exploitables. Le risque s’étend aussi à la chaîne d’approvisionnement logicielle. Le code ouvert, massivement réutilisé par l’industrie, devient un vecteur d’attaque amplifié. Un acteur malveillant pourrait scanner des bibliothèques populaires, y découvrir des vulnérabilités non divulguées, et les exploiter à grande échelle — ou pire, contribuer du code malicieux que des milliers de développeurs téléchargeraient en toute confiance. Le déluge de correctifs qui s’annonce Les premières conséquences sont déjà visibles : Microsoft et d’autres grandes entreprises ayant accès à Mythos publient des volumes de correctifs bien supérieurs à la normale. Nicolas anticipe que la situation va s’intensifier considérablement dans les mois à venir, particulièrement autour de la sortie publique du modèle, estimée vers juin ou juillet. Le modèle traditionnel du « Patch Tuesday » — ce cycle mensuel prévisible d’application de correctifs — risque de voler en éclats, car certaines failles seront trop critiques pour attendre le prochain cycle. Pour les entreprises qui peinent déjà à appliquer 10 à 12 correctifs mensuels sur des systèmes comme SAP, l’idée d’en gérer 200 ou 500 est vertigineuse. Les arrêts de production, les tests de régression, la coordination avec les équipes d’affaires : tout cela se complexifie de manière exponentielle. Et les pratiques modernes de développement (microservices, SRE, CI/CD) qui pourraient absorber ce choc ne sont maîtrisées que par une poignée de grandes entreprises technologiques. Les recommandations concrètes Face à ce tsunami, Nicolas et son interlocuteur reviennent aux fondamentaux avec trois axes prioritaires. Premièrement, scanner son propre code dès maintenant avec les modèles disponibles, sans attendre Mythos. Des chercheurs ont publié des méthodes de prompting permettant de simuler les capacités de Mythos avec Opus 4.7. Deuxièmement, assurer une couverture à 100 % des contrôles de sécurité existants. Chaque exception, chaque angle mort, chaque compte de service mal configuré devient une porte d’entrée potentielle. L’analogie de l’eau est parlante : comme l’eau qui s’infiltre par la moindre fissure, ces modèles d’IA trouveront inlassablement le moindre trou dans les configurations. Troisièmement, réduire l’exposition externe au maximum et développer une capacité de réaction en temps réel. Le passage de « plusieurs jours » à « quelques minutes » pour répondre aux menaces impose une transformation profonde des centres d’opérations de sécurité. Les approches traditionnelles de réponse aux incidents, avec leurs processus de révision humaine, ne suffiront plus. Un appel à l’action pour les dirigeants Nicolas conclut avec un message direct : chaque responsable de la sécurité (CISO) devrait engager dès maintenant une conversation transparente avec son conseil d’administration sur les implications de Mythos. Il s’agit d’aller chercher les budgets et les ressources nécessaires avant la crise, plutôt qu’après une attaque. L’industrie s’apprête à vivre un moment pivot où l’on passera d’une logique de liste noire à une logique de liste blanche, où seul ce qui est explicitement autorisé sera permis. Les paradigmes vont changer, et ceux qui ne s’y préparent pas risquent d’en subir les conséquences de plein fouet. Collaborateurs Nicolas-Loïc Fortin Nicolas Bédard Crédits Montage par Intrasecure inc Locaux réels par Nicolas Bédard

    31 min

  8. May 5

    Teknik - La place du tooling dans le threat intelligence (CTI)

    Parce que… c’est l’épisode 0x2F3! Shameless plug 9 au 17 mai 2026 - NorthSec 2026 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 Présentation des invités Dans cet épisode technique de Polysécure, l’animateur reçoit deux analystes de l’équipe TDR (Threat Detection and Research) de Sekoya. Charles Meslay se spécialise en reverse engineering et en analyse de malware, tandis que Félix Aimé se concentre sur l’étude de campagnes liées à des États — cyberespionnage, sabotage — et joue un rôle central dans le développement d’outils internes pour mener les investigations. L’épisode prend appui sur un billet de blog récemment publié par l’équipe portant sur une campagne d’APT28, groupe étatique lié à la Russie, pour élargir la discussion à l’ensemble du tooling utilisé en CTI. Du reverse engineering manuel à l’automatisation Le point de départ concret est l’analyse d’un malware écrit en .NET, attribué à APT28 et découvert début 2025. Initialement, le travail reposait sur des outils classiques comme dnSpy : une interface graphique permettant de décompiler le code, de renommer les fonctions et de comprendre progressivement leur logique. Ce processus, bien que relativement accessible, est extrêmement chronophage — de une à trois semaines par binaire et par analyste. Avec l’émergence des LLM, Charles a d’abord commencé à copier-coller manuellement des portions de code dans ChatGPT pour accélérer l’analyse. Cette pratique l’a conduit à une idée d’automatisation : la création d’un serveur MCP (Model Context Protocol), un protocole permettant à un LLM d’interagir avec des outils externes via une interface de type API. Ce serveur, mis en open source, est en réalité une brique d’un outil plus large développé en interne : Sara. sarA : un orchestrateur d’analyse automatisée Sara est présentée comme le cœur de l’écosystème d’analyse de Sekoya. Son fonctionnement est le suivant : on lui soumet un fichier, le LLM identifie le type de fichier et sélectionne les outils adaptés — qu’il s’agisse de Ghidra, d’IDA Pro ou d’outils maison en ligne de commande — pour procéder à l’analyse. À l’issue du processus, Sara génère un rapport structuré comprenant la description du comportement du binaire, les différentes couches d’obfuscation détectées, des scripts de désobfuscation si nécessaire, et une liste explicite des angles morts de l’analyse, notamment en cas de limitations liées aux tokens ou au nombre de passes effectuées. Le gain est spectaculaire : le temps d’analyse est passé de plusieurs semaines à quelques minutes. Au-delà du gain de vitesse, Sara a également élargi le cercle des analystes capables de contribuer au reverse engineering, y compris ceux qui n’avaient pas de formation approfondie dans ce domaine. Les analystes spécialisés, comme Charles, continuent quant à eux à intervenir sur les cas complexes que l’outil ne résout pas seul. Un écosystème d’outils progressivement construit Félix retrace l’histoire du tooling interne, développé de façon itérative au fil des années. Au départ, l’équipe disposait d’un simple serveur de cache connecté à des API tierces comme VirusTotal, permettant de limiter la consommation de quotas. Ce serveur a ensuite été refondu pour gérer de manière transparente les clés d’API, simplifiant ainsi la vie des développeurs internes. L’équipe a ensuite créé un ensemble d’API maison pour automatiser des tâches courantes : requêtes DNS, récupération de plages d’IP sur des AS, etc. Ces briques ont permis de construire 150 transformes pour Maltego, un logiciel d’analyse permettant d’appliquer des micro-opérations sur des entités (adresses IP, noms de domaine, etc.) afin d’enrichir les investigations. Aujourd’hui, l’équipe envisage de migrer vers Flosint, une solution open source française au fonctionnement similaire. Pour le suivi dans le temps des infrastructures malveillantes, deux outils ont été développés. Tracker interroge des services comme Shodan, Censys ou VirusTotal avec des règles précises pour surveiller en quasi-temps réel des infrastructures ou des malwares. Irma, plus orientée vers le hunting, permet d’initier des investigations à partir d’heuristiques poussées — par exemple, détecter un nom de domaine enregistré chez un registraire douteux qui résout vers un routeur potentiellement compromis en France. L’ergonomie au cœur du développement Un principe philosophique fort ressort de l’échange : l’ergonomie prime sur la complexité technique. Félix insiste sur le fait que les outils en ligne de commande, aussi puissants soient-ils, finissent par être abandonnés si leur utilisation requiert de consulter le manuel à chaque fois. L’objectif est que l’intégralité des outils soit accessible depuis un navigateur web, via des sous-domaines dédiés, avec une interface de recherche permettant de trouver un outil par mot-clé (par exemple, taper « LLM » pour lister tous les outils liés à l’intelligence artificielle). Cette centralisation présente plusieurs avantages : harmonisation des dépendances, déploiement automatisé via des pipelines CI/CD, et adoption effective par l’ensemble de l’équipe. Comme le résument les deux invités, un outil que personne n’utilise ne vaut rien — peu importe ses capacités techniques. L’IA comme accélérateur transversal L’arrivée des LLM a transformé deux autres facettes du travail. D’abord, le prototypage : là où il fallait parfois des semaines pour valider une preuve de concept, quelques heures suffisent aujourd’hui pour déterminer si une idée mérite d’être poursuivie ou abandonnée. Ensuite, la capitalisation du renseignement. L’équipe ingère des rapports publics d’éditeurs tiers, les modélise au format STIX — un standard structuré d’objets liés (campagnes, groupes d’attaquants, indicateurs de compromission) — et enrichit sa base de connaissance. Ce travail, autrefois fastidieux et manuel, est aujourd’hui en grande partie automatisé grâce aux LLM, avec une revue humaine finale. L’analyste se retrouve alors libéré des tâches répétitives pour se concentrer sur ce qui reste hors de portée de l’IA : la création de règles YARA, le développement de trackers d’infrastructure, et l’identification de détails techniques fins qui nécessitent encore un vrai jus de cerveau. Conclusion Cet épisode offre un regard rare et concret sur le quotidien d’une équipe CTI de pointe. Entre automatisation intelligente, philosophie d’ergonomie et intégration progressive de l’IA, Charles et Félix décrivent un métier en pleine mutation — où l’analyste humain reste indispensable, mais se concentre désormais sur ce qu’il fait le mieux. Notes APT28, sarA Is watching you! Collaborateurs Nicolas-Loïc Fortin Charles Meslay Félix Aimé Crédits Montage par Intrasecure inc Locaux virtuels par Riverside.fm

    35 min
See All (215)

About

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

Information

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