Shell Extension DLL Hijacking: How Attackers Exploit Windows Explorer and How to Defend Against It

Updated February 2026 — Covers Latest Windows 11 Security Updates

Windows Shell Extensions are one of the most powerful attack surfaces in the Windows operating system. Because they are loaded directly into explorer.exe — a process that runs with the current user’s full privileges and persists for the entire session — they represent an extremely attractive target for malware authors seeking persistence, privilege escalation, and stealth.

This guide explains how DLL hijacking attacks targeting shell extensions work, documents real-world examples, and provides concrete detection and prevention strategies that both system administrators and advanced users can implement immediately.

What Is DLL Hijacking?

DLL hijacking is a class of attacks where a malicious DLL is placed in a location where Windows will load it instead of — or in addition to — the legitimate DLL. The attack exploits Windows’ DLL search order, which checks multiple directories before finding the correct file.

The Standard Windows DLL Search Order

When a program (like explorer.exe) needs to load a DLL, Windows searches these locations in order:

1. The directory from which the application loaded
2. The system directory (C:\Windows\System32)
3. The 16-bit system directory (C:\Windows\System)
4. The Windows directory (C:\Windows)
5. The current working directory
6. Directories listed in the PATH environment variable

If an attacker places a malicious DLL with the expected filename in a higher-priority directory (or in the current working directory), Windows loads the malicious version instead of the legitimate one.

Why Shell Extensions Are Prime Targets

Shell extensions are uniquely vulnerable because:

• They load into explorer.exe, which runs throughout the entire user session
• They execute code on common user actions (right-clicking, opening folders, viewing properties)
• They are loaded via COM registration in the registry, making them easy to hijack
• Multiple third-party DLLs coexist in the same process space, providing cover for malicious code
• Users rarely audit their shell extensions, so malicious ones can persist for months or years

Real-World Attack Scenarios

Scenario 1: Phantom Context Menu Handler

An attacker creates a registry entry for a non-existent application’s context menu handler, pointing to a malicious DLL:

[HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\SystemHelper]
@="{ATTACKER-CLSID-GUID}"

[HKEY_CLASSES_ROOT\CLSID\{ATTACKER-CLSID-GUID}\InprocServer32]
@="C:\ProgramData\SystemUpdate\helper.dll"
"ThreadingModel"="Apartment"

Every time the user right-clicks any file, explorer.exe loads helper.dll, which can:

• Capture keystrokes
• Take screenshots
• Exfiltrate files on right-click
• Download additional payloads

Scenario 2: DLL Search Order Hijacking of Existing Extension

A legitimate application (e.g., WinRAR) registers a shell extension DLL at:

C:\Program Files\WinRAR\rarext.dll

If the attacker discovers that WinRAR’s DLL lookup does not use a fully qualified path, they can place a malicious rarext.dll in a higher-priority search location (such as the user’s profile directory or a temp folder in PATH).

Scenario 3: COM Object Hijacking via Per-User Registry

COM objects registered under HKEY_CURRENT_USER\Software\Classes\CLSID\ take priority over those in HKEY_LOCAL_MACHINE. An attacker with standard user privileges can:

1. Create a per-user CLSID entry that shadows a legitimate shell extension
2. Point the InprocServer32 to a malicious DLL in the user’s AppData
3. The malicious DLL is loaded instead of the legitimate one, without requiring admin privileges

This is known as COM hijacking and is documented in the MITRE ATT&CK framework as technique T1546.015.

Real-World CVE Examples

These CVEs demonstrate that shell extension hijacking is not a theoretical threat — it is actively exploited in the wild by APT groups and ransomware operators.

Detection Techniques

1. Autoruns (Microsoft Sysinternals)

Autoruns is the most effective tool for detecting suspicious shell extensions:

1. Download Autoruns from the Sysinternals website.
2. Run as Administrator.
3. Navigate to the Explorer tab.
4. Enable VirusTotal scanning: Options → Scan Options → Check “Submit Unknown Images to VirusTotal” and “Check VirusTotal.com.”
5. Look for entries with:
   • Unknown publishers (no valid digital signature)
   • Unusual file locations (AppData, Temp, ProgramData)
   • Non-zero VirusTotal detections (highlighted in red)
   • Missing image paths (the DLL file does not exist — could be an orphaned handler)

2. Process Monitor (Real-Time Monitoring)

Set up a Process Monitor filter to watch for suspicious DLL loading:

• Process Name is explorer.exe
• Operation is LoadImage
• Path contains AppData OR Temp OR ProgramData

Any DLL loaded from a user-writable directory into explorer.exe is suspicious and warrants investigation.

3. PowerShell Registry Audit

Run this PowerShell script to enumerate all shell extension handlers and check for suspicious entries:

$suspiciousPaths = @("AppData", "Temp", "ProgramData", "Downloads")

$handlers = @(
    "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers",
    "HKCR:\*\shellex\ContextMenuHandlers",
    "HKCR:\Directory\shellex\ContextMenuHandlers",
    "HKCR:\Directory\Background\shellex\ContextMenuHandlers",
    "HKCR:\Folder\shellex\ContextMenuHandlers"
)

foreach ($handler in $handlers) {
    if (Test-Path $handler) {
        Get-ChildItem $handler | ForEach-Object {
            $clsid = $_.GetValue("")
            if ($clsid) {
                $inprocPath = "HKCR:\CLSID\$clsid\InprocServer32"
                if (Test-Path $inprocPath) {
                    $dllPath = (Get-ItemProperty $inprocPath)."(default)"
                    foreach ($sp in $suspiciousPaths) {
                        if ($dllPath -match $sp) {
                            Write-Warning "SUSPICIOUS: $($_.PSChildName) -> $dllPath"
                        }
                    }
                }
            }
        }
    }
}

4. Sigcheck (Signature Verification)

Use Sysinternals Sigcheck to verify the digital signatures of all loaded shell extension DLLs:

sigcheck -u -e C:\Windows\System32\*.dll
sigcheck -u -e "C:\Program Files\*\*.dll"

The -u flag shows only unsigned files, which are the most suspicious. See our detailed guide on verifying shell extension digital signatures.

Prevention and Hardening

1. Enable SafeDllSearchMode

Ensure the SafeDllSearchMode registry value is enabled (it is by default, but malware sometimes disables it):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
"SafeDllSearchMode"=dword:00000001

2. Use Windows Defender Application Control (WDAC)

WDAC policies can restrict which DLLs are allowed to load into explorer.exe:

# Create a WDAC policy that only allows signed DLLs
New-CIPolicy -Level Publisher -FilePath "ShellExtPolicy.xml" -UserPEs
ConvertFrom-CIPolicy -XmlFilePath "ShellExtPolicy.xml" -BinaryFilePath "ShellExtPolicy.p7b"

3. Restrict Per-User COM Registration

Block per-user COM hijacking by denying write access to:

HKEY_CURRENT_USER\Software\Classes\CLSID

This prevents standard users from shadowing system-wide shell extensions with malicious per-user versions.

4. Monitor for Registry Changes

Use Windows Event Forwarding (WEF) or a SIEM to monitor for modifications to shell extension registry keys:

• HKCR\*\shellex\ContextMenuHandlers
• HKCR\Directory\shellex\ContextMenuHandlers
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers

5. Regular Audits with ShellExView

Schedule periodic audits using ShellExView. Export the list of active shell extensions and compare against a known-good baseline. Any new entries that appear between audits should be investigated.

Incident Response: What to Do If You Find a Malicious Shell Extension

If you discover a suspicious or confirmed malicious shell extension, follow this response procedure:

1. Do NOT simply delete the DLL file. It is likely locked by explorer.exe and may have rootkit protections.

2. Boot into Safe Mode (hold Shift and click Restart → Troubleshoot → Advanced Options → Startup Settings → Safe Mode).

3. Disable the handler first:

   • Open regedit and navigate to the handler’s ContextMenuHandlers key.
   • Export the key as a backup, then delete it.

4. Quarantine the DLL:

   move "C:\ProgramData\SystemUpdate\helper.dll" "C:\Quarantine\helper.dll.quarantined"

5. Run a full malware scan:

   • Use Malwarebytes Premium for rootkit and zero-day detection.
   • Follow up with Avast for a second opinion.

6. Check for persistence mechanisms: The malicious extension may have created scheduled tasks, services, or other persistence. Use Autoruns to check all autostart locations.

7. Analyze the DLL (optional): If you want to understand what the malware does, submit it to:

   • VirusTotal (virustotal.com) for multi-engine scanning
   • Any.Run sandbox for dynamic analysis
   • Hybrid Analysis for behavioral analysis

Key Takeaways

• Shell extensions are a high-value attack surface because they execute inside explorer.exe
• COM hijacking via per-user registry keys requires no admin privileges
• Autoruns + VirusTotal is the most effective detection combo
• Hardening with WDAC, SafeDllSearchMode, and registry restrictions significantly reduces risk
• Regular audits with ShellExView and Sigcheck are essential for maintaining security