After making rcrypt public it almost immediately became detected. This is not surprising as when something like this becomes more public it will also become detected. Whats important to realize is rcrypt 1.4, being the current released version, is detected but the in progress (fully functional) 1.5 remains undetected.
Now does this mean I will rush out and release 1.5? Well not exactly. I want to make clear the types of detection there are and the kinds of things you can do about it. There seems to be no end to incorrect information and lack of understanding so I am hoping to address at least some of that now.
There are two primary methods of detecting binaries employed by AVs.
- signature detection
- dynamic detection
The first method is the oldest and least useful. It requires the ability to detect known static patterns in a binary to function. The second one however is far more powerful.
Signature detection is barely more technical than grepping for byte sequences. Perhaps more advanced types have a sort of error tolerance but otherwise this is trivially bypassed by slight modifications in code.
Dynamic detection completely defeats code modification because this form of detection simply executes binaries in a sandbox and observes behavior. This is the important part that I think people don’t seem to understand.
When people try to evade AVs I see techniques employed such as:
- leetsauce METASM ninja
- leetsauce polymorphic stuff
- and more recently leetsauce shellcode injection into random PEs
These techniques are ALL excellent however they all bypass signature detection ONLY. They are absolutely useless against sandbox analysis. Anytime I read somewhere techniques for making msf payloads or random other payloads undetected I see people talk about projects that will, in a nutshell, modify their shellcode in some way.
I’m not knocking any of these techniques as they are all interesting and do something cool. However they don’t address the goal of evading the two main AV detection mechanisms. Another thing I’ve noticed, and I could be wrong, is that these techniques and tools don’t work on binaries at all. They only work on shellcode. This, for me, is useless.
The aim of rcrypt is to show how sandbox analysis can be defeated by, in this case, timing out the analysis engine. So how, you ask, is 1.4 detected? Seeing as how it completely defeats the strongest method of detection, sandbox analysis, it means that the detection is merely a signature match. Which means changing 1 or 2 bytes is all thats necessary to evade this weak detection (nice job KAV). The fact that 1.5 without any changes defeats this shows that the detection is quite weak and trivial to evade.
I won’t go into just how to perform these modifications as I trust that if you understand you can perform these modifications yourself. The fact is that rcrypt has, as of now, completely defeated the strong detection option and evading trivial signature matches is simply a function of swapping bytes around.