How to protect your network from PowerShell exploits

Hikers living off the land make use of existing nutrients and water sources to survive in the wilderness. In hacker parlance, the term “survive in the wilderness” means they cover their tracks and make use of tools and code that already exist on targeted endpoints. This hides their exploits by making them look like common administrative tasks so that detection tools can’t easily find them. Welcome to the world of PowerShell-based attacks.

PowerShell has deep roots in the DOS command line that came with the first IBM PCs back in the 1980s and the .NET universe. It is now the default command shell that is packaged in the current Windows 10 version. PowerShell has been around for more than a decade in one form or another. It comes bundled with Windows since version 7, and now has Linux versions as well. That widespread use can only encourage hackers to abuse it in the future.

PowerShell has become increasingly sophisticated, and a primer on essential PowerShell security scripts is well worth reviewing to learn how you can use that language to improve your defenses and be more productive in administering Windows computers. This article shows you how attackers can leverage this language for their own evil purposes. 

PowerShell is versatile, but dangerous

PowerShell has a lot of versatility, since it can execute a variety of commands that can directly examine and change particular Windows resources such as Registry objects, environment variables, the Windows Management Interface, and programs stored in memory. You can use it to administer Exchange functions and other Windows server tasks. It can install scripts that execute at boot time, which makes them attractive for hackers that want the scripts to persist.

Sadly, many antivirus (AV) tools typically have ignored PowerShell scripts, but that is changing as more malware is leveraging their use. A recent report by Symantec found that more than 95 percent of all scripts analyzed by its sandbox tool were malicious and more than half executed from command line parameters. For a file to get Symantec’s attention, it had to be a bit wonky to begin with, but still the numbers are sobering. The scripts causing alarm included Office macros, malicious JavaScript code, fileless injection attacks, and ways to hide suspicious downloads or URLs in phishing emails.

One of the challenges about PowerShell is that it is found in so many different legitimate Windows routines and launched and packaged in so many ways. You can’t just block it universally across your enterprise without preventing users from getting actual work done. 

Why hackers like PowerShell

PowerShell is a hacker’s playground for several important reasons:

• It generates few traces by default, making its operations hard to track with defensive tools and forensics.
• Defenders often overlook it as a potential infection source when doing their analysis of attacks.
• Many sandbox routines don’t closely look at its scripts.
• Many Windows sysadmins automatically trust PowerShell scripts, not realizing that they may contain malware.
• PowerShell can create various remote-access conditions and remote code execution, which makes it an attractive tool for hackers.

As you can see, PowerShell has some lousy security default conditions in terms of logging, encryption and access privileges. Microsoft did this to make the scripts easy to write and debug, leaving more stringent conditions to the users who mostly forget to implement them.

Hackers have figured out ways around the more restrictive policy settings, such as using network pipes and other command-line switches and modifications to the Windows Registry. The Symantec report goes into detail on how this is done, and it is recommended reading for information on other attack profiles and how you can harden your own PowerShell environments.

PowerShell exploit examples

Take the example of the Locky ransomware. This code is downloaded to a PC through a PowerShell exploit called Nemucod, which was typically delivered as attachments to spam and phishing emails. Neutrino, Magnitude, and Sundown malware exploit kits also all had PowerShell at their black hearts to enable scripts to execute inside the browser.

Let’s look at two deeper dives into how these attacks happen. First, Mari DeGrazia’s Another Forensics Blog walks you through a series of event log entries to show you how to find malicious PowerShell scripts. She shows how malware authors can encode their scripts to further hide them from view. Getting them decoded may take a series of steps, as her post describes. She recommends scanning the questionable scripts through sdbg.exe, shellcode2exe, or other malware analysis tools.

Another analysis is how PowerShell can be used for lateral network movement, so that once a single PC is infected an attacker can move to a more desirable target such as a domain server or database. This Attactics blog post goes into details using Distributed Component Object model techniques, which may not be familiar to network defenders. For example, you can use PowerShell to compromise PowerPoint presentations through malicious macros that contain the malware’s payload. The post has a demonstration macro to illustrate just how easily this can be accomplished.

Tips to defend against PowerShell exploits

You can do several things to prevent the most obvious PowerShell-based attacks from happening across your network:

• Get familiar with PowerShell attack methods. Metasploit, Veil, and the Social Engineering Toolkit include the ability to generate PowerShell payloads and output scripts. If you already use one of these tools, spend time with it and see how the scripts work.
• Use a PowerShell-specific pentesting tool, such as PowerSploit, Nishang or Mimikatz. Many come with pre-built scripts to do privilege escalation, script modification, and remote code execution. The more you can learn about the darker side of PowerShell, the more able you will be to defend against future attacks.
• Enable extended PowerShell logging so you can track what a script is doing across your network. This requires version 3, so make sure you upgrade to the latest PowerShell version on each PC, and if possible remove version 2 since it is the least secure version.
• Conduct continuous user education. Clicking on one attached email document can infect your entire network. When users are asked to enable macros to view an attachment, they should know by now to click “No.”
• Understand who is using PowerShell scripts and who really needs to run them across your enterprise. That might be two entirely different populations.
• Look into whether you can disable PowerShell by default through a Windows install process. Not everyone needs to run its scripts.
• Investigate whether you can leverage AppLocker’s app blacklisting feature to block potential malicious scripts, and set up policies to block unsigned PowerShell scripts and apps. While malware writers have developed ways around both these actions, they can help stem the potential tide of malicious apps entering your infrastructure.
• Research how PowerShell can be run other than through the actual program itself. It can worm its way into your network if you use .NET, Windows System Management and other tools.
• Check if your email protection can catch malicious scripts or can be set up to more closely examine their behavior. Most infections start with a phishing or spam email, so eliminating them before they ever enter your network is all the better.

PowerShell is both a blessing and a curse, and with the appropriate protections, can be less of the latter and more of the former. You now know not to just ignore these scripts in the future.