Phishing browser-in-the-browser : guide de détection

Les popups de SSO apprennent aux utilisateurs à faire confiance à une petite fenêtre montrant leur fournisseur d’identité. Le phishing browser-in-the-browser (BITB) reproduit cette fenêtre dans une page contrôlée par l’attaquant, jusqu’à une fausse barre d’adresse qui semble afficher le domaine légitime.

La technique convainc parce que la page extérieure contrôle chaque pixel. La défense doit réunir indices d’interface, authentification résistante au phishing et détection d’infrastructure.

Comment fonctionne le phishing BITB

La démonstration originale du BITB montre comment HTML, CSS et JavaScript imitent une popup OAuth ou SSO :

1. la victime visite un leurre ou une page compromise ;
2. la page propose une connexion avec un fournisseur connu ;
3. une fausse popup apparaît dans l’onglet ;
4. la barre affiche une origine légitime ;
5. identifiants et codes vont à l’attaquant ;
6. la victime peut être redirigée vers le vrai service.

Cette popup n’est pas une frontière de sécurité du navigateur. Ce sont de simples éléments de page.

Les indices visibles

Une fenêtre simulée ne se comporte pas exactement comme une fenêtre native. Les utilisateurs peuvent :

• la glisser en dehors de la zone de contenu du navigateur ;
• vérifier son apparition dans le sélecteur de fenêtres du système ;
• utiliser un gestionnaire de mots de passe qui ne remplit que la bonne origine ;
• ouvrir directement le service plutôt que se connecter depuis un lien reçu ;
• signaler tout flux demandant des données de récupération ou des MFA répétées.

Ces vérifications aident, mais la sécurité ne doit pas dépendre d’une vigilance parfaite.

Les opportunités de détection technique

Intelligence sur le leurre

BITB nécessite une page d’entrée. Analysez URL complète, redirections, âge, hébergement, certificats et relations. Utilisez le scanner d’URL et la réputation de domaine avant toute interaction.

Messagerie et collaboration

Détectez les messages menant à un domaine récent ou rare, particulièrement autour de documents partagés, paiements et services cloud.

Corrélation endpoint et identité

Reliez la visite du leurre à une connexion réussie depuis un nouvel appareil, une IP inhabituelle, un voyage impossible, un changement de MFA ou l’usage d’un jeton. L’identité confirme souvent ce que la page ne suffit pas à prouver.

Comportement de la page

Dans une sandbox, recherchez chrome de fenêtre simulé, formulaire dans un overlay et scripts de déplacement. Les attaquants changent les détails ; le comportement est plus durable qu’un sélecteur.

Les contrôles qui changent l’issue

FIDO2 et WebAuthn lient l’authentification à l’origine réelle. Une popup dessinée sur attacker.example ne peut pas demander un credential du fournisseur légitime. Passkeys et clés matérielles retirent donc une grande partie de la valeur du vol.

Pendant la migration, appliquez number matching, accès conditionnel, réauthentification fondée sur le risque et sessions courtes. Le push simple et les OTP restent phishables.

Réponse à incident

Si des identifiants ont été saisis, réinitialisez, révoquez sessions et jetons, vérifiez les méthodes MFA, les grants OAuth et les modifications du compte. Bloquez leurre et destinations confirmées.

Recherchez le même kit chez d’autres employés et regroupez la campagne par assets, domaines, certificats et IP. Un signalement peut être le premier élément d’un ensemble.

Métriques

Suivez leurres signalés, identifiants soumis, délai de révocation, couverture de la MFA résistante et domaines associés par campagne. Mesurez adoption des gestionnaires et de WebAuthn, pas seulement la formation.

Conclusion

BITB attaque la confiance dans le chrome visuel. Réduisez-la avec authentification liée à l’origine, navigation directe et gestionnaire de mots de passe. Détectez l’infrastructure de phishing par URL, domaine, identité et endpoint afin qu’une fenêtre convaincante ne devienne pas une preuve.