kevoreilly
commented
1 month ago Hello and thanks for the feedback. Reading your story I can understand your frustration. However, it's a bit unfair to describe this entire list as things that "detect CAPEv2". CAPE is a usermode sandbox that runs on a multitude of hypervisors as well as bare metal.
[Fri Oct 4 07:54:26 2024] [*] Checking if CPU hypervisor field is set using cpuid(0x1) -> 0Things like the hypervisor bit are really nothing to do with CAPE and all to do with virtual machine setup. This bit is not detected in my vms for example, and we do a lot to try and encourage good vm setup (for example https://www.doomedraven.com/2016/05/kvm.html mentions how to hide the hypervisor bit) but this is down to the user and hypervisor, and not something that CAPE should be blamed for. You didn't even mention which hypervisor you are using, nor how it was set up.
I hear your suggestion to 'mitigate the various techniques, not the function that shows the results'. But if we take the previous example of the hypervisor bit, as a usermode sandbox it's not possible to directly mitigate the output from the processor's CPUID instruction. The only way a usermode sandbox could reasonably be expected to help hide this from malware is by interfering with the result of the test. At least this is something!
There aren't many options for a usermode sandbox to hide this technique from a malware sample, but fortunately CAPE does have a unique and powerful debugger which is very stealthy and can be dynamically programmed during detonation by yara signature to set breakpoints on code and dynamically perform actions such as control flow manipulation. So it can, for example, break on the CPUID instruction and emulate it, or break after and modify the register values.
This is one of CAPE's greatest assets but a huge challenge for the project is making this capability well known and accessible to the end user. One of the only ways I have to try and 'sell' this capability is to demonstrate it by creating an array of yara signatures to show off its power whilst also making CAPE perform as well as possible against as much evasive malware and tests as possible. It's in this vein that I have also created dynamic bypasses for tools such as Pafish and Al-khaser.
So that is why this bypass for Al-khaser exists, of course its objective is to demonstrate how to bypass detection in the simplest way possible. It turns out there is a single function which evaluates (and prints) results so rather than bypassing individual tests it just targets the simplest intervention. It could of course put breakpoints on individual tests and subvert their results one by one, but that would be inefficient.
Did you notice that the Al-khaser debugger detection tests all failed? When you describe this bypass as merely a 'custom rule' that changes the results I think that does it a massive disservice, as if it were somehow fudging the results rather than demonstrating a powerful capability. During detonation, cape's monitor dynamically scans memory, detects a code sequence and programs the debugger to set a breakpoint on a specific instruction. The breakpoint is set and execution proceeds to sail through all Al-khaser's anti-debugger tests, hitting the breakpoint for every failed test and actively switching the results.
Really any intervention performed by cape, whether by debugger or API hooks, could be described as being misleading. For example, there are numerous anti-evasion techniques performed by API hooks such as hiding the number of processors/cores by modifying the results of API calls. Would you describe these too as 'custom rules that change the results'? Because really this boils down to the same thing, and other techniques or APIs might see through these interventions. Other examples worth considering are yara signatures that generically detect techniques, such as Syscall.yar which tries to detect variants of direct syscalls and capture them. If this signature worked against Al-khaser and avoided a syscall check, would it be misleading? Perhaps as it is more generic, not detecting a particular tool or malware family, it would be viewed as fair enough and better than nothing. If it then missed malware using a different variant of the same technique, it might then be accused of being misleading - seems like an impossible situation.
Perhaps we should make even more effort in documenting virtual machine setup by mentioning the presence of not just this capability in cape, but also the presence of the existing dynamic evasion bypasses as well, in case users to wish to use things like Al-khaser to assess the evasion capabilities. I will look at adding a note to the documentation somewhere that to test CAPE stripped of its inbuilt evasion bypasses, running with yarascan=0 might be worth trying. But since this bypass is a demonstration of (and part of) one of cape's greatest strengths, on balance I don't think it should just be binned.
packmad
doomedraven
YungBinary
Dear developers, First of all, thank you for your open product, which we (our team and I) use for our research projects.
When we first installed CAPE, one of the first tests we did was to run Al-khaser to get an idea of the techniques that were not mitigated (then possibly counteract the code to give the blue pills). However, as all evasion techniques were mitigated, we proceeded happily :)
Today we discovered that there is a custom rule for Al-khaser's print function that changes all results! This rule introduces a huge flaw in CAPE's evaluation, and we believe it should be removed. The purpose of Al-khaser is precisely to test the evasion capabilities of sandboxes, and this rule does not allow it to do this properly.
Instead (and we will try to help with this by pushing new rules), you should try to mitigate the various techniques, not the function that shows the results.
This is the list of the evasive techniques that detect CAPEv2