These days, I start to have second thoughts about releasing information that could be useful for attackers. So this time I’ll try something different. I will not tell you specifically what we found about the capabilities of specific EDRs on Linux. If you are interested, feel free to reach out, I’m glad to share once I know the information will be in good hands.
However, I’ll help you with a simple
Another reason I decided to pick this format is that these days security tools are picked frequently by non-security people who do not necessarily have the specialized background to set up realistic test cases and effectively focus their efforts when comparing products. Similarly, security teams often do not have the time to dig deep enough. With the test case in the
I encourage you if you have an EDR and your shop runs Linux or macOS, spend a few days and take it for a spin!
Here’s the TLDR, if you are testing EDR on Linux you don’t have to care about any of these:
When you are testing something you want to make sure that your test cases are representative of reality and complex enough. You don’t want your whole scenario detected because of a simple file hash in the beginning, but you also want to avoid concluding that a product is useless because they got unlucky and did not detect your single variant.
If you test EDRs, you ideally set up a realistic baseline environment, and go through each step in the
kill chainor tactic in MITRE ATT&CKand for every single stage you have different versions of the same steps each with different level of evasion sophistication.
Clearly, this leads to a huge combination and a tremendous amount of work. So you start cutting some of that complexity.
You can leave out some steps or some levels of sophistication. The problem is that either you ran out of time because you cut the wrong place and you end up concluding the tool is better than it is or you get to the limits of the product and in the end, your self-criticism, or the inevitable pushback from the providers, will remind you: maybe the reason why things did not get detect is that the scenarios were not realistic enough.
There are good arguments for this: reverse shell is not malicious by itself; the thing you did is not a technique that is actually used out there in the wild and detections on real behavior. These are fair points, so now you are stuck. You have to sink quite some more time into further testing or take the arguments at face value.
You can cut out a lot of complexity based on the observation we learned the hard way in our tests. If you expect the external challenge to your results I’m also giving you a simple test case that addresses most of the arguments you are going to encounter.
The test scenario is the following: Attackers publish and backdoored NPM package which is your dependency. The package uses a malicious preinstall script to download and run a script that drops a backdoors that establish communication to common open source C2 frameworks.
The scenario does happen in reality: packages
I also added a vulnerable VM set up with Vagrant that includes a number of ways to escalate privileges so that you don’t have to care about that either.
Good luck with your tests!
Special thanks to Andras, Keith, Marcus, Mark, and Zsolt for the help and guidance on the way, which allowed me to summarise quite extensive research for you and to distill a lot of the technical work in the simplest scenario that you can use for testing EDRs yourself.
Also published here.