Securing Tomorrow: Defeating Antivirus Detection - अर्धजीवित/Zombie Bypass Technique

Hey there, this is a DOOMs day edition of my tale, where I recount my victory over the major antivirus vendors. Behold as I reveal the recipe for lowering the payload detection rate.

TL;DR

• Old AV evasion tricks ("zombies") like the strip command and UPX packing still significantly drop detection counts on commodity AV engines.
• Without touching InjectProc.exe source, stripping symbols and packing with UPX dropped detections from 11/26 to 1/26 in our test bench.
• AV vendors keep their signature focus on the latest in-the-wild trends, leaving older bypasses underweighted, that gap is the bypass.
• Defenders should not assume packed/stripped binaries are benign just because no signature fires; weight entropy, packer indicators, and behavior at runtime.

Background

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 was widely used in the AV evasion community. I had no idea at the time that this technique would be something I'd 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. Past 2018, strip seems to have lost its significance after being adopted by many frameworks (such as Phantom Evasion). Before we revisit it, let's first understand its purpose and significance.

What the "Strip"?

In the land of programming, there is a powerful command known as strip. It is used to strip away symbols and debugging information from compiled executable files, which are stored in a data structure called the Symbol Table. What is a Symbol Table? It is a section inside the PE header used by the compiler at compile time to organise and store information about the symbols in a program. In short:

The symbol table contains data stored in an object file that 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

The data may include relocation information, scope of the symbol, symbol name, memory location, and so on. 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 used strip to create undetectable payloads.

Fast forward to 2022

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.

Over the years, AV vendors 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 complexity and is a fierce battle out there, believe me.

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 code in another process. For a deeper dive into process injection from the loader side, see Pwning the EDRs for Initial Access Part 1.

Pre-compiled InjectProc.exe

As expected, since this binary is freely available on the internet, there are detections in place. When we scanned the binary on this test bench, we got the expected result: 11 out of 26 antivirus products marked 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 a simple strings command on the binary revealed evident reasons for why it was flagged as malicious:

I knew the easiest way to evade detection and continue using the program would be to recompile the binary with obfuscated strings, encryption, and use direct or indirect syscalls to load shellcode 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 ever 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 to 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 relies only on static analysis. Other detection techniques, such as API hooking and dynamic analysis using sandboxes, have come into play and raised the bar for detection.

To cope with such techniques, malware authors and TAs are always changing their tactics, and in response, security software like EDRs and AVs is constantly updating its detection methods.

An interesting thing to note here is that these detections primarily focus on the most recent malware trends in the wild. With new bypasses and techniques coming out now and then, this kind of overrides the thrust of AV vendors to look more aggressively at previous bypasses used by malware in older campaigns. (For a related, by-design SmartScreen evasion that abuses the same "older signal, lower priority" gap, see BYOR.)

With that school of thought, I decided to revive this bypass that had been dead for a long time, the strip command. If I am right in my assumptions, there is a high probability that removing symbol data from the symbol table, as discussed previously, can be a useful way to evade detection by antivirus engines. Let's apply this technique to InjectProc.exe and see how things work out.

The command and flags used for removing the necessary symbols are:

Applying CLI arguments for stripping InjectProc symbol table information

• -U: Removes all local symbols (i.e. symbols that are not externally visible).
• --strip-all: Removes all symbols, including external symbols.
• --strip-debug: Removes debugging information.
• --strip-dwo: Removes debug information in DWARF Object (DWARF is a standard for debugging information).
• --strip-unneeded: Removes all symbols that are not needed for linking.
• -X: Do not preserve any symbols listed in a file specified by the --keep-symbols option.
• -x: Removes all local symbols, including static functions and variables.

After running the strip command, let's put our stripped InjectProc binary to the test by scanning it on Antiscan.me and checking for known detections.

Detection (4/26) by major Antivirus

To my surprise, the detection rate fell from 11/26 to 4/26 after a simple strip command. This proves that Zombie Bypasses are effective, and now I took on the challenge of reducing it further, again without fiddling with the source code.

The strip command appears to have made progress in reducing the detection rate for Bitdefender, BullGuard, Emsisoft, and others. But MalwareBytes, F-Secure, and a few others were still able to detect malicious activity in our InjectProc.exe through techniques such as signature scanning, heuristics, and sandboxing. The results are promising, but I felt I could push this zombie bypass even further and outperform major vendors like MalwareBytes. That meant reviving another zombie.

It's time to call UPX

The most trivial technique I thought of was using UPX (Ultimate Packer for eXecutables) compression as a zombie bypass.

UPX is the OG packer tool and inspired many malware authors to create more advanced PE packers.

A basic utility of UPX is changing the hash of a binary without changing its functionality.

Additionally, UPX reduces the size of a file by removing redundant information and replacing it with a compressed version. This can make it harder for a reverse engineer to analyse the code and data, as the compressed version may be more difficult to read.

Pro Tip: UPX compression may sometimes increase detection due to the increase in entropy of a PE. It's still worth 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. The smaller the payload, the less time and lower chance of detection 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

Our zombie UPX compression effectively hindered detection from MalwareBytes and F-Secure, reducing the detection rate to 1/26. Only Windows Defender withstood the zombie bypass. Every other commercial AV did not find this binary malicious enough for detection.

This is what I wanted to establish: we dropped the detection to 1/26 without fiddling with the source code itself and fooled almost all the commercial AV vendors in our AV test bench.

Conclusion

This experiment is a step towards victory in the battle against AV technology with 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.

In this article, we have demonstrated how zombie techniques that use strip and UPX compression (two widely abused commands) can be useful for reducing the detection rate of antivirus software. By applying these methods to a Portable Executable (PE), we were able to lower the detection rate from 11/26 to just 1/26.

It is important to note that AV software is constantly evolving and improving, and these techniques may not always be successful. They have their own limitations: the strip + UPX zombie combination does not work well with managed binaries where the CLR is involved, and detection results vary across binaries.

Despite all of this, strip and UPX compression can be effective tools for lowering detection rates in certain cases.

Defender Takeaways

• Track Authenticode + entropy together. A high-entropy unsigned PE freshly written to disk and immediately executed is a strong runtime signal even if no static signature fires.
• Hunt for telltale UPX section names (UPX0, UPX1) or generic packer indicators in EDR file telemetry, particularly on initial access binaries.
• Don't trust "AV did not flag it" as clean; layer behavioral detection on process injection primitives (CreateRemoteThread, NtMapViewOfSection, WriteProcessMemory) regardless of static verdict.
• Sample older bypass families during purple-team exercises. Vendors deprioritize older tradecraft, so re-test stripped/packed variants of known offensive tooling against your stack.
• For managed (.NET/CLR) workloads, lean on AMSI and CLR ETW providers since strip/UPX zombies are weaker against them.

MITRE ATT&CK Mapping

Technique	Name	Where it appears in this post
T1027.002	Obfuscated Files or Information: Software Packing	UPX compression of the InjectProc binary
T1027	Obfuscated Files or Information	Symbol stripping to remove static-analysis breadcrumbs
T1140	Deobfuscate/Decode Files or Information	UPX self-decompression at runtime
T1055	Process Injection	The underlying behavior of the InjectProc binary being evaded for

Final Words

This is a POC which proves that bypasses, like history, repeat themselves.

Thank you for reading. 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/