A newly published proof‑of‑concept (PoC) called EDRStartupHinder demonstrates a local, pre‑boot startup technique that can prevent antivirus and EDR agents from initializing on Windows 11 25H2 by abusing the platform’s Bindlink API and the interaction between DLL loading and Protected Process Light (PPL) policies. The tool — released on January 11, 2026 — creates a malicious service that runs before security services, uses bind links to redirect critical System32 DLLs to attacker-controlled locations during boot, and then relies on PPL-enforced signature checks to cause protected EDR processes to abort rather than load potentially unsigned code. This represents an evolution of earlier bindlink-based evasion tools and highlights an unexpected intersection where a legitimate OS feature can be turned into an operational bypass for endpoint protections.
Microsoft’s Bindlink API is a Windows 11 feature that provides transparent filesystem namespace redirection: an administrator can bind a virtual path to a backing path so that applications see files at the virtual location while the backing path actually supplies the contents. Bind links are implemented at the minifilter driver layer by bindflt.sys, and their behavior is intended to be transparent to user‑mode applications. The API exposes CreateBindLink and RemoveBindLink for administrators and requires elevated privileges to create links. The Bindlink API has been part of Windows 11 since early updates and is documented in Microsoft’s Win32 API references. Researchers have previously shown how bind links (and related minifilter behaviors) can be abused to redirect or hide security product folders after services launch. EDRStartupHinder extends this line of work by performing the redirection before endpoint services initialize, making several common vendor folder‑hardening measures ineffective. The PoC author published a demonstration and code that show Windows Defender and multiple commercial products failing to start under lab conditions after DLL redirection was applied during boot. The researcher withheld vendor names in public writeups while making the PoC available, which raises both defensive and disclosure challenges.
Source: Cyber Press https://cyberpress.org/edrstartuphinder-disables/
Background / Overview
Microsoft’s Bindlink API is a Windows 11 feature that provides transparent filesystem namespace redirection: an administrator can bind a virtual path to a backing path so that applications see files at the virtual location while the backing path actually supplies the contents. Bind links are implemented at the minifilter driver layer by bindflt.sys, and their behavior is intended to be transparent to user‑mode applications. The API exposes CreateBindLink and RemoveBindLink for administrators and requires elevated privileges to create links. The Bindlink API has been part of Windows 11 since early updates and is documented in Microsoft’s Win32 API references. Researchers have previously shown how bind links (and related minifilter behaviors) can be abused to redirect or hide security product folders after services launch. EDRStartupHinder extends this line of work by performing the redirection before endpoint services initialize, making several common vendor folder‑hardening measures ineffective. The PoC author published a demonstration and code that show Windows Defender and multiple commercial products failing to start under lab conditions after DLL redirection was applied during boot. The researcher withheld vendor names in public writeups while making the PoC available, which raises both defensive and disclosure challenges.How the attack works — technical breakdown
The attack chain for EDRStartupHinder is methodical and targets Windows startup sequencing, DLL resolution, and PPL code‑integrity checks. The researcher described a four‑step approach; below is a consolidated and verified technical breakdown with clarifying context where platform behavior is confirmed by Microsoft documentation.1. Reconnaissance: identify target DLLs and service groups
- Attackers must determine which DLLs an EDR service loads during initialization and whether those DLLs are part of Windows’ KnownDLLs list (KnownDLLs are handled specially by the loader and are less susceptible to simple file‑redirect tricks).
- Tools like Process Monitor and Process Explorer can reveal the loader’s runtime file access patterns (forensic/manual recon of an endpoint). The PoC author emphasized finding DLLs that the target loads from disk during service start that are not preloaded as KnownDLLs.
2. Establish an early startup foothold via service group priority
- Windows services are started in groups according to ServiceGroupOrder in the registry. By creating a malicious service that runs in a group with startup priority ahead of the EDR service, an attacker can run code early in the boot sequence.
- The PoC configures a service to run at boot and to execute the bindlink creation while the system is still initializing, ensuring redirections are in place before the target EDR process is loaded. This requires administrative privileges on the host.
3. Create bind links that redirect System32 DLLs to attacker-controlled paths
- Using the Bindlink API (CreateBindLink), the tool binds a System32 target path (or a subpath used by the EDR) to a backing path that points at attacker‑controlled files. Because bind links operate at the minifilter level, the redirection is transparent to applications — processes that request the file will be served the backing path content instead. Microsoft documents this transparent behavior and the requirement for elevated privileges to manipulate bind links.
- The PoC’s novelty is performing this redirection for core System32 DLLs used by security services during the earliest phases of service startup. Redirecting DLLs loaded by EDR/antivirus processes can alter the file signature profile those processes see at load time.
4. Weaponize PPL’s strict DLL signature policy to force a fail‑open exit
- Protected Process Light (PPL) is used for anti‑malware services to prevent code‑injection and tampering. PPL enforces code‑integrity policies that only allow DLLs with the required signing level to load inside a protected process.
- The PoC modifies a single byte in the PE header of the redirected DLL in the backing path so that the signature verification fails when the protected EDR process attempts to load it. Because PPL processes enforce signature requirements, they refuse to load the DLL and — according to the PoC behavior — the protected EDR process terminates instead of continuing in a state that might be compromised. Microsoft documentation confirms that protected anti‑malware processes restrict which signed binaries/DLLs may be loaded.
- After the EDR process exits (or is prevented from starting), the PoC removes the bind link so that the rest of the operating system operates normally and so that collateral breakage is minimized — a stealthy cleanup that reduces noise in typical monitoring.
What parts of the technique are verified by platform docs and independent analysis
- Bindlink API behavior, the minifilter implementation (bindflt.sys), and the requirement for administrator rights to create bind links are documented by Microsoft. This confirms the mechanic that allows transparent redirection of file system namespaces.
- The PPL model for antimalware services — including the fact that only appropriately signed code is allowed to load within PPL processes — is explicitly documented by Microsoft and discussed in industry analyses, validating the PoC’s premise that corrupting a DLL signature can cause a protected process to refuse that DLL.
- Prior public research and PoCs have used bindlink and minifilter redirection to neutralize or manipulate EDR software (EDR-Redir family). Independent writeups and community investigation prior to this PoC corroborate that bindlink exploitation has been used in lab settings to hamper EDR operation. Those accounts support the claim that the approach is realistic when an attacker already has local administrator privileges.
What remains unverified or incomplete in public reporting
- The specific GitHub repository, full artifact list, or canonical demonstration package for EDRStartupHinder could not be reliably traced to a single authoritative location in open indexes at the time of reporting. Community posts and news syndication reference a public repo and demo materials, but direct authoritative links were not confirmed; treat any public binaries as high‑risk and avoid executing them on production systems.
- The researcher’s claim that multiple unnamed commercial products were bypassed is difficult to independently validate without vendor names, reproducible test cases, or raw telemetry. Public disclosure withheld vendor names to avoid accelerating exploitation, which is responsible for limiting public verification but leaves defenders in a difficult position when assessing exposure.
- Whether Microsoft views this as a platform vulnerability requiring a kernel/driver patch or as a design nuance of a feature that needs guidance to vendors is not publicly confirmed; no vendor or platform patch notice was available at the time of the PoC’s publication. This means defenders must prioritize mitigations and detection until vendors produce formal guidance or fixes.
Why this is significant — security tradeoffs and weaponized protections
EDRStartupHinder illuminates a broader, structural tension in OS security design:- Trusted platform features can become attack primitives. Bindlink was built to improve compatibility and provide powerful namespace redirection for legitimate uses. But its position in the minifilter stack and the transparency to user mode mean it can be repurposed by an admin‑level actor to change the file landscape seen by early boot processes. Microsoft’s own docs show bind links were meant for trusted admin scenarios — if an attacker obtains admin rights, several previously safe features become powerful attack surfaces.
- PPL’s strictness is both strength and potential liability. PPL prevents code injection and many forms of tampering by enforcing signature levels. But that same strictness means a protected process may prefer to terminate rather than continue with a potentially invalid load — and an attacker can intentionally trigger that decision by serving an invalid signature at load time. In short, a protection mechanism designed to avoid compromise can be leveraged as a denial‑of‑service lever against the protection itself. Microsoft’s documentation on protecting anti‑malware services confirms the strict loading constraints in PPL processes.
- Operational constraints limit vendor hardening. Vendors often harden their own subfolders and monitor for symlink manipulation. However, if the parent namespace is redirected prior to those hardening checks — or at a level that vendor hardening cannot efficiently observe — folder hardening is ineffective. Prior community analysis of earlier bindlink PoCs documented precisely this gap and warned that blanket hardening of parent namespaces would break legitimate OS/installer behaviors.
Immediate defensive steps for administrators (priority actions)
While vendor mitigations and Microsoft guidance are awaited, defenders can take concrete steps to reduce risk and improve detection. The following list is practical and prioritizes detection over brittle prevention methods that would harm stability.- Harden administrative access and reduce attack surface
- Enforce least privilege: remove unnecessary users from local administrators and use Just‑In‑Time (JIT) elevation and Privileged Access Workstations (PAWs) for admin tasks.
- Monitor and restrict the use of administrative installers and scripts: all admin operations that modify system folders should be logged and gated through change control.
- Detect suspicious bindlink and minifilter activity
- Monitor for calls to the Bindlink API or for processes loading bindlink.dll or otherwise interacting with bindflt.sys at early boot. Bindlink usage is a high‑value telemetry signal in this context.
- Hunt for unexpected or recently created bind links bound to System32, ProgramData, or Program Files paths. Bind links are persistent artifacts and should be visible to endpoint and host instrumentation that queries the minifilter namespace or file‑system metadata.
- Audit service startup order and suspicious service creation
- Baseline ServiceGroupOrder and the set of services in each group across your estate. Alert on new services created with higher priority than known security services and on modifications to ServiceGroupOrder. The PoC relies on a higher‑priority startup entry to run before EDR services initialize.
- Monitor for runtime DLL resolution anomalies
- Alert on DLL loads that resolve outside expected System32 or vendor subfolders during early boot or during EDR process startup. Look for failures in signature verification or unexpected file paths returned by the kernel loader. Elastic and other vendor blogs describe detection approaches for non‑KnownDLL loads and anomalous DLL resolution.
- Protect EDR minifilter ordering (where feasible)
- In some environments, defenders can ensure that defensive minifilters are attached in a stack position that would allow them to veto bind link creation on boot volumes, though this is operationally delicate and may require vendor coordination. Prior research highlights that veto capability exists but is constrained by stack ordering and volume types — this is not a universal fix.
- Use immutable integrity checks for critical OS files
- Implement host integrity monitoring that compares System32 DLL hashes against a known good source (not just trusted timestamps or certificates); alert on unexpected modifications or the sudden unavailability of expected signed files during boot.
- Short‑term operational controls
- For high‑risk assets (domain controllers, internet‑facing servers, sensitive engineers’ workstations), require Secure Boot + measured boot and enable hardware attestation for boot integrity.
- Temporarily increase visibility of boot‑time process creation and service start telemetry and forward it to a central logging and SOAR pipeline.
- Consider temporary hardening of administrative endpoints to only allow privileged onboarding through MDM/joined devices and block ad‑hoc local admin accounts.
Detection playbook — practical rules and queries
- Windows Event and EDR hunts:
- Alert on Service Control Manager events that create services with StartType set to boot (Start=0) in groups that precede anti‑malware service groups.
- File system audit: watch for creation of bind link artifacts or calls that indicate CreateBindLink was invoked (where available).
- DLL load failures in EDR processes: log and escalate instances where msmpeng.exe (or other protected agent processes) attempt to load a DLL and the loader reports signature/CI failures.
- Endpoint queries:
- Enumerate current bind links and backing paths.
- Compare System32 DLL hashes with a known baseline; flag changes not attributable to Windows Update.
- Query the ServiceGroupOrder registry value and look for recent modifications.
- Network and management plane:
- Correlate new service or bindlink artifacts with administrative activity (RDP sessions, PSRemoting, Intune/MDM pushes, SCCM task sequences) to separate legitimate admin changes from anomalous local exploitation.
Long‑term mitigations and vendor responsibilities
- EDR vendors should:
- Extend telemetry to detect minifilter bind link creation operations that affect protected process dependencies and raise an alert if a product’s own critical DLLs are resolved through unexpected backing paths.
- Consider adding early‑boot integrity checks and cross‑process attestation that confirm the expected System32 DLL graph before protected processes proceed to load dependencies.
- Work with Microsoft to establish best‑practice minifilter attach ordering and to explore kernel-level vetoes or audit hooks for bindlink creation affecting security product directories.
- Microsoft should:
- Clarify guidance around bind links and their acceptable administrative use cases versus risk in managed environments.
- Consider platform changes that make early bindlink creation observable to security vendors in a robust, non‑breaking way, particularly for boot volumes and critical OS directories.
- Provide public guidance to defenders on telemetry points and remediation steps when bindlink misuse is suspected.
Risk assessment and likely attacker model
- Risk profile: This is a local evasion primitive that requires administrative privileges to create bind links or to install a malicious, boot‑time service. It is therefore not an unauthenticated remote worm, but it is highly powerful in post‑compromise scenarios where admin rights are available through phishing, supply‑chain compromise, or lateral movement. Real incidents often follow this pattern: initial foothold through a lower‑privileged vector, then privilege escalation that enables tools like this.
- Likely abuse cases:
- Ransomware operators who already have admin rights on a subset of hosts may use this to temporarily neutralize endpoint defenses while they deploy encryptors.
- Sophisticated intruders could use the technique as part of a targeted operation to suppress local telemetry during data exfiltration or credential harvesting.
- Red teams and pen testers may adopt the PoC for simulated attacks; organizations should treat publicized PoC artifacts as high risk for real‑world translation.
- Limitations and operational cost to attackers:
- The approach relies on modifying only a narrow window in startup — timing and correct identification of dependency DLLs are required.
- The attacker must avoid destabilizing the system; PoC authors demonstrated cleanup steps, but real operators risk causing boot failures if they misidentify essential DLLs or fail to restore bindings properly.
Responsible disclosure and the public availability problem
The PoC’s source code and demonstration material being public increases the risk of rapid weaponization. Researchers argue that public release is important to drive vendor attention and accelerate hardening. Defenders and vendors must treat the publication as a call to action: increase telemetry, test for the behavior, and coordinate mitigations. At the same time, enterprises must assume the technique will be incorporated into commodity toolkits and plan accordingly. Community reporting and prior bindlink PoCs already indicated similar abuse patterns; this release is a logical, if worrying, step of maturity for these techniques.Practical remediation checklist (concise)
- Immediately:
- Increase logging of service creation and registry modifications to ServiceGroupOrder.
- Hunt for bindlink creation artifacts on System32 and ProgramData-backed paths.
- Alert on EDR/antivirus processes that failed to start with signature/loader errors.
- Within 24–72 hours:
- Audit privileged accounts and privileged software deployment pathways.
- Ensure all endpoints have tamper‑protection features enabled and that MDM enrollment policies restrict ad‑hoc local admin actions.
- Coordinate with EDR vendors for vendor‑specific recommendations and signatures.
- Medium term:
- Deploy kernel/driver posture checks and ensure defensive minifilters are positioned optimally where feasible.
- Validate and expand integrity monitoring for OS files and the KnownDLLs set.
Conclusion
EDRStartupHinder is a sober reminder that powerful OS features can become potent attack primitives when combined with the realities of post‑compromise privilege and strict protective policies like PPL. The technique leverages documented platform behavior — the Bindlink API and PPL’s insistence on properly signed code — in a way that causes a protected EDR process to choose termination over potential compromise. The underlying facts about bind links and PPL loading policies are verifiable in Microsoft technical documentation and in prior community research, but key claims in the PoC — including an authoritative repository and precise vendor coverage — are not fully reproducible in public indexing at time of publication. Organizations should treat this as an immediate detection and hunting priority: focus on admin access control, bindlink/minifilter telemetry, early service startup anomalies, and file integrity checks. Vendors and platform owners must work together to close the gap between legitimate administrative capabilities and opportunistic misuse, because today a legitimate OS feature can be weaponized to disable the very protections it was designed to coexist with.Source: Cyber Press https://cyberpress.org/edrstartuphinder-disables/
