Des techniques permettant d’assurer à la fois la persistance et le déplacement latéral ont refait surface dans Microsoft Windows, en exploitant une faille de longue date de détournement de DLL dans l’outil d’accessibilité Narrateur.
Le problème, signalé pour la première fois en 2013, persiste dans Windows 10 et 11 et permet à des attaquants disposant de privilèges d’administrateur local d’exécuter du code arbitraire, de maintenir une persistance discrète et potentiellement de se déplacer latéralement sur les réseaux.
Les chercheurs de TrustedSec ont signalé que la technique d’exploitation « … nécessite un accès d’administrateur local au système que vous manipulez. »
De l’outil d’aide à la porte dérobée
Les outils d’accessibilité tels que Narrateur s’exécutent avec des privilèges élevés et peuvent être configurés pour se lancer avant l’ouverture de session de l’utilisateur, offrant aux attaquants un contexte d’exécution hautement privilégié si le mécanisme de chargement est détourné.
Cela est particulièrement préoccupant pour les organisations qui autorisent l’administration à distance ou l’accès RDP, car un attaquant capable d’écrire dans les chemins système ou de modifier des valeurs du registre peut transformer une technologie d’assistance inoffensive en implant persistant qui échappe aux défenses habituelles des terminaux.
Les récents tests de TrustedSec, qui s’appuient sur des travaux antérieurs de Hexacorn en 2013, ont confirmé que les versions modernes de Windows tentent toujours de charger une DLL spécifique du moteur de synthèse vocale depuis le répertoire système.
L’exécutable Narrateur recherche la DLL du moteur de synthèse vocale dans le chemin %windir%\system32\speech_onecore\engines\tts, et en remplaçant cette DLL par une DLL malveillante portant le nom attendu, un attaquant peut obtenir l’exécution de code au lancement de Narrateur.
Une persistance discrète grâce aux DLL d’accessibilité
La technique est un classique détournement de DLL, dans lequel une application de confiance charge une bibliothèque par son nom depuis un emplacement prévisible ; si ce nom est remplacé par une DLL malveillante, le système exécute alors le code de l’attaquant.
Dans ce cas, Narrateur exécute le code placé dans la routine d’initialisation de la DLL, ce qui signifie qu’aucune fonction exportée n’est nécessaire pour lancer la charge utile.
Les chercheurs ont ajouté de la discrétion en faisant suspendre par la DLL injectée le thread principal de Narrateur, empêchant toute sortie vocale ou indication à l’écran susceptible d’alerter l’utilisateur pendant que la charge utile s’exécute invisiblement.
La persistance peut être assurée via la configuration du registre.
La création d’une valeur REG_SZ nommée configuration sous HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Accessibility et sa définition sur Narrateur provoquent le lancement de l’outil d’accessibilité à l’ouverture de session de l’utilisateur, avec chargement de la DLL malveillante.
La même modification du registre sous HKEY_LOCAL_MACHINE établit à la place une persistance au niveau SYSTEM, en lançant Narrateur sur l’écran de connexion avec des privilèges élevés.
Avec un accès distant au registre, les attaquants peuvent également modifier les paramètres RDP — par exemple, désactiver les protections SecurityLayer — et déclencher Narrateur depuis l’écran de connexion à l’aide de la combinaison de touches Ctrl+Win+Enter, exécutant ainsi des charges utiles en tant que SYSTEM lors de la connexion RDP.
Les chercheurs ont également démontré une approche « Bring Your Own Accessibility » : créer dans le registre des outils d’accessibilité personnalisés pointant vers des binaires arbitraires, y compris des chemins UNC réseau, puis relier ces outils au même mécanisme de configuration pour les exécuter à l’ouverture de session ou au démarrage du système.
Renforcer Windows contre les détournements
Pour réduire le risque de détournement de DLL et de persistance via les outils d’accessibilité Windows, les organisations doivent renforcer les contrôles de sécurisation et de surveillance des systèmes.
- Appliquer le principe du moindre privilège: Limiter les comptes d’administrateur local et surveiller les accès en écriture inattendus aux répertoires système.
- Surveiller les modifications du registre : Signaler toute valeur nouvelle ou modifiée sous les clés de registre d’accessibilité Windows, dans HKCU comme dans HKLM.
- Restreindre l’accès en écriture aux chemins de chargement des DLL : Vérifier que %windir%\system32\speech_onecore\engines\tts et les répertoires associés ne sont accessibles en écriture qu’aux administrateurs.
- Appliquer une liste d’autorisation des applications : Bloquer les DLL et exécutables non autorisés à l’aide de solutions de liste d’autorisation.
- Renforcer l’administration à distance: Restreindre l’accès distant au registre et surveiller les modifications de la configuration RDP ainsi que les comportements inhabituels lors des connexions RDP.
- Détecter l’injection de processus et la suspension de threads : Ajouter une détection au niveau de l’hôte pour repérer les techniques qui suspendent les threads principaux des applications tandis que du code inconnu s’exécute.
La mise en œuvre de ces mesures contribue à limiter la capacité des attaquants à exploiter les fonctionnalités d’accessibilité pour assurer leur persistance ou élever leurs privilèges. En combinant des contrôles d’accès stricts, une surveillance continue et des listes d’autorisation, les organisations peuvent neutraliser les vecteurs courants de détournement de DLL et renforcer la sécurité globale des terminaux.
D’anciennes fonctionnalités, de nouveaux risques
Cette attention renouvelée portée à une ancienne technique souligne une vérité persistante de la cybersécurité : les fonctionnalités historiques et les fonctions pratiques survivent souvent aux hypothèses de sécurité qui les avaient initialement encadrées.
Les acteurs malveillants continuent de détourner des composants système de confiance — tels que les outils d’accessibilité, les tâches planifiées et les chemins de DLL courants — pour échapper à la détection et maintenir leur persistance.
Pour y remédier, les défenseurs doivent examiner les fonctionnalités historiques avec la même rigueur que le nouveau code, en imposant le principe du moindre privilège, une surveillance continue et des principes de conception sécurisée partant du principe que toute fonctionnalité pourrait un jour être détournée.
Cette évolution du paysage des menaces renforce la nécessité d’adopter des outils zero trust, qui reposent sur le principe qu’aucun utilisateur, appareil ou processus ne doit être considéré comme fiable par défaut sans vérification continue.