This blog post is mostly a copy/paste from two talks I recently gave at the security conferences BotConf 2025 and DEF CON (Malware Village). You can find the original slides here along with more detailed information.

Disclaimer: I used an LLM to generate some of this blog post, but the original slides were written entirely by me 😉

Sandbox Evasion and anti-analysis techniques in malware are surely not new. But every once in a while, I run across a malware sample or family that just.. well.. boggles the mind. In this case, it’s DBatLoader. In this post, we’ll talk about DBatLoader’s strange design decisions: How it works, what makes it distinctive, and what defenders can do about it.

What is DBatLoader?

DBatLoader goes by a few different alternative names, including NatsoLoader and ModiLoader. It is primarily a loader/downloader: its job is to fetch and deploy other malware (RATs, stealers, etc.). Some examples of payloads it delivers are Remcos, AveMaria, Formbook/XLoader.
 DBatLoader uses multi-stage infection chains, such as:

LNK File → Embedded PowerShell → DBatLoader


JavaScript File → Embedded BAT script → DBatLoader


The DBatLoader payloads are often stored on legitimate cloud services (OneDrive, Google Drive, sometimes Discord), which helps it hide or avoid suspicion.

Anti-Sandbox Tricks Up It’s Sleeve

Here are several of the more interesting (and messy) techniques that DBatLoader pulls off to try to detect, frustrate or overwhelm sandbox environments:

Evasion Technique	Why It Helps (or Doesn’t)
The malware tries to allocate multiple large chunks of memory (in the order of ~500 MB or more), more than many sandboxes can comfortably provide. If the sandbox lacks enough RAM, the payload isn’t executed and the malware fails to detonate.	If the sandbox can’t fulfill the request, the malware might detect something’s wrong, possibly abort or delay. But large allocations are noisy and may themselves raise flags.
Attempts to change memory protection on addresses it doesn’t necessarily have permission to. This often causes PAGE_NOACCESS errors.	It’s a kind of stress‑test: if the sandbox is strict, these operations will error. The malware might observe the behavior and change its execution path (e.g. stop or not reveal full payload).
If direct memory protection changes fail, DBatLoader tries writes to and free memory it doesn’t fully own. This leads to access violations or “partial copy” errors.	These errors may disrupt sandbox detonation or detection tools; or the malware may decide to abort in the presence of certain behaviors, avoiding giving a full behavior trace to the sandbox, similarly to the above technique.
AMSI (the Anti‑Malware Scan Interface) is a Windows component that lets code analysis tools scan scripts or code at runtime. Malware often tries to patch (disable) AMSI to avoid detection. DBatLoader does this, but in a sloppy way. Some pointer references or the method of patching are wrong, so it doesn’t work as designed.	It’s not fully clear why DBatLoader uses this flawed AMSI patching technique. It begs the question: Is this a bug or feature? I suspect it’s intentionally trying to be noisy to trigger anti-malware and EDR to detect the loader. If the loader is detected early-on in the attack chain, it will surely disrupt the attack, but will protect the payload (and the payload’s C2 addresses and other IOC’s). More on this below.

Design Choices: Why “YOLO” Over Stealth?

Rather than being subtle, DBatLoader takes an aggressive posture: lots of junk code, lots of large, risky memory operations, etc. But Why? Here are my theories:

Sandbox smashing: The malware seems more interested in physically denying the sandbox a chance to observe, rather than going undetected.

Detect & Abort: If something in the environment doesn’t match what it expects (e.g. low memory, missing permissions), DBatLoader likely will not execute fully (or at all). Better to evade being fully analyzed than be caught in full operation.


Intentional Detection: In an enterprise environment, DBatLoader wants to be detected as quickly as possible. But why would it wish to achieve this goal? If anti-malware or EDR detects the loader stage, the payload that DBLoader is trying to deliver will not be executed, thus protecting the payload and its valuable C2 addresses and other potential IOC’s. Why risk burning a C2 when the loader is detected anyway?

How Defenders Can Respond

Even though DBatLoader’s tactics are somewhat brute‑force, there are multiple points where defenders (sandbox architects, malware analysts, endpoint security) can fight back:

1. Monitor / hook memory APIs
   • Watch for calls like NtAllocateVirtualMemory, NtProtectVirtualMemory, NtWriteVirtualMemory. Large allocations or unusual protection changes should raise alerts.

   • If sandbox or detection systems stub, hook, or limit those calls, they can interfere with DBatLoader’s attempts.

2. Observe failed operations
   • For example, if memory protection changes fail or access violations are frequent, that suggests attempts to do invalid or unauthorized memory operations.

   • These errors themselves can be a clue.

3. Strengthen AMSI implementation
   • Ensure AMSI patching attempts are more difficult, or monitor code that attempts to locate/modify AMSI functions.

4. Resource constraints / threshold detection
   • Have reasonable resource quotas in sandbox: e.g. limit memory, but monitor when malware tries to allocate more.

   • Compare expected behavior: many real benign applications don’t try to allocate huge amounts of memory at startup.

5. Behavioural signatures
   • Because DBatLoader uses multi-stage loaders, with intermediary BAT, JS, PowerShell, etc., guard at multiple layers (e.g. flag suspicious .lnk → PS chains, cloud storage download of payloads).