Jump to content

Archived

This topic is now archived and is closed to further replies.

itman

Concerns About AV Industry Lack Of Response To .Net Based Malware

Recommended Posts

I am going to include Eset in this category since I have not seen any evidence this issue has been addressed by them.

Every since I observed the recent malware deployment of C# programs employing Powershell native APIs, I have been concerned about the AV vendors lack of response to the threat. My anxieties on this have escalated considerably with the weaponizing of this malware through the use of the TheFatRat exploit kit as noted below:

In this case study different tools and methodologies have been shown to create shellcode and Windows executables trying to evade some security systems such as antivirus systems and preinstalled Windows systems.

Making an overall analysis of the results obtained, we note that TheFatRat gives the best results, creating a fully undetectable payload (exe file with C# and powershell) that is recognized only by Kaspersky antivirus.

Ref.: http://www.iswatlab.eu/wp-content/uploads/2017/01/Technical_Report_Evasion.pdf

I do realize the difficulty involved with the use monitoring of Powershell native APIs. However if Kaspersky has figured out a way to do so, I assume Eset can as well.

Share this post


Link to post
Share on other sites

Improved scripts in .lnk files now deliver Kovter in addition to Locky Ref: https://blogs.technet.microsoft.com/mmpc/2017/02/02/improved-scripts-in-lnk-files-now-deliver-kovter-in-addition-to-locky/

The recommended Microsoft mitigation which is worthless to anyone not running Win 8/10 Enterprise is AppLocker policy:

In Windows 10, lock down PowerShell version 5 to “Constrained Mode“, which limits the extended language features that can lead to unverifiable code execution such as direct .NET scripting, invocation of Win32 APIs via the Add-Type cmdlet, and interaction with COM objects.

More on that:

In version 5, PowerShell now reduces its functionality to “Constrained Mode” for both interactive input and user-authored scripts when it detects that PowerShell scripts have an ‘Allow Mode’ policy applied to them. Constrained PowerShell limits the language mode to Constrained Language (as described in about_Language_Modes), a mode first introduced for Windows RT.

Ref.: https://blogs.msdn.microsoft.com/powershell/2015/06/09/powershell-the-blue-team/
 
-EDIT- Found a way to do this using Powershell: https://itfordummies.net/2015/06/01/powershell-constrained-mode/
 
Now I can sleep better at night:)

Share this post


Link to post
Share on other sites

Hello,

From the ESET NOD32 Antivirus Product Overview paper:

Script-Based Attack Protection

  • Detects attacks by malicious scripts that try to exploit Windows PowerShell
  • Also detects malicious JavaScripts that can attack via your browser. Mozilla Firefox, Google Chrome, Microsoft Internet Explorer and Microsoft Edge browsers are all supported

Source: https://cdn1-prodint.esetstatic.com/ESET/INT/Products/Home/EAV/v10/Product_Overview-ESET-NOD32-Antivirus.pdf [PDF]

This also applies to ESET Internet Security, ESET Smart Security and ESET Smart Security Premium v10.

Regards,

Aryeh Goretsky

 

 

Share this post


Link to post
Share on other sites
On ‎2‎/‎8‎/‎2017 at 0:33 AM, Aryeh Goretsky said:

Hello,

From the ESET NOD32 Antivirus Product Overview paper:

Script-Based Attack Protection

  • Detects attacks by malicious scripts that try to exploit Windows PowerShell
  • Also detects malicious JavaScripts that can attack via your browser. Mozilla Firefox, Google Chrome, Microsoft Internet Explorer and Microsoft Edge browsers are all supported

Source: https://cdn1-prodint.esetstatic.com/ESET/INT/Products/Home/EAV/v10/Product_Overview-ESET-NOD32-Antivirus.pdf [PDF]

This also applies to ESET Internet Security, ESET Smart Security and ESET Smart Security Premium v10.

Regards,

Aryeh Goretsky

 

 

The attacks I mentioned are not Powershell script based. They are .NET program based invoking internal Powershell commands via API.

Again, I am OK now since I set Powershell to Constrained Language mode which only allows Windows core processes to perform such activity.

-EDIT- More good news on this Powershell policy mode "hack" in regards to bypassing it in non-AppContainer supported Win OS versions. A Microsoft "employee" tested it for the prior documented bypass and found it to be non-applicable; at least for Win 10: https://blogs.technet.microsoft.com/kfalde/2017/01/20/pslockdownpolicy-and-powershell-constrained-language-mode/ .

As added protection, I will add a HIPS rule to monitor the applicable registry key for any modification attempts.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...