Current state of malicious Powershell script blocking

[itman 1,659]

Quote

Introduction

When I watched this great presentation from Will Schroeder (@harmj0y) it made me thinking. How about doing a quick and dirty Powershell test. For this exercise, I choose Invoke-Mimikatz.

Mimikatz (Benjamin Delpy – @gentilkiwi) is the gold standard when it comes to lateral movement or grabbing passwords/hashes. Invoke-Mimikatz is a Powershell version of Mimikatz, where the Mimikatz executable is not written to the disk.

AMSI is Microsoft’s “Antimalware Scan Interface”, which can be used to detect malicious Powershell code – even in-memory, at execution time. Let’s see what AMSI is capable of, and what can we expect if AMSI is not used.

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

Eset did quite well in this Win 10 testing being one of three AV vendors to detect fileless based PowerShell script execution. It now has to work on detection of obfuscated Powershell scripts.

Edited August 9, 2017 by itman

[itman 1,659]

I will add that Win 10 AMSI has a number of security issues. I will discuss two of them.

The entire AMSI interface consists of a single .dll. In Eset's case it is eamsi.dll. This can be disabled by malware unregisteing the eamsi.dll file using this command: regsrv32 /u C:\Program Files\ESET\ESET Security\eamsi.dll. Therefore this registry key, HKEY_CLASSES_ROOT\CLSID\{ECC7E393-B680-4109-86BD-7779105DF1BF}, needs a HIPS rule, if a default one doesn't currently exists, to prevent modification.

The Eset AMSI .dll could be highjacked i.e. provide and use a custom.dll and call that one from custom .exe as noted here: https://cn33liz.blogspot.nl/2016/05/bypassing-amsi-using-powershell-5-dll.html. This article applies to amsi.dll that is used by Windows Defender but appears it would be equally effective against Eset's AMSI .dll.

Edited August 9, 2017 by itman

[Peter Randziak 1,130]

Hello ITman,

we will check it, thank you.

Regards, P.R.

[itman 1,659]

4 hours ago, Peter Randziak said:

Hello ITman,

we will check it, thank you.

Regards, P.R.

I am adding another reference to AMSI vulnerabilities that as far as I am aware of, Microsoft has done "diddly squat" about.

As far as reference no. 1 goes, I am running PowerShell in "Constrained Language" mode which will block all its API call methods. Appears reference no. 2 use was what Eset was having an issue with in the MRG ad hoc test.:

Quote

Exploiting AMSI Script Protection

Mitall presented the following AMSI exploit methods:

1. Unusual Shell Execution
   • Run without powershell.exe
   • Utilize reflection (within the memory space of another process)
   • Apply application whitelisting bypass (install and so on)
2. Signature Bypass (This method is known as obfuscation, or the ability to render the script unclear or unintelligible to AMSI)
   • Remove the help section
   • Obfuscate the function and variable names (change names to numbers, for example)
   • Use simple obfuscation tools that work
   • Encode parts of the script
   • Deliver the payload

"This method is fast and very effective at the time of this presentation," Mitall explained. AMSI flaws extend beyond the ability to bypass the system. AMSI can also be exploited by attackers that have elevated permissions to the Windows machine running AMSI. Mitall presented two options, referencing two separate researchers:

• Matt Graeber (@mattifestation) -- a one-line command; no admin privilege is necessary (client-side attacks are possible); also bypasses automatic logging
• Cornelis de Plaa (@Cneelis) -- moves powershell.exe to where the AMSI.dll is and executes it from there; loads a fake DLL (AMSI doesn't execute)

 

Ref.: https://redmondmag.com/Articles/2016/10/01/Dissecting-Windows-10-Security.aspx?Page=1

Edited August 10, 2017 by itman

[itman 1,659]

Also of note is that Microsoft is removing Powershell 2.0 in Win 10 CE fall update. By default, it is presently installed on all Win 10 versions. More important is all the attacker has to is run PowerShell for example by specifying its version number via command shell at startup time, and AMSI will be bypassed as noted here:

Quote

 

The Problem with PowerShell 2.0

New security features in PowerShell 5.0 make it much harder for hackers to uncover users’ credentials, using frameworks like Mimikatz, if you follow security best practices.

Anti-Malware Scan Interface

The Anti-Malware Scan Interface (AMSI) interface in Windows 10, which is supported out-of-the-box by Windows Defender and available to other antimalware products, can perform deep scans on obfuscated PowerShell code. This is code that has been encoded specifically for the purposes of avoiding detection. If a hacker manages to force the use of PowerShell 2.0, then AMSI is unable to de-obfuscate the code.

 

Ref.: https://www.petri.com/microsoft-deprecate-powershell-2-0-windows-10-fall-creators-update

So PowerShell v2.0 needs to be uninstalled via Control Panel -> Programs -> Uninstall optional features or using the PowerShell command noted in the article. 

Edited August 10, 2017 by itman

[itman 1,659]

One final comment.

As far as the obfuscated in-memory script execution of PowerShell that Eset missed in the MRG test, running PowerShell in "Constrained Language" mode will block the Invoke-Mimikatz method used as shown in the below screenshot from another article on PowerShell exploiting here: https://adsecurity.org/?p=2921

Appears Avast and HitmanPro_Alert must be monitoring all or select API's used by PowerShell.

As far as setting Constrained Language mode within Powershell itself as shown in the screenshot, that is a temporary setting and will be lost at the next system boot. There is an undocumented way of making the setting permanent w/o the need for AppLocker which is only available on the Enterprise versions of Windows. It involves the creation of an environment variable.

[itman 1,659]

To point Eset in the right direction is a detailed write up on Invoke-Obfuscation and its use in Empire:

Quote

 

ObfuscatedEmpire - Use an obfuscated, in-memory PowerShell C2 channel to evade AV signatures

Mar 1, 2017

ObfuscatedEmpire is an integration of two fantastic projects, Invoke-Obfuscation and Empire. If you aren’t already familiar with those projects, you really should go check them out first. But here’s a quick summary for those who are unfamiliar:

• Empire is a PowerShell post-exploitation agent. It’s a powerful tool for attackers as it allows for a C2 channel to be run completely in-memory, without any malicious code touching disk, rendering traditional AV techniques ineffective.

Invoke-Obfuscation is a PowerShell script obfuscator. As the use of in-memory PowerShell malware has grown, implementation of in-memory AV scanning of PowerShell scripts has begun. Invoke-Obfuscation challenges all assumptions these in-memory PowerShell AV signatures have been making.

 

And most importantly what it has to do:

Quote

 

Mitigation

My intention in releasing this tool integration is to demonstrate to defenders the obfuscation tactics that are already being used in the wild. This will provide pentesters and red teamers the ability to provide more value to their clients by using already available obfuscation techniques when establishing their C2 channel. The end goal here is to improve security.

Mitigation of these obfuscation techniques can be tricky. As previously mentioned, using AV equipped with AMSI scanning is already a step in the right direction, as several layers of obfuscation are stripped off prior to scanning. However, there is still the token-level obfuscation to contend with, which is what makes Invoke-Obfuscation and ObfuscatedEmpire effective. A technique that has been suggested by Lee Holmes (of Microsoft) and others is to search for signs of obfuscation itself. For example, a token-level obfuscation trick utilized by Invoke-Obfuscation is to insert apostrophes into function names and other tokens. Invoke-Empire might become iN`v`OK`e-`eM`p`IR`e, these are functionally equivalent within PowerShell but will break AV signatures matching the string “Invoke-Empire”. But should we really expect that 50% of a script consist of apostrophe characters? This is an obvious sign of obfuscation, which AV vendors should begin to implement detection for. Holmes wrote about these types of detection methods as early as November 2015 here and here if you would like to read more

 

Ref.: https://cobbr.io/ObfuscatedEmpire.html

Edited August 12, 2017 by itman