Introduction
Evill-SSP est un projet de recherche que j’ai développé pour explorer une technique d’attaque souvent sous-estimée : le détournement des Security Support Providers (SSP) Windows pour intercepter des identifiants système. Les SSP tournent dans LSASS avec les privilèges SYSTEM et reçoivent les credentials en clair à chaque authentification. Ça en fait une cible de choix en post-exploitation.
Ce projet est strictement à but éducatif. L’implémentation complète n’est pas détaillée ici, et toute utilisation sur un système sans autorisation est illégale.
Les Security Support Providers
Les SSP sont des DLL qui implémentent l’interface SSPI (Security Support Provider Interface), permettant aux applications Windows de s’authentifier de façon standardisée. Ils s’exécutent dans le processus LSASS (Local Security Authority Subsystem Service) et chacun gère un protocole d’authentification spécifique.
Windows embarque nativement : Kerberos pour les environnements AD, NTLM pour l’authentification par défi-réponse, Negotiate qui sélectionne automatiquement entre les deux, Schannel pour SSL/TLS, et CredSSP pour la délégation de credentials.
Les SSP sont enregistrés via deux clés de registre sous HKLM\SYSTEM\CurrentControlSet\Control\Lsa. LSASS les charge au démarrage, ou dynamiquement via l’API AddSecurityPackage sans redémarrage nécessaire. C’est ce mécanisme qui constitue le vecteur : modifier la clé de registre + déposer une DLL dans System32 suffit pour que LSASS charge le composant au prochain boot.
Les SSP comme vecteur d’attaque
Contexte
La technique a été popularisée par Mimikatz et son composant mimilib, développé par Benjamin Delpy à partir de 2011 mimikatz. Le principe : un SSP reçoit les credentials en clair via SSPI, donc une DLL SSP malveillante peut les intercepter avant tout chiffrement. Le SSP doit recevoir les credentials en clair pour fonctionner.
Une DLL chargée dans LSASS donne accès aux mots de passe en clair, hachages NTLM et tickets Kerberos de tous les utilisateurs qui s’authentifient sur la machine. Avec une exécution en contexte SYSTEM, ainsi qu’une persistance du à un chargement automatique à chaque démarrage.
Dans le framework MITRE ATT&CK, c’est référencé sous T1547.005 - Boot or Logon Autostart Execution: Security Support Provider, classifié en persistance.
Ce qu’il faut implémenter
Pour qu’une DLL soit acceptée par LSASS comme SSP valide, elle doit exposer plusieurs fonctions de l’interface SSPI. Trois sont particulièrement importantes.
SpLsaModeInitialize() est appelée au chargement dans LSASS, c’est là que le SSP s’enregistre et déclare ses capacités.
SpAcceptCredentials() est le cœur du dispositif. LSASS l’appelle à chaque authentification réussie et lui passe le type d’auth, le nom d’utilisateur, le domaine, et les credentials, mot de passe en clair ou hachage selon le protocole. C’est ici que se joue l’interception.
SpShutdown() est appelée à l’arrêt de LSASS, utile pour flush les dernières données ou nettoyer.
Exfiltration
Evill-SSP exfiltre les credentials via HTTP ou HTTPS vers un serveur distant. L’avantage opérationnel : le trafic HTTP/HTTPS est rarement bloqué en sortie dans les réseaux d’entreprise. HTTPS complique en plus l’inspection sans broker SSL.
Contraintes réelles
Le principal prérequis reste les droits administrateur ou SYSTEM pour modifier les clés LSA et écrire dans System32, ce qui confine la technique à la post-exploitation. Sur un système durci, les obstacles s’accumulent : Driver Signature Enforcement, ELAM, LSA Protection (RunAsPPL) et Credential Guard peuvent tous bloquer le déploiement. C’est d’ailleurs là que sa devient intéressant.
Détection et défense
Détecter
Registre : toute modification de HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages ou OSConfig\Security Packages doit déclencher une alerte. La liste des SSP légitimes est stable, tout ajout est anormal.
Processus : monitorer les DLL chargées dans LSASS, notamment les DLL non signées ou hors des chemins attendus. L’API EnumerateSecurityPackages permet de lister les providers enregistrés et de détecter les intrus par comparaison avec une baseline connue.
Réseau : LSASS n’initie normalement aucune connexion réseau sortante. Un trafic HTTP/HTTPS émis par lsass.exe est un IOC fort.
Corrélation : modification de la clé LSA + écriture d’une DLL dans System32 + connexion réseau inhabituelle, ce triptyque d’événements est le pattern à surveiller, idéalement avant même la première interception de credentials.
IOC
- Clé
Security Packagesmodifiée récemment, présence de DLL inconnues dans la liste - DLL dans System32 sans signature valide ou avec timestamps incohérents
- Connexions HTTP/HTTPS depuis
lsass.exevers des IPs externes
LSA Protection
Activer RunAsPPL configure LSASS comme processus protégé (PPL), ce qui bloque le chargement de DLL non signées Microsoft. Contourner cette protection nécessite généralement un driver signé vulnérable, ce qui élève significativement le coût de l’attaque.
Credential Guard
Credential Guard isole les secrets d’authentification dans un processus séparé (LsaIso.exe) via VBS (Virtualization-Based Security). Les hachages NTLM, tickets Kerberos TGT et credentials de domaine sont stockés dans cet environnement isolé, inaccessible au reste du système y compris aux SSP malveillants.
Ses limites : Credential Guard ne tourne pas sur les contrôleurs de domaine, et ne protège pas les credentials saisis interactivement pour une authentification NTLM, dans ce cas ils transitent en mémoire LSASS avant isolation. Depuis Windows Server 2025, il est activé par défaut sur les machines répondant aux exigences matérielles.
Durcissement complémentaire
AppLocker ou WDAC permettent de restreindre les DLL autorisées à s’exécuter. MFA et segmentation zero-trust limitent l’impact des credentials collectés même en cas de compromission réussie.
Conclusion
Ce projet m’a permis de mieux comprendre les couches internes de l’authentification Windows et les points de friction qu’un attaquant rencontre sur un système moderne. La technique SSP est redoutable mais exige des privilèges élevés et devient de plus en plus difficile à déployer à mesure que RunAsPPL et Credential Guard se généralisent. Ce qui reste vrai : LSASS mérite un monitoring dédié et une protection maximale, RunAsPPL + Credential Guard + EDR + monitoring registre est la seule approche réellement robuste.