En décembre 2024, les chercheurs de Mandiant (Google Cloud) ont publié un rapport technique qui a fait l’effet d’un séisme discret dans la communauté de la cybersécurité. Intitulé « (QR) Coding My Way Out of Here: C2 in Browser Isolation Environments », ce travail démontre qu’il est possible d’établir un canal de commande et contrôle (C2) fonctionnel à travers certaines implémentations de Remote Browser Isolation, y compris, et c’est là que le bât blesse, celles dites transparentes.
Pour les équipes de sécurité qui ont déployé une solution de RBI en pensant avoir résolu le problème du trafic web malveillant, ce rapport mérite une lecture attentive. Et surtout, une réévaluation de l’architecture retenue.
Ce que Mandiant a découvert : le C2 par QR code
Le principe du Remote Browser Isolation repose sur une promesse simple : le navigateur distant exécute le code web (JavaScript, HTML, contenus actifs), et seul un flux de pixels chiffré est renvoyé vers le poste de l’utilisateur. Les requêtes HTTP ne sont pas décodables côté client, ce qui, en théorie, empêche un implant malveillant de récupérer des instructions depuis un serveur C2.
Mandiant a contourné cette protection par une approche aussi ingénieuse qu’inquiétante : plutôt que d’encoder les commandes C2 dans les en-têtes ou le corps d’une réponse HTTP, le serveur attaquant retourne une page web affichant un QR code. L’implant, installé sur le poste compromis, pilote un navigateur headless en mode automation (via le protocole Chrome DevTools), capture une screenshot de la page rendue par le système d’isolation, puis décode le QR code pour en extraire les instructions.
Le flux de pixels, censé être le garant de l’isolation, devient ici le vecteur de transmission des commandes. Ce qui est transmis « à la vue de tous » est pourtant parfaitement lisible par la machine.
Le débit est limité (~438 octets/seconde dans les tests de Mandiant), mais suffisant pour du C2 classique : exfiltration de données légères, exécution de commandes, staging d’implants additionnels. La technique a même été intégrée avec Cobalt Strike via son mécanisme d’External C2, validant son opérabilité en conditions réelles.
Point critique : cette technique est applicable dès lors qu’un navigateur Chrome est présent et accessible sur le poste de l’utilisateur : ce qui est précisément le cas de toutes les solutions de RBI dites transparentes.
Le point d’entrée de la vulnérabilité : qu’est-ce que le RBI transparent ?
Pour comprendre pourquoi certaines solutions sont plus exposées que d’autres, il faut revenir sur une distinction architecturale fondamentale, souvent sous-estimée au moment du choix d’une solution : RBI transparent vs. RBI non transparent.
Le RBI transparent a pour objectif de rendre l’isolation totalement invisible à l’utilisateur. Concrètement, cela signifie que la navigation isolée s’effectue au sein du navigateur Chrome déjà installé sur le poste — typiquement dans un nouvel onglet, via une extension, ou par une redirection proxy transparente. L’utilisateur continue d’utiliser son Chrome habituel, sans changer ses habitudes. C’est précisément l’argument commercial de nombreuses solutions du marché : zéro friction, zéro changement d’outil.
Mais cette transparence a un prix architectural lourd. Puisqu’une instance Chrome locale est en cours d’exécution sur le poste, le protocole Chrome DevTools est par définition disponible, le même protocole que Mandiant utilise dans sa démonstration pour piloter le navigateur, capturer le flux de pixels et décoder les QR codes contenant les commandes C2. Un implant capable d’énumérer les processus locaux peut détecter Chrome en mode automation (–enable-automation, –remote-debugging-port) et s’en servir comme canal de communication avec un serveur attaquant, même si le contenu web est techniquement « isolé » côté serveur.
En d’autres termes : le contenu est isolé, mais le canal de rendu reste exploitable. L’isolation du contenu ne suffit pas si le vecteur de communication lui-même est accessible depuis le poste compromis.
C’est précisément pour cette raison que Mandiant recommande, dans ses conclusions, de surveiller les processus Chrome utilisant des flags d’automation, une recommandation qui ne serait pas nécessaire si aucun Chrome local n’était impliqué.
Une question de philosophie de conception, pas de configuration
La réponse à cette classe de menaces ne tient pas à un patch ou à une règle de détection supplémentaire. Elle tient à un choix de conception posé bien en amont : le navigateur local doit-il exister sur le poste, ou non ?
Chez Reemo, ce choix a été tranché dès la conception : nous n’implémentons pas de RBI transparent. L’utilisateur n’interagit pas avec un Chrome local, il accède à une session de navigation qui s’exécute intégralement côté serveur, dans un environnement distant dédié et éphémère. Ce que reçoit le poste de l’utilisateur, c’est uniquement un flux de pixels chiffré, rendu dans une interface cliente légère qui ne dispose d’aucune capacité de navigation autonome.
Pas de Chrome local en mode automation, pas de DevTools Protocol exposé sur le poste, pas de processus de navigation pilotable par un implant. La surface d’attaque résiduelle côté client est réduite au strict minimum.
Cette architecture répond directement aux deux recommandations de Mandiant :
- Surveiller le trafic réseau anormal : sans session de navigation locale contrôlable, le vecteur C2 décrit n’a aucun point d’entrée sur le poste.
- Détecter les navigateurs en mode automation : aucun processus Chrome avec –remote-debugging-port ne s’exécute côté client, car aucun Chrome local n’est déployé.
La session distante est éphémère : à chaque fin de session, l’environnement est détruit. Aucune trace, aucun état persistant, aucun artefact exploitable.
Ce que cela signifie pour votre posture de sécurité
La publication de Mandiant doit être traitée comme une opportunité d’audit, pas seulement comme un bulletin d’information. Voici les questions à poser à votre fournisseur RBI actuel ou en priorité lors d’une évaluation :
1. Votre solution de RBI est-elle transparente ?
Si l’utilisateur navigue dans son Chrome habituel sans changer d’outil ni d’interface, il y a de fortes chances que vous soyez en présence d’un RBI transparent. Dans ce cas, le vecteur C2 par QR code décrit par Mandiant est techniquement applicable à votre environnement.
2. Un processus Chrome est-il en cours d’exécution sur le poste de l’utilisateur pendant la navigation isolée ?
Si oui, le protocole Chrome DevTools est potentiellement accessible. La présence de flags –enable-automation ou –remote-debugging-port dans les processus actifs confirme l’exposition.
3. L’environnement de navigation distant est-il véritablement séparé du poste client ?
La réponse doit être architecturale. « Le contenu web est exécuté à distance » n’est pas suffisant si le rendu final passe par un navigateur local pilotable.
4. Quelle est la surface d’attaque résiduelle sur le poste de l’utilisateur ?
Dans une implémentation RBI non transparente, elle doit être proche de zéro côté navigation : aucun exécutable de browser, aucun plugin, aucun processus d’automation.
Conclusion
La recherche de Mandiant ne condamne pas le Remote Browser Isolation en tant que technologie, elle en valide même la pertinence comme couche de défense contre les menaces web classiques. Ce qu’elle remet en cause, c’est l’hypothèse de sécurité implicite du RBI transparent : l’idée qu’une isolation peut être totale tout en restant invisible dans le navigateur local existant de l’utilisateur.
La transparence, ici, n’est pas une qualité de sécurité. C’est un compromis commercial, et comme tous les compromis, il a un coût que la recherche de Mandiant vient de chiffrer concrètement.
Pour les CISO et RSSI qui pilotent des environnements exposés (accès tiers, navigation à haut risque, OSINT, postes sensibles) la question n’est plus « avons-nous un RBI ? », mais « notre RBI laisse-t-il un navigateur local exposé sur le poste ? »
Sources :
- Mandiant / Google Cloud Threat Intelligence : « (QR) Coding My Way Out of Here: C2 in Browser Isolation Environments », décembre 2024
- Reemo Remote Browser Isolation
Laisser un commentaire