Cybercriminals are increasingly “living off the land”—using tools that are already installed on the systems they break in to, in the hope that their activity won’t trigger any alarms.

Among their favorite tools are scripting engines that sysadmins commonly use, like PowerShell, which they like for exactly the same reasons as sysadmins do—because they make it easy to automate system administration jobs and create complex commands. Criminals also like scripting engines because it’s extremely difficult for organizations to block them, precisely because they’re so important to the normal administration of their systems.

So, these days, securing your systems needs to include the tricky task of making the scripting engines your organization likes easy for your admins to use, and hard or impossible for your adversaries to use.

Here are five scripting engines that are popular with both ransomware gangs and sysadmins, and what you can do to harden them:

PowerShell

Microsoft’s PowerShell is a powerful tool that is very popular with both criminals and admins. It isn’t practical to block PowerShell completely in most organizations, but there are other ways to rein it in.

The first step towards making it harder for criminals to use PowerShell is to ensure that it is only available to specific administration accounts.

Many criminals use PowerShell in the initial stages of attacks, often by executing highly obfuscated scripts in .ps1 files that are triggered as Scheduled Tasks or other AutoRun options. If your organization typically uses PowerShell scripts through the command line and doesn’t use .ps1 files, then removing the association between .ps1 files with PowerShell may be an option.

Another way to blunt criminal use of .ps1 files is to store them in one folder and configure PowerShell so it can only execute scripts there.

Restricting how PowerShell can be used makes life more difficult for attackers, but your organization still needs to be able to identify potentially malicious PowerShell use. Whoever looks at the organization’s EDR alerts needs to understand how PowerShell is and is not normally used in that environment.

Windows Management Instrumentation (WMI)

Windows Management Instrumentation (WMI) is a Microsoft framework that administrators use to configure systems, execute processes or scripts, and automate tasks.

WMI can be used by attackers for lateral movement, data exfiltration, and to establish Command and Control (C2) access. For example, the Fog ransomware group has used WMI for lateral movement, and Akira has used it to delete volume shadows, which could have been used to recover encrypted files.

WMI Event Registration can be very useful in detecting suspicious use of WMI, particularly when combined with tools like Sysmon. Sysmon logs specific WMI-related events (Event IDs 19, 20, and 21) that track the creation of event filters, consumers, and bindings that are rarely used by legitimate software.

Windows Script Host (WSH)

WSH is a language-independent system that can use different scripting engines, including VBScript and JavaScript. Microsoft describes it as an administration tool that can be used for a variety of purposes, including logon scripts, administration, and general automation.

Scripts are often used in the first stage of an attack to profile a target’s computer and download other malware, such as droppers.

If you don’t want to block WSH entirely, you can remove the association between file extensions and WSH, so that double-clicking on those files won’t cause them to run.

WSH typically handles these file extensions:

• .vbs (VBScript)
• .js (JScript)
• .wsf (Windows Script File)
• .wsh (Windows Script Host Settings File)

If you want to check whether a certain file type is associated with WSH, open a command prompt and type, for example: assoc .vbs. If you want to remove the association, type: assoc .vbs=. Should you regret it later, you can correct it by typing: assoc .vbs=VBSfile

Microsoft HTML Applications (MSHTA)

Mshta.exe is a native file on Windows systems that can execute .hta files—even remote ones—or to trigger inline scripts written in VBScript or JavaScript.

There are several examples of different threats leveraging mshta.exe during initial compromise and for execution of code. For example, The TellYouThePass ransomware group used an exploit for CVE-2024-4577 to make mshta.exe run malicious .hta files from remote, attacker-controlled, locations.

In most modern environments, mshta.exe is not required for regular operations. By restricting or removing it, system administrators can significantly reduce their attack surface and mitigate a common malware vector.

AutoIt

AutoIt v3 is a general-purpose, third-generation programming language designed for automating the Windows GUI, and general scripting. AutoIt can be used by attackers to leverage legitimate Windows tools, like the Background Intelligent Transfer Service (BITS) user agent, for malicious activities.

For system administrators and attackers alike, AutoIt has the advantage that AutoIt automation scripts can be converted into a compressed, standalone executable which can be run on computers even if they do not have the AutoIt interpreter installed. Unfortunately, this also comes with a disadvantage. Malicious executables created with AutoIt can be named anything the attacker chooses, which makes them harder to block.

General protection

The key to identifying malicious use of legitimate tools is knowing what is and is not normal in your environment. However, there are few things that can be helpful in most environments:

• Segment networks to protect against lateral movement.
• Restrict remote access to powerful tools wherever possible.
• Restrict access to admin tools and scripting engines.

If you are using ThreatDown, you can create Application Block rules for:

• powershell.exe (for PowerShell)
• powershell_ise.exe (for PowerShell ISE)
• pwsh.exe (for PowerShell Core/7)
• wmic.exe (for WMI Command-line)
• wbemtest.exe (for WMI Tester)
• wscript.exe (for Windows Script Host)
• cscript.exe (for Windows Script Host – console version)
• mshta.exe (for MSHTA)
• AutoIt3.exe (for AutoIt)

Blocking these scripting engines can slow down an attacker, make them less dangerous, and make their activity more obvious, but it may not be enough to stop an attack entirely. So, while controlling scripting engines is an important step, it should be part of an approach of defense-in-depth that includes protection technologies like MDR.

ThreatDown’s team of dedicated MDR analysts monitors your network 24×7, responding to alerts in real-time. Get in touch with ThreatDown MDR today here and make sure your network is protected every hour of the day.