EDR Bypasses

During my time in the industry, I've been blessed to have opportunities to engage with a number of different EDR tools/frameworks at different levels. Mike Tanji offered me a look at Carbon Black before carbonblack.com existed, while it still used an on-prem database. I spent a very good deal of time working directly with Secureworks Red Cloak, and I've seen CrowdStrike Falcon and Digital Guardian's framework up close. I've seen the birth and growth of Sysmon, as well as MS's "internal" Process Tracking (which requires an additional Registry modification to record full command lines). I've also seen Nuix Adaptive Security up close (including seeing it used specifically for threat hunting), which rounds out my exposure. So, I haven't seen all tools by any stretch of the imagination, but more than one or two.

Vadim Khrykov shared a fascinating tweet thread regarding "EDR bypasses". In the thread, Vadim lists three types of bypasses:

1. Technical capabilities bypass - focusing on telemetry EDR doesn't collect
2. EDR configuration bypass - EDR config being "aggressive" and impacting system performance 
3. EDR detection logic bypass - EDR collects the telemetry but there is no specific detection to alert on the technique used

Vadim's thread got me to thinking about bypasses I've seen or experienced over the years....

1. Go GUI

Most EDR tools are really good about collecting information about new processes that are created, which makes them very valuable when the threat actor has only command line access to the system, or opts to use the command line. However, a significant blind spot for EDR tools is when GUI tools are used, because in order to access the needed functionality, the threat actor makes selections and pushes buttons, which are not registered by the EDR tools. This is a blind spot, in particular, for EDR tools that cannot 'see' API calls.

As such, this does not just apply to GUI tools; EXE and DLL files can either run external commands (which are picked up by EDR tools), or access the same functionality via API calls (which are not picked up by EDR tools).

This has the overall effect of targeting analysts who may not be looking to artifact constellations. That is to say that analysts should be validating tool impacts; if an action occurred, what are the impacts of that action on the eco-system (i.e., Registry modifications, Windows Event Log records, some combination thereof, etc.)? This way, we can see the effects of an action even in the absence of telemetry specifically of that action. For example, did a button push lead to a network connection, or modify firewall settings, or establish persistence via WMI? We may not know that the button was pushed, but we would still see the artifact constellations (even partial ones) of the impact of that button push.

Take Defender Control v1.6, for example. This is a simple GUI tool with a couple of buttons that allows the user to disable or enable Windows Defender. EDR telemetry will show you when the process is created, but without looking further for Registry modifications and Windows Event Log records, you won't know if the user opened it and then closed it, or actually used it to disable Windows Defender.

2. Situational awareness 

While I was with CrowdStrike, I did a lot of public presentations discussing the value of threat hunting. During these presentations I included a great deal of telemetry taken directly from the Falcon platform, in part demonstrating the situational awareness (or lack thereof) of the threat actor. We'd see some who didn't seem to be aware or care that we were watching, and we'd see some who were concerned that someone was watching (checking for the existence of Cb on the endpoint). We'd also see other threat actors who not only sought out which specific EDR platform was in use, but also began reaching out remotely to determine other systems on which that platform was not installed, and then moving laterally to those systems.

I know what you're thinking...what's the point of EDR if you don't have 100% coverage? And you're right to think that, but over the years, for a variety of reasons, more than a few organizations impacted by cyber attacks have had limited coverage via EDR monitoring. This may have to do with Vadim's reason #2, or it may have to do with basic reticence to install EDR capability (concerns about the possibility of Vadim's reason #2...).

3. Vadim's #2++

To extend Vadim's #2 a bit, some other things I've seen over the years is customers deploying EDR frameworks, albeit only on a very limited subset of systems. 

I've also seen where deploying EDR within an impact organization's environment has been inhibited by...well...the environment, or the staff. I've seen the AD admin refuse to allow EDR to be installed on _his_ systems because we (my team) might remove it at the end of the engagement and leave a backdoor. I've seen users in countries with very strict privacy laws refuse to allow EDR to be installed on _their_ systems. 

I've seen EDR installed and run in "learning" mode during an engagement, so that the EDR "learned" that the threat actor's actions were "good".

One of the biggest variants of this "bypass" is an EDR that is sending alerts to the console, but no one is watching. As odd as it may sound, this happens considerably more often than you'd think.

EDR is like any other tool...it's value depends heavily upon how it's used or employed. When you look closely at such tools, you begin to see their "blind spots", not just in the sense of things that are not monitored, but also how DFIR work significantly enhances the visibility into a compromise or incident.