The Security Funnel Has a Hole in It
Why modern architectures fund the edges and leave execution control empty. Most security architectures aren't missing another product. They're missing a layer. Network at the front, EDR at the end, and a hole in the middle where execution policy should be.
Most modern security architectures are not missing another product category. They are missing a layer. If you look at how a large share of programs actually spend, the pattern is consistent. Budget concentrates at the front of the funnel on network and edge controls such as next-generation firewalls, secure web gateways, and SASE platforms, then on cloud prevention, CSPM, and attack surface management. Identity and activity analytics usually sit somewhere in the middle of the purchase list. At the host, the default control is an EDR platform. After the EDR, organizations add SOAR and investigation tooling to process whatever the endpoint product escalates.
That stack is the beginning and the end of the funnel. The middle is often empty. The missing layer is application control: the set of policies that decide whether a binary, script, driver, or remote management tool is allowed to execute at all.
National guidance has treated this layer as high-impact for years. The Australian Signals Directorate describes application control as one of the most effective mitigation strategies for stopping malicious code from running, and includes it in the Essential Eight. The rest of that baseline is familiar to most programs: patching, multi-factor authentication, privilege restriction, macro control, application hardening, and backups. Microsoft’s current guidance points organizations toward App Control for Business, formerly WDAC, rather than AppLocker, and is explicit that AppLocker does not meet Microsoft’s servicing criteria for a security feature. The control is documented. The implementation rate in enforce mode is not what the documentation would imply.
A rough practitioner estimate is that only about 2% of security teams treat execution control as a first-class architectural layer rather than an optional hardening project. (4) That number is not from a published survey. It is an observation from working with detection engineering and prevention programs: almost every environment has an EDR and a firewall conversation, and very few have an enforce-mode allowlist that covers LOLBAS, drivers, and unapproved remote tools.
What each layer actually decides
These layers answer different questions, and collapsing them into a single “defense in depth” slide hides the gap.
Network and cloud controls decide how something arrives and how much of the attack surface is exposed. Identity controls decide who is holding a token or a session. EDR decides what to alert on after a process has already started. Application control decides whether that process, script, driver, or remote tool is allowed to exist on the host in the first place.
Those are not interchangeable controls. A next-generation firewall can inspect a download and still have no opinion about whether certutil, mshta, or an unapproved ScreenConnect client may run once the file is on disk. An identity platform can confirm a valid user and still permit that user to launch dual-use operating system utilities. An EDR can generate high-quality telemetry on a process that the organization has already allowed. If the execution decision is never made, the later layers inherit whatever was permitted.
Why living-off-the-land falls through the hole
Living-off-the-land techniques abuse tools that are already present, signed, or operationally expected. Joint guidance from CISA, NSA, the FBI, and international partners in 2024 described LOTL as increasingly common in the broader threat environment. CISA’s own red teams use LOTL for persistent access with little custom tooling. The same guide notes that LOTL can avoid triggering EDR products when living-off-the-land binaries are treated as safe, or when administrators request standard configurations that allow them.
The LOLBAS project documents Microsoft-signed binaries, scripts, and libraries with unexpected functionality that is useful to an attacker, including rundll32, mshta, certutil, and related utilities. A 2021 IEEE Security and Privacy study of more than 31 million malware samples found LotL techniques in 9.41% of samples overall and 26.26% of APT malware, and reported that ten popular antivirus products had a generalized detection gap against LotL use of native binaries. More recent operational telemetry points in the same direction. Bitdefender’s analysis of 700,000 security incidents found LOTL binaries in 84% of high-severity cases, with a similar rate in managed detection data.
The same pattern applies below user mode. Vulnerable and malicious drivers, catalogued by the LOLDrivers project, are used to load signed kernel code that can disable security products, escalate privileges, or hide activity. If the driver is allowed to load, the rest of the host stack is negotiating with an already compromised kernel.
Remote monitoring and management tools follow the same logic. CISA documented criminal campaigns that delivered legitimate ScreenConnect and AnyDesk packages as portable executables for persistence and remote control. The LOLRMM catalog exists because the set of legitimate remote tools that can be reused this way is large and still growing. Huntress reporting on 2025 telemetry across more than 230,000 customers found RMM exploitation in one quarter of observed incidents, up from 7% the prior year. ScreenConnect, AnyDesk, Atera, and related tools were among those used for access, staging, and ransomware operations.
None of that activity is exotic in the sense that it requires a custom implant on day one. It is signed, expected, or already on the disk. If those classes of software are allowed to execute, EDR sees suspicious but permitted activity. The investigation queue fills with dual-use tool noise. SOAR automates tickets that should never have been processes. That is not primarily an EDR failure. It is what happens when a detection product is asked to compensate for a missing prevention layer.
What changes when the middle layer exists
Application control does not replace the network stack or the EDR. ASD’s definition is specific: when implemented robustly, application control ensures that only approved executables, libraries, scripts, installers, compiled HTML, HTML applications, control panel applets, and drivers can run. On Windows, that is the job of App Control for Business policy, not of another dashboard.
If the default abuse classes are blocked, two things follow. First, a portion of commodity and living-off-the-land tradecraft never becomes an alert or a case, because the process never starts. The investigation pile shrinks because the execution pile shrinks. Second, an attacker who still wants in has to leave the well-worn path of signed system utilities, known-vulnerable drivers, and off-the-shelf remote tools. That improvisation is noisier. Noisy behavior is what EDR, threat hunting, and SOAR are built to handle.
Prevention in the middle does not compete with detection at the end. It changes the input to detection.
The architectural point
Our generation of security programs became very good at watching, detecting activity. They watch the perimeter, the cloud exposure, the identity plane, and the endpoint, and then they log the alerts produced by that watching. Watching is not the same as deciding what is allowed to run on a Windows host.
The industry often treats that decision as an old, brittle control that is too expensive to maintain. The same industry then treats it as surprising that attackers keep using the tools the environment already installed and allowed. The funnel is not broken because a vendor category was forgotten. It is broken because budget spending focused on ingress and on post-execution detection, and left a hole where execution policy should be.
Want to see what's falling through the middle of your funnel right now? MagicSword is free for up to 100 endpoints. Deploy in audit mode and find out what's been permitted that shouldn't be. Get started today.
Sources
Australian Signals Directorate. “Implementing application control.” Cyber.gov.au. https://www.cyber.gov.au/business-government/protecting-devices-systems/hardening-systems-applications/system-hardening/implementing-application-control
Australian Signals Directorate. “Essential Eight explained.” Cyber.gov.au. https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight/essential-eight-explained
Microsoft. “App Control and AppLocker Overview.” Microsoft Learn. https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/appcontrol-and-applocker-overview
(4) Practitioner estimate. Not a published survey. See notes 1 through 3 and 5 on the gap between documented high-impact guidance and typical enforce-mode deployment.
CISA, NSA, FBI, and partners. “Identifying and Mitigating Living Off the Land Techniques.” February 2024. https://media.defense.gov/2024/Feb/07/2003389936/-1/-1/0/JOINT-GUIDANCE-IDENTIFYING-AND-MITIGATING-LOTL.PDF
LOLBAS Project. “Living Off The Land Binaries, Scripts and Libraries.” https://lolbas-project.github.io/
Barr-Smith et al. “Survivalism: Systematic Analysis of Windows Malware Living-Off-The-Land.” IEEE Symposium on Security and Privacy, 2021. https://www.computer.org/csdl/proceedings-article/sp/2021/893400a806/1t0x8Gp3GzC
Bitdefender analysis reported in Help Net Security. “How analyzing 700,000 security incidents helped our understanding of Living Off the Land tactics.” 1 July 2025. https://www.helpnetsecurity.com/2025/07/01/bitdefender-lotl-security-incidents-phasr/
LOLDrivers. Living Off The Land Drivers. https://www.loldrivers.io/
CISA. “Protecting Against Malicious Use of Remote Monitoring and Management Software.” AA23-025A, 25 January 2023. https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-025a
LOLRMM. Curated list of remote monitoring and management tools. https://lolrmm.io/
Huntress 2026 Cyber Threat Report findings as reported by Channel Dive, 27 February 2026. https://www.channeldive.com/news/cybercriminals-seize-msp-tools-connectwise-huntress-personal-data/813394/
Australian Signals Directorate. “Implementing application control.” Cyber.gov.au. https://www.cyber.gov.au/business-government/protecting-devices-systems/hardening-systems-applications/system-hardening/implementing-application-control
Microsoft. “App Control and AppLocker Overview.” Microsoft Learn. https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/appcontrol-and-applocker-overview
Written by
Jose Hernandez
Threat Researcher
Jose Enrique Hernandez formed and served as the Director of Threat Research at Splunk. Jose is known for creating several security-related projects, including: Splunk Attack Range, Splunk Security Content, Git-Wild-Hunt, Melting-Cobalt, lolrmm.io and loldrivers.io. He also works as a maintainer to security industry critical repositories such as Atomic Red Team and lolbas-project.github.io.
