And the Top Source of Critical Security Threats Is...PowerShell (esecurityplanet.com) 73
Slashdot reader storagedude writes: That's right, Microsoft's CLI management tool was the source of more than a third of critical security threats detected by Cisco in the second half of 2020, according to eSecurity Planet.
Dual-use tool exploitation was the top threat category noted by Cisco, followed by ransomware, fileless malware, and credential dumping, with PowerShell a primary vector in those last two categories also.
"Based on Cisco's research, PowerShell is the source of more than a third of critical threats," noted Gedeon Hombrebueno, Endpoint Security Product Manager for Cisco Secure.
Cisco recommends a number of protection steps that are, of course, made easier with Cisco Secure Endpoint, and other EDR tools are effective against PowerShell exploits also.
But there are a number of steps admins can (and should) take that are completely free, like preventing or restricting PowerShell execution in non-admin accounts, allowing execution of signed scripts only, and using Constrained Language mode.
Dual-use tool exploitation was the top threat category noted by Cisco, followed by ransomware, fileless malware, and credential dumping, with PowerShell a primary vector in those last two categories also.
"Based on Cisco's research, PowerShell is the source of more than a third of critical threats," noted Gedeon Hombrebueno, Endpoint Security Product Manager for Cisco Secure.
Cisco recommends a number of protection steps that are, of course, made easier with Cisco Secure Endpoint, and other EDR tools are effective against PowerShell exploits also.
But there are a number of steps admins can (and should) take that are completely free, like preventing or restricting PowerShell execution in non-admin accounts, allowing execution of signed scripts only, and using Constrained Language mode.
How long before we begin hearing: (Score:2)
Powershell gets its powers used (Score:5, Funny)
Re: (Score:1)
Re: (Score:2)
Summary is crap (Score:2)
Powershell is what you use on Windows *after* exploiting the system to get remote code execution. /bin/sh is what you use on Linux. Because that's how you run things on those systems, if you aren't sitting at the console clicking things.
Re: (Score:2)
Would mod this up if I could. This "story" is deliberately misleading.
Powershell basically falls into the same category as *nix shells like sh, bash, etc. or commonly bundled scripting languages like Python, Perl, etc. on *nix systems. All of these tend to be abused AFTER initial infiltration.
Re: (Score:3)
I thought they rewrote it from the ground up already? And still have these problems?
Re:No way to fix Windows (Score:5, Insightful)
Re: (Score:1)
It's certainly the easiest target.
Re: (Score:2)
...the reality is that the most used system is the most attacked....
Linux is the most attacked system ever, yet successful exploitation is rare.
Successful Windows (or just about any Microsoft software) exploitation is extremely common because its security is terrible.
Re: (Score:3)
Android is Linux, and it's exploited constantly.
Re: (Score:2)
All of the Android exploits are in Android, not Linux. The kernel in Android has been rock solid.
Re: (Score:2)
If you think linux exploitation is rare you obviously aren't looking.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
PowerShell (and to a lesser extent C#) are used in a very large portion of successful attacks, though, but that's because it's built into Windows as its default scripting language and it allows extensive automation of the attack. When Linux systems get popped, you'll often see bash, Perl, or Python scripts used because those are widely present and allow extensive automation of the attack. If Microsoft adopted Python in place of PowerShell, you'd see a lot of Python used in attacks.
Re: No way to fix Windows (Score:2)
Even then, I think powershell (or even c#) is used because it's a lot easier to use as a programmer, thus the barrier to entry for the malware developer is lower.
If I were to write malware, my choice would be rust, not only because I can, but because it's so much easier to write robust rust code that works exactly as you intend it to work, even in environments that you can't necessarily test against before deployment, plus with rust I don't have to count on my target having some necessary frameworks or runt
Re: (Score:1)
"They did create OS/2 which was a ground up rewrite with a protected mode architecture but they decided to keep patching the old Windows... forever. Not backwards compatible enough."
More importantly, they didn't own OS/2, which belonged to IBM. They kept introducing new incompatibilities into Windows, which insured OS/2 would never be viable. I'm sure that was accidental.
Re: (Score:3)
Re:No way to fix Windows (Score:4, Informative)
Neither is entirely correct. The current versions of Windows are based on the NT kernel, which was written as a multi-user OS from the start. However the Windows layer on top was designed to be able to run Windows 3.1 and Windows 95 applications, and some compromises were made. Most of these have been factored out over the years. 16-bit applications no longer run, so nothing designed before NT existed can still be in use. And most of the insecure backwards-compatible features are now emulated. For example, one application I use saves files in the program directory - and Windows lets it. Except it doesn't - it silently redirects them to a folder in ProgramData, and the program directory is read-only. If system processes try to interact with the desktop (which they shouldn't), Windows creates a brand-new desktop for them with nothing on it. And so on. Which isn't to say that there isn't some long-forgotten piece of code lurking and waiting to become a security issue - it happens, but much less than it used to.
Re: (Score:2)
I think the steady pace of exposures of Windows vulnerabilities over the years shows that there are a lot of long forgotten pieces of code waiting for exploit.
Re: (Score:2)
This isn't strictly true. While 64-bit Windows does not include the 16-bit subsystem, 16-bit compatibility can added back by installing the NTVDM (NT Virtual DOS Machine). Doing so requires a conscious effort, though.
Re: (Score:3)
I write backwards-compatible APIs all the time, I've never found any reason to audit the old code for security bugs and then also reproduce them! Seems like a process that is unlikely to actually be taking place.
Honestly, it doesn't sound like you understand what the word "architecture" means in software, and how it compares to the word API.
Re: No way to fix Windows (Score:2)
APIs are crap if the underlying OS is crap. They just provide more opportunities for attack.
Can't patch up a fundamental architecture failure by putting lipstick on the pig. Microsoft has been doing that for years and it isn't working.
Re: (Score:2)
Yep, you don't know what the words mean.
Re:No way to fix Windows (Score:4, Informative)
Really folks, just choose another OS which was designed from the ground up with security in mind. Linux, Unix, BSD (MacOS).
How delusional must one be to think up something like that? Linux was designed from the ground up to scratch a very particular itch of Linus Torvalds, which has literally nothing to do with security.
Re: (Score:2, Informative)
His "itch" was a multiuser OS so it was designed from the start with security (modeled after Unix)
Re: No way to fix Windows (Score:5, Insightful)
As was windows. What windows do you think is being used? 3.1? Or 95? No. Itâ(TM)s based on win NT. which was based on OS2 and the main guy who turned it into NT was the guy who wrote VMS. Itâ(TM)s fully multiuser, preemptive multitasking, and has security acls up the wazoo. From the beginning. You can put acls on almost anything if youâ(TM)re so inclined. All while ânix was still playing with the Chmod stuff. Linux and the bsds had that shit bolted on afterward.
Re: (Score:2)
You can't even type correctly, why should we listen to you?
Re: (Score:3)
Linux was designed from the ground up to scratch a very particular itch of Linus Torvalds,
That is completely false. He followed the POSIX design as much as possible.
Re: No way to fix Windows (Score:5, Informative)
Oh good grief. Why not look at the pedigree of windows NT and how it was designed. No thought to security? Give me a freaking break.
Vulnerabilities? Sure. Lots. But it was pretty much designed from the ground up with security in mind. It could be locked tighter than a drum, but isnâ(TM)t, because mere mortals are trying to get shit done and donâ(TM)t think.
Re: (Score:2, Redundant)
The basic problem is that Windows is saddled with legacy "compatibility" to "get stuff done". This opens up lots of opportunities for exploits. They can't remove this stuff as it will break a lot of applications.
Re: (Score:2)
Re: No way to fix Windows (Score:1)
I seem to have triggered a bunch of Windows fanboys. Sorry to have offended you but you really should consider the points I have raised.
Re: (Score:2)
Re: (Score:2)
Re: No way to fix Windows (Score:1)
The problem (same as all of Windows problems) is that it relies on the poor underlying architecture of the core OS. It just opens up new avenues of attack. This defect is highlighted by TFA.
PowerShell... (Score:2)
Henceforth to be known as PowersHell.
powershell on linux (Score:2)
I wonder what surprises wait people who took the bait and installed powershell on Linux ?
https://docs.microsoft.com/en-... [microsoft.com]
I never used it and never saw in in action, but I knew enough to stay as far away from it as possible. For people who did did install it, between all the 'fun' breaches on M/S software lately, I wonder how many are looking at a rebuild.
Re: (Score:2)
installed powershell on Linux
I don't know how that would differ from something like bash, csh, ksh. All shells, all scriptable. But since they run on various flavors of *NIX, not terribly dangerous. As long as one doesn't do their day to day work logged on as root.
That said, it wouldn't surprise me if Microsoft's installation set PowerShell up as setuid. If so, people who use it deserve all the hell it will produce.
Re: (Score:3)
Windows doesn't have an equivalent of the setuid bit. It has a "Run as..." ability, but that requires a password or similar login credentials. There are also other mechanisms, such as User Account Control (UAC), that limit how programs running with administrator privileges (when started by an admin account) can communicate with unprivileged processes.
Re:powershell on linux (Score:5, Insightful)
Yea I think this is the point that others are missing - I imagine for *nix systems shell scripts, perl or python which are available by default in virtually every system are abused in a similar way by attackers.
While it may make sense for most users to remove or disable powershell, if enough people are doing that then attackers will simply switch to other tools that are available on the system.
Re: (Score:2)
Powershell (Score:2)
Does anyone routinely use powershell interactively? The few times I have used it the commands seemed overly verbose and reminded me a lot of OpenVMS.
Re: (Score:2)
I have vaguely tried to use it a few times, but was also annoyed by it's verbosity and general weirdness. If I need to do something on Windows that is too complex or unpractical for cmd.exe (which is most things, actually), I usually end up starting Ubuntu in WSL and doing it Bash or Perl.
Re: Powershell (Score:5, Informative)
Another good grief. There are a few syntactical oddities, but in general itâ(TM)s phenomenal. What I can accomplish via one liners is amazing. Think of Unix one liners, but the bits moving through the pipeline arenâ(TM)t necessarily text (though they could be), but are often times objects. And the exes on the pipeline usually know what to do with the object given to them. And when they donâ(TM)t, they tell you so.
Re: Powershell (Score:3)
Re: (Score:2)
It's good for administering Windows software. It has great integration with the MS suite of tools. Extensibility isn't so great, though.
Great! (Score:2)
Don't blame the tools. Blame yourselves. (Score:5, Insightful)
Re: (Score:1)
Call Me Skeptic (Score:4, Insightful)
Re:Call Me Skeptic (Score:4, Insightful)
First of all, this seems like a marketing ploy to get people to buy into Cisco Secure Endpoint. But, past that, I find it hard to believe that there are as many holes as they say (>33%) in a non-escalated process. Microsoft has patched all known bypasses of UAC. Is Cisco saying they know of new ones that MS hasn't patched yet?
I'm with you on this.
For one thing Powershell's execution policy is set to Restricted by default on Windows client computers, which means almost every computer on the planet cannot run Powershell.
Re: (Score:1)
What? Every computer can run Powershell. It's just a command interpreter.
Restricted does *not* mean that Powershell can't run; it only means Powershell won't execute scripts. Which is not even meant as a security system, as Microsoft's own documentation says: it's only meant so anyone can set basic rules and prevent accidentally violating those.
Re: (Score:2)
What? Every computer can run Powershell. It's just a command interpreter.
Restricted does *not* mean that Powershell can't run; it only means Powershell won't execute scripts. Which is not even meant as a security system, as Microsoft's own documentation says: it's only meant so anyone can set basic rules and prevent accidentally violating those.
good point and bad writing by me. Here's an updated statement:
I'm with you on this.
For one thing Powershell's execution policy is set to Restricted by default on Windows client computers, which means almost every computer on the planet cannot run Powershell scripts.
Misleading headline? (Score:4, Interesting)
Something tells me this is really about powershell being used as the implementation language for the attack payload. Not about vulnerabilities in powershell itself or in programs written in powershell.
Which means powershell is not the source of any threats.
Re: Misleading headline? (Score:2)
Amen. My thought exactly.
Re: (Score:2)
Something tells me this is really about powershell being used as the implementation language for the attack payload. Not about vulnerabilities in powershell itself or in programs written in powershell.
Which means powershell is not the source of any threats.
Yep, totally agree.
Quote from the article:
"The top category of threats detected across endpoints by Cisco Secure Endpoint was dual-use tools leveraged for exploitation and post-exploitation tasks. PowerShell Empire, Cobalt Strike, PowerSploit, Metasploit and other such tools have legitimate uses, Cisco noted in the report, but they’ve become part of the attacker toolkit too."
Thanks to this article, we now know that letting other people run pen-testing tools on it is a bad idea.
This article is more of
Re: (Score:2)
Re: (Score:2)
Which means powershell is not the source of any threats.
Which means guns are not the source of any threats.
So, why do we ban guns again?
Re: (Score:2)
No admin for you! (Score:3)
This is why you don't let every Tom Dick and Harry have admin rights to their box. Thing is, many admins do just that. And that makes my job so much easier.
Re: (Score:2)
Unsurprising really (Score:2)
However if you are not (Score:1)