PowerShell used as a tool in compound malware attacks is becoming more common, with 38% of all attacks seen by IT security vendor CarbonBlack and its partners involving the native Windows scripting language.
Its use is so common in enterprises for legitimate purposes that most security devices and personnel don’t regard it as a threat, says Ben Johnson, the chief security strategist at CarbonBlack.
That makes it all the more effective as a component of attacks. Its scripts can run in memory only so it never creates a file on disk, Johnson says. “It creates less noise on the system,” so it’s less likely to draw attention to itself, he adds.
It’s also relatively easy to write a script for, making it more productive for attackers to write a PowerShell script than to create compact binary code that would accomplish the same goal, he says.
PowerShell’s versatility is a strength but is also a downside when it’s viewed as an attack tool. In that sense, “PowerShell is too powerful,” Johnson says.
There’s no sure-fire way to stop this malicious use of PowerShell, but security pros can start by monitoring its use to discover how it is being used legitimately and by what applications. In most cases, for example, Microsoft Office applications don’t spawn PowerShell as a process, so that use would be considered suspicious.
If security pros log PowerShell activity and analyze it for anomalies then they can write rules to create alerts about known abnormal activity.
They should also look at the command lines. Often legitimate scripts have lines such as “Ben’s Cleanup Script” that give an intuitive sense of its purpose. Attackers often use Base64 encoding on the command line, often incorporating the entire script in the line. “You’ll see it with crazy arguments that humans would never use,” he says.
Ben Johnson, chief security strategist at CarbonBlack
Security pros should identify who has a need to use PowerShell and others should be restricted from using it. Admins legitimately use it to help with upgrades and patches, but HR staff and the CFO’s office probably don’t need it, he says. Use of PowerShell can also be restricted to certain time windows to make it more difficult for attackers to sneak it by unnoticed.
As it evolves, PowerShell is gaining security features, so upgrading to a newer version can help. For example, PowerShell 5.0 supports better logging, including for deobfuscated code so it is executed, according to “’PowerShell’ Deep Dive: A Unified Threat Research Report” written by CarbonBlack. “Note that newer versions of PowerShell are not supported on older versions of Windows, so you may not be able to fully upgrade all systems,” the report notes.
The report recommends setting standards for how PowerShell should be used:
- Change ExecutionPolicy to only allow signed scripts to run.
- Require all PowerShell scripts to be run from a specific location or path.
- Discourage (or require exception for) the use of encoded parameters on the command line.
- Discourage (or block) PowerShell scripts from downloading content from the Internet (or specify a “whitelist” of allowed IP addresses only).
- Discourage (or block) the use of PowerShell to invoke commands on remote systems.
- Require a custom parameter to be passed on all “legitimate” PowerShell usage.
- Restrict PowerShell to specific users in your organization.
- Require PowerShell to be launched from a specific process.
A relatively new iteration of ransomware called PowerWare is an example of PowerShell used maliciously. Distributed mainly via phishing attacks, PowerWare initiates as macros within emailed Word attachments. The macros launch an .exe file that starts up two PowerShell instances, one to download the ransomware script and the other to implement it.
PowerShell gives the attacker freedom of movement within the compromised network. “You become an employee of your target,” Johnson says.