T0853: Scripting
Adversaries may use scripting languages to execute arbitrary code in the form of a pre-written script or in the form of user-supplied code to an interpreter. Scripting languages are programming languages that differ from compiled languages, in that scripting languages use an interpreter, instead of a compiler. These interpreters read and compile part of the source code just before it is executed, as opposed to compilers, which compile each and every line of code to an executable file. Scripting allows software developers to run their code on any system where the interpreter exists. This way, they can distribute one package, instead of precompiling executables for many different systems. Scripting languages, such as Python, have their interpreters shipped as a default with many Linux distributions.
In addition to being a useful tool for developers and administrators, scripting language interpreters may be abused by the adversary to execute code in the target environment. Due to the nature of scripting languages, this allows for weaponized code to be deployed to a target easily, and leaves open the possibility of on-the-fly scripting to perform a task.
Analyst context for executives and security teams
Scripting matters in ICS because the same interpreters that help engineers and administrators maintain systems can also let an adversary run arbitrary code without bringing a traditional compiled executable. For business leaders, the concern is not “scripts” in the abstract; it is whether script execution is controlled and visible on systems that support operations, including workstations, HMIs, historians, control servers, application servers, gateways, jump hosts, switches, and firewalls.
Executive priority
Prioritize this as an operational resilience and control-governance issue. Ask which ICS assets are allowed to run scripting interpreters, who can use them, whether script execution is logged, and whether application control or script blocking is enforced where appropriate. ATT&CK maps this technique to notable ICS campaigns, groups, and software, so it is useful for tabletop exercises, audit evidence, and incident-response readiness, but the supplied data does not support any claim of current activity against your environment.
Technical view
SOC, detection engineering, and IR teams should validate coverage around interpreter use, script file creation/modification, and script execution on the ICS asset classes identified in the relationships. Because ATT&CK provides no official detection text and no explicit technique platforms or tactics, teams should not assume coverage from generic endpoint monitoring alone. Use DET0735 as the ATT&CK-linked detection strategy reference, then test whether logs exist and are normalized for workstations, HMIs, historians, control servers, application servers, data gateways, jump hosts, switches, and firewalls where scripting capability exists.
Likely telemetry
- Process execution records for scripting language interpreters where available
- Script file creation, modification, and execution metadata
- Application control, script blocking, and execution-prevention events
- Administrative and engineering workstation activity logs
- HMI, historian, control server, and application server audit logs where supported
Detection direction
- Inventory approved scripting interpreters and compare observed use against expected engineering, administration, and maintenance workflows.
- Tune detections for scripting on high-consequence ICS assets, especially jump hosts, HMIs, historians, control servers, and application servers.
- Separate legitimate operational scripts from unusual interactive, user-supplied, or newly introduced scripts to reduce false positives.
- Correlate script execution with remote access sessions, change windows, asset role, and user identity rather than alerting on interpreter use alone.
- Validate that DET0735-style detection content is supported by real telemetry in the local environment; ATT&CK does not provide detection detail for this object.
Mitigation priorities
- Start with necessity: remove or deny access to unnecessary scripting features or programs, aligned to M0942.
- Apply execution prevention using application control and/or script blocking where operationally safe, aligned to M0938.
- Use application isolation or sandboxing for code execution paths where scripts must be handled but should not directly affect endpoint systems, aligned to M0948.
- Define approved scripts, owners, maintenance windows, and change-control evidence for ICS assets that require scripting.
- Test controls with operations teams before enforcement on safety- or availability-sensitive systems.
Analyst notes and limits
The decision value is in distinguishing legitimate engineering automation from uncontrolled code execution capability. This technique is especially material in ICS because the related assets include operator-facing systems, remote access paths, data collection systems, control-support servers, and network boundary devices. The relationship set also links this behavior to historical ICS campaigns and software, supporting threat-informed validation without implying current targeting.
The supplied ATT&CK object has no official detection guidance, no listed tactics, and no explicit platform list for the technique itself. Platform references come from related ICS assets, not from the technique platform field. Local asset inventory, interpreter inventory, logging configuration, and operational change processes are required to determine actual exposure and detection coverage.
Scripting
Adversaries may use scripting languages to execute arbitrary code in the form of a pre-written script or in the form of user-supplied code to an interpreter. Scripting languages are programming languages that differ from compiled languages, in that scripting languages use an interpreter, instead of a compiler. These interpreters read and compile part of the source code just before it is executed, as opposed to compilers, which compile each and every line of code to an executable file. Scripting allows software developers to run their code on any system where the interpreter exists. This way, they can distribute one package, instead of precompiling executables for many different systems. Scripting languages, such as Python, have their interpreters shipped as a default with many Linux distributions.
In addition to being a useful tool for developers and administrators, scripting language interpreters may be abused by the adversary to execute code in the target environment. Due to the nature of scripting languages, this allows for weaponized code to be deployed to a target easily, and leaves open the possibility of on-the-fly scripting to perform a task.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Groups, software, and campaigns
G0064: APT33
G0049: OilRig
OilRig is a suspected Iranian threat group that has targeted Middle Eastern and international victims since at least 2014. The group has targeted a variety of sectors, including financial, government, energy, chemical, and telecommunications. It appears the group carries out supply chain attacks, leveraging the trust relationship between organizations to attack their primary targets. The group works on behalf of the Iranian government based on infrastructure details that contain references to Iran, use of Iranian infrastructure, and targeting that aligns with nation-state interests.[1][2][3][4][5][6][7]
S1009: Triton
S0496: REvil
REvil is a ransomware family that has been linked to the GOLD SOUTHFIELD group and operated as ransomware-as-a-service (RaaS) since at least April 2019. REvil, which as been used against organizations in the manufacturing, transportation, and electric sectors, is highly configurable and shares code similarities with the GandCrab RaaS.[1][2][3]
C0030: Triton Safety Instrumented System Attack
Triton Safety Instrumented System Attack was a campaign employed by TEMP.Veles which leveraged the Triton malware framework against a petrochemical organization.[1] The malware and techniques used within this campaign targeted specific Triconex Safety Controllers within the environment.[2] The incident was eventually discovered due to a safety trip that occurred as a result of an issue in the malware.[3]
C0034: 2022 Ukraine Electric Power Attack
The 2022 Ukraine Electric Power Attack was a Sandworm Team campaign that used a combination of GOGETTER, Neo-REGEORG, CaddyWiper, and living of the land (LotL) techniques to gain access to a Ukrainian electric utility to send unauthorized commands from their SCADA system.[1][2]
C0025: 2016 Ukraine Electric Power Attack
2016 Ukraine Electric Power Attack was a Sandworm Team campaign during which they used Industroyer malware to target and disrupt distribution substations within the Ukrainian power grid. This campaign was the second major public attack conducted against Ukraine by Sandworm Team.[1][2]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | ac0ca709c0c7… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack T0853Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.