Security tools may succeed in stopping a known version of an attack, yet allow the same behavior to pass when it is executed in a less obvious way. This is the main conclusion of an analysis based on Blue Report 2026, issued by Picus Labs, which measured the performance of prevention and detection controls in real customer environments across more than 338 million attack simulations conducted between January and June 2026.
Overall prevention effectiveness rose to 69%, compared with 62% the previous year, returning to the 2024 level. However, this figure is an average across the protection ecosystem and does not necessarily show what an attacker can do after entering the environment or when changing the tool and method used to achieve the same objective.
A Known Indicator Does Not Equal Behavioral Protection
The analysis distinguishes between two types of testing. Known-indicator, or IOC-based, testing verifies whether firewalls, web agents, and secure email gateways can recognize known malicious samples and block attempts to download them. This measurement is appropriate for the perimeter protection layer, but it does not answer a different question: Can the environment prevent the action an attacker performs regardless of the tool or path?
This is where behavior-based testing built around tactics, techniques, and procedures (TTPs) comes in. Instead of asking whether the Mimikatz tool is known to the system, this approach tests whether any program on the device can obtain user credential material. This question is important for endpoint protection tools and intrusion detection systems because the attacker has often already begun execution inside the environment by the time these controls intervene.
The rate of blocking known-malware downloads based on IOCs fell to 50% in the 2026 data, compared with 60% in 2025 and 71% in 2024. This indicates that even the layer most dependent on signatures does not provide consistent coverage, and that a good result in a known-signature test does not reveal what happens when the behavior or its execution method changes.
The Mimikatz Example Exposes the Gap
Customer environments used the Mimikatz tool to achieve the same objective—credential extraction—through three paths. Data extraction from the memory of the LSASS process was blocked in 94% of attempts, the traditional path widely monitored by products. However, the rate fell to 17% when RDP credentials were pulled from other memory locations using the same tool, and to 3% when LSA Secrets were read from the local system registry.
All three cases fall under the same parent technique, OS Credential Dumping (T1003), and end with the same result: the attacker obtains sensitive credential material. The difference was how visible the path was to security controls. Reading the memory of lsass.exe produces events that can be matched more easily, whereas reading a registry hive with SYSTEM privileges may look more like ordinary administrative activity.
Success in blocking a known version of Mimikatz also does not guarantee a consistent result. The strings relied on by a signature can be changed, the tool can be recompiled, code can be loaded into memory without leaving it on disk, or Microsoft-signed tools such as ProcDump or comsvcs.dll can be used and the data analyzed later. In these cases, the artifact sought by signatures changes, while the behavior and final objective remain the same.
Protection Inside the Environment Is Weaker Than Protection at the Boundary
The overall prevention rate was 69% when measured at the boundary level, but breach-and-attack simulations measuring what an attacker can do after entering as an authenticated user showed that only 37% of post-compromise actions were blocked. In other words, protection shifted from stopping roughly two-thirds of attacks at the perimeter to stopping slightly more than one-third of actions inside the environment.
The noisier actions were more detectable: lateral movement detection reached approximately 90%, UAC bypass exceeded 85%, while blocking credential reuse and Active Directory abuse reached approximately 63%. By contrast, rates fell for less obvious activities: protection of credential material passively read from memory and the registry did not exceed 22%, and was below 1% for extracting local registry secrets. Discovery and collection activities also did not exceed 10%; domain enumeration using SharpHound and local file collection were generally carried out without impediment.
What Changes in Practice?
The practical conclusion of the analysis is that security validation programs need to interpret each test according to what it measures, rather than treating a single result as comprehensive evidence of coverage. Known-sample testing remains appropriate for firewalls, web agents, web application firewalls, and secure email gateways. The endpoint and detection layer, including EDR, IDS, and SIEM content, needs to test every path leading to the same objective: LSASS memory, the registry, alternative memory locations, native tools, and recompiled versions.
The article warns that testing only the well-known procedure may result in closing an item that remains genuinely exposed. The analysis proposes using multiple simulations of the same behavior to validate existing controls, rather than merely proving that one signature recognized one tool. It mentions Picus Swarm as an orchestration layer for running and testing these variations across the environment, within the company’s products and services.
The recommendation is not necessarily to add new tools, but to identify the existing controls that can actually break the attack chain, then make a documented decision for each exposure: remediation, mitigation, monitoring, or acceptance with evidence. According to the article, the report’s findings remain part of a broader study covering performance differences across sectors and regions, the most exploited vulnerabilities, a logging rate of 58%, and an alert rate of 14%.