Detecting and Mitigating Command and Scripting Interpreter Abuse (T1059)

Command and Scripting Interpreter (MITRE ATT&CK T1059) is an execution technique. Adversaries abuse the shells and scripting languages that already ship with a system to run commands, scripts or binaries. MITRE lists a wide platform set: containers, ESXi, IaaS, identity providers, Linux, macOS, network devices, Office suites, SaaS and Windows.

That breadth is the point. Nearly everything with an interface has some way to take commands, and defenders cannot simply remove all of them.

How attackers use it

MITRE explains that macOS and Linux include a Unix shell, while Windows includes the Windows command shell and PowerShell. There are cross platform interpreters such as Python, and ones tied to client applications such as JavaScript and Visual Basic. Each has its own sub-technique page in ATT&CK.

Commands and scripts can arrive in several ways:

• Embedded in initial access payloads, delivered as lure documents.
• Downloaded as secondary payloads from an existing command and control channel.
• Typed into an interactive terminal or shell.
• Run remotely through remote services.

Once a script runs, it inherits the permissions of the account that started it. That is why execution through an interpreter so often follows a stolen credential or a user opening a document.

How to detect it

MITRE's strategy describes behavior per environment:

• Windows: powershell.exe, cmd.exe and wscript.exe running outside expected administrative hours or from abnormal user contexts, often followed by encoded or obfuscated arguments or secondary execution.
• Linux: bash, sh, python or perl started by users or processes that do not normally run them, especially when chained with utilities such as netcat, curl or ssh.
• macOS: command line interpreters launched through Terminal, Automator or a hidden osascript, particularly when the parent process does not look like a user opened application.
• ESXi: esxcli system commands or direct interpreter use such as a busybox shell, started from SSH or the host terminal unexpectedly.
• Network devices: CLI access such as Cisco IOS or Juniper JUNOS enable mode, or scripting capable sessions, by uncommon accounts or from unknown addresses.

The common thread is lineage and context. Collect process creation events with command lines and parent processes. Add authentication logs so every shell can be tied to a person and a source. For cloud and SaaS, look at the administrative audit logs that record command and script execution features.

A simple baseline helps more than a long rule list. Know which accounts run interpreters on which systems, and at what times. Alert on departures.

How to reduce the risk

MITRE lists these mitigations, in plain terms:

1. Inventory systems and audit for unauthorized interpreters.
2. Prevent users from installing interpreters they do not need.
3. Disable or remove shells and interpreters that are unnecessary.
4. Permit only signed scripts where possible.
5. Use application control. PowerShell Constrained Language mode can limit dangerous language elements such as Add-Type.
6. On Windows 10, enable Attack Surface Reduction rules that stop Visual Basic and JavaScript from executing potentially malicious downloaded content.
7. If PowerShell is needed, restrict its execution policy to administrators and consider Just Enough Administration to limit what remote sessions can do. MITRE warns that execution policy can be bypassed in some configurations, so do not rely on it alone.
8. Use script blocking extensions and ad blockers to reduce web delivered scripts, and use antivirus to quarantine suspicious files.

Try it yourself

Scripts also hide inside code and build files. A static scan shows how risky constructs such as shell execution are found before they ship.

Click through it at your own pace, or open it full screen.

If your concern is install scripts and build scripts in third party packages, run your manifest through the free in-browser dependency scan at https://gold.safeguard.sh/scan. No login is needed, the file never leaves your machine, and it covers up to 100 dependencies.

Check your own environment

• List the interpreters installed on a representative server and on a representative laptop. Ask whether each one is needed.
• Confirm process creation logging with command lines on Windows and auditd or equivalent on Linux.
• Check whether network devices and ESXi hosts send command logs to a central place.
• Find out who can run PowerShell remotely.

Windows, read-only:

Get-ExecutionPolicy -List
$ExecutionContext.SessionState.LanguageMode

The first shows policy by scope. The second shows whether the current session is in Full Language or Constrained Language mode.

Quick check

Sources

• MITRE ATT&CK, Command and Scripting Interpreter: https://attack.mitre.org/techniques/T1059