Attachment Security: Malware, Spoofed Files, and a Safe-Handling Policy

Ask anyone who has worked a serious security incident how it started, and the answer is very often the same: somebody opened an attachment. Not a foolish somebody — a busy one, doing their job, opening what looked exactly like the invoices and resumes and shipping notices they open all day. Attachments remain the most reliable way to put hostile code in front of a human being, because email is the one channel where outsiders are allowed, even expected, to hand your users files.

The good news is that attachment risk is one of the most understandable problems in security. The dangerous file types are known. The disguises are catalogued. The safe-handling habits fit on an index card. And the response when something does get opened is a sequence you can rehearse. None of it requires scaring anyone — in fact, fear actively damages the one defense that matters most, which is a user who reports quickly instead of hiding a mistake.

This article, part of our Email Attachments series, gives you the working set: which file types deserve which treatment, how spoofed files dress up, what preview really protects against, how to coach users without a syllable of condescension, and a paste-ready incident playbook for the day someone opens the wrong thing.

Why Attachments Are the Attacker's Favorite Door

Every network perimeter shares one deliberate gap: mail comes in. Firewalls refuse unsolicited connections, but email is solicited by definition — your organization publishes addresses precisely so strangers can write to them. An attachment rides that welcome straight through the perimeter and arrives somewhere no firewall can help: in front of a person with the authority to run it.

That is why attachment attacks are really two attacks stapled together. The technical half is the file — a program, a script, a document carrying active content. The human half is the story that makes opening it feel routine: an invoice during month-end close, a resume to the recruiter actually hiring, a delivery notice in shipping season, a "revised contract" replying to a genuine thread. The story is targeted at workload, not stupidity. On a calm Tuesday morning almost everyone spots the fake; at 4:55 on deadline day, almost anyone can miss it. Design your defenses for the 4:55 version of your users, because attackers do.

It helps to know what the attacker is actually buying with that click, because it explains the urgency of the response playbook later. Sometimes the payload is the whole crime — ransomware that begins encrypting whatever the user can reach. More often the click buys a foothold: a quiet program that phones out, harvests credentials, and lets a human operator explore your network at leisure, often for days, before anything visible happens. That gap between the click and the damage is your response window, and it is why "reported within five minutes" matters more than any other fact about an incident.

You are not defending alone. As we saw in the journey of an attachment, security gateways decode, unpack, and even detonate suspicious files before delivery, and they remove enormous amounts of hostile mail. But scanners match knowledge, and attackers manufacture novelty; some fraction always arrives. The human layer is not "the weakest link" — it is simply the last layer, and it deserves the same engineering attention as the others.

Risky File Types, Ranked

File types are not equally dangerous, and policy should say so plainly. A workable ranking, from "block outright" down to "relax":

Two footnotes make this table trustworthy. First, a good gateway identifies files by content, not name — it reads the internal structure, so renaming payload.exe to report.txt fools nobody worth fooling. Second, the blocked categories need a legitimate outlet: engineers really do exchange executables and admins really do ship disk images. Provide that outlet deliberately — a managed transfer server, covered below — or users will invent their own.

Disguises: Double Extensions and Other Costumes

Attackers know users check file types, so they costume the file. The classic trick exploits a default setting: Windows hides file extensions it recognizes. A file actually named Invoice.pdf.exe therefore displays as Invoice.pdf — the double extension disguise. The user sees a document; the operating system sees a program; only one of them decides what happens on double-click. The diagram below shows the costume and the reality side by side.

The rest of the wardrobe follows the same logic of borrowed trust:

• Forged icons. A program can carry any icon it likes, including a perfect copy of a document icon. Icons are decoration, not identification.
• Trusted-name senders. The display name says a colleague; the underlying address says otherwise. Clients that show only display names do the attacker's work for them.
• Hijacked threads. The most convincing costume of all: mail sent from a genuinely compromised mailbox, arriving as a reply inside a real conversation, attachment included. Every familiarity signal is authentic except the file. This is why coaching must center on expectation ("was I expecting this file?") rather than recognition ("do I know this sender?").
• Name games. Long runs of spaces before the real extension, and special characters that reverse how a name displays, both aim to push the truth out of view.

The countermeasures are refreshingly cheap: enforce extension display by policy on every machine, prefer mail clients that reveal the real sender address, and teach the one honest rule — when a file surprises you, the sender's familiarity is not evidence.

Preview vs Open: What Is Actually Safer

Users ask a fair question: is it safe to look at an attachment? The distinction that matters is between previewing — the mail client rendering a picture of the file in a pane, without launching its native application — and opening — handing the file to the program that owns it, with all that program's power.

Preview is meaningfully safer. The preview renderer does not run macros, does not execute programs, and typically draws a simplified version of the document. It is the right way to answer "what is this?" It is not, however, a guarantee — rendering software has had exploitable bugs, which is one reason preview panes for suspicious mail are sometimes disabled in hardened environments. Safer, not safe: a distinction worth stating honestly, because users trust guidance that admits its edges.

When neither preview nor instinct settles the question, the tiebreaker is out-of-band verification: confirm with the apparent sender through a channel the attacker does not control. Call the number you already have for them, or message them on the internal chat system — never by replying to the email itself, since a hijacked thread answers replies with the attacker's voice. Thirty seconds of verification is cheaper than any step of the incident playbook below, and users who see IT doing it themselves learn that checking is normal, not paranoid.

Opening adds the real hazards, and one button deserves special infamy. Modern document applications open email-borne files in a protected view — a read-only sandbox where active content cannot run — and then offer an Enable Editing / Enable Content button. That button is the detonator for the entire macro-malware genre: the document is inert until the user, prompted by instructions inside the document itself ("content blurred for security — click Enable to view"), disarms the safety personally. The coaching rule is short enough to stick: preview to identify; open if expected; never click Enable Content on anything that arrived by email unless you verified it with the sender by another channel.

Coaching Users Without Condescension

Security awareness fails in the delivery far more often than in the content, and the failure mode is tone. Users have sat through training that treats them as the problem; they respond by tuning out, or worse, by hiding mistakes. The corrective is genuine respect, expressed in mechanics, not just manner:

• Say the true thing first: these attacks are built by professionals to beat busy people, and anyone — including the IT team — can be caught on the wrong afternoon. This is not flattery; it is threat modeling, and users can tell the difference.
• Teach three checks, not thirty: Was I expecting this file? Does the real address — not the display name — match who this claims to be? Is it pushing urgency or secrecy? Three questions survive a deadline; a laminated page of heuristics does not.
• Make reporting one click and one minute. A report button in the mail client, or a short memorable address, with a same-day human acknowledgment. Every step you add to reporting is a report you will not get.
• Praise reports loudly, including false alarms. A false alarm is a user paying attention. The phrase that builds the culture: "good catch — keep them coming."
• Never punish the person who clicked. Not formally, not by mockery, not by a "wall of shame." Punishment does not reduce clicking; it reduces reporting, which converts ten-minute incidents into three-week ones. The click is an event; the silence afterward is the catastrophe.
• If you run practice simulations, run them as practice. The point of a fire drill is rehearsal, not catching people walking slowly. Debrief kindly, share aggregate results, and watch the metric that matters: report rate rising, and time-to-first-report falling.

The "Someone Opened It" Incident Playbook

Eventually the call comes: "I think I just opened something bad." The next hour goes vastly better if the steps already exist on paper. Here is a playbook to paste into your runbook and adapt to your tooling and obligations — rehearse it once a year, the way you would a restore:

WHEN A USER OPENS A SUSPICIOUS ATTACHMENT

 1. THANK THEM, note the exact time. Reporting fast is the win;
    say so out loud. Calm tone from the first sentence.
 2. ISOLATE the machine: disconnect network / disable Wi-Fi.
    Leave it powered ON unless your policy says otherwise --
    powering off can destroy evidence in memory.
 3. PRESERVE the email: note sender address, subject, file name.
    Do not forward the attachment around; use your mail system's
    admin tools to retrieve it safely.
 4. FROM A DIFFERENT DEVICE: change the user's passwords and
    revoke active sessions. Assume credentials typed after the
    open are burned.
 5. CHECK THE MAILBOX for attacker changes: new forwarding
    rules, unfamiliar sent items, altered recovery settings.
 6. CONTAIN THE MACHINE per policy: full scan at minimum;
    reimage if anything executed. When in doubt, reimage.
 7. SEARCH THE MAIL SYSTEM for the same message delivered to
    others; quarantine every copy before more clicks happen.
 8. BLOCK the sender, domain, and any addresses or links from
    the message at the gateway.
 9. WATCH for follow-on: unusual outbound traffic or logins
    from that account and machine over the following days.
10. NOTIFY per your obligations -- management, and, where data
    was exposed, whoever your compliance rules require.
11. DEBRIEF blame-free within a week: what made the lure
    convincing, which control failed, what changes. Update
    this playbook with what you learned.

Notice how much of the playbook's speed depends on the culture section above it. Steps 1 through 4 only happen quickly if the user calls immediately, and the user only calls immediately if reporting has always been safe. Blame-free response is not a kindness bolted onto security — it is a control, as real as the gateway.

Policy That Helps Instead of Nags

Write the safe-handling policy last, after the mechanics and culture exist, and keep it to one page. It needs five sections: which attachment types the gateway blocks (the table above, condensed); the three checks for unexpected attachments; how to report, in one step; what happens next when someone reports (spoiler: thanks, not trouble); and — critically — the sanctioned channel for legitimate files that email refuses or mishandles.

That last section is what separates a policy users follow from a policy they route around. Engineers will need to receive an executable from a vendor; a partner will need to send a giant archive; finance will need to move files too sensitive for the mailbox-copies problem described in why email falls short. Give those needs a first-class home: a managed file transfer server with per-user authentication and activity logging — a Windows deployment of Sysax Multi Server serves this role, with recipients downloading over HTTPS in a plain browser — so the blocked path and the approved path appear in the same sentence of your policy. Pair it with the honest small-file rules in when attachments are fine, and the rollout craft in weaning users off attachments, and the policy stops being a list of noes.

The Calm Summary

Attachments are the attacker's favorite door because email is the one door left open on purpose. The defense is layered and none of it is exotic: block the file types with no business traveling by mail, unpack and scan the rest, strip the costumes by showing extensions and real sender addresses, teach three checks and a one-click report, treat Enable Content as the detonator it is, and rehearse the eleven steps for the day a click gets through. Above all, protect the reporting reflex — a user who tells you within five minutes has handed you a small incident, and a user who is afraid to tell you has handed you a large one, later.

Frequently Asked Questions