Skip Navigation
Get a Demo
 
 
 
 
 
 
 
 
 
Resources Blog MITRE ATT&CK

Adversaries use scripting more than any ATT&CK technique except PowerShell

Brian Donohue
Originally published . Last modified .

Scripts provide a versatile mechanism for automating task execution at nearly every phase of an attack. If you can imagine it, then you can probably script it. So it makes perfect sense that scripting (T1064) is the second most prevalent MITRE ATT&CK™ technique among confirmed threats in the environments we monitor.

This is the fifth and final installment of a blog series where we’ve been examining each of the top five ATT&CK techniques from our 2019 Threat Detection Report. If you missed any of the prior blogs, you may want to go back and read them:

Alternatively, feel free to download a full copy of our 2019 Threat Detection Report and watch an on-demand webinar discussing the findings.

Why is T1064 prevalent?

Advances in security tooling and human analysis have made it far more difficult for adversaries to introduce overt binary payloads and execute them from disk. As a result, adversaries need to find alternative methods for executing payloads and performing other malicious activities, which accounts for much of the rising prevalence of scripting-related techniques. Add to this the same principles that apply to all techniques relying on native platform utilities such as PowerShell and regsvr32: the runtime environment, libraries, and executables leveraged by this technique are core components of every modern computing platform, cannot be easily disabled, and are not consistently and closely monitored.

Circumstance, however, only tells part of the story. There have also been breakthroughs in methods for escaping script-host constraints, particularly on Windows platforms but also on macOS, which have presented new options for adversaries. What was once difficult via scripting is now trivial; for example, it’s very straightforward for an adversary to make an arbitrary API call rather than having to rely exclusively on sanctioned scripting objects.

Beyond the normal scripting hosts such as WScript and CScript, which are the default binaries to host and execute scripts on Windows systems, there are also a number of trusted applications that can execute scripts, including MSXSL and WMIC. This means that scripts can be used by binaries that one may not expect to load and execute scripts. Make no mistake: scripting languages are often as performant and powerful as any binary application. As such, while our wariness about binaries may have necessitated a transition to scripting, scripting has proven a more than sufficient replacement for traditional, native code and the corresponding traditional delivery mechanisms.

Prominent examples

APT1

The group known as APT1, perhaps the most well-known cyberespionage group of all, was said to have deployed batch scripts in the early reconnaissance phase of its attack campaigns. Known as the subject of a sweeping Mandiant report from 2012, APT1 is thought to have compromised the networks of, and stolen proprietary and other information from, more than 150 organizations in the private and public sectors in primarily English-speaking countries. The group leverages scripting to conduct reconnaissance, including custom batch scripts designed to gather system configuration information, enumerate running services and processes, list accounts with administrative privileges, and gather other important data.

Smoke Loader

From the world of cybercrime, the Smoke Loader trojan, which installs additional malware on the machines it compromises, leverages scripting to launch its payload. More specifically, Smoke Loader saves a Visual Basic script that automates the execution of its payload in the startup folder for Windows, thereby executing itself each time a user logs in.

Detection strategies

According to MITRE, there are a number of data sources associated with scripting, and having access to these will help security teams detect adversaries using the technique in their environments.

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

Adversaries can leverage scripting in multiple ways:

  • Direct execution of a local script via default scripting harnesses. Examples might include Windows Script Host (wscript.exe, cscript.exe) or Python
  • Executing within a process that can execute scripts
  • On Windows, rundll32.exe with a script host scheme
  • Identification and exploitation of vulnerable scripts such as pubprn.vbs

On Windows, the simplest detection use cases for Windows Script Host (WSH) are based on process ancestry. This Includes monitoring for wscript.exe or cscript.exe being spawned from command shells (cmd.exe, powershell.exe), Office applications, web browsers, and web service handlers. It is also advisable to monitor for scripts executing from non-standard locations, such as user-writable paths including appdata\local\*, others like it, and temporary directories.

Monitoring process metadata, process command lines, and file modifications are invaluable strategies. In addition, instrumenting systems to observe suspicious module loads of binaries related to hosting scripts, such as vbscript.dll, are worthwhile strategies.

You may choose to disable Windows Script Host, or you can force scripts to be signed, ensuring that only approved scripts are executed. Tools like AppLocker also provide additional constraints related to script execution. These are prevention strategies, but are also useful for detection purposes, as attempted execution of an unauthorized script should produce a higher-quality signal.

What’s ahead?

Scripting as an adversarial technique will get worse before it gets better. The dynamic nature and performance of scripts put them on par with nearly any binary resource an adversary could use. As more organizations adopt application control solutions, scripting will become more attractive, and new techniques will evolve.

 

The dark side of Microsoft Remote Procedure Call protocols

 

Research ATT&CK techniques from the comfort of your VSCode editor

 

Remapping Red Canary with ATT&CK sub-techniques

 

Nothing to hide: seeking out rootkits

Subscribe to our blog

 
 
Back to Top