Cisco Talos a publié le 22 avril son rapport trimestriel Q1 2026 sur les réponses à incident. Deux constats, une seule histoire. L'hameçonnage a repris la première place des vecteurs d'accès initial au premier trimestre — plus d'un tiers des interventions — pour la première fois depuis le Q2 2025. Et enfoui dans ce chiffre de tête : le premier cas que Talos attribue à un constructeur IA en « vibe-coding ». Les attaquants ont utilisé Softr, une plateforme no-code, pour dresser un clone d'Outlook Web Access en fonctionnement sur un sous-domaine *.softr.app, récupérant les identifiants dans une feuille Google Sheets jetable. La page a été construite sans écrire une ligne de code. La réputation d'URL ne peut pas voir venir celui-là.

Le rapport trimestriel Q1 2026 de Talos est tombé le 22 avril, et le chiffre de tête est du genre que les défenseurs lisent comme un baromètre. L'hameçonnage est de retour comme vecteur d'accès initial le plus fréquemment observé — plus d'un tiers des interventions où le vecteur a pu être déterminé — pour la première fois depuis le Q2 2025. Les faiblesses MFA sont apparues dans trente-cinq pour cent des interventions, en hausse par rapport au Q4. L'administration publique et la santé sont à égalité comme secteurs les plus ciblés, avec vingt-quatre pour cent chacun. Rien de tout cela n'est particulièrement surprenant en soi.

La partie surprenante est une étude de cas au milieu du rapport. Talos documente ce qu'il qualifie, avec une confiance modérée, de première observation d'une application IA spécifique — Softr, un constructeur d'applications no-code en « vibe-coding » — utilisée pour héberger en direct une page de collecte d'identifiants. La page imitait Microsoft Exchange et Outlook Web Access. Elle capturait les identifiants soumis dans une feuille Google Sheets jetable. Elle envoyait un e-mail à l'opérateur à chaque nouvelle capture. Talos estime que le schéma remonte au moins à mai 2023 mais qu'il s'accélère depuis la fin 2025 et jusqu'au Q1. Le suivi parallèle de Trend Micro observe la même technique sur Lovable, Netlify et Vercel : de fausses pages CAPTCHA dressées sur des sous-domaines de constructeurs IA, avec le véritable formulaire d'identifiants chargé derrière le challenge.

La page, prise isolément, n'a rien de remarquable. C'est l'hébergement qui fait l'histoire.

À quoi ressemble réellement la chaîne.

Un constructeur no-code comme Softr est, par conception, à très courte distance entre un prompt et une application web en fonctionnement. Vous décrivez ce que vous voulez, il génère le HTML et le JavaScript, il déploie le résultat sur sa propre infrastructure, et il vous donne un sous-domaine gratuit. Ce sous-domaine est un frère de chaque autre sous-domaine client de Softr : quelquechose.softr.app. Softr s'occupe de l'hébergement, du certificat TLS, du CDN, de la disponibilité. Si vous êtes un attaquant qui veut faire tourner une page de collecte d'identifiants et que vous ne voulez pas enregistrer un domaine, acheter un certificat, louer un VPS, ni expliquer à qui que ce soit ce que vous hébergez, c'est une proposition de valeur extraordinaire.

La chaîne que Talos documente. Chaque élément sauf le premier est un SaaS réputé qui fait exactement ce que sa page produit annonce. Un système de réputation de domaine qui regarde cette chaîne voit du contenu de constructeur d'applications, du TLS émis par une autorité majeure, et une exfiltration vers de l'infrastructure Google. La seule surface réellement contrôlée par l'attaquant est le prompt de l'opérateur au début et la boîte de réception qui reçoit l'alerte à la fin.

Ce qui rend cette chaîne particulière intéressante, c'est que chaque maillon, à l'exception du prompt de l'attaquant et de sa propre boîte de réception, est un produit SaaS grand public qui fait exactement ce qu'il annonce faire. Softr construit la page. softr.app l'héberge sous un sous-domaine. Google Sheets stocke les identifiants récoltés. Gmail notifie l'opérateur. Un défenseur automatisé qui parcourt cette chaîne de haut en bas ne voit que des tiers réputés. La chaîne ne se cache pas. Elle porte un camouflage que la défense a été conçue pour classer comme bénin.

L'angle mort de la réputation d'URL.

La plupart des systèmes de réputation d'URL — ceux qui notent un lien comme « sûr », « suspect » ou « malveillant » avant même que votre navigateur ait terminé le handshake TLS — fonctionnent comme un bureau de crédit. Ils construisent un profil du domaine : son ancienneté, sa notoriété, le fait que son certificat TLS a un long historique ou soit un Let's Encrypt fraîchement émis, s'il a déjà été observé sur une liste de blocage, si sa maison mère est en bonne santé. Le profil produit un chiffre, le chiffre produit un verdict, le verdict produit une couleur.

Passez quelquechose.softr.app dans cette tuyauterie.

Une fiche de réputation d'URL pour un sous-domaine Softr fraîchement dressé. Chaque signal de niveau parent sur lequel s'appuie un système de réputation reçoit sa réponse du parent réputé, pas du sous-domaine qui fait réellement la collecte. Le formulaire de connexion dans le panneau inférieur est ce qu'un humain voit sur la même page — et ce qu'un score de réputation ne regarde jamais.

Chaque signal sur lequel s'appuie la couche de réputation est une propriété de softr.app, le domaine parent, et chaque réponse que le parent donne est la bonne. Il a six ans. Son certificat est valide. Il n'est sur aucune liste de blocage. Il sert du HTTPS. C'est une catégorie que le noteur a classée. Le sous-domaine ne change véritablement rien à tout cela. La page sur le sous-domaine pourrait être une carte d'anniversaire ou un formulaire de collecte d'identifiants — le noteur n'a aucun moyen de le savoir et, structurellement, dans la conception de la réputation d'URL, aucune raison de regarder.

L'observation de Talos est que les attaquants ont compris cela depuis un moment et qu'ils l'industrialisent maintenant : construire la page sur un SaaS réputé, récolter les identifiants dans un SaaS réputé, acheminer les alertes par un SaaS réputé. Ne rien donner au défenseur sur quoi refuser.

La bonne couche, c'est la page, pas l'URL.

La défense doit descendre dans la pile. Le seul signal qui reste fiable une fois que l'hébergement a été blanchi, c'est ce que la page elle-même prétend être et ce qu'elle est réellement. Un formulaire de connexion Outlook sur onboarding-portal-8xq.softr.app, c'est de l'hameçonnage. Un formulaire de connexion Outlook sur login.microsoftonline.com, non. Le même formulaire, une origine différente, un verdict différent. Un système capable de lire le formulaire et de le comparer à l'origine a quelque chose à dire sur cette page ; un système qui ne lit que l'URL, non.

C'est à cette couche que travaille déjà l'inspecteur anti-hameçonnage de Bromure. À l'intérieur de chaque onglet Bromure, un content script observe la page pendant qu'elle se charge, extrait les signaux qu'un humain utiliserait pour décider ce que la page prétend être — le texte visible, le titre, la source du logo, la forme des formulaires, les champs demandés — et transmet ce dossier par un canal vsock à un petit modèle qui émet un verdict en langage clair. « Cette page prétend être Microsoft Outlook mais elle est hébergée sur softr.app » : c'est le genre de phrase à laquelle un lecteur entraîné arrive en une fraction de seconde. Le modèle y arrive aussi, et la bannière que l'utilisateur voit le dit en une phrase, dans la couleur qui correspond au verdict.

Deux défenseurs regardant la même URL. Le score de réputation d'URL voit le parent et rien d'autre, et renvoie vert. L'inspecteur de contenu lit ce qu'est réellement la page et remarque la discordance — un formulaire de connexion aux couleurs de Microsoft sur un sous-domaine de constructeur d'applications — et renvoie rouge. La page sous-jacente est la même dans les deux cas.

L'inspecteur de contenu n'est pas magique et ce n'est pas une preuve. C'est un second avis entraîné qui répond à une question à laquelle la réputation d'URL est structurellement incapable de répondre : que prétend être cette page ? Cette question a un tranchant plus net sur un softr.app, un vercel.app ou un lovable.app que presque partout ailleurs sur le web, parce que sur ces sous-domaines, le contenu de la page est à peu près le seul signal qui survit. Tout le reste a été blanchi par le parent.

Ce que Bromure n'empêche toujours pas.

L'inspecteur de contenu, la bannière qu'il affiche et le blocage qu'il peut imposer constituent la première ligne. La première ligne ne tient pas toujours. Un utilisateur qui a été préparé par un e-mail convaincant, qui est en pleine journée de travail, qui a l'habitude de cliquer sur des écrans de connexion Outlook par automatisme, peut cliquer au-delà d'une bannière d'avertissement. Un utilisateur peut aussi atterrir sur une page que l'inspecteur n'a pas encore évaluée, ou qu'il évalue comme suspecte plutôt qu'ouvertement de l'hameçonnage, et décider que suspect est suffisamment proche de probablement correct.

Quand cela arrive, l'utilisateur tape un mot de passe dans un formulaire, et le formulaire le capture. Aucune architecture de navigateur au monde ne désactive la saisie au clavier. C'est la réserve la plus simple et la plus importante de ce billet. Bromure n'empêche pas un utilisateur de saisir un vrai mot de passe dans le formulaire d'un attaquant. Ce qu'il peut façonner, c'est ce qui se passe après, et ce qui se passe après dépend de là où vit le reste du travail de l'utilisateur.

Ce que la posture « habitude navigateur » change — et ce qu'elle ne change pas.

Voici, honnêtement, certaines choses que l'architecture Bromure change si un hameçonnage d'identifiants passe au-delà de la bannière :

Pas de remplissage automatique par le gestionnaire de mots de passe sur la mauvaise origine. Les gestionnaires de mots de passe associent les identifiants enregistrés à l'origine, et l'origine ici est softr.app, que le coffre-fort de l'utilisateur n'a jamais vue. L'auto-remplissage ne se déclenchera pas. L'utilisateur devra taper. C'est une défense réelle, bon marché, ennuyeuse — et elle fonctionne aussi bien dans Chrome que dans Bromure ; elle ne vaut d'être nommée que parce que c'est une défense qui ne repose pas sur le jugement, et c'est justement le jugement que l'hameçonnage met en défaut.
Pas de profil persistant dans l'onglet de l'hameçonnage. L'onglet qui a contenu l'hameçonnage est une VM Linux éphémère. Quand il se ferme, rien de ce qui y a été chargé — cookies, stockage, caches, empreintes — ne persiste. Cela ne fait pas revenir les identifiants que l'utilisateur a tapés. Mais cela signifie que la page ne peut pas discrètement planter un marqueur dans un profil de longue durée pour suivre l'utilisateur entre les sessions.
Une page qui tend la main vers l'hôte ne le trouve pas. L'étude de cas Talos est une simple capture d'identifiants. Le schéma plus large que Trend Micro suit à travers Lovable et Vercel inclut des pages qui préparent aussi une étape suivante — un collage ClickFix, un « exécutez cet installeur », un faux CAPTCHA qui débouche sur un prompt d'application native. Si la page d'hameçonnage tente de passer la main au système d'exploitation hôte, la VM d'onglet coupe ce passage à la frontière de l'hyperviseur. Pour la même raison architecturale que dans tous les autres billets de ce blog.

Et voici quelques choses que Bromure ne change pas :

La réutilisation d'identifiants depuis l'infrastructure de l'attaquant. Une fois que l'attaquant a un nom d'utilisateur et un mot de passe, il peut se connecter au vrai Outlook depuis sa propre infrastructure. Rien sur la machine de la victime, Bromure y compris, ne participe à cette session. Le MFA aide. Le MFA résistant à l'hameçonnage — clés matérielles, passkeys — aide davantage. Une politique au niveau du tenant qui interdit l'authentification héritée aide le plus. Ce sont les correctifs pour cette jambe de l'attaque, et ce blog ne va pas faire semblant qu'une architecture de navigateur se substitue à eux.
Les kits adversary-in-the-middle qui relaient des sessions vives. Le cas Softr que Talos documente est une page de capture d'identifiants statique, pas un proxy inverse AiTM. La classe de kits plus sophistiquée — Tycoon, Evilproxy, et leur lignée — capture, elle, un cookie de session vivant en relayant le challenge MFA de la victime à travers l'hameçonnage vers le vrai fournisseur. Ce cookie de session vit dans l'infrastructure de l'attaquant dès l'instant où il est capturé. La jetabilité côté navigateur aide à l'hygiène de session pour la suite ; elle n'invalide pas rétroactivement un cookie qui a déjà quitté les lieux. La liaison de cookie côté serveur — DBSC et ses pairs — est le correctif qui le fait.

Ce que l'inspecteur attrape

Un formulaire de connexion aux couleurs de Microsoft sur *.softr.app, *.vercel.app ou *.lovable.app est un motif que l'inspecteur de contenu est précisément conçu pour signaler. Le signal n'est pas l'URL. C'est la discordance entre la marque revendiquée et l'hôte.

Ce que la VM d'onglet attrape

Toute tentative de passage de la main depuis l'hameçonnage vers le système d'exploitation hôte — un collage dans Terminal ou Spotlight, un prompt d'installeur, un gestionnaire de protocole — échoue parce que l'onglet ne partage pas d'OS avec le bureau. L'hameçonnage reste dans la VM.

Ce que le jugement doit encore attraper

Si la bannière est ratée ou écartée, un mot de passe tapé s'échappe par le formulaire. L'inspecteur de contenu est une seconde paire d'yeux, pas une troisième main sur le clavier. Sur ce chemin précis, le MFA résistant à l'hameçonnage est le filet de sécurité, et Bromure ne le remplace pas.

Ce que le côté serveur doit attraper

La réutilisation d'identifiants depuis l'infrastructure de l'attaquant, le détournement de session vivante par AiTM et les jetons de longue durée se décident dans l'environnement du fournisseur d'identité, pas dans le navigateur. La liaison de cookie, l'accès conditionnel et les clés adossées au matériel sont les instruments qui s'appliquent là.

Pourquoi c'est un point de bascule et pas une mode.

Le cadrage « première attribution » de Talos est prudent, et l'évaluation à confiance modérée selon laquelle le schéma remonte à mai 2023 suggère qu'il s'accélérait tranquillement depuis près de deux ans avant que quelqu'un ne lui colle une étiquette. C'est ainsi qu'arrivent les meilleures techniques d'attaque — pas comme une annonce mais comme une courbe que l'on remarque sur un graphique que quelqu'un a enfin tracé. L'analyse de Trend Micro en septembre 2025 sur l'hameçonnage hébergé par des constructeurs IA dessinait la même courbe depuis l'autre direction. Le point de croisement est ici. Tout défenseur qui suppose que ses utilisateurs ne cliqueront jamais sur un lien vers *.softr.app, *.vercel.app, *.lovable.app ou *.netlify.app suppose un monde qui a pris fin au trimestre précédent.

La structure de coûts en est la raison. Il y a une décennie, monter une page d'hameçonnage crédible exigeait de la compétence ou de l'argent : un domaine, un certificat, un serveur, une page qui ne trahissait pas immédiatement son origine. Aujourd'hui, un constructeur no-code s'occupe des quatre en échange d'une inscription gratuite. Le coût marginal d'un site d'usurpation supplémentaire se mesure en minutes de prompting. Le coût marginal d'un takedown — parce que chaque page vit sur un sous-domaine d'un fournisseur réputé, pas sur son propre domaine — est plus élevé qu'auparavant. Ces deux courbes pointent dans le mauvais sens pour la défense, et la réponse dominante consistant à « former les utilisateurs à repérer les mauvaises URL » est à ce stade un centre de coûts, pas un contrôle.

La position honnête pour un navigateur qui prétend protéger les utilisateurs, c'est qu'il doit faire un travail que les systèmes de réputation d'URL ne peuvent pas faire. Il doit réellement lire la page. Il doit décider, pour chaque formulaire ressemblant à une connexion sur un domaine ne ressemblant pas à une connexion, si le formulaire correspond au domaine ou s'il ment à son sujet. Il doit le dire dans une phrase qu'un humain peut lire, et il doit avoir raison assez souvent pour que la phrase mérite d'être lue.

Une histoire, et ce qu'elle prédit.

Talos a écrit sur une seule page. La page a été construite sur un SaaS, a récolté les identifiants dans un autre, a alerté l'opérateur via un troisième. Chaque maillon de cette chaîne est, pour un noteur de réputation, un bon voisin. L'histoire que raconte Talos cessera d'être l'exception avant la fin de cette année. L'hameçonnage « vibe-codé » n'est pas l'étiquette d'une curiosité ; c'est le nom de la manière par défaut dont les attaquants d'identifiants construiront désormais leurs pages d'attaque, parce que c'est la plus bon marché et la plus indulgente.

Si la seule réponse de votre navigateur à l'hameçonnage est un score de réputation d'URL, votre navigateur n'a pas de réponse à cela. Le score de réputation sera vert. La page sera rouge. Installez Bromure — et placez la seconde paire d'yeux sur la page, là où la discordance vit réellement.