Analyzing the "Black Magic" PowerShell "Exploit" and Appropriate Actions

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.

 

 

About the Author

Don Jones

Don Jones is a Windows PowerShell MVP, author of several Windows PowerShell books (and other IT books), Co-founder and President/CEO of PowerShell.org, PowerShell columnist for Microsoft TechNet Magazine, PowerShell educator, and designer/author of several Windows PowerShell courses (including Microsoft's). Power to the shell!

4 Comments

  1. In my opinion, you're spot-on here. IT admins that don't have any specific security expertise tend to want to eliminate the "risk" at the lowest point in the layer chain. Good security is applied in layers. In this instance, you could say you've got your external corporate firewall, email filtering appliance, potential network traffic anomaly detection appliance, client-side malware detection and the Powershell execution policy.

    I saw your conversation on Twitter. The other admin thought it was best to simply stop users from executing scripts. He was advocating stopping this exploit at the lowest layer failing to realize this should be prevented MUCH higher in the chain. It's always better to stop it sooner than later, right? Granted, preventing users from executing scripts would stop this from happening but, as you mentioned, would kill all other good functionality that Powershell provides.

    I agree with your solution. Why would a user ever had a legitimate reason to be emailed a LNK file? Block it at your layer of choice in the email transport flow and be done with it. Problem solved and Powershell is still allowed!

  2. That's a very clear and logical explanation, I have learned a lot just from reading it! PowerShell is an administration and automation tool, not a security or anti-malware tool. Using Applocker is really the best protection from this entire kind of attacks. I hope everyone is going to realize it, because I'm telling: if it wasn't for PowerShell, I wouldn't be interested in Windows systems administration at all!

    Great article!

  3. Don, having been the one to enter into the discussion on Friday night over Twitter I am grateful of the discussion and the blog entry.

    Firstly, I would say that the exploit in question is not that elegant in the way it is trying to invoke PowerShell, however what it does demontsrate is that PowerShell is starting to be used as an exploit mechanism and that should cause concern for all in the community. Other exploits have occured that use Word and Excel documents as the payload, again they should be mitigated by educating users not to open docs from unknown senders and to take on board security warnings displayed in office. Unfortunately that doesn't mean they will.

    I totally get defence in depth and practice this, again the *.lnk file wouldn't have made it through most mail systems, but a word, excel or PDF might. AV is becoming less effective as a tool to stop malware and the time between malware release and pattern file update is too long. The same is true of outbound proxies which intercept traffic to known URL. These don't and can't cover zero days, they are reactive rather than proactive. If you don't believe me have a look at products like FireEye, whar are they becoming more popular?

    The commentor above has fallen into the trap of many ITPros (myself included up until the Wednesday of last week) that believe execution policy protects PowerShell, it doesn't all the execution policy really does is stop a PowerShell ps1 file automatically being fired. You can try it yourself or just read the following blog entry - http://www.darkoperator.com/blog/2013/3/21/powershell-basics-execution-policy-and-code-signing-part-2.html You can run PowerShell.exe with unrestircted policy and pipe the contents of the script into the session. If you want to hide things further or create more complex functionallity just use the -EncodedCommand and parse hex string into PowerShell.exe.

    I did not and do not advocate the crippling of PowerShell.exe but as yet no-one has been able to answer why the average person that only really uses Office and Internet Explorer needs to be able to run PowerShell. PowerShell is a fantastic tool and incredibly useful to administrators but that is surely the point it is aimed at administrators not standard users. Yes you can do the same with other CLI or interfaces but I don't buy that as an argument as to why it should be easy for the bad guys to take control of your machine. Hackers live in the same world as you and I; they go for maximum effect with minimum effort. For the same reason that PowerShell.exe is so easy for admins to use and access all of .Net it is the same for the bad guys. At the moment most of the attack vectors have not been very clever or have been aimed at post-exploit, but this will surely change as XP dies and Windows 7 becomes the norm.

    Since our discussions on Friday I noticed that Matt Graeber has written a very good explanation of the Trend "Black Magic" and demostrated how it could have been done using a Word or Excel document - http://www.exploit-monday.com/2014/04/powerworm-analysis.html

    I think it is fantastic that the first comment after the article is from a certain Jeffrey Snover which includes the comment "From your analysis, is there anything that we can/should be doing in PowerShell that would help protect users from attacks like this?" Dave Wyatt has now started a discussion thread on this very forum so we can discsuss further - https://powershell.org/2014/04/09/community-brainstorming-powershell-security-versus-malicious-code/

    I would also recommend following @briankrebs and @kjacobsen both pen-testers and InfoSec professionals who corrected some of my assumptions on the Wednesday before the discussion on Twitter with Don. In addition the following blogs make for interesting reading:

    Aperture Science - PowerShell Malware
    http://aperturescience.su/blog/2013/3/6/powershell-malware.html
    PowerShell ExecutionPolicy Bypass
    http://www.obscuresecurity.blogspot.co.uk/2011/08/powershell-executionpolicy.html
    PowerShell Basics - Execution Policy and Code Signing Part 2
    http://www.darkoperator.com/blog/2013/3/21/powershell-basics-execution-policy-and-code-signing-part-2.html

  4. I am sure this is not the last that we will hear of this type of attack. The options above are by and far the simplest and best. Educate the end user (as best as can be done) and make them accountable - this is not new as its now generally taken that every employee is responsible for health and safety which is physical like a spillage, so why not for computer systems? Finally put in perimeter systems to catch attacks. AppLocker helps enforce something I have advocated for years which is "Give users what they need on their computers, not what they want". (At risk of being lynched, that also should include Admins!)
    This concept of stopping the attack at the perimeter of your network is not a new one it been around for centuries. That's what a castle did, the outer wall only allowed for controlled access through the gate, (which was and should be guarded at all times).
    I can remember, back in the NT4 days, that an Admin had one account which had Domain Admin rights (because that's what we wanted) back then that was the norm. Now its generally accepted Admins have two accounts and don't use their Domain Admin account to open emails. PowerShell already will not allow certain commands to be executed without elevated rights, like Update-Help, perhaps not allowing a PowerShell session to download web content if not elevated could be an answer?
    I know there will be some code already out there that would not work if this came in, but perhaps if you had to go thought an authentication step (like setting up a remoting session to the local computer) before it allowed you access to all commands, that may be something to consider.