EDRSilencer

There's been a good bit of discussion in the cybersecurity community regarding "EDR bypasses", and most of these discussions have been centered around technical means a threat actor can use to "bypass" EDR. Many of these discussions do not seem to take the logistics of such thing into account; that is, you can't suddenly "bypass EDR" on an endpoint without first accessing the endpoint, setting up a beachhead and then bringing your tools over. Even then, where is the guarantee that it will actually work? I've seen ransomware threat actors fail to get their file encryption software to run on some endpoints.

Going unnoticed on an endpoint when we believe or feel that EDR is prevalent can be a challenge, and this could be the reason why these discussions have taken hold. However, the fact of the matter is that the "feeling" that EDR is prevalent is just that...a feeling, and not supported by data, nor situational awareness. If you look at other aspects of EDR and SOC operations, there are plenty of opportunities using minimal/native tools to achieve the same effect; to have your actions not generate alerts that a SOC analyst investigates.

Situational Awareness
Not all threat actors have the same level of situational awareness. I've seen threat actors where EDR has blocked their process from executing, and they respond by attempting to uninstall AV that isn't installed on the endpoint. Yep, that's right...this was not preceded by a query attempting to determine which AV product was installed; rather, the threat actor when right to uninstalling ESET. In another instance, the threat actor attempted to uninstall Carbon Black; the monitored endpoint was running <EDR>. Again, no attempt was made to determine what was installed.

However, I did see one instance where the threat actor, before doing anything else or being blocked/inhibited, ran queries looking for <EDR> running on 15 other endpoints. From our dashboard, we knew that only 4 of those endpoints had <EDR> running; the threat actor moved to one of the 11 that didn't.

The take-away from this is that even beyond "shadow IT", there are likely endpoints within an infrastructure that don't have EDR installed; 100% coverage, while preferred, is not guaranteed. I remember an organization several years ago that was impacted by a breach, and after discovering the breach, installed EDR on only about 200 endpoints, out of almost 15,000. They also installed the EDR in "learning mode", and several of the installed endpoints were heavily used by the threat actors. As such, the EDR "learned" that the threat actor was "normal" activity.

EDRSilencer
Another aspect of EDR is that for the tool to be effective, most need to communicate to "the cloud"; that is, send data off of the endpoint and outside of the network, were it will be processed. Yes, I know that Carbon Black started out with an on-prem approach, and that Sysmon writes to a local Windows Event Log file, but most EDR frameworks send data to "the cloud", in part so that users with laptops will still have coverage. 

EDRSilencer takes advantage of this, not by stopping, altering or "blinding" EDR, but by preventing it from communicating off of the endpoint. See p1k4chu's write up here; EDRSilencer works by creating a WFP rule to block the EDR EXE from communicating off of the host, which, to be honest, is a great idea. 

Why a "great idea"? For one, it's neither easy nor productive to create a rule to alert when the EDR is no longer communicating. Some organizations will have hundreds or thousands of endpoints with EDR installed, and there's no real "heartbeat" function in many of them. Employees will disconnect laptops, offices (including WFH) may have power interruptions, etc., so there are LOT of reasons why an EDR agent may cease communicating. 

In 2000, I worked for an organization that had a rule that would detect significant time changes (more than a few minutes) on all of their Windows endpoints. The senior sysadmin and IT director would not do anything about the rules, and simply accepted that twice a year, we'd be inundated with these alerts for every endpoint. My point is that when you're talking about global/international infrastructures, or MDRs, having a means of detecting when an agent is not communicating is a tough nut to crack; do it wrong and don't plan well for edge cases, and you're going to crush your SOC. 

If you read the EDRSilencer Github page and p1k4chu's write-up closely, you'll see that EDRSilencer uses a hard-coded list of EDR executables, which doesn't include all possible EDR tools.

Fortunately, p1k4chu's write up provides some excellent insights as to how to detect the use of EDRSilencer, even pointing out specific audit configuration changes to ensure that the appropriate events are written to the Security Event Log.

As a bit of a side note, audtipol.exe is, in fact, natively available on Windows platforms.

Once the change is made, the two main events of interest are Security-Auditing/5441 and Security-Auditing/5157. P1k4chu's write-up also includes a Yara rule to detect the EDRSilencer executable, which is based in part on a list of the hard-coded EDR tools.

EDRNoiseMaker detects the use of EDRSilencer, by looking for filters blocking those communications.

Other "Opportunities"
There's another, perhaps more subtle way to inhibit communications off of an endpoint; modify the hosts file.  Credit goes to Dray (LinkedIn, X) for reminding me of this sneaky way to inhibiting off-system communications. The difference is that rather than blocking by executable, you need to know to where the communications are going, and add an entry so that the returned IP address is localhost.

I thought Dray's suggestion was both funny and timely; I used to do this for/to my daughter's computer when she was younger...I'd modify her hosts file right around 10pm, so that her favorites sites (MySpace, Facebook, whatever) resolved to localhost, but other sites, like Google, were still accessible.  

One of the side effects would likely be the difficulty in investigating an issue like this; how many current or relatively new SOC/DFIR analysts are familiar with the hosts file? How many understand or know the host name resolution process followed by Windows? I think that the first time I became aware of MS's documentation of the host name resolution process was 1995, when I was attempting to troubleshoot an issue; how often is this taught in networking classes these days?

Conclusion
Many of us have seen the use of offensive security tools (OSTs) by pen tester and threat actors alike, so how long do you think it will be before EDRSilencer, or something like it, makes its way into either toolkit? The question becomes, how capable is your team of detecting and responding to the use of such tools, particularly when used in combination with other techniques ("silence" EDR, then clear all Windows Event Logs)? Tools and techniques like this (EDRSilencer, or the technique it uses) shed a whole new light on initial recon  (process/service listing, query the Registry for installed applications, etc.) activities, particularly when they're intentionally and purposefully used to create situational awareness.

Addendum, 1 Dec: I came across this Blu Raven blog post this morning, that mentions two alternatives to WFP as a means of silencing EDR. One is the hosts file, the other is custom routes. Very cool stuff folks, not terribly sophisticated, but can be done in a manner that would leave most current investigators and analysts kind of confused.

Addendum, 18 Dec: Yet another means of 'silencing' EDR (and other) agents is by modifying the Name Resolution Policy Table, which is maintained in the...wait for it...Windows Registry.