The Trickbot malware that targets bank customers. Password harvesters like Mimikatz. "Fileless malware" attacks. All three are popular hacking tools and techniques, but they're unconnected except for one trait: They all rely in part on manipulating a Windows management tool known as PowerShell to carry out their attacks.
Long a point of interest for security researchers, PowerShell techniques increasingly pop up in real-world attacks. Last year, well over a third of the incidents assessed by security firm Carbon Black and its partners involved some sort of PowerShell component. But as network defenders catch on to Microsoft's recent release of additional PowerShell protections, the attack sequences that exploit PowerShell are finding some long-overdue resistance.
A shell is an interface, often a simple command line, for interacting with an operating system. PowerShell specifically also includes a scripting language, and helps system administrators automate tasks across their networks, configure devices, and generally manage a system remotely. A framework like PowerShell has several network security benefits, because it can facilitate tedious but necessary tasks, like pushing updates and configuration improvements across a large number of devices.
But the same qualities that make PowerShell versatile and and easy to use—it sends trusted commands to devices throughout a network—also make it an appealing tool for attackers.
When Microsoft first developed PowerShell for release in 2006, it immediately recognized the framework's potential security implications. "We absolutely knew that PowerShell was going to be [appealing]. Attackers have job satisfaction as well," says Lee Holmes, the principal software design engineer for PowerShell and the lead security architect for the Azure Management Group at Microsoft. "But we’ve been laser-focused on PowerShell security since the very first version. We’ve always approached this in the context of larger system security."
Outside observers picked up on those potential pitfalls as well. Companies like Symantec focused on PowerShell's potential ability to directly propagate viruses throughout a network. Before it was even officially released, though, Microsoft took steps to make it much more difficult for attackers to so directly hijack the framework through precautions like placing restrictions on who could initiate what commands and requiring script signing by default—the process of adding digital signatures to validate that a command is legitimate, so attackers can't just freely input anything they want. But while PowerShell's initially limited distribution made it less of a hacker target at first, its popularity exploded after Windows began shipping it standard with Windows 7 in 2009. Microsoft even made it an open source tool as of last year.
"We will be the first ones to admit the usefulness and power of PowerShell in a positive manner. The ability to perform advanced tasks on Microsoft-based operating systems is a huge leap forward," penetration testers and researchers David Kennedy and Josh Kelley wrote in the first DefCon security conference talk about PowerShell, back in 2010. But "PowerShell also gives hackers a full-fledge programming and scripting language at their disposal on all operating systems by default ... [which] does pose significant security risk."
Microsoft's security precautions prevented hackers from using PowerShell for total takeovers, but attackers increasingly found that they could use it for certain attack steps, like remotely adjusting the settings on a particular device, or initiating a malicious download, even if they couldn't rely on PowerShell to do everything. For example, the Odinaff hacker group leveraged malicious PowerShell scripts as part of its rash of attacks on banks and other financial institutions last year. And the popular "W97M.Downloader" Microsoft Word macro trojan uses PowerShell tricks as well to spread malware.
A crucial attribute attackers discovered was that PowerShell didn't offer particularly extensive logs of its activity, plus most Windows users didn't set PowerShell to record logs at all. As a result, attackers could abuse the framework in plain sight, without a victim system flagging the activity in any way.
Recent changes, though, have made attacks easier to identify. PowerShell 5.0, released last year, added a full suite of expanded logging tools. In one system attack recorded by the response firm Mandiant, which collaborates on PowerShell research at times with Microsoft's team, Advanced Persistent Threat 29 (also known as Cozy Bear, a group that's has been linked to the Russian government) used a multi-pronged attack that incorporated a PowerShell element.
"As quickly as they were remediating machines, they were getting compromised again," Holmes says of Mandiant's defense efforts. "They knew that the attackers were using a combination of Python and command line tools and system utilities and PowerShell—all the stuff that’s out there. So they updated the system to using the newer version of PowerShell that has the expanded logging, and suddenly they could look at the logs and see exactly what [the attackers] were doing, what machines they were connecting to, every single command they ran. It completely took away that veil of secrecy."
While it's no panacea, and doesn't keep attackers out, the renewed focus on logging aids flagging and detection. It's a baseline step that helps remediation and response after an attack is over, or if it persists long-term.
"PowerShell created the ability for users to define what logging they want or need, and it also added a bypass policy. As an attacker you’re either going to log your event or you’re going to put in the command to bypass, which is a major red flag," says Michael Viscuso, the CTO of Carbon Black, which tracks PowerShell trends as part of its threat intelligence research. "From that perspective the developers of PowerShell have sort of cornered the attackers to make a decision. Still, if an attacker does choose to allow you to log their activities, assuming they have any sort of privileged access to the machine, they can just remove those logs afterward. It's a roadblock, but it's mostly just more inconvenient."
And PowerShell's recent defense improvements go beyond logs. The framework also recently added "constrained language mode," to create even more control over what commands PowerShell users can execute. Signature-based antivirus has been able to flag and block malicious PowerShell scripts for years, and the release of Windows 10 expanded those services' capabilities by integrating the Windows Antimalware Scan Interface for deeper operating system visibility. The security industry at large has also made strides to determine what baseline normal activity for PowerShell looks like, since deviations could indicate malicious behavior. It takes time and resources to individually establish that baseline, though, since it differs for each organization's network.
Penetration testers—security experts paid to break into networks so that organizations can plug the holes they find—have paid increasing attention to PowerShell, too. "This past year definitely seems to have produced an uptick in interest from the pentest community, along with defensive products paying more attention to PowerShell-related attacks," says Will Schroeder, a security researcher who studies offensive PowerShell capabilities.
As with any defense mechanisms, though, these measures also stimulate attacker innovation. At the Black Hat and DefCon security conferences in Las Vegas last month, Microsoft's Holmes gave multiple presentations tracking methods attackers could use to hide their activity in PowerShell. He also showed how customers can set up their systems to maximize tools for gaining visibility and minimize misconfigurations attackers can exploit to shield their behavior.
"You're going to see more advanced attackers. The ones who were using PowerShell as a cutting-edge technology four or five years ago start to pivot away from using pure PowerShell into other more obscure corners of the operating system as defensive tactics catch up," says Matthew Hastings, a detection and response product manager at the endpoint security firm Tanium. "There’s no reason to change my tools, tactics, and procedures if I’m not being caught, but if people start monitoring what I’m doing I’m going to shift what I need to do in order to get around it."
Experts also note that offensive PowerShell techniques have become a fairly typical 'pre-fab' component of hacking toolkits that sophisticated hackers develop and then pass around the black-hat community. "I don’t envy Microsoft’s plight," Carbon Black's Viscuso says. "If you talk to system administrators across the world they will tell you that PowerShell has changed the way that they administer the network in a very positive way. But all the same descriptive words that you would hear a systems administrator use—lower cost, more efficient—you would also hear a hacker use."
PowerShell's not a unique target; scripting languages like Bash, Perl, and Python all have similar traits that are attractive to hackers. But the recent improvements in PowerShell reflect an important conceptual shift in how defenders operate. "Where Microsoft and the security industry is moving towards is much more of an enlightened approach to security," Holmes says. "You can focus harder on protecting against breaches and defense in depth, but the enlightened approach is to assume breach and build the muscle on detection and remediation—make sure that you’re really thinking about security end-to-end in a holistic manner."
Of course, assaults on PowerShell will evolve as well. But at least now it's a real race.
