Detecting T1059 Command and scripting interpreter

How T1059 command and scripting interpreter abuse shows up in intrusions

For a SOC lead, the working question is which interpreter executions are adversary-driven. Shells, PowerShell-style hosts, Python and cloud or hypervisor command-line tools run constantly on ordinary business systems, so an alert on the mere presence of an interpreter produces noise. MITRE defines the Execution tactic (TA0002) as the adversary trying to run malicious code or instructions on a system. Technique T1059 is the part of that tactic where the adversary uses an interpreter to do it, and it has 13 sub-techniques. This page targets ATT&CK v20.0, released on 2026-10-13, so detection mappings should be checked against that version before they are deployed.

In intrusions, interpreter abuse usually appears after an attacker already has a foothold. It can start on a user workstation, a web-facing server, a build host, a container, an ESXi host, an IaaS management plane or an identity provider administration console. A common pattern, described here as illustrative, is an interpreter launched by a service account or web application process rather than by a person, followed by activity the account has no business reason to perform. Another is an administrator interpreter session opened outside change windows or from an unexpected source host. The signal is rarely the interpreter itself. It is the combination of parent process, account, host role and time.

The practical step is to build a baseline before writing detections. Inventory which interpreters exist on each platform class, and document which accounts and parent processes normally start them. Confirm that Process Creation and Command Execution telemetry is collected on every platform in scope, including containers and hypervisors, because gaps there hide the executions that matter most. Ask the team operating the SIEM which of these sources reach it today and with what retention. Finally, record the ATT&CK version your mappings target, since releases can rename or deprecate techniques and sub-techniques.

Which data sources reveal T1059 and which open-source tool collects them

This table maps each telemetry source that reveals T1059 activity to the open-source collector that gathers it and the gap to close. Read each row as a question: what the signal shows, where it comes from, and what usually stays invisible if the collector is missing.

Data source	What it reveals for T1059	Open-source collection point	Gaps to close
Process Creation (DC0032)	Interpreter launches such as shells, PowerShell, Python or Perl, with parent process and arguments	Sysmon on Windows, auditd execve rules on Linux, Wazuh agent process monitoring	Confirm argument capture is enabled; Sysmon and auditd do not log full command lines by default on every host
Command Execution (DC0064)	Commands typed or piped into an interpreter, including inline script bodies passed on the command line	Wazuh agent command monitoring, shell history forwarding, Sysmon command line field	Shell history is often written only on exit and can be cleared; forward it in near real time where policy allows
Script Execution	Script files run by an interpreter, including script block logging for PowerShell and module loads for other runtimes	Windows PowerShell script block logging forwarded to Wazuh, Sysmon, Zeek file analysis for downloaded scripts	Script block logging is a configuration choice; verify it is on and that logs reach the manager
User Account Authentication	Logons that precede interpreter use, showing which account ran the commands and from where	Wazuh authentication decoders for Windows, PAM and sshd logs on Linux	Service and shared accounts blur attribution; confirm each account has an owner in the logging pipeline
Application Log Content (DC0038)	Interpreter use inside applications, hypervisors and cloud consoles, such as administrative actions and API calls	Wazuh log collection from application files, syslog forwarding, cloud audit log ingestion	ESXi and many IaaS consoles do not forward logs by default; configure explicit syslog or API export
Network Connection Creation (DC0082) and Network Traffic Content (DC0085)	Outbound connections started by interpreters, and content of downloads or reverse shell sessions where visible	Zeek connection and HTTP logs, Suricata alerts on the same segments	Encrypted traffic hides content; rely on connection metadata and endpoint process data for those flows
Identity provider and cloud audit logs	Token issuance, administrative sign-ins and automation identities used before scripts run in cloud environments	Forwarded identity provider and cloud audit events into Wazuh or a log pipeline	Retention periods and export scope vary by provider; confirm them in the provider documentation before relying on them

Detection logic for T1059 that SOC teams can tune

The six detection groups below describe logic in words, not queries. Each one pairs a behavior with a threshold approach and the benign activity that will trigger it, because most T1059 noise comes from administration, configuration management and CI tooling that legitimately starts interpreters. Tune each group against a baseline from your own estate before it pages anyone.

Unusual parent-child interpreter pairs

Flag interpreters such as shells, PowerShell or Python whose parent is a process that does not normally spawn them, for example a document viewer, a web server worker or a database process. Baseline the parent-child pairs per host role for two to four weeks, then alert only on pairs never seen in that baseline. Main false positives: installers, monitoring agents and CI runners that wrap scripts in shells.

Interpreter launches from unexpected contexts

Alert when an interpreter starts under a user or service account that has no documented need for it, such as a service identity running an interactive shell or a standard user launching a script host. Compare the launching identity against an allowlist maintained with the application owner. Main false positives: scheduled jobs, patch tooling and administrators using break-glass accounts, which should be recorded in change tickets so the allowlist stays current.

Encoded or obfuscated invocation patterns

Describe the signal conceptually: an interpreter invoked with long, high-entropy or base64-like arguments, or with options that hide a window or bypass a local policy. Score command lines by length and character distribution, and tune the threshold on the top decile of your own administrative traffic. Main false positives: configuration management and software deployment tools that pass encoded payloads by design, so exclude them by known parent and signed binary instead of by string match alone.

Interpreters on container and ESXi hosts

Container images and ESXi hosts normally run no general-purpose interpreter, so any shell or script engine starting there is a high-fidelity candidate. Confirm the expected process inventory per image and per host build, and treat anything outside it as a finding. Main false positives: debugging sessions, health-check scripts baked into images, and vendor support tooling, which should be listed as named exceptions with an expiry date.

Cloud CLI use from non-admin identities

Watch cloud command-line tools invoked from hosts or sessions tied to identities that do not hold administrative roles, and alert on first use of administrative API actions by those identities. Correlate the CLI command execution with the identity's role assignments in the provider's audit log. Main false positives: developers testing infrastructure code and automation roles that have been granted broader rights than their job needs, so review role grants as part of the tuning.

Authentication anomalies on identity providers

Correlate interpreter activity with authentication events on the identity provider, such as a new sign-in location, a burst of failed attempts followed by success, or a session that starts a script host shortly after an unusual token request. Use a per-user baseline of sign-in geography and device, and raise severity only when an authentication anomaly and a host-side execution event occur in the same window. Main false positives: travel, VPN exit changes and shared service accounts, which should be identified and documented before enabling the rule.

How to validate that T1059 detections fire as intended

This sequence proves, in a lab or cyber range, that each T1059 detection fires on the benign interpreter activity it was written for, and it leaves a dated record of what fired, what was missed and which ATT&CK and rule versions were tested. Teams use that record to tune rules and to show their detection coverage is working.

Fix the ATT&CK and rule versions under test
Before any activity runs, the detection lead records the ATT&CK version the mapping targets, the exact version of each Sigma or vendor rule, and the log source configuration on each in-scope platform. ATT&CK can rename, deprecate or revoke techniques between releases, so the T1059 sub-technique mapping must name its version. The step closes when this manifest is signed off and stored with the test plan.
Define sub-techniques and platforms in scope
The team selects which of the 13 T1059 sub-techniques and which platforms (for example Windows, Linux, macOS, containers, ESXi, IaaS and identity provider logs) the exercise covers. Each in-scope sub-technique is matched to the data components the detection relies on, such as Process Creation and Command Execution. The step closes when every in-scope detection has a named owner and a named log source.
Agree rules of engagement with the range owner
The security lead, the range or lab owner, the system owners and the SOC agree in writing which hosts, accounts and time windows are used, who may stop the exercise, how benign activity is labeled, and how alerts raised during the test are handled so they are not confused with real incidents. Everyone who receives alerts is told the exercise window. The step closes with a signed rules of engagement document.
Run benign interpreter activity per detection
Testers perform harmless, documented interpreter actions that should match each in-scope detection, using a test script or a scenario agreed in the plan. Each run is logged with a unique identifier, the operator, the target and the start and end times, so the activity can be traced to its expected alert. The step closes when every planned action has been executed once and its identifier is recorded. This is a controlled test, not an attack script, and no payloads or evasion are used.
Record alerts, timestamps and missed events
The SOC and detection engineers compare the expected activity log with what reached the SIEM, such as Wazuh or Security Onion, and note for each run whether an alert fired, which rule and version produced it, the alert timestamp and the lag from the event time. Activity that produced no alert is recorded as a missed event with the most likely cause, such as a missing log source or a threshold. The step closes when every run has a result row in the test register.
Tune rules and document changes
For each missed or noisy result, the detection engineer adjusts the rule logic, the log collection or the thresholds, and records the change in version control with a reason and a link to the test row that triggered it. False positives from the benign activity are also logged so analysts know what to expect. The step closes when every change is reviewed and merged, and the register shows the rule version after each change.
Retest and retain the evidence
The same benign activity is run again against the tuned rules, and the results are compared with the first pass to confirm that previously missed events now fire and no new noise has appeared. The final register, the ATT&CK version, the rule versions and the test identifiers are stored as evidence for internal review or a compliance assessor. The step closes when the retest results are approved by the detection lead and the range owner.

Preventive controls mapped to T1059 mitigations

ATT&CK maps several mitigations to T1059 Command and scripting interpreter, and they work at different layers: who can run interpreters, what interpreters are allowed to execute, and what gets recorded when they run. The cards below cover the two mitigations most directly aimed at interpreter misuse, then the supporting controls that make them enforceable and reviewable.

Privileged account management

ATT&CK mitigation M1026 focuses on restricting and monitoring privileged accounts, so an interpreter run under an administrator or service identity carries far more impact than one run by a standard user. For T1059, the practical question is which identities can start shells, PowerShell sessions or hypervisor and cloud CLIs on servers and management planes. Check that admin rights are granted just in time where the platform allows it, that break-glass accounts are logged, and that interpreter access on domain controllers, ESXi hosts and cloud consoles is limited to named roles. Confirm each capability in your own environment rather than assuming it.

Execution prevention

ATT&CK mitigation M1038 covers controls that stop unapproved code from running, such as application allowlisting, script policy and signing requirements. For T1059, this is where an organization decides whether an interpreter can run arbitrary scripts from user-writable folders, whether macro-enabled or inline script content is blocked, and whether scripts must be signed before execution. Expect exceptions for admin tooling, and record each one with an owner and review date. Confirm which enforcement modes your endpoint and server products support, including audit-only modes, before you treat any block as in force.

User account management

ATT&CK mitigation M1018 addresses how accounts are created, changed and removed. Stale accounts, shared service identities and dormant administrator accounts give an attacker a valid login from which to open an interpreter session. For T1059, review which accounts can log on interactively or over remote management protocols, remove unused ones, and separate human and service identities. Confirm how your identity provider handles account lifecycle and whether interpreter-capable roles can be scoped by host group.

Behavior prevention on endpoint

ATT&CK mitigation M1040 covers endpoint controls that judge process behavior rather than file identity. For T1059, this means blocking or alerting on patterns such as an office application starting a shell, an interpreter spawning a download cursor, or encoded script content being decoded in memory. These controls depend heavily on vendor rule sets and tuning, so ask for evidence of which behaviors are blocked in prevention mode and which only raise alerts. Test them in the cyber range before relying on them.

Audit logging

ATT&CK mitigation M1047 is about deciding what gets recorded and keeping it. Interpreter misuse is only visible if process creation, command line and script block content are collected from endpoints, servers and management consoles. For T1059, confirm which of these your platforms log by default, where logs are forwarded, how long they are retained, and whether a detection engine such as Wazuh can read them. Missing command line capture is a common gap, so verify it during validation.

User training

ATT&CK mitigation M1017 is the human layer. Administrators and developers who routinely use shells and scripts are the people most likely to paste untrusted commands or run a script from an email or chat link. Training should explain which interpreter actions are expected in daily work, how to report an unexpected prompt or script, and when to stop and ask. Keep the material tied to your own tooling and runbooks, and rehearse the reporting path during cyber range exercises.

Triage and response when a T1059 alert fires

Start by confirming what actually ran. The first decision is whether the alert reflects a real interpreter execution or a mis-parsed event. Confirm the interpreter process name, its full command line, the user context it ran under, and the host or workload it ran on. Then check the parent process and what that parent was launched from, since an interpreter started by a scheduled job, a configuration management agent or an administrator's remote session reads very differently from one started by a document viewer or a web service. Pull the network connections opened by the process and its children in the same window. Record the findings in the case ticket before deciding anything else, so later steps can be checked against them. Ask your security operations team to write down which of these fields were available in your telemetry, because gaps here usually explain slow triage more than anything else.

Decide whether the activity is authorized, then scope it. Compare the activity against change records, runbooks and the owner of the account or workload. If no owner can confirm the activity within your agreed response window, treat it as unauthorized. Once that call is made, widen the search to related hosts and identities: other executions of the same interpreter with the same arguments, the same account authenticating from unfamiliar sources, and the same parent process on peer systems. For a privileged identity, review what that identity did after the alert, not only the single event. Contain in proportion to the evidence: disable or restrict the affected account, isolate the workload or host through your endpoint or orchestration tooling, and rotate any credentials the process could reach. Preserve memory, process listings, relevant logs and any script files before cleanup changes the host, and keep a chain of custody record for each artifact.

Feed the outcome back into detection tuning. Close each alert with a disposition that names the cause, such as an approved automation job, a misconfigured monitoring agent or a confirmed incident, and link it to the detection rule and the ATT&CK version it was written against. Recurring benign causes should lead to narrowly scoped allowlisting that names the account, parent process and host group, not a blanket exclusion. Review confirmed cases with the team to decide whether a new analytic or data source is needed. Document the decision and the owner of each tuning change so that auditors and future responders can trace why a rule behaves the way it does.

Rehearsing T1059 detection and response in a private cyber range

Build the range with a small set of Linux and Windows endpoints enrolled in the same log pipeline as production, with agents forwarding process and command telemetry to a Wazuh or Security Onion stack. Keep the topology close to your real estate, including a domain-joined Windows host, a Linux server with sudo logging enabled, and a jump host, so that analysts see the same event shapes they will meet in production. Schedule injects that run scripting interpreters in several forms, such as a PowerShell session, a Bash session and a Python one-liner, each with a benign payload that writes a marker file. Good detection means the Process Creation event, the parent process and the command line all reach the SIEM within the time your operations team has agreed to, and that a Sigma rule mapped to the relevant ATT&CK sub-techniques fires on the expected sub-technique. Good response means the analyst isolates the host through a documented playbook, preserves the command history and script block logs, and records the scope before anything is cleaned up. Record time to alert, time to triage decision, whether the correct sub-technique was assigned, and any gaps where logging was disabled or dropped. Confirm the exact log sources and agent versions with your SIEM vendor and your own environment before you schedule the injects.

Questions SOC leads ask about detecting T1059

How do we separate admin scripting from adversary use of interpreters?

Start by baselining who runs interpreters, from which hosts, under which accounts and at what times, then alert on deviations from that baseline rather than on the interpreter itself. Admin scripts usually come from known service accounts, signed or version-controlled repositories, and scheduled jobs with predictable parent processes. Adversary activity tends to show an unexpected parent process such as a document reader or web server, encoded or long command lines, downloads followed by execution, or an interactive session from an account that normally never runs scripts. Record the expected pattern for each admin workflow in your runbooks so analysts can confirm or reject an alert quickly.

Should we alert on every PowerShell, Bash or Python launch?

No. Alerting on every interpreter launch produces volume that analysts cannot review, and the signal gets lost. A more workable approach is tiered: low-severity logging for all interpreter process creation, and higher-severity alerts when the launch combines an unusual parent, an unusual user, a network connection, or obfuscated arguments. Process Creation (DC0032) and Command Execution (DC0064) are the data components to collect for this. Tune thresholds in a test environment first, and review false positive rates with the operations team before promoting any rule to paging.

How do we close logging gaps on ESXi and container hosts?

Gaps usually come from logs that never leave the host, from default retention that is shorter than your investigation window, or from interpreters that run inside containers without any host-level process record. Confirm which log sources each platform produces, forward them to a central store such as Wazuh or a Security Onion deployment, and test that events arrive with the expected fields. For ESXi, check the Application Log Content (DC0038) coverage available in your version. For containers, validate that runtime or host audit records capture command execution inside the container. Document each gap you cannot close as a formal risk with a compensating control.

How do we map detection rules to ATT&CK v20.0 sub-techniques?

Map each rule to the specific sub-technique it covers, such as the PowerShell, Unix shell, Python or visual basic variants, and record the ATT&CK version alongside the mapping. Use the enterprise-attack 20.0 STIX bundle published in the MITRE attack-stix-data repository as the authoritative reference for IDs and names, and check the ATT&CK updates pages for renames or deprecations before each release. Keep one spreadsheet or detection-as-code file that lists rule name, sub-technique ID, data components used, and last validation date. This makes coverage gaps visible and supports later audits.

How can we test T1059 detections without risking production?

Rehearse in a private cyber range that mirrors your production logging pipeline, identity provider and hosts, with no live business data. Run approved, labeled simulations of each sub-technique in a controlled window, confirm that the expected telemetry reaches the SIEM, and check that the rule fires with the right severity and context. Include negative tests, such as routine admin scripts, to measure false positives. DeployOpen runs private cyber ranges and security testing as part of its services, and the written scope should name the environments, the simulated activity and the rules under test before work starts.

How often should we retest T1059 detections after rule changes?

Retest every affected rule after any change to the rule, the log source, the parser, the interpreter version, or the ATT&CK version you target, and run a scheduled regression pass on the full set at a cadence your risk team agrees on. The cost driver is mostly staff time for building and maintaining test cases, plus the range environment if you run it internally. Recurring work includes keeping test cases current with ATT&CK releases, such as v18, v19 and v20, which can rename or deprecate techniques. Ask any partner to quote retesting as a separate retainer or as a fixed-scope exercise so the recurring effort is visible.

How DeployOpen builds T1059 detections and range exercises

DeployOpen treats T1059 Command and scripting interpreter as a fixed-scope engagement inside your own infrastructure. We agree in writing which platforms, telemetry sources and sub-techniques are covered, then build and test detections against that scope and document them for your team to run.

How we scope

Agree in writing which platforms carry T1059 telemetry, such as containers, ESXi, IaaS and identity providers.
Confirm which of the 13 sub-techniques are in scope and which are excluded or deferred.
Map telemetry sources such as Process Creation and Command Execution to the detection strategies in the ATT&CK version you target.

How we build

Build detection logic in open-source tooling such as Wazuh, Sigma rules and Zeek, using your existing log pipeline where possible.
Write detection logic in plain language so analysts can review intent, not only syntax.
Test each detection against benign administrative activity to measure false positive exposure before handover.

How we hand over

Deliver documentation naming the ATT&CK version, data components, mitigations and detection owners for each rule.
Run a cyber range exercise so responders rehearse the T1059 detection and response path in a private environment.
Record validation results and open gaps in a handover report that your security team keeps.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends.
Review detection mappings when ATT&CK releases rename, deprecate or revoke techniques that T1059 depends on.
Confirm with your team which support scope, response hours and change process apply before work starts.

T1059 Command and scripting interpreter