Hey there, I bring to you a DOOMs day edition of my tale, in which I recount my epic victory over the major antivirus vendors. Behold as I reveal the secret to lowering the payload detection rate and emerge victorious!
As the number of devices connected to the internet grew, so did the risk of malware and ransomware attacks. This led to the development of antivirus and other security solutions to protect against these advanced threats.
It all goes back to 2018, when I was beginning to understand the importance of antivirus bypass techniques. As a self-proclaimed cyber ninja, I was intrigued by the idea of sneaking past antivirus detection. I was determined to master this art and during my training, I stumbled upon a technique that seemed simple and widely used in AV evasion community and I had no idea at the time that this technique would be something I would revisit so many years later. It was the strip command — a stealthy way to evade detection from major antivirus vendors without even altering the Portable Executable (PE) source code. But before we delve into the workings of strip command which past 2018 seems to have lost it’s significance in the AV Bypass techniques after being utilised by many frameworks in 2018, such as phantom evasion, let’s first understand it’s purpose and significance.
In the land of programming, there is a powerful command known as strip. This is used to strip away symbols and debugging information from compiled executable files, that are stored in a mysterious data structure called Symbol Table. Now you may ask what is a Symbol Table ? Well, It is a mighty section inside of PE header wielded by the compiler at the compile time of the code. This is used to organise and store information about the symbols in a program. In short —
Symbol table contains data that is stored in an object file which is used by the linker to resolve symbols (names and addresses of functions and variables) when the object file is linked with other object files to create an executable program (.exe)
Symbol Table information inflow/outflow
These symbols data may include — relocation information, scope of the symbol, symbol name, memory location etc. Stripping these symbols might not seem like a big deal, but it actually makes debugging and reverse engineering PE files much more difficult. Tools such as Phantom-evasion was using strip to create undetectable payloads.
The internet is now crawling with even more connected systems and the malware lurking within has only gotten more sophisticated, covert and harder to detect.
And, over the years, Antivirus have introduced a variety of detections to try and catch wicked AV Bypass frameworks like Phantom-Evasion and many others, with the help of signature scanning, heuristics, sandboxing, and other methods such as checking memory artifacts or detecting windows APIs. Escaping detection now involves a lot of complexities and is a fierce battle out there, believe me.
So, one day I was analysing the detection rate for the pre-built binary called InjectProc.exe (GitHub — secrary/InjectProc) on Antiscan.me — It’s a sly little program that uses various process injection techniques to run malicious code on the system.
Pre compiled InjectProc.exe
As expected, since this binary is freely available on the internet, there are detections in place. When we scanned this binary onto this test bench, we got a quite expected result: 11 out of 26 antivirus products were able to mark it as malicious.
Detection (11/26) by major Antivirus
As I began my analysis on InjectProc.exe, to determine the cause of its widespread detection, it was unsurprising that the simple strings command on the binary revealed some evident reasons for why it was flagged as malicious —
I now knew that the easiest way to evade detection and continue using the program would be to recompile binary with obfuscated strings, encryption, and use direct or indirect syscalls to load up the shellcodes in the process. But I wanted to do things differently this time and I challenged myself to see if I could lower the detection rate from 11/26 without even touching the code base responsible for detection.
This is where the Zombie bypasses came to life.
Remember the strip command I told you about ? It used to work like a charm up till 2019 but it seems to have lost its battle with AV.
One possible reason for strip losing its relevance is that malware analysis no longer extensively relies only on static analysis. Other detection techniques, such as API hooking and dynamic analysis using sandboxes, have also come into play, raising the bar for detection.
To cope with such techniques, its evident that malware authors and TAs are always changing their tactics, and in response, security software like EDRs and AVs are constantly updating their detection methods.
An interesting thing to address here is that these detections primarily focus on detecting the most recent malware trends that are in the wild. With new bypasses and techniques coming out now and then, it kind of overrides the thrust of AV vendors to look more aggressively at previous bypasses used by malware in older campaigns.
With that school of thought, I decided to revive this bypass, which had been dead for a long time, the strip command. If I am right in my assumptions, there is a high probability that removing symbols data from the symbol table, as discussed previously, can be a useful way to evade detection by antiviruses. Let’s apply this technique to InjectProc.exe and see how things work out.
The command and flags which are used for removing the necessary symbols are —
Applying CLI arguments for stripping InjectProc Symbol table information
After running the strip command, lets now put our stripped InjecProc binary to the test by scanning it on Antiscan.me and checking for any known detections. Let’s see if it lives up to our claims! —
Detection (4/26) by major Antivirus
To my surprise, the detection rate unexpectedly fell from 11/26 to 4 out of 26 after we used a simple strip command. How can this be even possible, right? Well, this proves something to us and i.e., Zombie Bypasses are effective, and now I took the challenge to reduce it even further,that too without fiddling with the source code.
The strip command appears to have made some progress in reducing the detection rate for Bitfender, BullGuard, Emisoft etc. But it seems that MalwareBytes, F-Secure and few others were still able to detect malicious activity in our InjectProc.exe through techniques such as signature scanning, heuristics, sandboxing and other methods. Although the results are promising, I feel that I can push this zombie bypass technique even further and potentially outperform major vendors like MalwareBytes. This potentially means I need to revive another zombie this time.
The most trivial technique that I thought of was using UPX (Ultimate Packer for eXecutables) compression as a zombie bypass this time.
UPX is kind of an OG packer tool which inspired many malware authors to create more advanced PE packers.
A basic utility of UPX could be to change the hash of binary without changing the functionality.
Additionally UPX reduces the size of a file by removing unnecessary or redundant information and replacing it with a compressed version. This can make it harder for a reverse engineer to analyse the code and data in the file, as the compressed version may be more difficult to read or understand.
Pro Tip : It is important to note that UPX compression may some times also increase the detection due to the increase in the Entropy of a PE. But it is definitely worth the try to give it a shot.
UPX compression on stripped InjectProc.exe
Thanks to UPX compression, the size of our stripped version of InjectProc.exe has been dramatically reduced, almost by half! This is great, because the smaller the payload size, the less time with lesser chance of detection ,it will cause when it gets loaded into a target system (Like a stealthy ninja, slipping in and out without causing a fuss)
Let’s test the detection rate of this updated file[strip + upx] by uploading it to Antiscan.me —
Detection (1/26) from major Antivirus softwares
Yasss, our zombie UPX compression has effectively hindered the detection from MalwareBytes and F-Secure, reducing the detection rate to 1 out of 26 . This outcome is very surprising to me, and only Windows Defender was able to withstand against this zombie bypass. Every other commercial AV sadly was not able to find this binary malicious enough for detection.
This is what i wanted to establish. We finally dropped the detection to 1/26 without even fiddling with the source code itself and were able to fool almost all the commercial AV vendors in our AV test bench.
In a real-world scenario, this experiment is a step towards victory in the battle against AV technology with such zombie bypasses that used to live a few years ago.It’s time to bring them back to life and see if we can conquer this challenge once and for all!
In this article, we have demonstrated how zombie techniques that use strip and UPX compression (two of the widely abused commands) can be useful for reducing the detection rate from antivirus software.
By applying these methods to a Portable Executable(PE), we were able to significantly lower the detection rate from 11 out of 26 to just 1 out of 26.
However, it is important to note that antivirus software is constantly evolving and improving, and these techniques may not always be successful. They also have their own limitations, such as the fact that the “strip+UPX zombie combination” does not work well with managed binaries where the CLR is involved, and the detection results may vary for different binaries.
Despite all of this, it is now proven that strip and UPX compression can be effective tools for lowering detection rates in certain cases.
This is just a POC which again proves that “bypasses and history repeats itself”
Thank you for reading this. If you like this post, you can follow me on these platforms:
Twitter : https://twitter.com/ihackstuffs
LinkedIn: https://in.linkedin.com/in/nikhilcyber
Udemy: https://www.udemy.com/user/pivot-security/
