Malicious File

This is the moment a phishing lure actually pays off: a user, believing a malicious file is legitimate, runs it themselves. The file might be an executable disguised as a PDF, a macro-enabled document, or a script. What defines this technique isn't the file type, it's that execution requires the human in the loop to act.

It's the companion technique to delivery methods like spearphishing. The attachment or download is how the file arrives; this is the moment it actually runs.

Attackers invest heavily in making the file look legitimate and the pretext compelling enough that a normal, reasonably careful user still runs it: double extensions (invoice.pdf.exe), icons matching a familiar file type, or a macro-enabled document with fake "enable content to view this document" instructions embedded in the document itself.

Once run, the file typically performs its actual malicious function immediately, dropping a payload, establishing persistence, or reaching out to command infrastructure, while often opening a decoy document to keep the user's suspicions low.

Data source: endpoint process-creation telemetry for the file handler started with the file on its command line (Sysmon Event ID 1), plus the file's creation record (Event ID 11)

{
  "host": {
    "name": "WKSTN01"
  },
  "event": {
    "action": "start",
    "category": "process"
  },
  "process": {
    "name": "invoice_macro.docm",
    "parent": {
      "name": "explorer.exe"
    },
    "executable": "C:\\\\Users\\\\jdoe\\\\Downloads\\\\invoice_macro.docm"
  }
}

Prebuilt Elastic rule: Suspicious MS Office Child Process

Look for execution originating from user-writable, non-standard locations. Downloads, Temp, and email-client attachment cache folders are common launch points for malicious files, since that's where they land before a user runs them, and legitimate software is rarely installed or run directly from there.

Hunting manually: filter process-creation events where process.executable path includes Downloads, AppData\Local\Temp, or similar user-writable paths, with process.parent.name: explorer.exe (indicating direct double-click execution rather than a script or service launching it).

Users do legitimately run downloaded installers and occasionally execute scripts from these same locations. A downloaded, digitally signed installer for known, common software is routine.

The distinguishing signal is a combination of signing/reputation and behavior after launch: an unsigned or unknown-publisher executable launched from Downloads that immediately spawns further processes, modifies registry run keys, or reaches out to an external IP is a very different pattern than a signed installer that runs its own setup wizard. If your environment allows user-installed software, focus on unsigned binaries and post-execution behavior rather than the launch location alone.

• MITRE ATT&CK T1204.002: Malicious File
• Elastic Security: Suspicious MS Office Child Process

2 scenarios in this catalog cover T1204.002. We don't name them — identifying the technique is part of what a scenario grades. Explore the dashboard →