Attacker File Formats: How File Types Get Weaponised

Almost every intrusion starts with a file arriving somewhere it is trusted: an email attachment, a download, a shared drive. The attacker's choice of file format is deliberate. It has to pass the mail filter, look ordinary to the person who opens it, and then hand execution to something the operating system already trusts. The format is the delivery vehicle, and the categories of vehicle are surprisingly few.

This is a narrative explainer of those categories and how each is abused, framed at the detection level. The live, enumerable catalogue of specific formats, the tools they invoke, and their ATT&CK mappings lives on our data site. Read this to understand the shape of the problem, then work from the atlas for the specifics.

The categories of weaponised format

Each row is a family of formats that shares an abuse pattern. The extensions are examples, not an exhaustive list.

Read the table and the same shape appears in every row. The file itself carries little or no obviously malicious code. It is a wrapper whose job is to reach a trusted execution path, then trigger it.

Why the format is a wrapper

The reason these categories keep recurring is that each abuses a specific trust the operating system grants by default.

• Scripts run interpreted, so there is no compiled binary for signature tools to flag, and the script host is a signed Microsoft component that application allowlisting waves through.
• Shortcuts hide their real intent in a target field the user never sees. A .lnk that appears to point at a PDF can actually launch PowerShell with an encoded command.
• Disk images and archives are containers. A payload inside an ISO or a nested ZIP is harder for a scanner to reach, and critically, files extracted from some containers do not inherit the Mark-of-the-Web, the flag Windows uses to warn that a file came from the internet.
• Macro documents were the dominant vector for years because Office would run embedded code on open. When macros from the internet were blocked by default, attackers pivoted to the other categories, which is why disk images and LNK files surged afterward.
• Images exploit the assumption that a picture is inert. SVG is XML that browsers render, and it can contain script. Polyglot files are valid as two formats at once, so a file that is a legitimate image can also be a valid archive or script.

In nearly every case the file then invokes a LOLBin, a legitimate Windows binary repurposed to download and execute the real payload. The document is the trigger; the trusted binary is the engine. This is why file-format defense and behavioural detection are the same problem seen from two ends, and it is covered in depth in LOLBins Explained.

Detection follows behaviour, not extension

Extensions lie. Attackers rename files, use double extensions, nest formats inside archives, and build polyglots that are valid as two types at once. A defense that keys on the extension alone is trivially bypassed. The durable signal is what the file does when it is opened.

The highest-value detection is the parent-child process chain. A document, archive, or image that leads to a script host or shell being spawned is the moment the wrapper does its work, and that chain is almost never legitimate:

• winword.exe or excel.exe launching powershell.exe, wscript.exe, or cmd.exe.
• explorer.exe launching a shell immediately after a .lnk was opened.
• An archive tool or a mounted ISO followed at once by execution from that path.
• A browser writing an executable or archive to disk, then that file running, the fingerprint of HTML smuggling.

Gateway and policy controls

Detection catches what got through; policy stops it arriving. The controls that remove the most delivery surface:

1. Strip or quarantine risky formats at the mail gateway. Script files, HTA, and often disk images have no legitimate business as email attachments for most organisations.
2. Block macros from the internet. This single default change reshaped the threat landscape and remains one of the highest-value settings.
3. Change default handlers. If .js, .vbs, .hta, or .wsf never legitimately run on your endpoints, set their default handler to open in Notepad so a double-click edits rather than executes.
4. Preserve and enforce Mark-of-the-Web so Protected View and SmartScreen fire on internet-sourced files.
5. Constrain the execution engines. Application control, Constrained Language Mode for PowerShell, and disabled script hosts break the step after the file opens.

The catalogue of which specific formats fall into each category, the exact binary each tends to invoke, and the ATT&CK technique behind it is maintained on the File-Format Abuse Atlas. Use it to turn the categories here into concrete blocklist and detection entries.

How to use this reference

1. Think in categories, not extensions. The seven families above cover almost every delivery format, and each has a stable abuse pattern.
2. Assume the file is a wrapper. Ask what trusted execution path it reaches, since that path is where you detect and where you control.
3. Detect on the process chain. A document, archive, or image leading to a script host or shell is the signal, whatever the file was called.
4. Fix the gateway and the defaults. Strip risky attachments, block internet macros, change default handlers, and keep Mark-of-the-Web intact.
5. Work from the atlas for specifics. When you need the exact format, its typical tool, and a detection, the live table has the detail this narrative sets up.

Attackers keep a small deck of file formats and reshuffle it as defenses close individual paths. Learn the categories and the wrapper-to-LOLBin pattern once, and each new lure is a variation you already recognise rather than a novel threat.

A worked example: how one lure chains together

Follow a single common delivery pattern from arrival to execution, and the wrapper logic becomes concrete. No real campaign is named here, only the mechanical steps a typical chain performs.

1. The lure arrives as an archive. An email carries a ZIP attachment with a name that fits the pretext, an invoice or a shipping notice. The archive matters for two reasons: it hides the true contents from a surface scan of the attachment, and files extracted from some archive handling do not carry the Mark-of-the-Web, so the internet-origin warning never appears.
2. Inside sits a shortcut, not a document. The user opens the archive and sees what looks like a document. The icon and name are chosen to match, while the actual file is a .lnk shortcut. The target field of that shortcut, which the user never reads, holds a command.
3. The shortcut launches a trusted binary. Double-clicking runs the hidden command, which invokes a signed Windows component such as a script host or a downloader LOLBin. Nothing about that binary is malicious on its own, which is exactly why it is chosen.
4. The trusted binary fetches the payload. The LOLBin reaches out to a remote host and pulls down the real payload, or reconstructs it from data already on disk. Because the fetch comes from a legitimate system tool, naive allowlisting waves it through.
5. The payload executes and persistence follows. The retrieved code runs, and the intrusion moves past initial access into whatever the operator does next.

Every stage maps to a control. The archive stage argues for stripping or quarantining risky attachments and preserving Mark-of-the-Web. The shortcut stage argues for watching explorer and .lnk handling spawn a shell. The LOLBin stage argues for the parent-child process detections. No single control has to be perfect, because the chain gives several independent chances to break it.

A quick map of ATT&CK techniques

The behaviours in this guide line up with a small set of stable MITRE ATT&CK techniques, which are useful anchors for detection engineering and reporting.

Mapping detections to these IDs keeps a program honest. It makes coverage measurable, lets you compare your telemetry against what adversaries actually do, and gives incident reports a shared vocabulary.

Detection signals for each category

The parent-child process chain is the backbone, and several categories add their own tells worth instrumenting alongside it.

• Scripts. A script host such as wscript, cscript, mshta, or powershell launching from a mail client, a browser download path, or an archive extraction directory. Encoded or heavily obfuscated command lines raise the weight further.
• Shortcuts. A .lnk opened from a download or archive path immediately followed by a shell or LOLBin. Shortcuts with unusually long target fields, or targets that reference a script host, are inherently suspicious.
• Disk images. A mount event for an ISO, IMG, or VHD followed by execution from the newly mounted volume. Mounting a disk image is rare on most user workstations and stands out on its own.
• Macro documents. An Office application spawning a script host, a shell, or a LOLBin. Modern telemetry can also flag documents that reach out to the network or write executable content.
• Installers. msiexec invoked with a remote URL or run from a user-writable path such as a downloads or temporary folder, rather than from a managed software deployment.
• Images and SVG. A browser rendering an untrusted SVG that contains script, or a file whose declared type does not match its content, the signature of a polyglot.
• Archives and smuggling. An extraction tool immediately followed by execution of extracted content, or a browser writing an executable or archive to disk followed by that file running.

How the mix shifted over time

Delivery formats move as defenses close paths, and the recent history is instructive. For years, macro-enabled Office documents were the dominant vector, because an embedded macro would run on open and the user only had to click through a warning. When macros sourced from the internet began to be blocked by default, that single change removed the easiest path and pushed operators elsewhere.

The pivot went first toward container formats. Disk images such as ISO and IMG surged because they smuggled payloads past scanning and stripped the Mark-of-the-Web, so the extracted contents did not trigger the internet-origin warnings that Protected View and SmartScreen depend on. Shortcut files rose alongside them, since a .lnk hides its command in a field the user never inspects. HTML smuggling grew as a way to assemble a payload inside the browser, past a gateway that only saw benign-looking HTML.

The lesson for a defender is that the categories are stable even as the popularity of each one rises and falls. A control that assumes today's favourite format will still be popular next year ages badly. A control built on the wrapper-to-trusted-binary pattern keeps working, because that pattern is what every category has in common regardless of which is currently in fashion.

Container formats and the Mark-of-the-Web

Container formats deserve their own note, because their abuse turns on a single mechanism: whether the Mark-of-the-Web survives extraction. When it survives, internet-sourced files trigger Protected View, SmartScreen, and macro restrictions. When it is stripped, those defenses stay silent and the user sees an ordinary local file.

Password-protected archives add a second twist. A password in the email body lets the human open the archive while denying a scanner the contents, because the gateway cannot decrypt what it cannot read. Treat password-protected attachments from outside as high-risk, and prefer tooling and policies that carry Mark-of-the-Web through extraction so the internet-origin warnings still fire on whatever comes out.

Common misconceptions

"Blocking executables at the gateway is enough." The whole point of these categories is to avoid shipping an obvious executable. Scripts, shortcuts, documents, images, and archives all reach execution through trusted components, so a filter that only stops .exe files misses the entire pattern.

"A picture cannot hurt me." SVG is XML that a browser renders, and it can carry script. Polyglot files are valid as two formats at once, so a file that opens as a legitimate image can also be a valid archive or script. The assumption that images are inert is exactly the trust these formats abuse.

"The extension tells me what the file is." Attackers rename files, use double extensions, and nest formats. The extension is a hint the user sees, and the real behaviour is decided by how the file is handled when opened. Detection built on extensions alone is trivially bypassed.

"If antivirus passed it, it is safe." These wrappers often contain little obviously malicious code, because their job is to reach a trusted execution path and trigger it. A clean scan of the wrapper says little about what the chain does once the user opens it.

"Disabling macros solved the problem." Blocking internet macros was one of the highest-value changes available, and it moved the problem rather than ending it. Operators shifted to disk images, shortcuts, and HTML smuggling, which is why the wrapper pattern, and not any single format, is the thing to defend against.

Frequently asked questions

Why do attackers prefer file formats that invoke trusted binaries? Trusted, signed system components are waved through by application allowlisting and raise little suspicion in logs. By making the file a wrapper that reaches one of these components, the operator borrows its trust and avoids shipping code that a scanner would flag on sight. This is the LOLBin pattern, covered in LOLBins Explained.

What is the Mark-of-the-Web and why does it matter? It is a flag Windows attaches to files that came from the internet. Protected View, SmartScreen, and macro-blocking policies rely on it to decide whether to warn or restrict a file. Container formats like ISO and some archive handling can strip the flag, so the extracted contents run without the warnings the user would otherwise see. Preserving it through extraction is a high-value control.

Are disk image files really that dangerous? Mounting an ISO or IMG is uncommon on most user workstations, and the format smuggles payloads past scanning while breaking the Mark-of-the-Web. That combination made disk images a popular pivot after internet macros were blocked. Because legitimate mounts are rare, a mount event followed by execution from the mounted volume is a strong and low-noise signal.

Can SVG files carry malware? SVG is XML that browsers render, and it can contain embedded script. It is also used in HTML smuggling to reconstruct a payload in the browser. Treat untrusted SVG rendered by a browser as active content, not as an inert picture.

Is HTML smuggling a file format or a technique? It is a technique that uses ordinary web formats. The HTML or SVG delivered to the browser looks benign to a gateway, and script inside it reassembles the real payload locally and prompts the user to save or run it. The detection signal is a browser writing an executable or archive to disk followed by that file running.

What single control removes the most delivery surface? There is no one control that covers everything. Blocking macros sourced from the internet, stripping high-risk formats at the mail gateway, and preserving Mark-of-the-Web through extraction together close most of the common paths. Layer the parent-child process detections on top to catch what still gets through.

Should I block password-protected archives outright? For many organisations, inbound password-protected archives from external senders carry more risk than value, because the password in the message body lets a human open what a scanner cannot inspect. Blocking or quarantining them, with an exception process for known business needs, removes a reliable smuggling path while keeping a way through for legitimate cases.

Related guides

• LOLBins Explained
• What Is Phishing
• What Is an Infostealer
• HTML Smuggling Explained
• Ransomware Anatomy