Skip Navigation
Get a Demo
 
 
 
 
 
 
 
 
 
 

Technique T1064

Scripting

Adversaries continue to evolve their use of Scripting in response to improved application controls. Routinely among our top threats, malicious scripts are performant, available, and inconspicuous.

Editors’ note: While the analysis and detection opportunities remain applicable, MITRE has depreciated this technique and this page has not been updated since 2020. 

Analysis

Why do adversaries use Scripting?

Scripting is a relatively broad technique that covers a wide array of behaviors, many of them involving the use of tools and languages that are functionally critical components of operating systems. Scripts are as versatile as they are ordinary, which makes it difficult to baseline normal scripting activity and build detection strategies for abnormal scripting activity.

Because continued improvements to (and adoption of) application control solutions make it difficult to install a malicious binary on a host machine, scripts allow adversaries to perform actions without having to install anything. There is also no shortage of publicly available scripts—malicious and benign—that administrators or adversaries can find on the internet and use to perform all variety of actions.

How do adversaries use Scripting?

Adversaries use scripts to perform actions on an endpoint. This might include using a script to download something from an external host, embedding a script in an email attachment as part of a phishing campaign, embedding binaries that might be blocked into a script, or writing a script that automates and expedites otherwise tedious work that would have to be done by hand.

We routinely observe:

  • Direct execution of local scripts via default scripting harnesses (e.g., cscript.exe and wscript.exe)
  • Execution of a script within a process that can execute scripts (e.g., cmd.exe or PowerShell)
  • Execution of processes such as rundll32.exe with a script host scheme
  • Identification and exploitation of vulnerable, trusted scripts, such as pubprn.vbs

The adversary behaviors we observe most commonly involve Windows script hosts (e.g., cscript.exe or wscript.exe) or other popular scripts (e.g., JavaScript or Visual Basic Script) making network connections to an external host.

Emerging tactics

Some less common malicious Scripting methods include:

  • Adware and malware installers on macOS using obfuscated script content that deobfuscates at runtime (e.g., Shlayer and Bundlore)
  • Scripts that are dynamically created at runtime (e.g., impacket smbexec does this to write commands to disk temporarily)

Sighted with

We frequently detect adversaries using Scripting in conjunction with other techniques, most notably Mshta (T1170) and Deobfuscate/Decode Files or Information (T1140). Mshta can be used as a proxy to execute scripts, and, as a result, we have a high volume of analytics that trigger on and map to both Scripting and Mshta-related activity. Co-occurence with Deobfuscate/Decode Files or Information is more obvious, as it is commonplace for adversaries to obfuscate their scripts.

Definition

Detection

MITRE’s data sources

  • Process monitoring
  • File monitoring
  • Process command-line parameters

Collection requirements

For all the various ways an adversary might leverage Scripting, there are two general approaches for gathering the visibility needed to detect and investigate Scripting activity. For one, you can target malicious use of Scripting by focusing on the means of execution. Valuable data sources for this approach include:

  • Process monitoring (including process network actions and module loads)
  • Process command-line parameters

Alternatively, you could also focus on data sources that help with detecting and investigating the actual contents of malicious scripts. In this case, it’s critically important to monitor files and collect the actual scripts. While this will almost certainly be time intensive—both in terms of machine processing and analysis—it will also provide important context.

Detection suggestions

We’ve produced effective analytics by focusing on script host process telemetry. Specifically, it makes sense to look out for abnormal activity emanating from processes that are capable of running scripts. Such abnormal activity might include:

  • Establishment of persistence mechanisms
  • Making network connections
  • Unexpected process ancestry

You may want to look for wscript.exe or cscript.exe spawning from command shells (e.g., cmd.exe or powershell.exe), Office applications, web browsers, and web service handlers. Also look out for scripts executing from unusual locations, including user-writable paths and temporary directories.

Some adversaries attempt to execute scripts from hosts in abnormal ways, so it’s a good idea to monitor for suspicious module loads of binaries related to hosting scripts (e.g., vbscript.dll).

Weeding out false positives

While you will almost certainly find malice by alerting on scripting engines that make external network connections, doing so will also overwhelm you and your team with a high volume of false positives. As always, be specific in your detection logic and robust in your suppression logic, so you can control false positives while casting an effectively wide net for suspicious activity.

Testing

Getting Started With Atomic Red Team

Start testing your defenses against Scripting using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.

Getting started

View Atomic tests for T1064: Scripting. In most environments, these should be sufficient to generate a useful signal for defenders.

Run this test on a Windows system using PowerShell:
New-Item $env:TEMP\T1064_script.bat -Force | Out-Null
Set-Content -Path $env:TEMP\T1064_script.bat -Value "dir"
Start-Process $env:TEMP\T1064_script.bat

Useful telemetry will include:

Data sourceTelemetry
Data source:

Process monitoring

Telemetry:

powershell.exe, cmd.exe

Data source:

File monitoring

Telemetry:

write and execute from appdata\local\temp

Review and repeat

Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:

  • Were any of your actions detected?
  • Were any of your actions blocked or prevented
  • Were your actions visible in logs or other defensive telemetry?

Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.

 
 
Back to Top