Current state of malicious powershell script blocking

Are there other script interpreters besides powershell that malcoders like to launch in tricky ways?
By "tricky ways", I mean a method that ordinary anti-exe/command line parsing would not detect and block.
 
Are there other script interpreters besides powershell that malcoders like to launch in tricky ways?
By "tricky ways", I mean a method that ordinary anti-exe/command line parsing would not detect and block.

All of them. Not to mention a whole range of other things shipped with Windows such as .NET Framework, Windows Management Instrumentation, etc. In a nutshell, anything and everything that they can abuse, they will abuse - and that is pretty much the entirety of the OS and what is shipped with it.

The vast majority of attacks using interpreters is not that sophisticated. Disabling the interpreters shipped with Windows goes quite a long way in hardening the system:

1. cscript
2. wscript
3. powershell
and
4. cmd - the user has to determine for themselves if cmd is needed on any regular basis by softs

Microsoft is now exploring the viability of disabling the most abused processes by default. So the people that say "Users shouldn't have to disable things to protect their systems" - well - that is a theoretical that bears no relation to reality. Microsoft is exploring it because they are aware that the "shoulds" just aren't possible either practically, technologically nor economically.
 
Last edited by a moderator:
All of them. Not to mention a whole range of other things shipped with Windows such as .NET Framework, Windows Management Instrumentation, etc. In a nutshell, anything and everything that they can abuse, they will abuse - and that is pretty much the entirety of the OS and what is shipped with it.

The vast majority of attacks using interpreters is not that sophisticated. Disabling the interpreters shipped with Windows goes quite a long way in hardening the system:

1. cscript
2. wscript
3. powershell
and
4. cmd - the user has to determine for themselves if cmd is needed on any regular basis by softs

Microsoft is now exploring the viability of disabling the most abused processes by default. So the people that say "Users shouldn't have to disable things to protect their systems" - well - that is a theoretical that bears no relation to reality. Microsoft is exploring it because they are aware that the "shoulds" just aren't possible either practically, technologically nor economically.
I know that all sorts of processes can be injected directly into memory. That's not really the point I'm asking about.
And this thread talks a lot about how powershell can be launched in a roundabout way.
But how does something like cmd.exe get launched in a roundabout way?
 
I know that all sorts of processes can be injected directly into memory. That's not really the point I'm asking about.
And this thread talks a lot about how powershell can be launched in a roundabout way.
But how does something like cmd.exe get launched in a roundabout way?

The MRG Effitas article does not discuss roundabout ways to launch powershell. Zoltan is lamenting the fact that security softs cannot protect against malicious scripts.

I like his comment "Try harder..."

OK... we'll try harder, but you are now going to have to pay us to try harder to the tune of $150 per month for your subscription instead of only $24.95 per year. Most users will reply "OK... we aren't going to pay..."
 
I know that all sorts of processes can be injected directly into memory. That's not really the point I'm asking about.
And this thread talks a lot about how powershell can be launched in a roundabout way.
But how does something like cmd.exe get launched in a roundabout way?

If something is enabled, it will be abused. How it is abused doesn't really matter. There's literally thousands of ways to abuse stuff. And trying to prevent those thousands and thousands of methods of abuse is a futile enterprise.
 
If something is enabled, it will be abused. How it is abused doesn't really matter. There's literally thousands of ways to abuse stuff. And trying to prevent those thousands and thousands of methods of abuse is a futile enterprise.
Okay but look, Powershell has got this folder in Program Files, with 44 subfolders and 133 files, and it has at least three times more than that in System32. That's a lot to abuse. It provides sneaky ways to launch Powershell.
But little old wscript or cmd doesn't have anything like that. Ostensibly, it has only one way to execute, so your average anti-exe should be able to handle that, wouldn't you say?
 
Okay but look, Powershell has got this folder in Program Files, with 44 subfolders and 133 files, and it has at least three times more than that in System32. That's a lot to abuse. It provides sneaky ways to launch Powershell.
But little old wscript or cmd doesn't have anything like that. Ostensibly, it has only one way to execute, so your average anti-exe should be able to handle that, wouldn't you say?

Simply disabling the interpreters goes quite a long way in preventing a good portion of the "advanced" attacks. Disable... and not monitor

One of the most effective protection strategies is to reduce attack surface and thereby eliminate potential attack vectors. That is why Microsoft pushes that advice so hard at the Admin level. It is a golden rule that is at the very heart of Microsoft's recommended best practices.