Not to ruin anyone’s childhood, but the havoc-wreaking blue shell from Nintendo’s Mario Kart series is not, in fact, called the PowerShell. It should be, but it is not.
No, that high honor belongs to Microsoft’s task-based command-line shell and scripting language. That’s a mouthful, but in short: PowerShell helps administrators and other power users string a bunch of otherwise repetitive, boring, awful, manual steps together into an automated amalgamation of awesomeness. If there is a poster child for the old “work smarter, not harder” mantra, it’s PowerShell.
So, PowerShell is great for administrators in that it can greatly reduce the amount of time and effort it takes to manage and configure Windows. But much like the blue shell in Mario Kart, it can also wreak havoc when it’s used as an attack mechanism. It has access to things like file systems, registries, certificate stores, and a whole host of other sensitive data.
The issue is that PowerShell is generally treated as a trusted application by security software – heck, it’s part of Windows – so it has become increasingly popular for malware authors to leverage PowerShell in order to slip bad stuff onto good machines.
Some notable Powershell threats in recent years have included:
- PowerWare: a ransomware leveraging Powershell and MS Word macros
- POWELIK: a malware that burrows and hides itself within Windows Registry
- A variety of exploits used by the espionage group, Turla
Instead of trying to load executable malware files, which anti-virus software often catches, bad guys look to gain control of PowerShell and use it to load malware directly into the computer’s memory, bypassing the need to execute it as a program from the disk – also known as a “fileless” malware attack, or living off the land (LotL). Imagine the mess you could make by sneakily sequencing a series of attacks from a tool that Windows trusts!
How Can I Reduce Exposure to PowerShell Attacks?
Admins are already busy maintaining all systems running onsite and remotely, so the extra demand to protect against fileless threats can be overwhelming for manual security operations and inexperienced IT professionals. There are, however, five basic steps you can take to help mitigate the threat:
1. Ensure Use of PowerShell version 5 (or higher)
PowerShell version 5 provides more enhanced security and logging capabilities – from anti-malware scanning, script block logging and transcription. Previous versions of PowerShell offered little to no logging abilities and should be avoided. All the new features in PowerShell v5 offer improved usability and allow you to control and manage Windows-based environments more easily and comprehensively.
2. Upgrade your Operating Systems to Windows 10
While not entirely without faults, Windows 10 is still the most secure Windows operating system to date. In it, PowerShell's improvements go further than just logging capabilities. The framework added a new constrained language mode to create even more visibility and control over the commands PowerShell users can execute. Windows 10 also expanded security capabilities by integrating the Windows Antimalware Scan Interface (AMSI) for deeper operating system visibility.
3. Stay up to date with patching
Okay this might seem like basic advice, but always apply the latest patches and keep your systems updated. Fileless attacks are known to exploit vulnerabilities in trusted whitelisted applications. Attackers can and will exploit whitelisted application vulnerabilities to embed and execute their malicious scripts or codes – all made possible from gaining the privileges of the application. A strong patch management policy that balances productivity and security is highly recommended.
4. Limit Administrative Access (think least privilege)
An effective Privilege Management solution can limit who can run PowerShell commands/scripts and at what level of privilege. Elevated use of the shell can be controlled, challenging for approval from IT, or simply creating an audit trail when high-privilege users start flexing their PowerShell muscles. That attacker would immediately hit a dead end when he or she tried to use this instance of PowerShell to carry out an attack. The organization has neutered the PowerShell access; ergo, the attacker is also neutered.
5. Deploy Effective Application Control Policies
Application control policies can restrict the use of Powershell to those who shouldn’t need access in their role, stopping any Powershell attack in its tracks.
Where blocking is too restrictive, whitelisting trusted applications with simple rules means authorized Powershell scripts can run while the unknown (user or malware introduced) are blocked (or at least challenged).
If the malware is fileless and loads the payload into memory, BeyondTrust can block/trust based on criteria, such as command line (blocking known Powershell commands that are used to bypass security restrictions for example).
If an end-user’s role requires them to create or introduce their own scripts, whitelisting alone may prevent them from being productive. To reduce the risk this role presents, advanced application control (Trusted Application Protection) can create a safety net for even the most ‘cyber aware’ techies. For example, if PowerShell is launched as a child process to a content reader, in a social engineering attack, it can be blocked. If launched by the user via File Explorer, the application runs as expected.
Defending against PowerShell attacks is complicated and far from straightforward. The good news is that, much like finding an invincibility star in Mario Kart, there’s hope!
For more information about defending against fileless attacks, check out these resources:
