The rise of .NET and Powershell malware

OK, so I suppose blocking powershell.exe from loading would stop this particular attack.

 

The three attacks shown in the article all execute powershell.exe directly. So, blocking/monitoring its execution would suffice.

What was a bit strange was one attack showed the path c:\windows\system32>powershell.exe? Powershell is located in C:\Windows\System32\WindowsPowerShell\v1.0 by default. This might be an example of something I have suspected; malware dropping an instance of powershell in another directory? Or, the ">" redirect symbol in a cmd line will cause a search of all sub-directories for the program instance?

More Evasion Techniques

In addition to anti-vm tricks, the malware uses PowerShell features such as encoding and quote obfuscation were also used.

For example, all three commands shown below will launch Notepad.

https://www.fireeye.com/content/dam/fireeye-www/blog/images/Powershell/powershellfig18.jpg

 

So virtually any malware which uses PowerShell features could run ANY harmless installed application?
For example I use SecureFolders to protect in a locked state a special data folder from any kind of cryptomalware. However I added some trusted applications allowed to do anything to the files within that special data folder (explorer.exe, notepad.exe, notepad++.exe, excel.exe, powerpnt.exe, winword.exe, etc.)
Am I still at risk if I don't monitor PS?

 

Actually, you do almost anything with Powershell. Only way to stop it is monitor its execution. And, that can be difficult if malware downloads it to some other location than its default C:\Windows\System32\WindowsPowerShell\v1.0 location such as "trusted" directory. I just ran it out of my Downloads folder. It ran fine.

Then there is the execution of its assemblies using a C# program that has been discussed previously.

 

Nice move Peter, I'll do the same right away!

Thanks both of you.

 

If you monitor it's execution than dropping it somewhere else and trying to launch it from there would probably also be stopped by same tool or program that you use to monitor it's execution, wouldn't it?

 

And then there is PS2EXE which simplifies creation of a C# malware program that uses the Powershell assemblies. Not very creative since it dynamically loads them.

During my research, I have discovered an interesting tool named PS2EXE. The tool encapsulates PowerShell code within a PowerShell host object written in C# and generates an EXE file from it. This EXE contains all functions necessary to run PowerShell through a .NET object. However, it can’t be run without an installed version of PowerShell and the .NET framework. However, this EXE doesn’t access powershell.exe and can therefore be executed despite the Deny rule. It’s possible to create one such EXE for every PS script and define it as an exception in an Executable Rule. In addition to that, PS2EXE can be used to circumvent a PowerShell block.

Ref.: http://www.scip.ch/en/?labs.20150507

 

No.

If using WIN 8 and above, you can create a hash rule for powershell.exe using AppLocker. Pretty sure this will work since powershell.exe is an unsigned file. Not 100% secure due to past AppLocker bypasses. You can use this as a reference: http://www.grouppolicy.biz/2010/04/...y-in-windows-7-to-block-third-party-browsers/

 

That's only if you are using blacklisting approach. If you are using whitelisting (much more secure) then all new binaries will be automatically blocked. Personally I use SRP and all locations where I can drop exe without admin rights are blocked from executing.

 

You might want to read the below articles. Think I posted these links before?

https://www.sentinelone.com/blog/the-truth-about-whitelisting/
http://foregroundsecurity.com/resou...hite-flag-bypassing-application-white-listing

 

I don't know if you've already posted them. I know that whitelisting is not bullet-proof as no other singular protection layer. Anybody exploiting this (mostly theoretical) weaknesses wouldn't have to use powershell or .net malware as they would already have much more powerful tools in their hands.

 

SRP protection against dropping without admin rights + Secure Folders with Microsoft.NET and Powershell directories set to no execution (go out of your way to source non- .NET apps) = win? (I feel comfy with it)

 

Thanks @marzametal
Which are the .NET Framework and Powershell directories to set to no execution on a x64 system?
I have several versions of .NET installed, does it matters?

 

Probably enough against usual malware, so if your not under targeted attack you are IMO more than OK.

 

Whitelisting for .Net is far more complex than another can imagine.

Let's backup to this prior posted link: https://www.sixdub.net/?p=367 that people are treating as a guide to blocking the loading of the System.Management.Instrumentation.dll from the .Net global assembly cache i.e. GAC. For starters, no decent C# hacker employing Win API calls would do so for the following reason:

5. Programmatically accessing the GAC through APIs

CAUTION: Do not use these APIs in your application to perform assembly binds or to test for the presence of assemblies or other run time, development, or design-time operations. Only administrative tools and setup programs must use these APIs. If you use the GAC, this directly exposes your application to assembly binding fragility or may cause your application to work improperly on future versions of the .NET Framework.
Ref.: http://www.codeproject.com/Articles/4352/Demystifying-the-NET-Global-Assembly-Cache

Instead the hacker is going to reference the System.Management.Instrumentation.dll stored in one of these directories;

C:\Windows\Microsoft.NET\Framework\v2xxxxxxxxx
C:\Windows\Microsoft.NET\Framework\v3xxxxxxxxx
C:\Windows\Microsoft.NET\Framework\v4xxxxxxxxx
C:\Windows\Microsoft.NET\Framework64\v2xxxxxxxxx
C:\Windows\Microsoft.NET\Framework64\v3xxxxxxxxx
C:\Windows\Microsoft.NET\Framework64\v4xxxxxxxxx​

depending on the OS type and version of .Net used to create his C# program.

Now back to the proper way to whitelist .Net.

First note that .Net .dlls can be created on the fly; see the Wilders posting on 'Just-In-Time Malware Assembly' for one such method. This is really what you want to protect against.

Rule 1. Protect what can create where .Net .dlls can be written to.
Rule 2. Restrict what can access .Net .dlls

All that is explained in this .pdf: https://www.sans.org/reading-room/w...s/application-white-listing-bit9-parity-35572 ; pages 10 - 11.

Note: Creating these rules will require you to create an exception for rule 2 for every app that runs .Net .dlls. On my PC there is one only app that does so.
Also worth noting is nothing is mentioned about the GAC in the SANS article.

-EDIT-

A bit of explanation on this "HKLM\Software\Microsoft\.NetFramework\InstallRoot>*\mscorsvw.exe" entry and the same for the SysWow6432 key in SANS article. It means every instance of mscorsvw.exe located in the directory specified in the registry value of InstallRoot located in HKLM\Software\Microsoft\.NetFramework\. In other words, all the C:\Windows\Microsoft.NET\Framework64 and/or C:\Windows\Microsoft.NET\Framework directories specified above

Note: This is for WIN7. So check the registry key value for the correct directories to use for other Win versions.

Important: The mscorsvw.exe rule shown in the SANS article is disabled. The assumption is your running in lockdown mode; mscorsvw.exe is not allowed to execute at all. You would enable this rule to allow it to execute. This is important for WIN updates since you will see mscorsvw.exe running during WIN updating.

Here is where a HIPS would be a better solution since you can monitor mscorsvw.exe execution and allow it to run during the WIN updating process. Change your current ver. of .Net service which is probably .v4x from delayed auto start to manual . That way you won't get a HIPS alert at boot time. Note: on my PC all the older .Net versions are disabled.

 

@itman Thank you very much.

 

Great article on .Net dynamic code execution along with examples to execute code on the fly both locally and remotely.

It is interesting how .NET allows you to run dynamic code; essentially it provides you all the tools that a compiler uses to generate an executable. If you want to get even more low level you can use the System.Reflection.Emit namespace to generate IL level code directly.

http://www.codemag.com/article/0211081

 

Here is an example of just how powerful and stealth .Net based malware can be.

Most Window's troubleshooting is .Net based. A good one to run to and observe its activities is the network connection trouble shooter which I am sure most have run at one time or another. Upon startup of this trouble shooter:

1. Csc.exe will start execution and create a .dll in the %Windows%\temp directory.
2. Next, mscorsvw.exe will start and execute the newly created .dll.
3. Finally, csc.exe will delete the previously created .dll.

So here we have a method to dynamically create a malicious .dll on the fly, execute it, and remove all traces of its activities. Best way to control this activity is to monitor it using HIPS rules.

 

Hi itman, you seem to rely on HIPS, pretty much. Do you think SpyShelter is a good choice?

 

Can't comment on it. Never used the product. Rasheed187 thinks highly of it though.

I always try to find an AV solution that has a good HIPS included. No reason to pay double for both security solutions. Also since the HIPS is integrated within the product, less conflicts and I believe better overall protection. Note: it is getting increasingly difficult to find retail products with an integrated HIPS. Retail security vendors are all developing "intelligent" behavior blockers which require little if any user interaction. I will concede this is a good move but I don't believe the BB's are at the development stage yet they can be fully trusted.

 

Alright thanks for the info.

 

• Don't bother using Sandboxie with SpyShelter; you will be required to consolidate some security. They do not work in harmony at 100%.
• If you deny specific things on SpyShelter, eventually you will be visited by "WerFault.exe" and be required to restart "explorer.exe". Some things are required by Windows, whether you like it or not.
  
• If you are using a VPN, SS Firewall is not VPN friendly; cannot "hide you".
• SpyShelter comes with its own version of a "sandbox". Some applications let you use multiple sandboxes (eg: can manage to get an app to run in SBIE, whilst being contained in SS, along with Access Control Lists), while others kick up a fuss. SpyShelter's sandbox is more for prevention of privilege escalation (their terminology is "shatter attacks").

If I was to go back to SpyShelter (I have a lifetime licence), I would only use it for file/folder monitoring (notify me when a file or folder is being accessed/written to) and the NetworkSpy feature.

 

And for file/folder, mainly folder, I use SecureFolders. So I think I'm safe (for my particular needs) with my current programs... thanks @marzametal

 

It's currently the best HIPS for Win 8 and 10, it just needs some polishing when it comes to certain things. Personally I prefer standalone HIPS, especially now most AV's are bloated as hell.

I haven't got any problems with the SBIE + SS combo. It's of course not advisable to block things that are required by Windows, and if you use SBIE, you don't need the SS sandbox. The sandbox will basically strip admin rights + deny write access to certain folders.