Détectez l'account takeover avant qu'il réussisse en instrumentant le navigateur et l'appareil durant la phase de préparation de l'attaque, pas après que le compte soit vidé. Les signaux qui comptent tôt sont différents de ceux que vous vérifiez après une brèche : signaux headless et stealth-browser, dérive de fingerprint contre l'historique d'un compte, comportement de proxy résidentiel et vélocité de login qu'aucune main humaine ne produit. Un signal prouve rarement l'intention à lui seul. Un motif de signaux le fait, et vous pouvez voir ce motif avant que l'attaquant ne monétise quoi que ce soit.
La plupart des programmes ATO sont post-hoc. Ils confirment la fraude après une réinitialisation de mot de passe, un changement d'adresse ou un paiement. La détection pré-ATO déplace la décision plus tôt : attrapez la vague de test d'identifiants, le premier login depuis un environnement falsifié, la session qui s'authentifie proprement mais porte des fingerprints d'automatisation. Les logs serveur montrent qu'un login a eu lieu. Les signaux navigateur expliquent si la chose qui se connecte est plausiblement votre utilisateur. cside capture ces signaux runtime (appareil, IP réelle, posture d'automatisation et comportement des scripts tiers) et les expose comme un risque de session sur lequel vous pouvez agir avant le checkout.
Ce que « avant que ça arrive » signifie vraiment
L'ATO a une phase de préparation. Les attaquants testent des listes d'identifiants volés, sondent votre endpoint de login et préparent l'automatisation avant qu'un seul compte ne tombe. Chacune de ces étapes laisse une preuve au niveau navigateur qu'une vue uniquement réseau ne capture jamais.
| Phase | Ce que fait l'attaquant | Signal pré-ATO à capturer |
|---|---|---|
| Reconnaissance | Sondage des endpoints de login et de récupération | Vélocité des requêtes, dispersion d'endpoints, signaux d'automatisation |
| Test d'identifiants | Passage de listes de stuffing dans des navigateurs réels ou stealth | Signaux headless, réutilisation de fingerprint entre comptes, rotation de proxy |
| Premier point d'appui | Un login propre depuis le mauvais environnement | Dérive de fingerprint, événement nouvel appareil, vélocité impossible |
| Pré-monétisation | L'attaquant reste sur la session avant d'agir | Rupture de continuité de session, mismatch comportemental |
L'objectif est d'agir sur les trois premières lignes, pas la quatrième.
Signaux d'automatisation navigateur qui se déclenchent avant le point d'appui
Une règle de détection générique rate cette couche. Le takeover automatisé passe de plus en plus par de vrais moteurs navigateur pilotés par des frameworks, pas des scripts bruts. Les signaux sont spécifiques et observables au runtime, et la plupart sont les mêmes signaux qui trahissent les agents IA et les navigateurs stealth.
navigator.webdriveràtrueest la valeur honnête par défaut d'un navigateur contrôlé. Les attaquants sérieux le patchent, donc son absence ne prouve rien, mais l'incohérence entre lui et d'autres surfaces est elle-même un signal.- Artefacts Chrome DevTools Protocol (CDP). Les frameworks qui pilotent Chrome via CDP peuvent laisser des effets de bord runtime détectables ; une session qui expose un comportement d'évaluation piloté par CDP tout en se prétendant un navigateur piloté à la main se contredit.
- Lacunes de propriétés headless. Le Chrome headless classique livre des APIs manquantes ou stubées, des tableaux de plugins à zéro et des états de permissions qui ne correspondent pas à une installation réelle. Les kits stealth couvrent les signaux connus, ce qui crée un nouveau signal : des surfaces trop propres et uniformes sur des milliers d'« utilisateurs » différents.
- Uniformité de fingerprint des kits stealth. Quand une liste de mots de passe fuitée est testée via un profil d'automatisation, des centaines de comptes sont touchés par des environnements navigateur improbablement identiques. La réutilisation entre comptes est le signal, pas un attribut unique.
La recherche cside a trouvé que les installations de playwright-stealth, l'un des nombreux kits stealth-browser utilisés pour habiller l'automatisation en navigateur humain, ont augmenté d'environ dix fois sur 2025 (selon le rapport Future of Web Security 2026 de cside). C'est le tooling qui se présente devant votre formulaire de login. Le détecter vous permet de bloquer une campagne de credential stuffing au lieu d'en lire le récit après l'arrivée des chargebacks.
Dérive de fingerprint sur les comptes réels
Une fois qu'un attaquant a un mot de passe fonctionnel, le premier login authentifié est votre prochaine fenêtre. Un utilisateur de retour porte un fingerprint d'appareil et de navigateur cohérent dans le temps. Un login de takeover casse généralement cette baseline.
La dérive n'est pas un seul champ qui change. Les gens mettent à jour leur navigateur et achètent des téléphones. La dérive devient un signal quand plusieurs surfaces stables bougent à la fois, sur un compte qui a été cohérent, d'une façon qui ne ressemble pas à une mise à jour normale.
- Construisez une baseline par compte à partir de sessions connues bonnes : appareil, famille d'OS, navigateur, surfaces de rendu, fuseau horaire, langue.
- Scorez le delta à chaque login, pas le fingerprint absolu.
- Pondérez plus fortement les surfaces qui changent rarement pour un vrai utilisateur que celles qui dérivent naturellement.
- Combinez la dérive avec le contexte réseau et de vélocité avant de challenger.
La mise en garde face au phishing adversary-in-the-middle est réelle : un kit qui rejoue les cookies d'une victime peut aussi refléter les surfaces de fingerprint, donc une correspondance propre ne prouve pas un utilisateur propre. Traitez la correspondance de fingerprint comme une entrée aux côtés de la réputation et du comportement, jamais comme une autorisation autonome.
Comportement réseau : proxy, VPN et vélocité
Les attaquants cachent leur origine derrière des pools de proxies résidentiels et des VPN commerciaux pour battre la réputation IP. La défense est comportementale, pas une blocklist statique.
- Rotation de proxy résidentiel. Un même compte ou une même campagne sort par de nombreuses IPs résidentielles dans un court intervalle, parfois une par requête. Les vrais utilisateurs ne rotent pas leur sortie comme ça. Le pattern de rotation est le signal, même quand chaque IP individuelle ressemble à une connexion domestique propre.
- Sortie VPN et datacenter. Un login arrivant d'un ASN d'hébergement, ou d'une plage VPN corrélée à un abus antérieur, élève le risque comme contexte, pas comme blocage dur, parce que les utilisateurs légitimes utilisent aussi des VPN.
- Vélocité de login. Des rafales de tentatives par compte, ou un environnement qui touche un nombre inhabituel de comptes, marquent un test d'identifiants avant qu'un login unique ne réussisse.
- Vélocité impossible. Le même compte s'authentifiant depuis des lieux trop éloignés pour le temps écoulé pointe vers des identifiants partagés ou volés en usage actif.
Capturer la vraie IP client au niveau navigateur compte ici. Une requête peut traverser un proxy qui réécrit ou omet les en-têtes forwarded, laissant les logs serveur avec une source trompeuse. La capture côté navigateur vous donne la sortie que la session a réellement utilisée.
Pourquoi c'est un travail de couche navigateur
La page de login elle-même est une surface d'attaque, et c'est souvent là que le takeover commence, avant même qu'un identifiant ne soit testé. Un script first-party ou tiers compromis sur votre page de login peut skimmer des identifiants pendant que l'utilisateur tape, ou superposer un formulaire falsifié, sans que rien n'arrive à votre serveur comme anomalie. C'est de l'e-skimming pointé vers l'authentification au lieu du paiement.
Donc la détection pré-ATO a deux moitiés. Surveillez l'environnement de l'attaquant pour des signaux d'automatisation et de dérive. Surveillez votre propre page pour des scripts altérés qui transforment le login légitime d'un utilisateur en fuite d'identifiants. Les deux vivent dans le navigateur au runtime, et les deux sont invisibles pour un WAF ou un log serveur. cside instrumente la page et la session ensemble : monitoring en temps réel des scripts tiers et du comportement, détection agents IA et headless, capture appareil et IP réelle, et visibilité des payloads runtime, livrés comme signaux sur une API que votre logique de fraude peut consommer. Pour le volet intégrité de page de ce tableau, voir client-side security.
Plan opérationnel
- Instrumentez les endpoints de login et de récupération avec des signaux de couche navigateur, pas seulement des logs d'auth serveur.
- Détectez la posture d'automatisation à chaque tentative : signaux headless, fuites CDP, uniformité de kits stealth.
- Scorez la dérive de fingerprint contre une baseline par compte au lieu de matcher des absolus.
- Ajoutez le comportement de proxy résidentiel, le contexte VPN/datacenter et la vélocité comme entrées de risque.
- Challengez ou montez en friction les sessions risquées avant tout changement de compte, paiement ou checkout.
- Réinjectez les résultats des challenges dans la baseline pour que le modèle s'affine dans le temps.
L'objectif est une décision confiante construite à partir de signaux faibles qui se cumulent, assez tôt pour challenger la session, pas juste documenter la perte.
