Unix Shell abuse (MITRE ATT&CK T1059.004) sits under the Execution tactic. The shells in question are the ones you already run every day: sh, ash, bash and zsh. MITRE lists the platforms as Linux, macOS, ESXi and network devices.
A shell can control nearly every aspect of a system, and some commands need elevated privileges to do real damage. That is exactly why it is useful to an intruder who has landed on a host. There is no new tool to drop. The interpreter is already there.
How attackers use it
MITRE describes a few patterns. Interactive shells may be reached through a command and control channel, or during lateral movement, for example over SSH. Shell scripts let an adversary deliver and run many commands in sequence, and they can be part of the payloads used for persistence.
Shells also support conditionals and loops, so one small script can repeat the same steps across many machines. That is a normal admin habit, which makes the abuse hard to tell apart from routine work.
Smaller systems add a twist. Embedded devices, lightweight Linux distributions and ESXi servers often ship a stripped-down shell through Busybox, a single executable that bundles many tools. If you only watch for bash, you can miss these.
How to detect it
MITRE's detection strategy for this technique is behavioral and centers on chains rather than single events. Per platform, the analytics look for:
- Linux: bash, sh, zsh or BusyBox started from remote sessions, by unauthorized users, or from inside another script interpreter, followed by suspicious commands, network discovery or persistence indicators.
- macOS: shell scripts launched from unusual apps, embedded in LaunchDaemons or LaunchAgents, run through Automator, or run outside Terminal.app.
- ESXi: BusyBox or Ash shells from unexpected logins, such as SSH or the DCUI, plus droppers or persistence artifacts created by shell.
- Network devices: rare console commands, CLI use, or script injection through exposed APIs or SSH.
In practice, that means process creation logs with full command lines and parent process, authentication logs, and file creation events in startup locations. The useful question is always "who started this shell, from where, and what did it run next?"
How to reduce the risk
MITRE lists one mitigation, Execution Prevention. Use application control where it fits. On ESXi hosts, the execInstalledOnly feature prevents binaries from running unless they were packaged and signed as part of a vSphere installation bundle (VIB).
Around that, the plain steps are to limit who can log in remotely, remove interactive access where a service account does not need it, and keep shell and process logs flowing to a central store.
Check your own environment
Read-only checks you can run today:
# Linux (auditd): list recent program executions
sudo ausearch -m EXECVE -ts today | head -50
# Linux: recent logins and sources
last -n 20
# macOS: list launch items that can start shell scripts
ls -l ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons
# ESXi shell: show whether execInstalledOnly is enabled
esxcli system settings kernel list -o execInstalledOnly
Then confirm that shell history and auth logs from these hosts also exist somewhere an attacker on the box cannot edit.
Quick check
Why is a bash-only detection rule not enough?
Embedded devices, lightweight Linux builds and ESXi often use a Busybox shell such as ash. MITRE's analytics cover BusyBox and Ash explicitly.
What does execInstalledOnly do on ESXi?
It blocks binaries from running unless they were packaged and signed as part of a vSphere installation bundle.
