When Windows Helpers Turn Hostile: DLL Hijacks Return

Techniques for enabling both persistence and lateral movement have resurfaced in Microsoft Windows, exploiting a long-standing DLL hijacking flaw in the Narrator accessibility tool. 

The issue, first noted back in 2013, persists in Windows 10 and 11 and enables attackers with local administrative privileges to execute arbitrary code, maintain stealthy persistence, and potentially move laterally across networks.

TrustedSec researchers noted that the exploitation technique “… requires local administrator access to the system you are manipulating.”

From help tool to backdoor

Accessibility tools such as Narrator run with elevated privileges and can be configured to launch before user logon, giving attackers a high-privilege execution context if the loading behavior is abused. 

This is especially concerning for organizations that allow remote administration or RDP access because an attacker who can write to system paths or edit registry values may convert a benign assistive technology into a persistent implant that evades typical endpoint defenses.

TrustedSec’s recent testing, building on earlier work by Hexacorn in 2013, confirmed that modern Windows builds still attempt to load a specific speech engine DLL from the system directory. 

The Narrator executable looks for the speech engine DLL in the path %windir%\system32\speech_onecore\engines\tts, and by substituting a malicious DLL with the expected filename, an attacker can achieve code execution on Narrator launch.

Silent persistence via accessibility DLLs

The technique is a classic DLL hijack, where a trusted application loads a library by name from a predictable location, and if that name is replaced with a malicious DLL, the system will execute the attacker’s code. 

In this case, Narrator executes code placed inside the DLL’s initialization routine, meaning no exported functions are required for the payload to run. 

Researchers added stealth by having the injected DLL suspend Narrator’s main thread, preventing spoken output or on-screen cues that would otherwise alert a user while the payload runs invisibly.

Persistence can be achieved via registry configuration. 

Creating a REG_SZ value named configuration under HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Accessibility and setting it to Narrator causes the accessibility tool to launch at user logon, loading the malicious DLL. 

The same registry change under HKEY_LOCAL_MACHINE instead establishes SYSTEM-level persistence, launching Narrator at the login screen with elevated privileges. 

With remote registry access, attackers can also modify RDP settings (for example, disabling SecurityLayer protections) and trigger Narrator from the login screen using the Ctrl+Win+Enter key sequence, executing payloads as SYSTEM during RDP login.

Researchers also demonstrated a “Bring Your Own Accessibility” approach: creating custom accessibility tools in the registry that point to arbitrary binaries (including network UNC paths), then wiring those tools into the same configuration mechanism to run at logon or system boot.

Hardening Windows against hijacks

To reduce the risk of DLL hijacking and persistence through Windows accessibility tools, organizations should strengthen system hardening and monitoring controls.

• Enforce least privilege: Limit local administrator accounts and monitor for unexpected write access to system directories.
• Monitor registry changes: Alert on new or modified values under the Windows accessibility registry keys in both HKCU and HKLM.
• Restrict write access to DLL load paths: Ensure that %windir%\system32\speech_onecore\engines\tts and related directories are writable only by administrators.
• Apply application allowlisting: Block unauthorized DLLs and executables using allowlisting solutions.
• Harden remote administration: Restrict remote registry access and monitor RDP configuration changes and unusual RDP logon behavior.
• Detect process injection and thread suspension: Add host-level detection for techniques that suspend primary application threads while unknown code runs.

Implementing these measures helps limit attackers’ ability to exploit accessibility features for persistence or privilege escalation. By combining strict access controls, continuous monitoring, and allowlisting, organizations can close off common DLL hijacking vectors and strengthen overall endpoint security.

Old features, new risks

This renewed attention to an old technique underscores a persistent truth in cybersecurity: legacy features and convenience functions often outlive their original security assumptions.

Threat actors continue to repurpose trusted system components — such as accessibility tools, scheduled tasks, and common DLL paths — to evade detection and maintain persistence. 

To counter this, defenders must treat legacy functionality with the same scrutiny as new code, enforcing least privilege, continuous monitoring, and secure design principles that assume every feature could one day be abused.

This evolving threat landscape reinforces the need for zero-trust tools, which operate on the principle that no user, device, or process should be inherently trusted without continuous verification.