Les incidents liés aux Infostealers restent sous-estimés. Ces malwares ciblent directement les coffres de mots de passe intégrés aux navigateurs. Ils opèrent dans la session utilisateur et contournent fréquemment la détection des EDR. L’enjeu est simple, en cas de fuite, vous devrez déclarer l'incident à l'ANSSI (NIS2).

La configuration "par défaut" de votre navigateur

Les navigateurs proposent par défaut la configuration optimale pour les utilisateurs : mémoriser les mots de passe de l'utilisateur. C'est très pratique, cela réduit la "password fatigue", et semble plus sécurisé que de les stocker dans un fichier plat...

Mais cette option, bien utile pour palier à l'absence de SSO (Single Sign-On) en entreprise et, à la limite naturelle de notre cerveau à retenir des centaines de mots de passe, est-elle bien sécurisée ?

Quelles sont les conséquences si la synchronisation de profil avec un compte personnel (Chrome/GMail, Edge/Microsoft) est autorisée ?

Nous avons le sentiment d'être protégés au sein de notre navigateur, sur notre ordinateur professionnel, muni d'un EDR (Endpoint Detection and Response). Mais les infostealers sont là pour mettre à l'épreuve ce faux sentiment de sécurité.

Qu'est ce que l'Infostealer ?

Un infostealer arrive par des vecteurs classiques : pièce jointe piégée, faux installeurs, publicité malveillante (malvertising), site compromis ou loader déjà présent.

Le binaire est souvent obfusqué, compressé, voire chiffré, pour échapper aux signatures. Une fois exécuté, il fonctionne dans le contexte de l’utilisateur, hérite de ses accès, et cible prioritairement ce que l’utilisateur voit et utilise.

L’infostealer n’a pas besoin d’élévation de privilèges pour lire ce que le navigateur ou l’application déchiffre pour l’utilisateur. Il accède au profil local et aux données puis extrait en clair les identifiants enregistrés. Il cible des réservoirs de secrets existants pour être efficient.

Infostealer : pourquoi est-ce si efficace

Localement sur un poste : Un infostealer s’exécute dans la session de l’utilisateur, sans privilèges élevés. Il lit les bases, profils et tokens du navigateur, puis extrait les identifiants enregistrés. L’outil d’EDR n’est pas infaillible : un exécutable furtif, une fenêtre de détection trop tardive, ou un binaire récemment muté suffisent à passer inaperçu et exfiltrer les informations avant la détection.

Si les profils sont synchronisés : Lorsque la sauvegarde de mots de passe est autorisée et que la synchronisation avec un compte personnel (GMail) n’est pas bloquée, les conséquences sont bien plus grandes. Les identifiants voyagent entre le poste géré par l’entreprise et des appareils personnels, non maîtrisés...

La synchronisation permet d'accéder à tous les mots de passe quel que soit le navigateur infecté (professionnel ou personnel). Sans MFA (Multi-Factor Authentication), la prise de contrôle est immédiate. Les accès sont revendables à des IAB (Initial Access Brokers), qui monétisent ces accès initiaux à des environnements d’entreprise. Avec MFA, le risque résiduel demeure : tokens persistants, sessions déjà ouvertes, mais il est considérablement réduit.

Conclusion opérationnelle : tant que les navigateurs stockent et synchronisent des mots de passe, l’attaquant bénéficie d’un périmètre d’exfiltration élargi, souvent en dehors du champ de contrôle de l’EDR.

Comment résoudre les problèmes liés à l'infostealer ?

Il ne sera pas possible d'empêcher l'infostealer d'agir, mais on peut réduire drastiquement sa surface d'attaque.

Les actions suivantes doivent être imposées par GPO (Group Policy Object), MDM (Mobile Device Management), ou équivalents : Intune, Jamf, ou plateformes multi-OS.

Navigateurs (Chrome / Edge / Firefox)

• Désactiver l’offre d’enregistrement et l’auto-remplissage des mots de passe. Exemples indicatifs à adapter : PasswordManagerEnabled=false, AutoFillPasswordsDisabled=true, OfferToSaveLogins=false.
• Bloquer la connexion navigateur non-entreprise et désactiver la synchronisation hors domaine. Exemples : BrowserSignin=Disabled, SyncDisabled=true, restriction des domaines autorisés à *.entreprise.fr.
• Imposer des profils gérés et restreindre les extensions. Exemples : blocklist d’extensions non approuvées, allowlist des coffres dédiés, interdiction d’extensions “password export”.
• Séparer les contextes pro/perso via profils, et interdire les profils non gérés sur les postes d'entreprise

Postes de travail et MDM

• Appliquer les politiques de navigateur via GPO / Intune / Jamf avec dérive tolérée = 0
• Inventorier les extensions et bloquer l’installation latérale
• Empêcher l’usage des gestionnaires intégrés du navigateur et imposer un coffre-fort dédié
• Mettre à jour rapidement navigateurs et moteurs, et refuser les versions obsolètes
• Sur les mobiles, enveloppes gérées pour les navigateurs d’entreprise et séparation stricte des données

Identité et authentification

• SSO via un IdP (Identity Provider) d’entreprise, avec MFA systématique pour les applications et services sensibles
• Déployer les passkeys FIDO2 / WebAuthn pour réduire la dépendance aux mots de passe

Conclusion

Les infostealers exploitent les angles morts, notamment les coffres des navigateurs.

La réponse efficace combine politiques centralisées, coffre dédié, MFA généralisé, et passkeys. Sous NIS2, l’important n’est pas seulement de “bien faire”, mais de prouver que vous appliquez, contrôlez et corrigez.

Le changement de politique ne se fera pas heurts, les habitudes des utilisateurs sont difficiles à faire évoluer mais si rien n'est fait, les effets de la synchronisation des comptes pro / perso pourraient rapidement s'avérer dévastateurs.

Article rédigé par Gilles Favier - VP Product - Board of Cyber