This blog is not here to give you a “step-by-step recipe.” It’s here to open your mind – to challenge how you think about Red Teaming, malware analysis, and how both can work together. If you’ve read my book Antivirus Bypass Techniques and the upcoming book of MAoS – Malware Analysis on Steroids, you already know and will know that I like to mix technical depth with perspective. This is one of those cases.
Why Red Teams Should Learn Malware Analysis
Malware analysis is the process of studying malicious software to understand what it does, how it does it, and why.
In practice, this usually means:
- Automated analysis – Running a sample in a sandbox for quick IOCs (hashes, domains, IPs).
- Static analysis – Looking at the file structure and code without executing it.
- Dynamic analysis – Running it in a controlled environment to see its real behavior.
- Reverse engineering – Digging into the code itself, disassembly or decompilation, to find the real logic.
Here’s the thing: most real-world attacks rely on malware. If you’re a Red Teamer and you want to simulate a real threat actor, you need to understand how their malware operates. Otherwise, you’re guessing.
Red Teaming – More Than Domain Admin
Getting domain admin is a nice milestone. But that’s not the goal.
The goal is to simulate real-world threats against real targets. And in many cases, those targets are data – not a domain controller. A true Red Team engagement models the tactics, techniques, and procedures (TTPs) of real adversaries. This means knowing how attackers move, what they value, and how they deliver their payloads. Tools like Cobalt Strike or Havoc are useful. But they are tools, not the mission. The mission is realistic simulation, and that means borrowing from the same playbook the adversaries use – malware included.
Why Malware Analysis and Red Teaming Work Together
Attackers learn from each other. They reverse engineer other malware, reuse code, and adapt techniques.
So why shouldn’t Red Teamers do the same?
By studying real-world malware, you can:
- Understand how advanced attacks bypass detection.
- Discover techniques you can re-implement in authorized operations.
- Improve your knowledge of OS internals and security product behavior.
I see it as two sides of the same coin – one side is the analyst’s mindset (Blue), the other is the operator’s mindset (Red).
When you bring them together, you get a clearer, sharper picture of the battlefield.
The Malware Development Lifecycle (MDLC)
Think of it as SDLC for malware:
- Plan and define your goals.
- Develop securely (OPSEC in mind).
- Test and QA.
- Add bypass techniques where needed.
- Test offline against security products.
- Remove IOCs and other telltale signs.
- Collaborate with Threat Intelligence for realistic targeting.
The key point: you don’t have to start from zero. Learn from real incidents and adapt the tactics to your own safe, authorized tools.
A good example: DarkSide Ransomware
It’s not just about the malware and the techniques it applies, but the impact it had on countless lives, privacy, stolen data and even, yes, and even safety. When ransomware like the wreaks havoc and disables big portion of the United State’s gas stations ran by the Colonial Pipeline company, sure thing a malware is not a small child’s play. Having that said, let’s now explore the technical aspects of the original DarkSide ransomware sample and some other bypass techniques.
Technically speaking, DarkSide ransomware used many techniques, and we will focus on the following:
- Runtime code decryption – Encrypted code stored in resources is decrypted in memory just before execution.
- Dynamic API imports – Functions are resolved at runtime, hiding them from static analysis.
In the first glimpse of the PE structure’s Import Address Table, it seems like a very odd thing to have only one import like can be seen in the following screenshot:
Furthermore, while inspecting the sections entropy we can notice that there are two sections of “text” and “text1” which is very odd:
Not only that, but we can also notice that the entropy value of the “text” section is 7.9 which is considered to be packed and\or encrypted in some way while the “text1” section entropy value does not show any packing signs which can lead to the conclusion that an unpacking stub code resides there that aims to decrypt / unpack the code on runtime execution.
If you carefully observed the above screenshot you can see in the left side we have IDA window that shows that actually the unpacking / decryption stub code is actually there. Diving further into the code we can find the XOR-based decryption routine:
After the encrypted code in the “text” section successfully decrypted, another bypass \ evasion technique is applied, the technique of IAT Hashing or what’s called Dynamic API Resolve:
After both above Windows API functions of LoadLibraryA and GetProcAddress used, the following other Windows API functions are finally resolved for the use of the ransomware:
This combination made it harder for security tools to detect and analysts to dissect.
By the way, LockBit ransomware also implemented similar techniques – proof that threat actors actively learn from one another.
An extensive reverse engineering walkthrough of the LockBit ransomware can be watched here:
Example Bypass Techniques I Use
While it is fine and good to re-implement bypass \ evasion techniques from other malware, it is a good idea to test them on your lab both as a red teamer and a blue teamer and even play with some more AV / EPP/ EDR bypass techniques. Here we will be focused on the following:
- Rename Obfuscation – Changing function names and breaking up strings to remove obvious IOCs.
- Memory Bombing – Allocating large chunks of memory to slow or evade dynamic scanning.
We will take a simple CPP based TCP reverse shell to gain full control of the targeted endpoint:
Before applying any bypass techniques, it’s important to compile the code and inspect its content (like strings and assembly Opcodes) that can be potentially detected by endpoint protection solutions like an EDR. After inspecting the compiled PE-exe file, I’ve noticed that CMD present there which can be statically detected by AV \ EDR engines:
Based on the above code, we will apply a simple yet very powerful technique of rename obfuscation. In this case, I’ve decided to use the strcat() function to concatenate two string variables into a single pointer variable in order to pass it to the CreateProcess Windows API function to execute CMD while hiding it from the strings of the PE-exe file:
And this is the results, no strings related to CMD:
Also, to bypass the dynamic engine of endpoint protection solutions like EDR, I choose to use one of my favorite techniques of “Memory Bombing”, In this technique, we instruct our malware to allocate a relatively big chunk of memory to “choke” the dynamic / sandbox engine of the security solution. It seems as simple as something like this:
Applied to a simple reverse shell, these techniques dropped detections from 35 to 13 in VirusTotal. Small changes, big difference
Before the bypass \ evasion techniques were applied:
After the bypass techniques were applied:
Some Personal Suggestions
- Understand your own tools and malware – How they run, how they talk to the OS, how they look on the wire.
- Think like both attacker and defender – This “transcendent thinking” changes how you approach problems.
- Research real malware – Get real-world inspiration for safe, authorized testing.
- Follow the MDLC model – Structure your malware development like any professional project.
- Stay curious and balanced – Keep learning but take breaks to avoid burnout.
By the way, if you want to become a real professional, consider joining our “EDR Internals – Research and Development” live workshop here:
If you approach Red Teaming and malware analysis with an open mind, you’ll see they are not separate worlds. They are connected. Each side has knowledge the other can use. The more you combine them, the closer you get to simulating, and defeating, real adversaries.
“For by wise counsel you shall wage your war, and in a multitude of counselors there is victory.”
(Proverbs 24:6)
Peace.