Purpose of EDRs
EDR (Endpoint Detection and Response) tools identify suspicious behavior on endpoints and provide alerts to administrators. Additionally, they might initiate protective actions on the endpoints, e.g., by blocking and removing potentially malicious executables. One ever on-going question for EDR developers and users is:
What qualifies as suspicious behavior and how should it be handled?
In this blog post, we explore this question, as we stumbled across an interesting and apparently intended behavior in CrowdStrike's Falcon Sensor that is inconsistent with other state-of-the-art EDR (Endpoint Detection and Response) tools. For example, CrowdStrike describes its solution in the following way:
"Powered by the CrowdStrike Security Cloud, the CrowdStrike Falcon® platform leverages real-time indicators of attack, threat intelligence on evolving adversary tradecraft and enriched telemetry from across the enterprise to deliver hyper-accurate detections, automated protection and remediation, elite threat hunting and prioritized observability of vulnerabilities – all through a single, lightweight agent. With CrowdStrike, customers benefit from superior protection, better performance, reduced complexity and immediate time-to-value."
Source: www.crowdstrike.com/about-us/
The Scenario
A malicious actor gains local administrator privileges (with "NT AUTHORITY\SYSTEM" permissions) on a Windows machine that is protected by CrowdStrike Falcon Sensor. This is a real-world scenario, as for example our advisory on a OneIdentity Kiosk-Escape Vulnerability shows. Additionally, we encountered this behavior in the wild during IT infrastructure and red teaming assessments. The compromised machine is running CrowdStrike Falcon Sensor:
PS C:\Program Files\CrowdStrike> .\CSSensorSettings.exe --version
CsSensorSettings Version: 7.11.18110.0
Sensor settings payload version: 1 Wow64 Process: False
OKBy checking CrowdStrike's dashboard, we see that the CrowdStrike Falcon Sensor is up and running (Figure 1):
Figure 1: CS Falcon Sensor is "operational and up to date"
Since the CS Falcon Sensor is running, any attempt to execute even slightly malicious applications, such as “winPEAS”, “Rubeus”, or “Certipy”, ends with a terminated process and a deleted executable.
Falcon Sensors Cannot be Killed but they can be put to Sleep
Our target in this post is the CS Falcon Service. This service is responsible for utilizing CrowdStrike's cloud-based EDR capabilities that e.g. include advanced signature checks of binaries. As a local admin (with "NT AUTHORITY\SYSTEM" permissions), the SysInternals Process Explorer can be used to control the CS Falcon Service, e.g., to kill, suspend or restart the process.
Figure 2: Process Explorer allows us to Suspend or Kill a process
Intuitively, killing the process is prohibited, as this would undermine its capability to talk to the cloud backend which does the heavy lifting in terms of threat detection.
Figure 3: Process Explorer - Killing the process is not allowed
Nevertheless, suspending the process is possible without any problems, and from the viewpoint of the attacker yields the same result as killing it for a number of use cases.
Figure 4: Process Explorer - Process suspension is just fine, everyone needs a break at some point
Advantages of Suspended CS Falcon Sensor Processes
Tested malicious scripts and executables with a yet unknown file signature, such as “winPEAS”, that are usually terminated by CrowdStrike's EDR during execution, are now able to execute normally. Furthermore, the suspension of the CS Falcon Sensor processes enable an attacker to retain malicious applications on the disk, which would usually be automatically removed by CrowdStrike. In this example, we can see the CS Falcon Service and its containers suspended while winPEAS happily executes.
Figure 5: winPEAS starts
Figure 6: winPEAS can perform enumeration tasks
This applies to any suspicious .NET application that can be executed directly via reflection. Of course, winPEAS will be terminated and removed by CrowdStrike as soon as it starts to expose actual malicious behavior such as dumping credentials. Re-enabling the processes after suspension allows us to see CrowdStrike in all its might, with an instantaneous removal and report of the suspicious binary winPEAS.
Figure 7: CrowdStrike quarantines and removes winPEAS immediately after the Sensor process is resumed
Trying other tools such as Rubeus or Certipy yields the same behavior.
Caveats
Keep in mind, processes that are already hooked at the time of the sensor suspension are still supervised by the CS kernel processes. For example, LSASS dumps are still not possible and will lead to the removal of the application that attempts them. Nevertheless, a motivated attacker will gladly reach for any foothold that is available.
How Do Other EDR Solutions Handle This Issue?
So, we would expect that process suspension is not possible for a software that tries to prevent malicious actions on a system. And indeed, other tools like Microsoft Defender for Endpoint or also Malware Bytes simply block process suspension.
Figure 8: Microsoft Defender for Endpoint blocks process suspension attempts.
CrowdStrike's Reaction
SEC Consult brought the behavior to CrowdStrike's attention via different channels, such as a HackerOne ticket (2274888) back at the end of 2023, which resulted in a closed issue and the following (shortened) statement by the vendor (vendor statement in quotes):
The vulnerability is only a "detection gap as the sensor has visibility into the action but does not generate a detect/prevent in the UI" and "suspending the user mode service does not stop the kernel components or sensor communications.
An administrator performing this action does not cross a logical security boundary within the operating system and therefore does not pose a security vulnerability within the sensor. Additionally, suspending the user mode service does not stop the kernel components or sensor communications.
You may have noticed while Winpeas could be run from memory, it could not be written to disk, and likewise, other dangerous actions like dumping lsass are still prevented. With that said we will be closing this issue as informative."
Other researchers did not fare much better: a similar answer was provided to security researchers that found a comparably simple implementation flaw. In their case, CrowdStrike Falcon Sensor could just be uninstalled, which leads to similar problems as in our case.
How Does CrowdStrike Handle This Issue in 2025?
In 2025, CrowdStrike does not allow process suspension anymore and appears to have decided that process suspension is indeed a detection gap that should not exist. SEC Consult was not informed about this status update and we found out by chance during another check of CrowdStrike Falcon Sensor during our security assessments.
Vendor contact timeline
2023-12-06: Contacting vendor through HackerOne submission (2274888)
2023-12-06: Vendor needs more info, our version seems to have been outdated, but
they could not reproduce the vulnerability.
2023-12-07: Tested latest version, sent update to vendor that it is also vulnerable.
Added further POC details for exploitation.
2023-12-07: Vendor: the vulnerability is only a "detection gap", closes the issue.
"the sensor has visibility into the action but does not
generate a detect/prevent in the UI", "suspending the user mode
service does not stop the kernel components or sensor
communications".
2024-02-14: Follow-up with other vendor contacts, not via HackerOne.
2024-03-05: Asking for a status update.
2024-04-15: No updates received from any contacts.
We decided not to pursue this topic any further because of the vendor response.
2025-02: Found out that CrowdStrike FS now mitigates this issue and prepared blog post.
This research has been performed by Constantin Schieber-Knöbl and Stefan Schweighofer and the blog post was written with support of Werner Schober, Clemens Stockenreitner and Stephan Mikiss. It is published on behalf of the SEC Consult Vulnerability Lab.