Current state of malicious Powershell script blocking

For starters, this is a Word exploit. The .dll in question is not being memory injected into Word. The .dll is a hijacked one and is being loaded into Word normally at startup time.

Correct - by now hopefully everyone is monitoring outbound connections from MS Office executables. As far as HIPS monitoring, I also assume everyone is now monitoring mshata.exe startup. I will add csc.exe to my MS Word child process startup monitoring since that is a "new twist." Also the running of csc.exe from Word will run up all kinds of "red flags" by the behavior monitors especially Next Gen ones.

 

Interesting PowerShell script based "test" tool here: https://github.com/subTee/Interceptor/blob/master/InterceptorNG.ps1

Was used by MRG in their recent Q2 - 2017 Online Banking Protection test: https://www.mrg-effitas.com/wp-content/uploads/2017/09/MRG-Effitas-Online-Banking-Certification-2017Q2_wm.pdf

 

Here is another one that can be blocked with monitoring of outbound access, process execution and code injection/process hollowing:

https://www.fireeye.com/blog/threat-research/2017/04/cve-2017-0199-hta-handler.html

 

Guys/Gals, I was not sure where to post this so if anyone wants to start a new topic based on it or have mods move it appropriately. Anyway, it has to do with malicious script blocking via AMSI as well.

Link: https://twitter.com/JohnLaTwC/status/916693494504157184

So Microsoft Office will also be able to have VBA scripts pass through AMSI soon, similar to PowerShell filtering through AMSI.

 

Anyone relying on signed Powershell scripts to protect them, especially those using AppLocker, really needs to read this: https://pentestlab.blog/2017/11/06/hijacking-digital-signatures/ . Also what is published can be also used to sign stuff like mimikatz.exe.

 

https://www.fireeye.com/blog/threat-research/2017/07/revoke-obfuscation-powershell.html

 

The problem with Revoke-Obfuscation is it is a post breach forensic tool. Lee Holms has been pushing un-obfuscation research at Microsoft for some time with what appears to be the failure to the brass there to incorporate it into AMSI real time process in Win 10. As this posting notes: https://www.wilderssecurity.com/thr...-windows-10-needs.383448/page-61#post-2724158 , the Win 10 RS3 WDEG ASR to detect potentially obfuscated scripts is deficient. To further add to the problem is each AV vendor that choses to use the AMSI interface is responsible for the full decoding of obfuscated scripts and applying their realtime scan engine signatures to those scripts for malware detection.

The bottom line is that real time script obfuscation mitigation still has a long way and is far from being fully effective in the majority of security solutions.

 

Is there any information available if browsers like Chrome and firefox will make use of AMSI?

 

Win 10 AMSI is a script filtering interface available to AV vendors for their products; it has nothing to do with filtering browser traffic or script execution within the browser itself. AMSI captures script execution code from the PowerShell, wscript, and cscript engines. It primary purpose is to monitor scripts after they have been unpacked and un-obfuscated. Also of note is each AV vendor is responsible for creating their own version of the native amsi.dll that is used in Windows Defender.

 

Thanks, itman.
I think any application may make use of AMSI.
I guess Edge does so.
Check the URL / IP section of this article https://msdn.microsoft.com/de-de/library/windows/desktop/dn889587(v=vs.85).aspx

 

FYI: https://blogs.technet.microsoft.com...-application-developers-new-malware-defenses/

 

I have been playing around with a 4 year old Powershell based global keylogger that runs under .Net control. Runs great on Win 10 1709. You can read about it here: https://hinchley.net/articles/creating-a-key-logger-via-a-global-system-hook-using-powershell/.

For those too lazy to create the PowerShell code, I am attaching a .txt version of the Powershell script. Just rename it to .ps1. It can run from any directory of your choice.

To run it, do the following. Obviously, you have to let Powershell run:

1. Open up a command prompt - admin level not need.
2. Do a cd command to change to the directory where you stored the script. Or alternatively, specify the directory path of the script in the following command.
3. Enter in the command prompt window the following:

powershell.exe -ExecutionPolicy Bypass -file Logger.ps1
​

All your keystrokes will be stored for every app you run in a file named log.txt in the same directory where the script is located.

This keylogger is a great one to test your security app online banking protection with. At the minimum, all your keystrokes within the browser protected by banking protection should be scrambled.

@Rasheed187 test under SpyShelter to see if it can block the global keylogger or scramble all recorded keystoke output. Also, anyone using Zemana Anti-logger can do the same. I am curious if the dedicated anti-logger solutions can detect this PowerShell based global keylogger.

-EDIT- I forgot to mention that there is nothing malicious about this keylogger so you don't have to run it in a VM.

To terminate the keylogger, just kill the PowerShell instance running it via Process Explorer or Win Task Manager. That will remove the hook from user32.dll in system space previously set. I also recommend rebooting after testing.

Finally, setting Powershell to Constrained Language mode stops the keylogger dead in its tracks since the C# program can't load and execute from .Net.

 

Great article on .NET based Powershell bypasses. Skip to section IV for Windows Defender bypasses:

https://arxiv.org/ftp/arxiv/papers/1709/1709.07508.pdf

 

I will see what I can do, but to be honest, I don't see why SS would fail. It simply encrypts keystrokes for all applications, so it should easily block all hook based keyloggers.

 

It was my understanding that the "full" SpyShelter product will actual block the global hooking activity, i.e. hook and thread setting, versus the keystroke encryption only done by the anti-keylogger product?

Eset's Online Payment Protection(OPP) likewise scrambles keystrokes. It passed with "flying colors" against the above .Net based global keylogger. However, it does so only while OPP is active. So if you accessed a web site outside of OPP mode, your keystrokes could be captured.

 

No, it does both. It alerts about global hooking and the keystroke encryption feature is always active. If ESET passed then so will SS. It also auto-blocks API hooking. As we discussed before, the ability to block API hooking (used by banking trojans) is much more impressive, because not a whole lot of security tools offer this feature.

 

BTW, perhaps you can test Ghostpress, I wonder if the method that it's using is good enough. It makes use of a global hook, to protect against hook based loggers. So in fact, it's using the same trick that keyloggers use.

https://hendrik.tf/ghostpress.html

 

Lo and behold, the free ver. of SpyShelter Anyi-Keylogger - current one it appears - is available at FileHippo. Got it currently installed.

 

So, what were the results of both SS Free and Ghostpress?

 

I never used GhostPress, so can't comment on it.

As far as SS Free goes, I didn't care for all the changes it made to default system settings and uninstalled it. It is also a bit "chatty" in its default installed aggressive mode with a lot of its alerts duplicates of those I have created in Eset's HIPS. The universal keystroke encryption it does is a nice feature but I have never been one that is paranoid about that. Eset's Online Banking Protection feature does the same which I use if I am conducting any Internet based financial activity.

 

A good Outbound firewall would be enough to stop any keylogger. A logger (or Banker) can collect any data it wants but if it cannot transmit this data to the bad guys who really cares?

 

Yes but why didn't you test them? Also, perhaps you should install SS Silent, which only offers keystroke encryption, without the HIPS.

https://www.spyshelter.com/download-spyshelter/

Correct, that's why people who say that outbound firewalls are a thing of the past don't get it. File/folder monitoring is also important, if malware don't have access to files, they can't steal or encrypt data.

 

For those employing a registry hack to set PowerShell language mode to "Constrained" such as yours truly, I have some bad news. It can be bypassed:

https://adsecurity.org/?p=2921

My take on this is it can only be done it the context of a Powershell session. Since most are monitoring PowserShell execution, you should still be OK. However, one needs to scroll down in the above linked adsecurity.org article to near the end. There is a section noting that if the attacker runs PowerShell from a .exe, it is "game over" since language mode restrictions are N/A in that instance.

 

It also helps to look at an actual PowerShell attack. In this instance it was for a server running Win 2012 Server OS using an unpatched ver. of MySQL.

Note the use of New-Object Net.WebClient - ref.: https://blog.jourdant.me/post/3-ways-to-download-files-with-powershell . Unfortunately, this Admin was clueless about the dangers of PowerShell.

 

Below is an interesting posting in regards to Powershell Invoke-Expression, i.e. powershell IEX, used in the above attack and in many of the .Net based attacks seen to date. Microsoft a while had a discussion about allowing for disabling it outright. As the Conclusion section notes, there is really no complete way to do so as there is no like method for ExecutionPolicy. But there appears to be ways to "slow down" hackers ways of using it.

https://blogs.technet.microsoft.com/pstips/2016/05/12/disable-invoke-expression/