On-Disk Evasion

Disguising the File

The file engine is the most mature, most aggressive part of any antivirus. It scans every file the moment it touches disk.

On-disk evasion is the first family of techniques: you accept that your payload lives as a file, and you disguise it so the file engine doesn’t recognize it.


The contrast above frames the whole module. On-disk keeps a file and hides it; in-memory (the next note) removes the file entirely. This note is the on-disk half.


Packers, Obfuscators, Crypters

There are three classic ways to mangle a file past the file engine:

TechniqueWhat it does
Packers (e.g. UPX)Compress and repackage the binary into a new structure with a new hash
ObfuscatorsRewrite the code with equivalent-but-different instructions, dead code, reordered functions
CryptersEncrypt the payload on disk, bundle a small decryption stub that restores it in memory at runtime

Crypters are the strongest of the three. On disk, the payload is just encrypted noise with no matchable signature. It only becomes real in memory, after the stub decrypts it. Encryption is foundational to modern malware.

Packers alone no longer cut it against modern AV. Disguising the file buys time, not invisibility.


Hide in a Real Program

Instead of disguising your file, hide inside someone else’s. Take a real, trusted program and quietly inject your shellcode into it.


Tools like Shellter automate this. You hand it a legitimate, signed installer (a media player, a PDF reader, anything the victim would expect to run), and it:

  1. Analyzes the program’s real execution paths
  2. Injects your shellcode along one of them, reusing the program’s existing imports instead of the obvious inject-API pattern AV watches for
  3. Restores the original flow afterward (stealth mode), so the program still looks and behaves exactly like the real thing

Because it doesn’t add new sections or change memory permissions (the tells AV looks for), a signature scan comes back clean.


The victim runs what looks like a normal installer. The program works normally. And in the background, your payload fires and a session connects back.

You didn’t write a new piece of malware. You hid inside a program AV already trusts. The legitimate code is the disguise.


Don’t Burn Your Own Payload

A subtle but critical operational point that applies to any on-disk file: be careful where you test.


Public multi-scanner services are tempting, “let me just check if my payload is detected.” But many of them, including the most popular one, share every submitted sample with all participating AV vendors.

The moment you upload:

  1. Your sample is distributed to every vendor
  2. They run it through their sandboxes and ML engines
  3. They build a signature for it
  4. Within hours, your payload is dead everywhere

The file’s hash is considered public from the instant of first submission.


So, the testing rules:

  • Prefer private scanners (like AntiScan.Me) that claim not to share samples, or build a VM that mirrors the target’s AV and test locally
  • Disable automatic sample submission on your test box so your own testing doesn’t leak the sample to a vendor’s cloud
  • Prefer custom code. Signatures are built from samples. The more novel your code, the less there is to match
  • Remember the AV isn’t the only watcher. A good EDR can silently alert the SOC and burn you in minutes, even while the AV scan says “clean”

Bypassing the antivirus is not the same as being undetected.


On-disk evasion is a constant race against the file engine. The way to step out of that race entirely is to never write a file at all, which is the next note.


Practice Boxes