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.
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 AwarenessNot 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
.
Again, no attempt was made to determine what was installed.
I did see one instance where the threat actor, before doing anything else or being blocked/inhibited, ran queries looking for running on 15 other endpoints.
From our dashboard, we knew that only 4 of those endpoints had running; the threat actor moved to one of the 11 that didn't.
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.
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.
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 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.
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.
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.
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 resolved to localhost, but other sites, like Google, were still accessible.
This Cyber News was published on windowsir.blogspot.com. Publication date: Mon, 15 Jan 2024 18:13:04 +0000