Trend Micro released a report on a new PowerShell-vectored exploit named Black Magic. I had a lovely Twitter conversation about what this means in terms of PowerShell’s vulnerability to attack, and what admins should do. Unfortunately Twitter sucks for carrying on that kind of conversation, so I wanted to post this to clarify a few things.
First, I’m going to write this article as if “you” were hit by this exploit. Don’t take it personally, it’s just an easier style of language for me - it’s not actually addressing you.
Second, when it comes to security, the goal is to stop attacks from happening. That means you have to consider all the ways something could nail you, and try to block as many of them as is practical. That’s called “defense in depth,” giving you multiple layers of defense. The corollary to that is that your environment must still be functional. I mean, from a secure standpoint, if I unplugged all the WiFi access points and Ethernet switches you have, you’d be pretty secure. And non-functional.
Third… and I don’t know how to be delicate about this, but a lot of admins out there aren’t very sophisticated about security. There’s sometimes a tendency to fix what they can get their hands on, whether or not that makes any impact on security or not. So let’s be very clear about what you do when it comes to security: You do as little as possible, and impinge as little functionality as possible, while achieving your security goals. That helps maintain a “functional” environment, and keeps the security aspect of it “maintainable.” Sometimes, “as little as possible” is quite a lot indeed - but you look for that balance. Finally, you almost never do anything to “improve” security if it is in fact a null improvement. That is, you don’t lock the doors if the windows can’t be closed. There’s no point.
Now, let’s look at how Black Magic operates.

Step 1: Social Engineering

The exploit comes in the form of an .LNK e-mail attachment. That’s a Windows shortcut file. Users are meant to double-click it, and the shortcut launches a PowerShell session with the execution policy essentially turned off.

Problem 1: You let users get .LNK e-mail attachments from external users. This is stupid. Users shouldn’t be able to receive executable file types. Note that a .PS1 file isn’t an executable file type, which is why the exploit had to take this action. If you’d blocked .LNK attachments at the firewall, the exploit would be useless.
Problem 2: Your users are opening file attachments from people they don’t know. There is no technical way to protect an environment where users aren’t doing the right thing. No way. Just give up. This is why I keep going on about building a “culture of security.” If your users’ job descriptions, or your company employee manual, doesn’t say something to the effect of, “employees must be able to safely operate company computers in accordance with company policies and standards,” then you’re just doomed. If it does say that, and a user does open an attachment like this, you write them up and eventually fire them. If you think you can stop stupid users from bypassing every security measure you put in place, you are dumber than they are . You have to fix the social engineering element. There is almost no point in trying anything else, because users will get around it.

I know. A lot of you are shrugging and saying, “well, you can’t fix users, so I’ll just lock down PowerShell.” It won’t work.
I once, and rather famously, refused to help a law firm client get their NTFS file permissions under control, because they let users print sensitive documents and leave them lying around the office. Don’t bother locking the door if the windows are open.

Step 2: The Download

One of the elements of the Twitter discussion was, “maybe standard users shouldn’t have PowerShell able to run, because it’s so powerful and can be exploited so easily.”
Um, no.
First: PowerShell’s execution policy is not a measure against malware. It was never designed to be, so don’t be disappointed when it isn’t. If you thought it was, you were wrong, and that’s your fault for not educating yourself, not Microsoft’s fault for failing to do something they never set out to do in the first place.
Second: PowerShell only lets you do what you have permission to do. The Black Magic exploit used PowerShell simply to download a file from the Internet. That’s it. It didn’t wipe out Active Directory, it didn’t erase a file server, and it didn’t start grabbing messages out of Exchange, because normal users can’t do those things.
Would locking down PowerShell, so that normal users couldn’t run it, have stopped this exploit? No, because normal users have an abundance of ways to download files, and the exploit would simply have used a different one. PowerShell was convenient here, not necessary. If you’re going to posit locking down PowerShell, you must also lock down every other possible means of downloading a file from the Internet, or you’ve done nothing to impact security. Nothing.
PowerShell is not powerful. Erase that from your mind. Everything PowerShell is and does comes from the .NET Framework installed on every one of your computers, which your users have full access to. PowerShell is nothing more than a human-friendly way of getting to the Framework without needing Visual Studio on-hand. You could erase PowerShell and 100% of its functionality would still be present and absolutely usable by an exploit. Get your brain wrapped around that, because it’s an important concept.

Problem 3: You let your users download files from trashy websites. Your firewall should have been blocking access, and if it had integrated malware tools and realtime block lists, it probably would have caught this access.
Problem 4: You’re not using a local to block outgoing access by applications. For standard users, there’s little reason to access the Internet by means other than a web browser or known applications. This is a well-known technology and approach that’s been around for a decade.

Step 3: Run a File

Black Magic’s last step is to run the downloaded payload, which it does under normal user permissions.

Problem 5: You’re allowing users to run arbitrary applications. AppLocker has been around since Windows Vista, and provides a way of “whitelisting” applications that may run. This payload would never have been allowed to execute if you’d been using a built-in tool that’s been around since 2008. AppLocker even offers the ability to build that whitelist for you.
Problem 6: You’re not running updated anti-malware software that would have detected the payload and blocked it - and alerted someone. Most would have blocked access to the URL where the payload came from, too.

Conclusions

So you’ve had six opportunities to stop this exploit, all of which involve well-known, years-old technologies and techniques. You probably haven’t done most of them, and so you want to blame PowerShell.
OK… I’ll step out of the “you” attack-y mode :).
The point is that, once you have arbitrary code running on users’ systems, you’re owned. Nothing you can do to PowerShell will stop that. This attack could easily have been a .LNK file that ran Cmd.exe and the Telnet or FTP client - it could have achieved the same thing. It could easily have been an .EXE (“no, we block EXE file attachments;” “why the hell don’t you also block .LNK then, dummy?”).
I don’t want to come across as defending PowerShell per se; I’m trying to help folks understand where the real security problems lie. PowerShell is a red herring in all this; it was a convenient way of getting innocuous code to execute. There were six other places where this attack would have been stopped in its tracks, and any six of those would also have stopped every other similar kind of attack that didn’t rely specifically on PowerShell. That’s what makes those six effective - they’re global, not targeted at one specific piece of code. All of those six act to stop malware.
Before you take actions in security, you need to make sure you’re doing so from a holistic, professional security perspective. The first time a fire broke out in a crowded theater, officials didn’t say, “well, we should put sprinklers and alarms in that theater.” They put them in every theater, and started demanding flame-retardant fabrics and other measures. You address security across the board, not on a piecemeal basis.

A Tangent Argument

“Ah,” the argument goes, “but we should reduce moving parts. Users don’t have a legit need to run PowerShell, so we should lock them out of it.”
Valid. Except that PowerShell.exe isn’t PowerShell. PowerShell is a .NET Framework-based engine; PowerShell.exe is just a console application that lets you feed typed commands to that engine. You can’t remove PowerShell, and you can’t “block” users’ access to it, because it’s part of the Framework. It’s an integral part of the operating system. Things you don’t even realize are using it, are using it.
But yes, you could block users’ access to the console application, PowerShell.exe. I might even buy that argument, especially in a highly secure environment where you simply don’t want users having access to anything they don’t explicitly need to do their jobs. In fact, I would buy that argument, if and only if you block users’ access to everything they don’t explicitly need. Notepad. Windows Paint. Solitaire. Etc. Because based on the theory you’re working from, all code is bad code (a valid security perspective) and you block everything not explicitly needed. Remember, PowerShell doesn’t give users any special capabilities. Anything a normal user can do in PowerShell can be done in at least 2 other ways using other native tools. This is why AppLocker is a better approach: the list of apps a user needs is smaller than the list of apps they don’t, and so a whitelist is more maintainable, no matter how huge it is.

Anyway…

There you go. Now, you’re welcome to make comments on this, and offer your perspective. However, I have a couple of guidelines.

1. Keep the conversation civil and professional. I’ll delete anything obnoxious.
2. Keep the conversation focused on security. And remember that security isn’t about locking down the doors when the windows are open; it’s about holistically achieving specific goals. You don’t take security measures that simply move the target elsewhere. “Defense in depth” doesn’t mean 80 security restrictions and 20 ways around them. If something is super-easy to bypass, you don’t bother.