Spearphishing Attachment

Spearphishing attachment is the oldest trick in the book, still working because it targets a person, not a system. An attacker sends an email carrying a malicious file (a Word document with a macro, an Excel workbook, a disguised executable) crafted to look like something the recipient expects: an invoice, a resume, an internal memo. The "exploit" is the recipient double-clicking it.

Unlike a technical vulnerability, there's no patch for this. The attachment itself is often not malware in the traditional sense. A macro-enabled document is a completely legitimate file format doing something it's allowed to do (run code) in a context nobody expects, opened by an unsuspecting employee.

This is almost always step one. Attackers research a target organization (or don't bother, and blast a template broadly), craft a lure relevant to the recipient's role, and attach a document that, once opened and macros are enabled, downloads or directly executes a second-stage payload. Finance staff get invoices; HR gets resumes.

The email itself rarely needs to be sophisticated. What matters is the pretext being plausible enough that one person out of hundreds clicks "Enable Content."

Data source: mail transfer agent delivery logs with the envelope sender domain and SPF/DMARC results, plus file-creation records (Sysmon Event ID 11) for the attachment on disk

{
  "host": {
    "name": "WKSTN01"
  },
  "event": {
    "action": "start",
    "category": "process"
  },
  "process": {
    "name": "cmd.exe",
    "parent": {
      "name": "winword.exe"
    },
    "command_line": "cmd.exe /c powershell -enc <base64>"
  }
}

Prebuilt Elastic rule: Suspicious MS Office Child Process

Office applications spawning a command interpreter, scripting host, or living-off-the-land binary is the single strongest signal. Word, Excel, and PowerPoint essentially never legitimately spawn cmd.exe or powershell.exe as a direct child in normal office use.

Hunting manually: filter for process.parent.name in ("winword.exe", "excel.exe", "powerpnt.exe") with a child process that isn't a known Office helper (splwow64.exe, officeclicktorun.exe). Pull the full command line of the child, which usually reveals the next stage immediately: a download command, an encoded PowerShell payload, and so on.

Office documents do legitimately spawn helper processes: printer spoolers, Click-to-Run updaters, and certain approved internal macros used for automation (mail-merge tools and report generators are common in finance departments specifically).

What separates a real attack from legitimate macro use: destination. A benign internal macro tool typically spawns a known, signed helper doing something narrow and repeatable (opening another Office file, writing to a specific network share). A malicious one spawns a general-purpose interpreter (cmd.exe, powershell.exe, mshta.exe, wscript.exe) with an unusual, often obfuscated or base64-encoded command line. If your organization has known legitimate macro-driven tooling, baseline exactly what it spawns and treat any deviation from that baseline as the signal, rather than the mere presence of a child process.

• MITRE ATT&CK T1566.001: Spearphishing Attachment
• Elastic Security: Suspicious MS Office Child Process

1 scenario in this catalog covers T1566.001. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →