PowerShell Security Threats Greater Than Ever, Researchers Warn (computerweekly.com)

Microsoft's Windows PowerShell configuration management framework continues to be abused by cyber attackers, according to researchers at Symantec, who have seen a surge in associated threats. From a report on ComputerWeekly: More than 95% of PowerShell scripts analysed by Symantec researchers have been found to be malicious, with 111 threat families using PowerShell. Malicious PowerShell scripts are on the rise, as attackers are using the framework's flexibility to download their payloads, traverse through a compromised network and carry out reconnaissance, according to Candid Wueest, threat researcher at Symantec.

Comments

Well...

[The-Ixian]

Good thing MS had the foresight to make sure that non-signed PS scripts aren't executable by default.

Of course... sysadmins generally disable that restriction just like they turn of UAC... MS makes a security measure and people disable it and then complain that MS is so insecure.

But then Linux is insecure in a lot of the same ways... it's only as secure as the weakest link... which is generally the apps running on it.

Re:Replacing CMD

[houstonbofh]

Or, to rephrase, powerful tools are powerful tools. The main reason PowerShell can do more damage is because it can do more stuff.

Re:Replacing CMD

[naasking]

However, powershell *puroports* to have security features like execution policies and signing, so it draws more scrutiny.

Both terrible "security" policies. What would a signature possibly mean to me as a user if I don't know you? With or without a signature, my choice is still: either I run this script I need to my job, or I don't and I can't do my job (or it gets much, much harder). So basically PowerShell's security is no better than any other shell that's come before it; it projects a false sense of security, and like UAC before it, it just gets in your way.

So given the fact that getting a job done is king, and running scripts or programs written by potentially malicious people is the only reasonable way to do your job, then running arbitrary scripts must be made safe. The means to achieve this is the Principle of Least Authority (POLA), and POLA environments can and have been done before, even within commodity POSIX and Windows systems.

The earliest secure POSIX shell that I recall was Plash. Now we also have Shill (requires a kernel module) and the Capsicum shell (also requires kernel modules). Windows can be made POLA secure out of the box as was demonstrated with Polaris.

It's just amazing that we fail to learn the mistakes of the past even when solutions are available.

Had to be said

[SuperKendall]

With great PowerShell comes great ResponsibilityShell.

Well duh

[Billly Gates]

WHen you run powershell as an admin it can do bad things. Who would have thought? I wonder if Linux is vulnerable if someone is logged in as root?

Powershell is not enabled with an execution policy by default. It has to be enabled and most people do not even know what it is so this is no threat? At work we have a GPO that blocks powershell for any non AD admin.

Re:Replacing CMD

[naasking]

Some of them, like the encrypting ransomware requires no special privileges at all, but simply access to user files, and to network files that the user has read/write access to.

Those are special privileges. I don't think you truly appreciate the meaning of POLA. When you run a program with a POLA shell, it literally has access to nothing except the memory in its own address space and any parameters it's passed via the command line. Here's a simple example of copying a file in a traditional Unix shell:
$ cp foo.txt foo.bak
To implement the desired copy functionality, the cp command must have access to the entire local environment, including the entire file system since it can lookup an arbitrary path. This is an absurd amount of authority for a program that merely copies bytes from a source to a sink. Now here's a POLA version of the same command:
$ cp < foo.txt > foo.bak
Notice that the only permissions cp needs are explicitly specified in the command. They are then opened by the trusted shell and passed in as file descriptors, a read-only one and a write-only one, to the untrusted program. The explicit permission grants are obvious, and POLA shells generalize this type of pattern to compartmentalize all programs.

For whatever reason, Outlook allowed it to be executed, and the user clicked the dialog that might have prevented it, and then the script went to town encrypting files on the user's own folders and the share.

A perfect failure of POLA. In a proper least authority environment, it would have been perfectly safe to run that program because it would have had to raise a request to the environment for a set of read/write file descriptors and your user would have been rightly suspicious of any program requesting access to so many files.