Current state of malicious Powershell script blocking

True if .Net Powershell assemblies are to be executed locally such as previously described via a WMI Consumer Event. Remember that in a Empire Powershell attack that would employ a script only, all that is needed is for Empire to remotely load the script into the target's memory space and execute it. .Net not required in this case. Remember that Empire is running PowerShell from the attack server.

 

Correct.
I would like to emphasize that, based on the topic of this discussion, I think it is easier to protect XP compared to other OS.
But others will have different opinion.

 

Looking for "ingenious" ways for PowerShell attack methods, I started "blue skying" the possible use of Node.js. This lead me to the following which will embed PowerShell within it:

https://www.npmjs.com/package/node-powershell

There is one problem with Node.js usage however. It must be installed on a web server. So that rules out a desktop attack. Or, does it? Well what happens if one of your trusted apps actually installs a Node.js web server on your desktop? This scenario actually occurred last year curtesy of NVidia. And what is illuminating is you have all PowerShell's attack capability w/o actually employing it.

Abusing NVIDIA’s Node.js To Bypass Application Whitelisting

https://www.sec-consult.com/en/blog/2017/04/application-whitelisting-application/index.html

BTW - if you have GeForce Experience 3.xx installed, you need to read this: http://nvidia.custhelp.com/app/answers/detail/a_id/4459

 

https://twitter.com/JohnLaTwC/status/977660530310627328

 

PowerShell Obfuscation Ups the Ante on Antivirus
September 12, 2018
https://threatpost.com/powershell-obfuscation-ups-the-ante-on-antivirus/137403/

 

The write-up is from Sept 12 but ESET has blocked the domain with the payload since July 18 which is when they submitted the file for analysis at VT. According to the time of submission, ESET was already blocking the hostname at that time.

Scanning just a downloader script does not give a whole picture of how well a particular AV can protect the system.

 

Cylance is at it again I see. Actually, I read the article yesterday but decided to abstain from comment since again, it just the same old propaganda spewing by Cylance.

 

yes... you know, for Cylance, VT represent the true power of the AV listed, with all features right...? because real world users disable all pro-active features...

 

What do you expect them to do run the script against the 59+ engines on VirusTotal so they don't catch flak from itman and guest on the wilders forums?

 

Good point and wasn't Cylance bad in blocking script based malware?

 

The consumer version (Smart antivirus) doesnt have the Script Control module present in the enterprise product (Cylance Protect), so only the home version can be considered weak against script based malware.

 

The issue of highly obfuscated PowerShell, etc. scripts is nothing new. Malware Research Group well over a year ago conducted an ad hoc test on the subject:

https://www.mrg-effitas.com/research/current-state-of-malicious-powershell-script-blocking/

Appears to me Cylance is just "scrapping the bottom of the propaganda barrel" in its never ending attempts to discredit its competition.

Also of note is that with the next release of Win 10, you will be able to unconditionally block any obfuscated PowerShell script via WDEG ASR mitigation. Somewhat of a moot point since by now, almost all are monitoring/blocking PowerShell execution.

 

I hope this is an appropriate thread for this post. I had been playing around with the 'setx' command line app a few weeks ago and came up with another way to enable/disable Constrained Language Mode in an easy way. I used to always go through Control Panel - System - Advanced system settings - Environment Variables anytime I needed to temporarily disable CLM for whatever reason.

I was seeking a quicker method which I could use in an Admin command prompt or with shortcut or batch script. Anyway, I figured I would share this in case it is useful to anyone else.


Enable Constrained Language Mode:

Code:

setx __PSLockdownPolicy "4" /M

Disable Constrained Language Mode: (revert to Full Language Mode)

Code:

setx __PSLockdownPolicy "0" /M

 

One more Win utility .exe to monitor since it can likewise be used by malware to disable constrained language mode.

A few other points to consider:

https://ss64.com/nt/setx.html

 

Case in point about SETX.

Windows Defender new sandbox protection can be enabled/disabled using it from any malware w/admin privileges or bypass:

https://www.bleepingcomputer.com/news/microsoft/microsoft-sandboxes-windows-defender/

Or, just use SET to remove the entire environment variable.

Did we just discover a security hole for this new WD sandbox protection? Let's see how long it takes for a POC bypass using this.

 

How this is a security hole? Could you please explain further?

 

same way malware disabled WD entirely, can also disable this as well.

 

Thought I already did that?

Look for previous malware examples that abused existing Win system utility process. Again, we'll just wait for some pen tester to develop a POC on how to so. Don't believe that will take that long.

 

Perhaps but 8.1 also, properly conditioned, is and should compare up with XP very well in the protection category. Just a reminder

 

@itman Great points, thank you for sharing.

 

FYI.

Ensilo has a good article in regards to environment variable exploiting and SETX usage:

Elastic Boundaries – Elevating privileges by environment variables expansion
https://blog.ensilo.com/elastic-boundaries-elevating-privileges-by-environment-variables-expansion

One scenario among many:

​

 

Here's a clever PowerShell attack that uses a .lnk file loaded into a Win startup directory: https://forum.eset.com/topic/17441-clever-virus-that-stores-its-execution-code-in-registry/

-EDIT- Also of note is the malware used PowerShell to run via registry key, a .Net subassembly.