So I'm fairly new to security research, not sure if EDR developers are typically friendly to research aiming to break into their product, but I do think it's ultimately a good thing for this kind of thing to be done, especially when it's published for all to learn from / respond to rather than quietly developed to be abused for cyber crime. After doing this I'll definitely share a write-up of the results, maybe even privately with the contributors here if possible ahead of a public paper.
Some questions I want to answer:
Could an open source project implement edge of the art payload anti-detection tradecraft in such a way to allow any non-sophisticated threat actor to leverage it easily?
Can publicly available endpoint threat detection tools (i.e. not custom tools or private tech for defense contractors / nation-states) deal with edge of the art payload anti-detection tradecraft effectively? Even get close?
If not, could we make an open-source tool (or improve one, for example this one) to be good enough to do that?
If we can demonstrate 1 to be true and 2 to be false (by defeating all the publicly available EDRs), then it would be really important to answer 3 (preferably in the affirmative).
I decided to start out testing against OpenEDR, since the source being available should make it the easiest tool to build a testing pipeline for. Some things I intend to test against this EDR:
A new (maybe?) form of binary obfuscation. At least I haven't seen any literature on it, but I find relevant research I hadn't seen before every day, so who knows.
Avoiding common OS API and standard lib hooks by importing obfuscated fresh copies of those libraries
Using uncertainty in jump destinations to prevent behavior analysis outside of the intended target environment (evasion)
If Event Tracing for Windows is being leveraged, I'll be testing some defeat methods (see last few paragraphs on that post) against that.
To get really close to what I think might be the edge of the art in this problem-space, Windows does expose some built-in kernel hooking APIs which seem most useful (short of hooks injected via direct kernel patching, which Windows has long since prevented from happening) and if this EDR is using them, I'll be researching some ways to defeat those.
And if anyone close to the project's development would be willing to have discussion on some of the low-level advanced concepts involved, maybe exchange some back-and-forths on penetration approaches, perhaps we could all learn something.
The links above all point to posts by my reddit account, so it shouldn't be hard to get in touch if anyone likes, or else I'd be happy to have some discussion here openly within this issue. Basically for now I'm just hoping to learn about the core components of the EDR and sort of where this tool stands between 'state-of' and 'edge-of' the art against the various defeat methods I'm interested in testing. It would save me a lot of time to have that dialogue.
Hook evasion research: A little more on my research and why I say kernel hooks are most useful; It's just because of the way evasion (due to the existence of dynamic jump destinations based on conditions fundamentally uncertain to the defender combined with the variable-length nature of the x86 instruction set) makes it impossible for endpoint defense products to reliably predict what a program will do. The true control flow is fundamentally unknown. But in order to create an effect, the attacker must interface with the hardware or other processes in some way, which it must ask the kernel for permission to do (system calls). By 'hooking' (redirecting control flow to intermediately executed security subroutines) any calls to the kernel, the defender can gain valuable insight into the behavior of the program when it executes on its intended target, despite evasive behavior, and potentially recognize / stop the threat. So as the attacker, we really need to avoid these kernel hooks. Windows actually really hurts the defender here by forcing its own implementation of this (here's an example of this for filesystem interaction), so by exploiting this single implementation, every single endpoint security product which leverages Windows kernel hooks can potentially be subverted.
Binary obfuscation research: So right now I would say most attacks don't involve great obfuscation. Some of the best source code obfuscation tools out there (like Tigress) are aimed at preventing reverse engineering (because that's where the money is) moreso than avoiding detection, resulting in very recognizable control flow graph patterns and well, binary obfuscation is hard. But binary obfuscation is much more powerful, and it is likely possible to innovate in this space, through the approach I mentioned previously and others. Even where we might struggle to evade certain kernel-level system call hooks, we can add noise to this analysis channel. This could fool some signatures based on analyzing system call sequences, although other heuristic based signatures might not be fooled, hence the importance of the previous bullet for attacking those more robust defenses by evading the hooks themselves. Still other signature metrics exist beyond system call sequences, to include resource usage patterns, register activity patterns, and so on, all of which an EDR endpoint sensor might seek to analyze.
But this list will probably double in size as I probe the EDR and see what mechanisms and detection strategies are used. I'll comment on this thread as I find potential attack vectors against the tool and better understand its inner workings, and seek further discussion with anyone interested in this. As I said, I'm no veteran researcher and I surely have much to learn on the topic. Thanks ahead of time for any advice or insight given!
So I'm fairly new to security research, not sure if EDR developers are typically friendly to research aiming to break into their product, but I do think it's ultimately a good thing for this kind of thing to be done, especially when it's published for all to learn from / respond to rather than quietly developed to be abused for cyber crime. After doing this I'll definitely share a write-up of the results, maybe even privately with the contributors here if possible ahead of a public paper.
Some questions I want to answer:
If we can demonstrate
1to be true and2to be false (by defeating all the publicly available EDRs), then it would be really important to answer3(preferably in the affirmative).I decided to start out testing against OpenEDR, since the source being available should make it the easiest tool to build a testing pipeline for. Some things I intend to test against this EDR:
And if anyone close to the project's development would be willing to have discussion on some of the low-level advanced concepts involved, maybe exchange some back-and-forths on penetration approaches, perhaps we could all learn something.
The links above all point to posts by my reddit account, so it shouldn't be hard to get in touch if anyone likes, or else I'd be happy to have some discussion here openly within this issue. Basically for now I'm just hoping to learn about the core components of the EDR and sort of where this tool stands between 'state-of' and 'edge-of' the art against the various defeat methods I'm interested in testing. It would save me a lot of time to have that dialogue.
Hook evasion research: A little more on my research and why I say kernel hooks are most useful; It's just because of the way evasion (due to the existence of dynamic jump destinations based on conditions fundamentally uncertain to the defender combined with the variable-length nature of the x86 instruction set) makes it impossible for endpoint defense products to reliably predict what a program will do. The true control flow is fundamentally unknown. But in order to create an effect, the attacker must interface with the hardware or other processes in some way, which it must ask the kernel for permission to do (system calls). By 'hooking' (redirecting control flow to intermediately executed security subroutines) any calls to the kernel, the defender can gain valuable insight into the behavior of the program when it executes on its intended target, despite evasive behavior, and potentially recognize / stop the threat. So as the attacker, we really need to avoid these kernel hooks. Windows actually really hurts the defender here by forcing its own implementation of this (here's an example of this for filesystem interaction), so by exploiting this single implementation, every single endpoint security product which leverages Windows kernel hooks can potentially be subverted.
Binary obfuscation research: So right now I would say most attacks don't involve great obfuscation. Some of the best source code obfuscation tools out there (like Tigress) are aimed at preventing reverse engineering (because that's where the money is) moreso than avoiding detection, resulting in very recognizable control flow graph patterns and well, binary obfuscation is hard. But binary obfuscation is much more powerful, and it is likely possible to innovate in this space, through the approach I mentioned previously and others. Even where we might struggle to evade certain kernel-level system call hooks, we can add noise to this analysis channel. This could fool some signatures based on analyzing system call sequences, although other heuristic based signatures might not be fooled, hence the importance of the previous bullet for attacking those more robust defenses by evading the hooks themselves. Still other signature metrics exist beyond system call sequences, to include resource usage patterns, register activity patterns, and so on, all of which an EDR endpoint sensor might seek to analyze.
But this list will probably double in size as I probe the EDR and see what mechanisms and detection strategies are used. I'll comment on this thread as I find potential attack vectors against the tool and better understand its inner workings, and seek further discussion with anyone interested in this. As I said, I'm no veteran researcher and I surely have much to learn on the topic. Thanks ahead of time for any advice or insight given!