Every Windows 10 and 11 machine ships with thousands of Microsoft-signed executables in “C:\Windows\WinSxS” that can be abused to load attacker-controlled code. No admin privileges required. No exploits needed. The binaries are already there, trusted, and signed by Microsoft.
Our Red Team leverages this technique to execute C2 payloads such as Cobalt Strike beacons inside genuinely signed Microsoft processes bypassing application allowlisting, evading memory scanners, and operating beneath the detection threshold of modern Endpoint Detection and Response (EDR) platforms. We developed internal tooling to identify exploitable targets, built weaponised proxy DLLs with escalating evasion techniques, and tested the full chain against Microsoft Defender & Elastic Defend achieving zero behavioural alerts.
This post covers the offensive research, the technical obstacles we solved, and the detection guidance defenders need.
Note to readers: The research enclosed in this article is aimed primarily at threat hunters, SOC teams and security practitioners, but highlights wider detection and hardening considerations that security leaders should be aware of.
The Windows Side-by-Side (WinSxS) directory is one of the largest folders on any Windows system, often exceeding 10Gb. It stores multiple versions of system components such as dynamic-link libraries (DLLs), executables, drivers, and configuration files, so that Windows can maintain backward compatibility and roll back failed updates.
From a security perspective, the most important detail is that WinSxS contains thousands of legitimate, Microsoft-signed executables. On a typical Windows 11 system, we found over 6,000 of them.
These binaries are signed by Microsoft, exist in a trusted system directory, and are part of the operating system. Most endpoint detection tools and application allowlisting policies consider them inherently safe...
But that assumption is not always justified.
Leader's takeaway:
Attackers do not necessarily need to introduce new tools or malware to evade controls. In this scenario, the operating system already provides the trusted binaries required to execute malicious activity, making behavioural monitoring more important than reputation-based controls alone.
When a Windows executable needs to load a DLL, it searches for it in a specific order defined by Microsoft. The application directory and system directories (System32, KnownDLLs) are searched first. If the DLL is not found in any of these trusted locations, the Windows loader will eventually search the current working directory (CWD).
This is well-documented by Microsoft and is the intended behaviour. The problem arises when a WinSxS executable imports a DLL that does not exist in any of the higher-priority search locations. When that happens, the loader falls through to the CWD and if an attacker has placed a DLL with the matching name there, it gets loaded into the trusted, signed process.
No privilege escalation exploit required.
No vulnerability in the traditional sense.
Just the Windows DLL search order working exactly as designed.
We tested two operational variants of this technique:
CWD hijack (T1574.001) - The attacker drops only DLLs into a writable directory, then executes the WinSxS binary from its original path with the CWD set to the payload directory. The signed EXE stays in WinSxS; the loader falls through to the CWD and picks up the attacker's DLL. Minimal footprint: two files on disk (proxy DLL + real DLL), no executable dropped.
DLL sideloading (T1574.002) - The attacker copies the signed WinSxS EXE alongside the proxy DLL in the same directory. The DLL resolves at application-directory priority (step 4 in the search order) rather than falling through to CWD. More reliable, avoids the "WinSxS binary with non-system CWD" detection pattern, but requires dropping an additional executable.
In controlled testing against Microsoft Defender & Elastic Defend, the CWD technique produced zero behavioural alerts when combined with proper process arguments. The sideloading variant was equally silent.
Other DLL hijacking scenarios require the attacker to either find a vulnerable third-party application or copy a legitimate binary to an attacker-controlled location (which may trigger detection).
WinSxS binaries are different. They already exist on every Windows machine, they are already trusted by allowlisting tools, and a subset of them import DLLs that are not present in the standard system directories. An attacker does not need to bring their own signed binary - the operating system provides one.
From a threat perspective, this means:
We developed internal tooling to systematically audit every executable in WinSxS for this class of vulnerability. The scanner performs five analysis phases: enumeration of all WinSxS executables, PE import parsing (standard and delay imports), multi-layer protection filtering, dynamic validation with canary DLLs, and proxy DLL generation with export forwarding.
The static analysis checks each imported DLL against multiple protection layers that would prevent hijacking:
On a fully-patched Windows 11 (Build 26200) system, the static scan identified 73 candidates after all filtering. Dynamic validation with canary DLLs confirmed 15 exploitable targets; binaries that genuinely load an attacker-controlled DLL when executed from a directory containing it.
Leader’s takeaway:
The key finding is not that a single vulnerable binary exists, but that exploitable WinSxS binaries can be identified systematically. As Windows evolves, so does the available attack surface, meaning detection logic and hardening measures should be reviewed regularly rather than treated as one-time exercises.
Dynamic testing confirmed DLL hijacking for targets spanning .NET framework tools, Windows services, WMI infrastructure, and IIS components. The confirmed targets include binaries present on every default Windows installation alongside those that appear when specific roles or features are enabled.
Several findings from testing are worth highlighting:
Variation across Windows builds: The WinSxS attack surface is not static. Windows updates add, remove, and modify WinSxS binaries. A target confirmed on Windows 11 23H2 may not exist or may behave differently on 25H2. Periodic re-scanning is essential.
Multiple assembly versions: The same EXE name (e.g. ngentask.exe) may appear under half a dozen different assembly-version directories in WinSxS. Some of these are delta-compressed (DCS/PA19/PA30 format) and cannot be directly executed. The scanner validates MZ headers to filter these out, but defenders should be aware that the same binary name may have multiple valid paths.
EXE search-order hijacks: Beyond DLL hijacking, certain WinSxS binaries spawn child processes by name. If the current working directory contains an executable matching the expected child process name, the attacker's binary runs instead of the legitimate system utility. We confirmed this for several WinSxS binaries that call utilities like ipconfig.exe, cmd.exe, and ClipUp.exe.
Threat actors using this technique in the real world go far beyond simply dropping a payload DLL. Dropping a DLL that only contains payload code will crash the host process when it attempts to call any of the expected exported functions. Sophisticated implementations use export-forwarding proxy DLLs; a DLL that transparently forwards all legitimate API calls to the original system DLL (renamed to <name>_real.dll) while executing the payload silently in the background.
We developed internal tooling to systematically audit every executable in WinSxS for this class of vulnerability. The scanner performs five analysis phases: enumeration of all WinSxS executables, PE import parsing (standard and delay imports), multi-layer protection filtering, dynamic validation with canary DLLs, and proxy DLL generation with export forwarding.
The proxy DLL is compiled with linker directives that redirect every export to the renamed original:
#pragma comment(linker, "/export:CreateAssemblyCache=mscorsvc_real.CreateAssemblyCache")
#pragma comment(linker, "/export:CorSvcStartWorker=mscorsvc_real.CorSvcStartWorker")
// ... every export from the original DLL
The host application calls CreateAssemblyCache as normal. The loader resolves it in the proxy DLL, which forwards the call to mscorsvc_real.dll. The application functions normally. Meanwhile, the proxy DLL's DllMain has already launched a beacon thread in the background.
The result: a Microsoft-signed process running normally, loading DLLs from its own directory (or via CWD), with attacker code running on a separate thread. No crashes, no error dialogs, no Windows Error Reporting entries.
An obstacle we encountered during testing was Windows Control Flow Guard (CFG). Several WinSxS targets are compiled with CFG enabled (IMAGE_DLLCHARACTERISTICS_GUARD_CF, flag 0x4000). When CFG is active, the OS validates that indirect call targets are in the process's CFG bitmap - a list of approved call targets populated at compile time.
Shellcode allocated via VirtualAlloc is not in the CFG bitmap. Attempting to execute it via API callbacks like EnumSystemLocalesA (a common shellcode execution technique) triggers a CFG violation: __fastfail with status 0xC0000409 and the process terminates instantly.
Not all WinSxS targets have CFG. For example, ngentask.exe (importing mscorsvc.dll) does not have CFG enabled, making it the lowest-friction target. Others like ilasm.exe (importing fusion.dll) do have CFG and require the bypass.
The bypass uses NtSetInformationVirtualMemory with the VmCfgCallTargetInformation information class to register the shellcode allocation as a valid CFG call target:
typedef struct { PVOID Offset; ULONG_PTR Flags; } CFG_CALL_TARGET_INFO;
CFG_CALL_TARGET_INFO cti = { execMem, 1 }; // CFG_CALL_TARGET_VALID
NTSTATUS s = NtSetInformationVirtualMemory(
GetCurrentProcess(), VmCfgCallTargetInformation,
1, ®ion, &cti, sizeof(cti));
After this call, the shellcode address passes CFG validation and EnumSystemLocalesA executes it normally.
For defenders: CFG is one of the few mitigations that directly affects this technique. Binaries compiled with CFG are harder to exploit for callback-based shellcode execution. However, the VmCfgCallTargetInformation bypass is well-documented and effective. WDAC-enforced CFG (where the OS prevents processes from modifying their own CFG bitmap) would close this gap but is not widely deployed.
The general shellcode loader in a proxy DLL would typically consist of structure : VirtualAlloc(PAGE_EXECUTE_READWRITE) + memcpy + direct call. This is trivially detected by any modern EDR. The RWX memory allocation and execution pattern is heavily signatured. In testing, we developed four escalating loader implementations:
Level 0 (Default): VirtualAlloc RWX + memcpy + CreateThread. Plaintext shellcode in the binary. Immediate detection by memory scanners and API hooks.
Level 1 (XOR + Executable Heap): Shellcode XOR-encrypted with a random 16-byte key at build time. At runtime: decrypt, allocate an executable heap (HeapCreate with HEAP_CREATE_ENABLE_EXECUTE), copy shellcode, execute via EnumSystemLocalesA callback. No VirtualAlloc, no RWX pages.
Level 2 (RC4 + Section Mapping + Fibers): Shellcode RC4-encrypted using a random key. At runtime: decrypt via SystemFunction033 (always available in advapi32.dll), create a section object with NtCreateSection, map two views - one RW (for writing shellcode), one RX (for execution). Copy shellcode to the RW view. Execute via ConvertThreadToFiber + CreateFiber + SwitchToFiber. No VirtualAlloc, no RWX pages, no CreateThread - fibers are user-mode constructs with no kernel thread object. All ntdll functions resolved via GetProcAddress at runtime (not in the IAT).
Level 3 (RC4 + Module Stomping): Shellcode RC4-encrypted. At runtime: decrypt, load a sacrificial Microsoft-signed DLL (amsi.dll, wintypes.dll, or msvcp_win.dll) with DONT_RESOLVE_DLL_REFERENCES (prevents DllMain execution), walk its PE headers to find the .text section, VirtualProtect to RW, overwrite with shellcode, VirtualProtect back to RX, execute via EnumSystemLocalesA. The shellcode now runs from MEM_IMAGE pages backed by a signed Microsoft DLL and most memory scanners that check page protection and backing will classify this memory as legitimate.
In our testing against Elastic Defend and Microsoft Defender, the Level 3 module stomping combined with the proxy DLL technique produced zero behavioural alerts and zero YARA detections.
We conducted systematic testing across Windows 10 and Windows 11 25H2 with Microsoft Defender & Elastic Defend 9.3.1 in a controlled lab environment. The testing followed a single-variable methodology: identical Cobalt Strike payloads delivered through different paths, with EDR alert data deduplicated by SHA256 hash and split by process.entity_id for accurate attribution.
In our testing, WinSxS sideloading achieved zero behavioural alerts: Using ngentask.exe with a proxy DLL (export-forwarding mscorsvc.dll) and embedded Cobalt Strike shellcode, the full execution chain - process creation, DLL loading, beacon callback, interactive post-exploitation commands - generated zero Elastic behavioural rule triggers. Zero YARA signature matches. The only detection was the Elastic static ML score of 0.9345, which is below the default blocking threshold for DLLs.
Elastic keys on call-target memory provenance, not caller stack: During our broader evasion research, we discovered that Elastic Defend's shellcode detection rules examine the protection_provenance of the call target memory rather than analysing the caller's call stack. This means that even with fully spoofed call stacks, shellcode running from anonymous RWX memory (provenance: Undetermined) will still trigger detection. The module stomping technique (Level 3) addresses this by placing shellcode in MEM_IMAGE pages with a valid module backing.
Process arguments matter: Some WinSxS binaries are on EDR watchlists. During testing, we found that launching certain WinSxS binaries without arguments triggered "Unusual Process Execution" type rules. Passing plausible arguments (e.g. /executeQueuedItems for ngentask.exe) eliminated these alerts.
Parent process correlation is a detection opportunity: The deployment script's direct execution method creates a powershell.exe -> ngentask.exe parent-child chain, which is anomalous. Using WMI execution (Win32_Process.Create) shifts the parent to WmiPrvSe.exe; taskbar shortcut hijacking shifts it to explorer.exe. Both are more plausible parents for a WinSxS binary.
WinSxS hijacking works on both platforms, but Windows 11 25H2 introduces security features that affect the broader attack chain:
Virtualisation-Based Security (VBS) on Windows 11 25H2 uses the hypervisor to validate that syscall origins are image-backed memory. Indirect syscalls from VirtualAlloc-allocated shellcode are rejected at the hypervisor level. This does not directly prevent WinSxS hijacking (the proxy DLL is image-backed), but it constrains what the loaded shellcode can do if it relies on direct or indirect syscall patterns from non-image memory.
Different WinSxS surfaces: The set of exploitable WinSxS targets varies between Windows 10 and Windows 11 builds. Some binaries are present on one platform but not the other. Certain DLLs that are valid gadget sources on Windows 10 (feclient.dll, wuuhext.dll) do not contain the required instruction patterns on Windows 11 25H2, due to changes in the MSVC toolchain that eliminated specific code generation patterns.
CFG coverage differences: The CFG bitmap population differs between Windows versions. A binary that loads successfully via callback execution on Windows 10 may CFG-fault on Windows 11 (or vice versa) depending on compiler flags used for that specific build.
This technique has been observed beyond controlled research environments and has been documented in active threat campaigns:
| MITRE ID | Technique |
| T1574.001 | DLL Search Order Hijacking |
| T1574.002 | DLL Side-Loading |
| T1036.005 | Masquerading: Match Legitimate Name |
| T1218 | System Binary Proxy Execution |
Leader’s takeaway:
While the technical details of WinSxS hijacking are complex, the risk is straightforward.
Attackers do not always need new malware or previously known vulnerabilities to evade security controls. In some cases, they can abuse trusted operating system components that already exist on the endpoint. This reinforces the importance of monitoring behavioural anomalies, process lineage and DLL loading activity rather than relying solely on application reputation or code signing.
The good news is that this technique, while effective against default EDR configurations, leaves detectable artefacts at multiple points in the execution chain. The key is layering detections so that evading one creates signal in another.
Sysmon Event ID 7 (Image Loaded) is the most direct indicator. A WinSxS binary should only load DLLs from trusted system directories. If a process running from C:\Windows\WinSxS\ loads a DLL from any other location -- particularly a user-writable directory like C:\Users\, C:\Temp\, or Downloads - that is a high-confidence indicator of compromise.
<!-- Alert: WinSxS binary loading DLL from non-system location -->
<ImageLoad onmatch="include">
<Image condition="contains">\WinSxS\</Image>
</ImageLoad>
<ImageLoad onmatch="exclude">
<ImageLoaded condition="begin with">C:\Windows\System32\</ImageLoaded>
<ImageLoaded condition="begin with">C:\Windows\WinSxS\</ImageLoaded>
<ImageLoaded condition="begin with">C:\Windows\Microsoft.NET\</ImageLoaded>
</ImageLoad>
Sysmon Event ID 1 (Process Create) catches two scenarios: WinSxS binaries launched with a suspicious working directory, and WinSxS binary names being executed from outside the WinSxS directory entirely (indicating the binary was copied for sideloading).
<!-- Alert: WinSxS binary executed with non-system working directory -->
<ProcessCreate onmatch="include">
<Image condition="contains">\WinSxS\</Image>
</ProcessCreate>
Cross-reference the CurrentDirectory field in these events - if a WinSxS process has a working directory outside of C:\Windows\, this warrants immediate investigation.
Critical gap in CWD detection. The Sysmon rules above detect the CWD hijack variant. They do not detect the sideloading variant where the signed EXE is copied to the same directory as the proxy DLL. In that case, the Image path will be something like C:\Users\Public\data\ngentask.exe -- not in WinSxS at all.
Defenders must also monitor for WinSxS binary names executing from non-WinSxS paths:
<!-- Alert: known WinSxS binary name executing from non-WinSxS location -->
<ProcessCreate onmatch="include">
<Image condition="end with">\ngentask.exe</Image>
<Image condition="end with">\ilasm.exe</Image>
<Image condition="end with">\aspnet_wp.exe</Image>
<Image condition="end with">\wmiprvse.exe</Image>
</ProcessCreate>
<ProcessCreate onmatch="exclude">
<Image condition="contains">\WinSxS\</Image>
<Image condition="contains">\System32\</Image>
<Image condition="contains">\Microsoft.NET\</Image>
</ProcessCreate>
For child process hijacking, monitor parent-child relationships where a WinSxS binary spawns a child process from a non-system path:
<!-- Alert: WinSxS binary spawning child from unexpected location -->
<ProcessCreate onmatch="include">
<ParentImage condition="contains">\WinSxS\</ParentImage>
</ProcessCreate>
For SOC teams using EDR platforms, build detections around these patterns:
For advanced detection, the Microsoft-Windows-Kernel-Process ETW provider generates DLL load events that can be consumed by EDR agents. This provides kernel-level visibility into which DLLs are being loaded by which processes, independent of Sysmon.
The Microsoft-Windows-Threat-Intelligence ETW provider is particularly valuable for detecting the more sophisticated loader techniques. It generates events for memory protection changes (VirtualProtect), section mapping (NtMapViewOfSection), and CFG modifications that the stealth loaders rely on.
When enabled, the CWD is searched after System32 rather than before it, reducing (but not eliminating) the attack surface. Note: this does not prevent the sideloading variant (where the DLL resolves at the application-directory step, which is always before CWD).
DLL Search Order Hijacking via WinSxS is not a new vulnerability, but it remains underappreciated in many security programmes. The combination of trusted binaries, no privilege requirements, application allowlisting bypass, and the ability to achieve EDR-silent execution with proxy DLLs and evasive loaders makes it an attractive technique for both sophisticated threat actors and commodity malware.
Our testing against Elastic Defend 9.3.1 demonstrated that the full chain - from proxy DLL loading to interactive C2 - produces zero behavioural alerts when combined with proper OPSEC (process arguments, parent-process control, module stomping). The most effective defences are layered: WDAC for DLL signature enforcement, process lineage monitoring for anomalous WinSxS execution, file-system monitoring for proxy DLL indicators, and memory integrity checks for loader technique artefacts.
The most important takeaway for defenders is this: a Microsoft-signed binary loading an unsigned DLL from a user-writable directory should be treated as highly suspicious and warrants investigation.
If your detection stack can identify that pattern reliably, you have a high-confidence detection for this entire class of attack. But go further - monitor for the sideloading variant (known WinSxS binary names executing from non-system paths), the proxy DLL indicators (*_real.dll files), and the memory manipulation techniques that advanced implementations use to evade runtime detection.