Skip to content
Sign In
Learn

T1059

Command and Scripting Interpreter

What it is

Attackers run commands and scripts through interpreters that are already on the host: PowerShell and the Windows command shell, Unix shells, and languages such as Python, JavaScript and Visual Basic. This is the parent technique; each interpreter has its own sub-technique, with its own page in this catalog where one is written.

Interpreters are built to run arbitrary instructions, so using one needs no exploit and adds nothing new to the host beyond, at most, a script file. Defenders cannot simply remove them, because administrators and software depend on them every day. That makes what an interpreter was asked to do, and what asked it, the evidence that matters.

How adversaries use it

Once attackers can run anything at all, they usually reach for an interpreter: to look around the host and the network, download and start the next stage, change settings, set up persistence and move to other machines. The instructions arrive typed into an interactive session, as a script file, or as text passed on the command line, often obfuscated so that a quick read reveals little.

The interpreter is frequently started by something with no ordinary reason to start one: a document viewer, a web server process, a service or another interpreter. That is why the chain of parent and child processes is as telling as the command itself.

Detect it in Elastic

Data source: Process creation events on every platform (Sysmon, Windows Security, Elastic Defend, Auditbeat), plus PowerShell's own script block log on Windows

Key fields

event.code: 1 (Sysmon) or 4688 (Windows Security) when a process starts; on Linux and macOS, event.action records the start process.name: the interpreter process.command_line: what it was told to run; 4688 carries it only when command-line auditing is on process.parent.name: what started it user.name: the account it ran as event.code: 4104 when PowerShell script block logging records a script's text, in powershell.file.script_block_text host.name, @timestamp

Example event

{
  "host": {
    "name": "ws-307.corp.example"
  },
  "user": {
    "name": "m.castell"
  },
  "event": {
    "code": "1"
  },
  "process": {
    "name": "cscript.exe",
    "parent": {
      "name": "explorer.exe"
    },
    "command_line": "cscript.exe //nologo E:\\Depot\\inv.vbs"
  },
  "@timestamp": "2026-06-02T09:07:51.734Z"
}

Prebuilt Elastic rule: Unusual Parent Process for cmd.exe

Hunt guidance

Start from what is normal. For each interpreter your hosts run, learn which programs usually start it, as which accounts and from which folders; a short list of usual parents per interpreter covers most activity. Then look for the exceptions: an interpreter started by a document viewer, a web server, a database or a service that never starts one; scripts run from temporary, download or removable folders; command lines that are very long or deliberately obfuscated; and interpreters that make network connections or start further interpreters.

A query to begin with on Windows, here for the two script hosts: process.name: ("cscript.exe" or "wscript.exe") and process.parent.name: *, grouped by process.parent.name; add the program names of PowerShell, the command shell and any other interpreter your hosts run. On Linux, group shell and Python starts by their parent the same way. Where PowerShell script block logging is on, read the script text itself (event.code: 4104), which shows the script as PowerShell actually ran it.

The prebuilt rule named on this page covers one interpreter, the Windows command shell, and only when one of a fixed list of system and background processes with no reason to start it does; the other interpreters, and every other parent, are this hunt's to find. Where a sub-technique's page is written, it names a rule for that interpreter.

Ruling out legitimate activity

Interpreters run all day for legitimate reasons: logon and management scripts, software installers and updaters, administrators' own tooling and developers' builds. Most of that comes from a stable set of parents, accounts and script locations, and repeats on a schedule. Check a suspicious start against that baseline: whether the parent is installed software, whether the account and script location are ones that host normally uses, and what the interpreter did next. An interpreter started by a document viewer or a web server, running a script from a user folder and then reaching out to the network, is rarely legitimate.

Telemetry needed

The log events that help detect this technique, from the Telemetry reference: which log source to collect, which event in it, and how to enable each one.

References

Practice it

1 scenario in this catalog covers T1059. We don't name it, because identifying the technique is part of what a scenario grades. Explore the Range →