Current state of malicious Powershell script blocking

The above posting leads into something I have been "pondering." How about Microsoft via Windows Defender Exploit Guard create mitigation policies in regards to PowerShell use? Namely the ability to set ExecutionPolicy level and disable the use of Invoke-Expression?

 

In the Advanced section of OSA there is a rule to mitigate IEX:

 

Interesting.

Assumed it is scanning the command line for Invoke-Expression, IEX, etc.. This also implies other like security software e.g. AppGuard might have like capability. Also possibly some HIPS, but they would need the capability to scan the entire command line and recognize parameters. Many don't have such capability. Also ask the developer if he can detect like activity if done via a WMI command event? Doubtful I would think. Finally if OSA is using PostCommandLookupAction as noted in the above linked TechNet article, it can be bypassed.

Ask the developer to add like capability to set ExecutionPolicy to "Constrained Language" mode. Should be doable since OSA is policy based software. This alone will prevent most .Net features from functioning via Powershell.

Finally, blocking IEX usage via command line is great, but malware can execute the same PowerShell .Net based assemblies and functions via a .exe.

 

Also an interesting code sample employing cmd echo set xPost = createObject("Microsoft.XMLHTTP") and employing Mimikatz is here: https://github.com/yaseng/pentest/blob/master/note/windows.txt

 

Yes, it is doing it (it monitors processes, parent processes & command-lines). Regarding PowerShell it also blocks "ExecutionPolicy Bypass"
Collection of available PowerShell/WMI-options:

Spoiler: OS Armor - PowerShell/WMI

[X] Prevent PowerShell from using Invoke-Expression via cmdline
[X] Block execution of Windows PowerShell
[X] Block execution of .ps1 (PowerShell) scripts
[X] Block "ExecutionPolicy Bypass" on command-line (PowerShell)
[X] Block "WindowStyle Hidden" on command-line (PowerShell)
[X] Block ShellExecute\Start-Process in PowerShell cmdline

[X] Block execution of PowerShell malformed commands
[X] Block execution of PowerShell encoded commands
[X] Prevent regsvr32.exe from using /i:Powershell

WMI:
[X] Prevent WMIC from using "process call create" via cmdline
[X] Block any process executed from wmic.exe
[X] Block any process executed from wmicprvse.exe

 

Probably the monitoring function sought could be included in the rules below:



But you should ask the developer directly.

 

@Sampei Nihira why don't you post this idea in the OSA thread?
I kind of doubt it can be done, because I don't think that OSA modifies Windows policies, but maybe I will be pleasantly surprised.

 

In my opinion, the Developer already has a lot of work to do.***
For me it should be itman himself if he is interested in asking this question.
At least this is the mentality of us Italians.
Thanks for the consideration.

P.S. *** And also apparently of our French cousins (see comment Cruelsister).

 

Dnx.exe can be used to bypass Device Guard as noted below:

Note that Device Guard gives many of the same mitigations in regards to Powershell as AppLocker:

https://enigma0x3.net/2016/11/17/bypassing-application-whitelisting-by-using-dnx-exe/

As far as using WMI to create a malicious Powershell consumer event via WMIC as noted here: https://www.fireeye.com/blog/threat-research/2016/08/wmi_vs_wmi_monitor.html , OSA has a mitigation for WMIC use. However, the same activity can be accomplished using for example MetaSploit as noted here: https://www.rapid7.com/db/modules/exploit/windows/local/wmi_persistence .

 

BTW - Most of the recent WMI persistence attacks against Win OS servers I have recently observed employing PowerShell were RDP brute force attacks. Even when the installations were informed of this, they still refused to lockdown RDP for operational reasons.

Note that the Powershell based attack shown in reply #174 was not WMI based. All that was required in that instance was the attacker finding an open inbound port.

 

Blocking Malicious PowerShell Downloads
https://www.crowdstrike.com/blog/blocking-malicious-powershell-downloads/

Nothing "earth shattering" in this Cloudstrike posting released today. It does show, as I recently posted, the increased use of .Net's new-object system.net.webclient by Powershell to download malware.

-EDIT- Oops - got the dates wrong; this was issued a year ago. Forgive me since my eyesight in my old age is not what it was when I was younger.

 

Now this one is a new one ..............

https://community.spiceworks.com/to...gn-hides-malicious-powershell-script-in-image

 

This just might be the ultimate PowerShell and MS Word combo attack.

Securityweek.com just posted this Middle East targeted attack:

Actor Targeting Middle East Shows Excellent OPSEC
https://www.securityweek.com/actor-targeting-middle-east-shows-excellent-opsec

Of interest is the following:

Take note of what I underlined above.

Next up is a POC that can bypass Win 10 Controlled Folders protection that was posted and commented up in the 'Windows Defender is Becoming blah-blah" thread: http://www.securitybydefault.com/2018/01/microsoft-anti-ransomware-bypass-not.html?m=1 . Of note is the following code:

Note that when running Word in the above fashion, all protective measures that would be provided by opening a .doc/x file using winword.exe are bypassed; including prohibiting the execution of macros.

Combining the two attack methods yields:

1. Execute a VBScript designed to create a second stage PowerShell script that would create a Microsoft Office document. The document, e.g. malicious.docx, created would contain nothing but the malicious macro.

2. Run the following python script compiled into a Win .exe -or- download Python to the target and use that to execute the script:

import win32com.client
filetoberun = r'C:/................/malicious.docx'
word = win32com.client.Dispatch("Word.Application")
word.visible = 0
doc = word.Documents.Open(filetoberun)
word.Documents.Item(1).Close()
word.Documents.Item(1).Delete()
word.Application.Quit()

Bingo! You're nailed.

Ref.: https://techblog.dorogin.com/generate-word-documents-with-powershell-cda654b9cb0e

 

Another "goodie" from Blackhat Asia 2017:

HACK MICROSOFT USING MICROSOFT SIGNED BINARIES

https://www.blackhat.com/docs/asia-17/materials/asia-17-Braeken-Hack-Microsoft-Using-Microsoft-Signed-Binaries-wp.pdf

Also use of PowerMemory is not new as noted here: http://securityaffairs.co/wordpress/39721/hacking/powermemory-extract-credentials.html .

 

I have previously mentioned the use of Empire as a way of getting nailed by a Powershell attack but did didn't get into a lot of details. So lets do that.

You are blocking/monitoring execution of the default version of PowerShell installed on your PC. You have uninstalled PowerShell 2.0 or are using Win 10 1709 on which it is uninstalled by default. You have set PowerShell to "Constrained Language" mode in the event it is employed via .Net methods. You think you are safe from a PowerShell attack. You are not:

https://blog.stealthbits.com/how-attackers-are-bypassing-powershell-protections/

-EDIT- Here's a more recent article that describes how Empire does the privilege escalation that was not detailed in the previous article. Also how WD was totally useless against this attack: https://www.alpinesecurity.com/blog/2018/1/11/empire-a-powershell-post-exploitation-tool

 

Research CobaltStrike, experts on metasploits using powershell and various reflective injections.

 

That privilege elevation mentioned in script and described here really looks interesting. I don't know why a normal user can set environment variables in HKCU. It would probably be better to store them only in HKLM.
I also wonder if MS fixed it already or did they just say "UAC is not a security boundary". Under SUA elevation - and consequently exploit - wouldn't work.

 

Does that privilege escalation work on Windows 10?
Either way, disabling system.management.automation.dll would prevent this exploit, correct?

 

OSA block the attack:



Configuring Additional LSA Protection:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn408187(v=ws.11)

 

From blog:

Interesting, that built-in software restriction policies also show problems if default rules with variables are used. Maybe MS should reconsider their usage and just use absolute paths instead.

IDK about exploit itself and if disabling that DLL would mitigate it.

 

So it sounds like the current version of win10 is not vulnerable to it.

As far as I understand, if powershell.exe is blocked, and also system.management.automation.dll is blocked, it is pretty hard to get any powershell functionality.

 

Yes, but there could be a problem if another instance of powershell is downloaded and run from some other location. And with elevated rights that could be possible.
You might be using a security approach where user can run things from where he can't write and can write things from where he can't run anything. If privileges are elevated, that approach falls apart.

 

Right. If malware already has elevated privileges, it's too late.

 

Hum ............... Looks like everyone missed Empire's capabilities.

Please re-read reply #190. Empire's use of PowerShell is totally independent of Window's based PowerShell or any of its components such as system.management.automation.dll. Empire employs equivalent PowerShell capability in the Agent modules it deploys. Therefore blocking anything to do with Windows based PowerShell, any of its system components, or restricting execution of same thru language mode restrictions have absolutely no impact on Empire's use of Powershell functionality.

Another way to understand Empire is it is the equivalent of Windows PowerShell but being run from the attacker's server.