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.
Every day, security teams block email by filename and extension. Attackers have moved past that. Whether a campaign targets a finance lead with a PDF or an engineer with a crafted image document, the file is still the fastest route past the human on the other side.
This is the mental model I reach for when I look at an inbound attachment. What is this file really doing? Why might the gateway miss it? And what should detection actually look at instead?
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 only 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. Once you can name them, you can spot them. The map below shows the way a payload is used as a vector: a file arrives, and the danger activates at a specific surface.
Here is the roster I keep coming back to.
Document macros
The oldest trick. 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, so signatures miss and the generic "enable macros" warning still gets clicked by enough people.
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 extracts the image and reads the text in it to pull out a callback URL. This is a great example of detecting the file the way attackers wrote it.
HTML smuggling
The payload never crosses the wire in its final form. An HTML page or attachment carries the malicious bytes encoded and reassembles them in the browser using JavaScript Blob APIs and the download attribute. This is a documented MITRE technique, T1027.006.
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.
Detection needs 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 scanner-invisible contents hidden from inspection.
ISO, VHD, and LNK files get used because a downloaded 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 this
roster too.
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. And an attached EML, or an SVG placed inside an iframe, can auto-render in an email client. That means delivery needs no click at all.
Detection extracts URLs and embedded actions, and treats client-side rendering as an execution surface, not a display nicety.
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.
Before we move on, try this. Pick a file type, see how it lands, then reveal the tell and how detection catches it.
Office macro
How it lands. A .doc or .xls that runs VBA when the user enables content. Detection says the macro hash is unknown or the doc is a fresh, per-target build.
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.
Nearly 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?
Part 1 sets up the map. Later parts in this series will take each family one at a time, with a real payload pattern, examples, and the detection that works. Part 2 will start with macros and image-only Office files.
Useful references: