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.
| ID | Name | Description |
|---|---|---|
| C0025 | 2016 Ukraine Electric Power Attack |
During the 2016 Ukraine Electric Power Attack, Sandworm Team utilized VBS and batch scripts for file movement and as wrappers for PowerShell execution.[1] |
| C0034 | 2022 Ukraine Electric Power Attack |
During the 2022 Ukraine Electric Power Attack, Sandworm Team utilizes a Visual Basic script |
| G0064 | APT33 |
APT33 utilized PowerShell scripts to establish command and control and install files for execution. [3] [4] |
| G0049 | OilRig |
OilRig has embedded a macro within spearphishing attachments that has been made up of both a VBScript and a PowerShell script.[5] |
| S0496 | REvil |
REvil utilizes JavaScript, WScript, and PowerShell scripts to execute. The malicious JavaScript attachment has an obfuscated PowerShell script that executes the malware. [6] |
| S1009 | Triton |
Triton communicates with Triconex controllers using a custom component framework written entirely in Python. The modules that implement the TriStation communication protocol and other supporting components are found in a separate file -- library.zip -- the main script that employs this functionality is compiled into a standalone py2exe Windows executable -- trilog.exe which includes a Python environment. [7] |
| C0030 | Triton Safety Instrumented System Attack |
In the Triton Safety Instrumented System Attack, TEMP.Veles used a publicly available PowerShell-based tool, WMImplant.[8] |
| ID | Asset |
|---|---|
| A0008 | Application Server |
| A0007 | Control Server |
| A0009 | Data Gateway |
| A0006 | Data Historian |
| A0002 | Human-Machine Interface (HMI) |
| A0012 | Jump Host |
| A0001 | Workstation |
| ID | Mitigation | Description |
|---|---|---|
| M0948 | Application Isolation and Sandboxing |
Consider the use of application isolation and sandboxing to restrict specific operating system interactions such as access through user accounts, services, system calls, registry, and network access. This may be even more useful in cases where the source of the executed script is unknown. |
| M0942 | Disable or Remove Feature or Program |
Consider removal or disabling of programs and features which may be used to run malicious scripts (e.g., scripting language IDEs, PowerShell, visual studio). |
| M0938 | Execution Prevention |
Execution prevention may prevent malicious scripts from accessing protected resources. |
| ID | Data Source | Data Component | Detects |
|---|---|---|---|
| DS0017 | Command | Command Execution |
Monitor command-line arguments for script execution and subsequent behavior. Actions may be related to network and system information Discovery, Collection, or other scriptable post-compromise behaviors and could be used as indicators of detection leading back to the source script. Scripts are likely to perform actions with various effects on a system that may generate events, depending on the types of monitoring used. |
| DS0011 | Module | Module Load |
Monitor for events associated with scripting execution, such as the loading of modules associated with scripting languages (e.g., JScript.dll, vbscript.dll). |
| DS0009 | Process | Process Creation |
Monitor log files for process execution through command-line and scripting activities. This information can be useful in gaining additional insight to adversaries' actions through how they use native processes or custom tools. Also monitor for loading of modules associated with specific languages. |
| Process Metadata |
Monitor contextual data about a running process, which may include information such as environment variables, image name, user/owner, or other information that may reveal abuse of system features. |
||
| DS0012 | Script | Script Execution |
Monitor for any attempts to enable scripts running on a system would be considered suspicious. If scripts are not commonly used on a system, but enabled, scripts running out of cycle from patching or other administrator functions are suspicious. Scripts should be captured from the file system when possible to determine their actions and intent. |