La crise du Shadow Tunneling : pourquoi votre périmètre 2026 est déjà brisé

Le “périmètre d’entreprise” n’est plus un concept utile. Depuis des années, les responsables de la sécurité de l’information concentrent leurs défenses sur le blocage des applications SaaS non autorisées — le problème de Shadow IT du début des années 2020. En 2026, une menace plus insidieuse a pris la première place dans le registre des risques d’entreprise : Shadow Tunneling.

Alors que Shadow IT signifiait que les employés utilisaient des web apps non approuvées, Shadow Tunneling désigne des employés — et des attaquants — qui perforent des trous cryptés et directs à travers le pare-feu d’entreprise pour exposer des services internes au public internet. Que ce soit un développeur utilisant ngrok pour présenter une version locale, ou un acteur malveillant utilisant un daemon cloudflared pour maintenir une persistance, ces tunnels d’ombre sont les portes dérobées invisibles de l’ère moderne. Ils contournent votre WAF, aveuglent votre DLP, et rendent votre IDS obsolète — tout cela sans nécessiter de privilèges administratifs.

Ce document explore comment nous en sommes arrivés là, pourquoi les défenses traditionnelles basées sur l’IP ont échoué, et les deux outils les plus importants que les équipes de sécurité déploient en 2026 pour lutter : JA4+ fingerprinting TLS et monitoring kernel eBPF.

---

Partie 1 — Comment le périmètre est mort

Du Shadow SaaS à l’infrastructure Shadow

Le modèle château-et-fosse reposait sur une prémisse simple : faire confiance à tout ce qui se trouve à l’intérieur du réseau, bloquer tout ce qui est à l’extérieur. Cette fosse a été contournée par des milliers de petits ponts cryptés — chacun ouvert en quelques secondes par un développeur frustré par la friction VPN.

Des outils comme ngrok, Cloudflare Tunnel, Tailscale, et un écosystème croissant d’alternatives auto-hébergées (Pangolin, basé sur WireGuard, est devenu une option notable en 2025–2026) permettent une seule commande dans le terminal — souvent sans permissions élevées — pour créer une URL publique routable pour n’importe quel service privé. Le dépôt awesome-tunneling sur GitHub recense plus d’une centaine de ces outils, avec de nouvelles entrées apparaissant régulièrement, au point que le mainteneur a ajouté une exigence minimale de 100 étoiles début 2026 pour gérer le volume.

La menace n’est pas hypothétique. Lorsqu’un développeur exécute ngrok http 3000, il publie un port directement sur internet, contournant complètement la pile de sécurité d’entreprise. Le chiffrement de bout en bout du tunnel signifie que même si le trafic passe par une infrastructure surveillée, le contenu reste invisible aux outils d’inspection.

Pourquoi le blocage IP échoue

La réponse évidente — bloquer les plages IP connues des fournisseurs de tunnels — est effectivement obsolète depuis des années. Les services de tunneling modernes utilisent des réseaux Anycast et de grands pools d’adresses rotatives. Au moment où une liste de blocage se propage, le tunnel a migré vers un nouveau nœud. Bloquer une IP en 2026, c’est comme essayer de attraper de la fumée avec un filet de pêche.

Cela oblige les défenseurs à changer complètement leur cadre de référence — de où va le trafic à à quoi ressemble le trafic.

---

Partie 2 — JA4+ Fingerprinting TLS : Identifier l’invisible

Le problème que JA4 a été conçu pour résoudre

Chaque connexion TLS commence par une poignée de main ClientHello — un message d’ouverture non chiffré dans lequel le client déclare ses versions TLS supportées, suites de chiffrement, extensions, et autres paramètres. Ce message est une empreinte digitale. Différents logiciels — Chrome, curl, une bibliothèque HTTP en Go, un agent ngrok — produisent des messages ClientHello distincts, même lorsqu’ils communiquent avec la même destination.

La norme originale d’empreinte, JA3, fonctionnait en hachant ces paramètres dans une chaîne MD5 de 32 caractères. Elle a été largement adoptée et s’est avérée efficace pendant des années. Mais en 2023, Google a mis à jour Chromium pour randomiser l’ordre des extensions TLS à chaque connexion — une mesure de confidentialité qui a aussi brisé la stabilité de JA3, générant des milliards de hachages possibles pour ce qui était fonctionnellement le même navigateur.

Qu’est-ce que JA4+ et comment ça fonctionne

En septembre 2023, John Althouse chez FoxIO a publié JA4+, une suite modulaire de méthodes d’empreinte réseau conçues explicitement pour survivre à la randomisation. L’empreinte JA4 pour le trafic client TLS suit un format structuré, lisible par l’humain :

JA4 = [protocole+version]_[empreinte suites cryptographiques triées]_[empreinte extensions triées]

Par exemple, une empreinte pourrait ressembler à : t13d1516h2_a0e9c7f32f1c_e5b1d8a03d9a

L’innovation clé est le tri. Avant le hachage, JA4 trie à l’alphabet toutes les suites cryptographiques et extensions. Cela signifie que l’ordre aléatoire des extensions dans Chrome ne produit plus un hachage différent à chaque connexion — l’étape de tri normalise la sortie, produisant une empreinte stable indépendamment de l’ordre de présentation. Elle neutralise aussi une technique appelée “cipher stunting”, où les clients randomisent l’ordre des suites cryptographiques pour échapper à la détection basée sur JA3.

La suite JA4+ s’étend bien au-delà de TLS :

• JA4 — empreinte client TLS
• JA4S — empreinte réponse serveur TLS
• JA4H — empreinte client HTTP
• JA4X — empreinte certificat X.509
• JA4SSH — empreinte trafic SSH
• JA4T / JA4TScan — empreinte TCP

L’empreinte de base JA4 est open-source sous licence BSD 3-Clause. La suite plus large JA4+ est sous licence propriétaire FoxIO Licence 1.1, permettant une utilisation interne mais nécessitant un accord commercial pour la monétisation.

Adoption dans l’industrie

L’adoption de JA4+ parmi les grandes plateformes a été rapide. Cloudflare a intégré JA4 dans sa gestion des bots et sa stack Zero Trust — en développant un parseur TLS dédié en Rust (client-hello-parser) pour exposer les empreintes JA4 dans ses règles de pare-feu, ses Workers, et ses systèmes d’analyse. AWS, VirusTotal, et NetWitness ont tous adopté cette norme. VirusTotal permet spécifiquement aux analystes de pivoter sur les empreintes JA4 via son filtre de recherche behavior_network, permettant aux chasseurs de menaces d’identifier des familles de malware partageant la même bibliothèque TLS même lorsque les IP et domaines changent.

La gestion des bots d’entreprise de Cloudflare expose à la fois JA3 et JA4 directement dans ses règles de pare-feu. La plateforme ngrok affiche désormais les empreintes JA4 via son Traffic Inspector, et supporte des buckets de limitation de débit liés à l’empreinte JA4 — faisant de l’empreinte une variable de politique native, pas seulement un artefact d’observation.

Application de JA4+ à la détection de Shadow Tunnel

C’est ici que JA4+ devient directement pertinent pour le problème du Shadow Tunneling. Les agents de tunneling comme ngrok, cloudflared, et leurs équivalents ont des signatures distinctes lors de la poignée de main TLS — des combinaisons spécifiques de suites cryptographiques supportées, extensions, et valeurs ALPN qui diffèrent des navigateurs ou stacks TLS d’OS.

Important : renommer l’exécutable n’aide pas. Si un développeur renomme cloudflared en chrome.exe, le comportement de la poignée de main TLS reste identique à celui de l’agent cloudflared réel. Un navigateur Chrome produit une empreinte JA4 cohérente avec Chromium. L’agent tunnel renommé produit une empreinte cohérente avec la bibliothèque TLS Go sous-jacente à cloudflared. Ce ne sont pas la même chaîne.

Les équipes de sécurité en 2026 maintiennent des bibliothèques curatées d’empreintes JA4 pour les agents de tunneling connus — la base de données FoxIO est construite explicitement pour cela — et peuvent couper la connexion à la périphérie dès qu’une poignée de main correspondante est détectée, quel que soit l’IP de destination. Contrairement au blocage IP, cette approche reste efficace même lorsque les fournisseurs de tunneling font tourner leur infrastructure.

---

Partie 3 — eBPF : L’agent undercover dans l’OS

Les limites de la sécurité en espace utilisateur

JA4+ opère à la périphérie du réseau. Mais qu’en est-il des tunnels qui n’atteignent jamais un point de contrôle surveillé — trafic qui provient d’une machine à l’intérieur du réseau et en sort directement ? Et que faire lorsqu’un attaquant a déjà obtenu un accès au niveau processus et peut échapper à l’inspection réseau ?

C’est ici que eBPF (extended Berkeley Packet Filter) change la donne.

eBPF est une technologie intégrée dans le noyau Linux qui permet à des programmes sandboxés de s’exécuter en toute sécurité dans le noyau lui-même. Initialement conçue pour le filtrage de paquets de bas niveau, elle est devenue la couche fondamentale de la sécurité cloud-native moderne. Ses propriétés clés pour la sécurité sont : elle ne nécessite pas de modification ou recompilation du noyau, fonctionne avec un impact minimal sur la performance par rapport aux agents en espace utilisateur, et offre une visibilité profonde sur les syscalls, événements réseau, accès fichiers, et exécution de processus — tout en temps réel.

Tetragon et Falco : Les deux principaux outils

Deux outils de sécurité basés sur eBPF ont émergé comme standards dans les environnements d’entreprise et cloud-native :

Tetragon, un sous-projet du projet Cilium (maintenant partie de Cisco suite à son acquisition d’Isovalent), fournit une observabilité de sécurité basée sur eBPF combinée à une application en temps réel. Il traduit les politiques de sécurité en YAML en programmes eBPF qui s’exécutent directement dans le noyau, et est conscient de Kubernetes — il comprend les métadonnées de namespace et de pod, pas seulement les syscalls bruts. Tetragon peut détecter le moment précis où un processus tente d’ouvrir une socket réseau, faire le lien avec le namespace, l’arbre de processus, et l’historique d’accès fichiers, et terminer le processus avant que le premier octet de données ne quitte l’hôte. Son mécanisme d’application fonctionne via des hooks BPF LSM (Linux Security Module), qui sont synchrones — la décision du noyau se fait en ligne, pas après coup.

Falco, un projet open-source CNCF, est un moniteur d’activité comportementale qui audite le système au niveau du noyau Linux via eBPF. Là où Tetragon se concentre sur l’application, Falco se focalise sur la détection et l’alerte — signalant un comportement anormal selon une bibliothèque de règles, et transmettant les alertes à des plateformes SIEM, Slack, PagerDuty, ou via ses webhooks avec Falcosidekick. Falco fonctionne en tant que DaemonSet dans Kubernetes, assurant la surveillance de chaque nœud du cluster. Son pilote eBPF (modern_bpf) est le mode recommandé sur les distributions modernes.

Ces outils sont complémentaires. Comme le dit clairement ARMO (créateurs de Kubescape) : Falco pour la détection, Tetragon ou KubeArmor pour la détection plus l’application.

La stratégie kill-at-source

Lorsqu’on applique cela à la détection de Shadow Tunnel, eBPF permet ce que certaines équipes SOC appellent “kill at source”. Le workflow ressemble à ceci :

1. Un programme eBPF attaché aux points de trace syscall détecte qu’un processus tente d’ouvrir une interface TUN/TAP — le mécanisme au niveau du noyau sous-jacent à la plupart des tunnels VPN.
2. Tetragon corrèle cet événement : ce processus a-t-il récemment lancé un shell ? A-t-il des modèles d’accès fichiers inhabituels ? Son hash binaire correspond-il à un agent de tunneling connu ?
3. Si la politique est remplie, le processus est terminé au niveau du noyau — pas via un signal kill envoyé depuis l’espace utilisateur (qui peut être intercepté ou retardé), mais via le hook BPF LSM qui refuse l’appel syscall sous-jacent.

L’avantage clé par rapport aux agents en espace utilisateur est que cette approche ne peut pas être contournée par un processus ayant compromis l’agent de surveillance. La sécurité est intégrée dans la couche du système d’exploitation elle-même. Un développeur ne peut pas simplement désinstaller cela.

L’intégration de Tetragon par Cisco dans ses offres d’entreprise a accéléré l’adoption en production. La capacité de déployer des politiques eBPF dynamiques — et de les mettre à jour à la volée sans redémarrer ou redéployer les agents — a été démontrée lors de la réponse à la backdoor xz utils (CVE-2024-3094), où des programmes eBPF ont été utilisés pour appliquer des mitigations en quelques heures après divulgation.

---

Partie 4 — La menace de détournement de sous-domaine OAuth

Comment les tunnels expirés deviennent des vecteurs d’attaque

Peut-être le risque sous-estimé dans le paysage du Shadow tunneling est ce qui se passe après qu’un développeur ferme son tunnel.

Les services de tunneling sur des tiers gratuits ou à faible friction attribuent des sous-domaines éphémères : dev-app-123.ngrok-free.app, staging-preview.trycloudflare.com, et similaires. Quand le développeur ferme son ordinateur portable, le tunnel meurt — mais l’enregistrement DNS associé à ce sous-domaine peut toujours être actif dans des services externes.

Considérons un développeur qui a enregistré son URL de tunnel comme URI de redirection OAuth dans une App GitHub ou une configuration Webhook Stripe. Il termine son travail et ferme le tunnel. Le sous-domaine redevient disponible. Un acteur malveillant revendique ce sous-domaine via le fournisseur de tunneling en version gratuite, contrôlant ainsi le point de terminaison que GitHub ou Stripe considèrent comme légitime.

Détournement de redirection OAuth en pratique

Des recherches de sécurité récentes, publiées lors de USENIX Security 2025, ont identifié des vulnérabilités liées à grande échelle dans des plateformes d’intégration. Les chercheurs ont développé COVScan, un outil semi-automatisé de test, et ont trouvé que parmi 18 plateformes d’intégration grand public et professionnelles, 11 étaient vulnérables aux attaques Cross-app OAuth Account Takeover (COAT) — y compris celles de Microsoft, Google, et Amazon. Bien que ce ne soit pas exclusivement un problème de tunneling, la classe de vulnérabilités — URI de redirection OAuth expirés ou mal configurés — est directement facilitée par le modèle de sous-domaine éphémère sur lequel reposent les services de tunneling.

L’attaque spécifique sur ce type de tunnel est bien documentée en 2026 : un attaquant revendique un sous-domaine de tunnel expiré qui reste en liste blanche dans un fournisseur d’identité (IdP) comme Okta ou Azure AD, puis déclenche une requête d’autorisation. Si la victime a une session SSO active, l’IdP peut émettre un code d’autorisation vers le sous-domaine hijacké sans que l’utilisateur voie une invite de connexion — le paramètre prompt=none dans la requête d’autorisation permet cela. L’attaquant échange le code intercepté contre un jeton de session et obtient un accès complet à l’identité d’entreprise du développeur.

L’équipe de sécurité de CrowdStrike a également documenté le détournement de sous-domaine comme une surface d’attaque active, notant que ces sous-domaines hijackés sont utilisés pour le phishing, la distribution de malware, et l’interception de crédentials — tout cela sous l’apparence d’un domaine d’entreprise légitime.

---

Partie 5 — La stratégie de défense en profondeur 2026

Bloquer tous les outils de tunneling de manière totale devient de plus en plus impraticable dans des organisations fortement orientées développement. Les développeurs doivent exposer des webhooks pour les tests, partager des versions locales pour revue, et itérer sans attendre des jours pour des demandes de modification de pare-feu. La posture la plus productive est gouverner, pas simplement bloquer.

1. Tunneling basé sur l’identité à la périphérie

L’ère des tunnels anonymes est révolue pour les environnements d’entreprise sérieux. Le modèle sur lequel convergent les organisations axées sur la sécurité : exiger une authentification OIDC (OpenID Connect) au niveau du tunneling lui-même, avant que tout trafic n’atteigne la ressource interne.

Les offres d’entreprise ngrok et Cloudflare Access (qui s’intègre avec Cloudflare Tunnel) supportent ce modèle nativement. Par exemple, Cloudflare Access intercepte chaque requête vers un endpoint exposé par tunnel, émet un JWT basé sur l’identité SSO d’entreprise de l’utilisateur, et transmet ce JWT au backend. Le tunnel n’est plus un tuyau anonyme — c’est un point d’application de politique. Les utilisateurs doivent être authentifiés auprès du fournisseur d’identité d’entreprise avant qu’un seul paquet n’atteigne le service interne.

2. Sinkholing DNS et surveillance passive DNS

Tandis que le blocage IP échoue, la résolution DNS reste un point de contrôle critique. Bloquer la résolution pour *.ngrok.io, *.trycloudflare.com, *.ngrok-free.app, et les domaines de contrôle d’autres services de tunneling empêche les agents d’établir la connexion initiale — ils ne peuvent pas “appeler à la maison” pour configurer le tunnel si le DNS du plan de contrôle est sinkhole.

En complément, la surveillance Passive DNS (pDNS) permet aux équipes de sécurité de repérer des modèles inhabituels de sous-domaines et d’identifier quand une machine interne résout des domaines liés au tunneling, même avant qu’une connexion ne soit complètement établie.

3. Application de PKCE pour tous les flux OAuth

Pour contrer le détournement de sous-domaine OAuth, les équipes de sécurité doivent appliquer PKCE (Proof Key for Code Exchange) à tous les flux de code d’autorisation — y compris ceux côté serveur, où cela était auparavant optionnel.

PKCE fonctionne en faisant générer au client initiateur un secret cryptographique (code_verifier) et en envoyant un hachage de celui-ci (code_challenge) avec la requête d’autorisation initiale. Lors de l’échange du code d’autorisation contre un jeton, le code_verifier original doit être présenté. Un attaquant interceptant le code d’autorisation — en détournant un sous-domaine de tunnel — ne peut pas l’échanger contre un jeton sans le code_verifier, qui n’existe que dans la session légitime du navigateur.

Appliquer une correspondance exacte sur les URI de redirection (plutôt que des modèles ou wildcard) côté serveur d’autorisation ferme les chaînes de redirection ouvertes qui permettent aux attaquants d’exploiter les flux OAuth même sans détournement DNS.

4. Bibliothèques de signatures JA4 à la périphérie

Les équipes SOC doivent construire et maintenir des bibliothèques d’empreintes JA4 pour les agents de tunneling connus et les déployer en périphérie du réseau. Parce que l’empreinte JA4 identifie la bibliothèque TLS client, pas le nom du processus ou l’IP de destination, cette détection survit au renommage, rotation IP, et à l’obfuscation CDN. Un client cloudflared produisant l’empreinte t13d... lors de la poignée de main TLS produira cette empreinte quelle que soit la nom de l’exécutable ou le nœud Cloudflare auquel il se connecte.

5. Politiques d’exécution eBPF pour le comportement processus

Déployez Tetragon ou une couche d’application eBPF équivalente avec des politiques qui signalent ou bloquent :

• Processus ouvrant des interfaces TUN/TAP
• Binaires non présents dans l’inventaire logiciel approuvé tentant des connexions sortantes vers des plages de contrôle de tunneling
• Processus montrant la signature comportementale d’un agent de tunneling (par ex., maintenant une connexion TCP persistante tout en acceptant des connexions entrantes sur un port local)

Parce que l’application eBPF se fait au niveau du noyau, cela s’applique indépendamment du runtime de conteneur, du langage, ou du niveau de privilège. Un développeur exécutant un agent de tunneling dans un conteneur Docker sur sa station de travail d’entreprise est soumis à la même application qu’un autre l’exécutant directement sur le système hôte.

---

Conclusion : Zero Trust n’est pas un produit

La crise du Shadow Tunneling rappelle que Zero Trust n’est pas un produit que l’on achète et déploie — c’est une posture de sécurité qui doit être continuellement maintenue à mesure que le paysage des menaces évolue.

Le périmètre traditionnel a été remplacé par un réseau changeant de micro-tunnels cryptés connectant laptops, services cloud, webhooks, et agents IA. Les défenseurs qui restent ancrés dans des contrôles IP se retrouveront à courir perpétuellement après des ombres.

Le chemin à suivre passe par deux couches : comportement réseau (fingerprinting JA4+ qui identifie les clients par leur façon de parler TLS, pas par où ils se connectent) et application en temps réel (monitoring kernel eBPF qui observe et contrôle ce que les processus font réellement, pas ce qu’ils prétendent faire).

Aucune couche seule ne suffit. Ensemble, elles représentent la meilleure visibilité qu’en 2026 la sécurité peut avoir sur une menace autrement invisible. L’objectif n’est pas de construire un mur plus grand — mais de faire en sorte que chaque tunnel, autorisé ou shadow, soit authentifié, fingerprinté, surveillé, et tenu au même standard d’identité.