How File-Based Attacks Land: A Detection Engineer's Field Guide
A practical taxonomy of how malware and phishing arrive as files, why classic controls miss them, and how detection should think.
Files are still the most reliable way past a human. The attackers who keep winning do not rely on clever signatures. They rely on render-time behavior, in-browser assembly, and human trust. Detection has to care about what a file does when it opens, not just what it is called.
I spend my working days staring at inbound attachments and asking one question: what is this file actually going to do? Not what it is called, not what it looks like at the gateway. What it does the moment someone opens it. This guide is the mental model I reach for, written down, so the next person who has to triage a suspicious document has somewhere to start.
Here is the problem in one line. By the time a file reaches a human, every control that inspected it has already lost.
Why is the file still the attacker's favorite delivery?
Because it plays on trust. A link asks the user to leave the inbox and enter a URL. A file asks for nothing except a click, and it can look exactly like the document the user was already expecting.
Most delivery that gets past a human relies on one of three things:
- Render-time behavior. The payload fires when the file is opened or rendered, which happens as far away from the gateway as possible.
- In-browser assembly. The malicious file is rebuilt after inspection, so nothing bad ever crosses the wire in its final form.
- Human reaction. The warning to keep going is one click away, and users are conditioned to click it.
That combination is why filename blocking and static signing keep failing. The file looks fine at the choke point and dangerous at the point of use.
How do the main file attack families work?
There are a small number of repeating families. Learn to name them and you can spot them. The map below shows how a payload is used as a vector: a file arrives, and the danger activates at a specific surface.
For each family below, keep two moments in your head: what the scanner sees, and what actually runs. The gap between them is the whole game, so the interactive section right after the roster shows that gap side by side.
Document macros
The oldest trick in the roster. A .doc or .xls carries VBA that runs when the
document opens and the user enables content. Classic controls look for a known
macro hash or flag any macro at all.
Attackers respond with low-volume, per-target documents. Signatures miss, and the generic "enable content" warning still gets clicked by enough people to make the campaign worth running.
Detection looks at structure. Inspect the OLE or zip layout, extract and review the macros, and run the document in a sandbox that simulates a user enabling content.
Image-only office files
A docx or pptx that contains exactly one embedded image and almost no
extractable text. The attack is a callback or credential phishing page rendered
as a picture. Because the text lives in pixels, body and text scanners find
nothing to flag.
The tell is structural. A well-known community rule looks for a textless Office file with a single embedded image, then pulls the image, reads the text inside it, and extracts the callback URL. This is one of the cleanest examples of detecting the file the way the attacker wrote it.
HTML smuggling
The payload never crosses the wire in its final form. An HTML page or attachment carries the malicious bytes encoded, then reassembles them in the browser using JavaScript Blob APIs and the download attribute.
Because the bytes are encoded text, the gateway inspects something that looks benign. The real file is assembled only when the page renders. Campaigns have nested a double-Base64-encoded ZIP inside an HTML attachment, which adds another layer between inspection and execution.
The encoded blob is usually just base64. If you want to see how little is hiding in there, paste a sample into the Base64 workbench and decode it by hand. Then remember that at scale you need to emulate the script, watch for Blob and download behavior, and follow what gets created.
Container formats and Mark of the Web
Password-protected ZIPs keep their contents invisible to inspection. ISO, VHD,
and LNK files get used because a downloaded disk image is not stamped with Mark
of the Web the way a direct .exe is. The ISO mounts and runs without the block
a downloaded executable would get. OneNote documents have joined the roster too.
The underlying technique is a trust bypass: the container is treated as a local file, so what is inside never inherits the download block. Detection has to inspect inside containers, preserve provenance onto derived files, and watch the mount-and-execute sequence rather than any single artifact.
PDFs and self-rendering attachments
PDFs hide URLs in annotations, form fields, and older JavaScript actions. An attached EML, or an SVG placed inside an iframe, can auto-render in an email client. Delivery needs no click at all.
Detection extracts URLs and embedded actions, and treats client-side rendering as an execution surface instead of a display nicety. If you want to pull one apart yourself, PDF-lite can preview, strip, and extract locally without uploading the file.
AI and LLM payloads
The newest family. Prompt injection gets smuggled into the same files an assistant reads: a PDF, a cached page, an imported document. It is the same delivery model with a different final executor.
Detection treats model-facing content as untrusted input, filters prompt injection the way it filters an executable, and monitors what tools and actions the model is allowed to take.
What does the scanner see versus what actually runs?
This is the part worth slowing down for. Pick a family, look at what crosses the wire, then look at what happens after the file is opened. The payloads here are illustrative and defanged; the real mechanics live in the deep dives.
Office macro
| Item | Qty | Amount |
|---|---|---|
| Consulting | 2 | 4,200 |
| Licence | 1 | 8,000 |
| Support | 3 | 1,500 |
One hidden cell carries the macro; the sheet looks like a normal invoice.
A .xlsm with a vbaProject.bin stream, nothing unusual in the file name or size.
The macro runs on open once the user enables content, then fetches a second stage.
The tell. An unknown macro hash on a low-volume, per-target document, plus the enable-content prompt.
Why do classic controls miss these attacks?
Because they inspect the wrong moment. Static signing and block-by-type look at the bytes at the choke point, when the file is still encoded, still whole, still dormant.
Every family above defeats that by moving the danger to a later moment: render time, browser execution, or a container that is opened after inspection.
The gap is not the file extension. It is the behavior that happens after the file is trusted.
How should detection actually think about files?
Treat the label as a hint, not a verdict. Then combine payload signals with behavior. The pipeline below is the mental model: the file goes in, you render and follow the chain, then you act on behavior. Click each stage for the detail.
Now the concrete moves, step by step.
- Render or emulate the file in a controlled sandbox that clicks the buttons and enables the content a user would.
- Follow the chain. Decode, extract URLs, follow them through DNS and requests, and watch for the download or process that follows.
- Preserve provenance. Carry Mark of the Web and trust signals across containers so a nested file keeps its origin.
- Keep a known-good baseline. Allowlisting known and trusted senders and files cuts false positives so the behavioral signals can be taken seriously.
The winning posture is not a longer blocklist. It is a pipeline that treats every file as a story: where it came from, how it changes when it opens, and where it tries to go.
Where do you start?
Pick the family that maps to the most risk in your environment and start there. For most teams that is the ones that need no deliberate user action: image-only documents, HTML smuggling, containers, and self-rendering attachments.
Stand up the render and follow-the-chain loop first. You will be surprised how much of the stream resolves just by emulating the click.
Is the risk really in the file type?
Mostly not. The risk is in what the file does after it is trusted. The type only narrows down which behavior to watch for.
Does sandboxing catch everything?
No. A sandbox is a strong signal, not a silver bullet. Evasive files detect the sandbox and behave differently, so sandboxing works best alongside behavioral and provenance signals, not alone.
Is prompt injection really a file attack?
It is the same delivery model. The payload travels inside a document or page the model is asked to read, and the trigger is the read itself. Treating read content as input is the secure default.
Test yourself
A quick self-check on the field guide so far. Pick an option to see the answer.
1. Which delivery can need no user click at all?
2. In HTML smuggling, where is the malicious file assembled?
3. What is the structural tell of an image-only Office file?
Where this comes from
I work on file and email threat detection, and this is the model I use when I pick up an inbound attachment. Nothing here depends on a specific product or vendor. It is the shape of the problem as I see it from the triage side, and it holds whether you defend one mailbox or a few million.
Part 1 sets up the map. The rest of the series takes each family one at a time, with a real payload pattern and the detection that works. Part 2 covers HTML smuggling, where the file is built inside the browser after every check has passed. Part 3 moves to macros and image-only Office documents.
If you triage attachments for a living, I would like to hear which family gives your controls the most trouble.
Useful references:
- Phishing, technique T1566 (MITRE ATT&CK)
- HTML Smuggling, sub-technique T1027.006 (MITRE ATT&CK)
- Open-source detection rules for email attacks (Sublime Security)
- Threat research and attack spotlights (Abnormal Intelligence)
- Threat intelligence reports (Mimecast)
- State of the Phish report (Proofpoint)
- Email Threats Report (Barracuda)
- Microsoft Digital Defense Report