Endpoint Detection and Response products are a critical and fundamental part of your security stack. The main function of an EDR is to detect and alert security teams to anomalous, and likely malicious, activities occurring on a given device in real-time with the analytics capabilities that enable a security team to respond at a very granular level.
EDRs are a fundamental element of a complete solution, but they cannot win the fight alone. Just like every other component of business, you must resource and manage it, but most importantly, you must verify it’s doing what it’s supposed to be doing.
The Paperweight EDR
Having an EDR is great, but if it’s only configured to log activity, logs are all you get. We call this “paperweight mode.” The EDR is operating and collecting information, but is anyone reviewing the logs or responding in any way? Likely not, and this scenario is quite common, especially when initially implementing an EDR solution.
Let’s say for example you’ve bought the latest in AI and automated technology only to find out it’s supervised machine learning. You must now tune these systems specific to your digital infrastructure to perform the right surgical actions, all while toggling the parameters relevant to your organization’s risk tolerance.
We’ve seen it happen too many times, a new security “feature” totally interrupts business operations. If not tuned correctly, the tool adds no value and only causes alert-fatigue and false-positive bias for an already overstretched security team who now have thousands of lines of logs to review. It goes without saying that any security feature embedded in your network that is heavily dependent on proper configuration comes with a risk of increased downtime and false alarms.
It might be turned “ON” and collecting information, but if no one looks at the information and/or no mitigating actions take place, it’s just paperweight. On the bright side, when you do get breached, you see a very pretty dashboard that correlates and lays out log by log just how someone pwnd you, after the fact.
NodeZero draws attention to this mode of operation quite often. The first knee-jerk response we typically see is “there’s no way my EDR didn’t stop that,” and because n0 utilizes autonomous reinforcement learning to actively test every possibility with no prior assumptions about the infrastructure, it is able to provide proof of exploitation through actual execution of arbitrary code. The follow up question we ask is either, “did it capture the activity?” or, believe it or not, “was it even on?”
It’s simple–you can put guards in the guard shack, but if their order is to only ask the attacker to sign a logbook before stealing a bunch of stuff, can you really say it’s security?
By using NodeZero to test your security tools from an attacker’s perspective, Horizon3.ai provides hard intelligence that if the EDR was armed and ready and did not log or prevent the exploit, the client now has a clear picture of the true attack paths used to get to your crown jewels and how effective (or ineffective) the security stack is in its current iteration. NodeZero then further empowers end users to continuously run new penetration tests after each fix, to verify each remediation and ensure the EDR, and the rest of the security stack, are working the way they were designed.
The Ghost EDR
As the name implies, this is a scary story to have to tell, but it emphasizes the need to verify everything.
In a recent pen-test operation, Horizon3.ai’s NodeZero chained together credential dumping attack methods at machine speeds to successfully collect dumps of credentials and hashes across every single sub-technique of ATT&CK T1003[1] and T1557.[2]
Taking advantage of this wealth of fresh intel straight from the client’s infrastructure, NodeZero was then able to utilize a combination of attack methodologies, including pass-the-hash (T1550.002), adversary-in-the-middle, and all four sub-techniques of brute force (T1110) to pivot and escalate privilege from an unauthenticated local user to local admin to domain user and, ultimately, domain admin.
In a traditional manual pentest, or a real attack, this would be enough, however, because NodeZero doesn’t take any breaks, it steps back out and tries to attack again in different ways, testing different elements of the loot that it collects along the way. This leads to discovery of multiple attack paths, rather than just one.
In this case, NodeZero identified three additional attack paths to domain admin. NodeZero then enumerated the resources in which these four credentials had access to, which translated to just over 4.5M resources accessed. Keep in mind, these credentials were not provided to NodeZero, they were harvested along with hundreds of credentials via the attack methods mentioned above.
For example, local admin accounts pulled from just the SAM database alone allowed NodeZero to provide proof of access to roughly an additional 4M resources across 60 file shares with write access to 1/3 of them. Some of which included sensitive documents from the client’s network security tool (keystore, sec stack intel, config files), MSP strategy, audits, and system config files. That’s some serious ransomware exposure.
We were just as surprised as the customer to discover such extensive exploits originating from a completely unauthenticated local user and a few misconfigurations. As the client has a low risk tolerance, their EDR is deployed as “shoot first, ask questions later,” so how were these attacks possible?
Even the most basic EDRs should have prevented or at least logged activity of some of the attack methods NodeZero utilized along the way. For example, LSASS dumps have been widely used in the past, popularized by tools like Mimikatz, so these TTPs were not novel in nature for an EDR to recognize or log. As it was, the client’s EDR logged zero evidence of the credential harvesting techniques performed by NodeZero.
After confirming that the EDR in question had the capability to detect this type of attack, we wondered what went wrong? There was no doubt that an EDR that was configured as purposefully as the client’s should have been able to log and alert on the activity.
The client’s MSP questioned the findings and doubted NodeZero’s capabilities by assuming false positives. However, after NodeZero presented proof of arbitrary code being executed on the hosts supposedly protected by the MSP provided EDR, Horizon3.ai was able to provide the client with real accountability both with the MSP and the EDR in question.
Turns out it was not a configuration, capability, or compatibility issue. After further investigation, the customer discovered that the vendor had pushed an update to the EDR system, causing it to power off, and it remained off for a whole month before Horizon3.ai came into the picture and exploited their environment from an attacker’s perspective to verify that the EDR was not running in Ghost Mode.
Our customer was grateful for this level of visibility as a real-life attacker does not care if you forgot to close the gates, they simply enter and wreak havoc.
Understanding your risk is constantly and continuously growing is key to any purple team exercise. By utilizing Horizon3.ai’s NodeZero and Customer Success Team as a sparring partner, the customer was able to not only run quality control on their own security stack & MSP vendor, successfully verify remediation of 200+ weaknesses in only 2 weeks, but also build a much more resilient network by implementing a new set of protocols, policies, and configurations, recommended by the CS team, to tackle vulnerabilities at the source instead of running around with band-aids.
[2] https://attack.mitre.org/techniques/T1557/
