A rash of invisible, fileless malware is infecting banks around the globe

As best as I can determine, command shell scripting is ignored by most AV products save Emsisoft which does monitor .bat scripts with its behavior blocker.

It is possible to bypass Win 10 native SmartScreen using a command shell script.

Additionally, command shell scripts have been used by ransomware as noted below.

After some additional deobfuscation on the VBA macro I combined the 3 parts to reveal full script and the actions performed.

1. VBA macro creates file %temp%\arra.bat

2. Writes decodes and writes value of textbox1 and textbox2 to arra.bat

3. Executes %temp%\arra.bat

3.1. Arra.bat in turn creates %tmp%\dasdee.vbs
3.2. Echo’s the script contents to the dasdee.vbs script
3.3. Executes dasdee.vbs using cscript

3.3.1. dasdee.vbs performs a GET request to the http address passed in parameter %0% and saves the response to the location in parameter %1%


​

3.4. The bat file then executes the file save by the vbs script, deletes the vbs scripts and deletes itself.​

Ref.: https://www.sternsecurity.com/blog/locky-ransomware-analysis​

 

Interesting, a little technical for me but the answer is: no, neither is particularly "safe." Locky...geez. OK, I will have to keep an eye out for a standalone behavior blocker to add--there doesn't seem to be much available right now. Thank you for this information, itman.

 

Since you never got any clear feedback.
SUA are a security boundary.
Anything capable of escalating to admin or higher from such, would be 1. priority in next batch of OS updates.
Furthermore Microsoft are currently doing a lot of work on the UAC implementation so the bypasses of UAC that are possible for those not using SUA are minimized or hopefully all blocked when Creators Update are ready.

As for the thread in general -
This thread has become a Wilders classic.
A report are released.
It is being misinterpreted.
And then these misinterpretations results in overthinking issues into the irrelevant.

Nothing in report can happen without admin credentials.
How did attacker get admin credentials ? - they used a as of now undisclosed vulnerability in a domain controller to run Mimikatz.
With Mimikatz running the attacker waited until someday when sys.admin remoted in and then harvested admin credentials.
Next with obtained admin credentials the attacker used PowerShell to load Meterpreter into memory and NETSH to tunnel out from server.

Absolutely nothing to worry about for any regular user that might be reading along.
Zero of them will be running a domain controller on their network.
Zero of them will be remoting into servers on their network.
Zero of them has a server running always-on on their network where such in-memory only malware are a problem, and zero of them will ever experience such a attack move laterally through their home network.

To a home user or SMB user, the only thing that matters are that anything passing through PowerShell are being inspected.
And as I posted a link to in another thread a week ago, then AMSI will make sure that no matter how obfuscated the script might be then AMSI will pick it up as it becomes unobfuscated and before being executed it is inspected by AV registered in AMSI.
The native security in Windows 10 for example are deeply tied together with AMSI.

(and a small note to the thread in general without starting a big back and forth argument - claims of SmartScreen bypasses through scripts are irrelevant, since SmartScreen are not meant to monitor scripts. That is done with AMSI that makes it possible for any AV registered in AMSI like the native security in Windows 10 for example to monitor the unobfuscated script before execution. And any executable executed from a script are monitored by running AV. Different features for different protective actions, as mentioned in another thread. )

 

FYI and clarification:

As it is possible to see, created executables are blocked by Windows SmartScreen, which carries out some checks on downloaded files from Internet. In fact, these payloads are passed to the testing virtual machine downloading them from Google Drive and running them by double clicking through Windows GUI. However, if payloads are executed through command line shell, Windows SmartScreen does not block their execution. In this way, its protection has been bypassed.

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

Additionally verified by my own testing.

Also from the above study it appears that Windows Defender does scan command shell scripts from the AMSI interface. Eset for example does not since I specifically asked them about it.

​

 

Thank you for reply @Martin_C . It didn't make sense to me for MS to break their own security model and I was just looking for confirmation.

 

To close out my discussion on this topic, it should be noted that AMSI can be exploited: https://redmondmag.com/Articles/2016/10/01/Dissecting-Windows-10-Security.aspx?Page=1 ; scroll down to this section "Exploiting AMSI Script Protection." The thing I find disturbing is that the AMSI.dll hijacking exploit noted was originally reported in 5/2016 here: http://cn33liz.blogspot.com/2016/05/bypassing-amsi-using-powershell-5-dll.html and appears not to have been mitigated yet at the time of Redmondmag article publishing.

So I guess we have come full circle with the only "foolproof" method of stopping malware scripting excluding Powershell is what a lot of folks are presently doing. That is to block/monitor all script execution.

-EDIT- For anyone using a HIPS, Eset developed script execution monitoring rules for their Endpoint customers that I use: http://support.eset.com/kb6119/. I have all rules set to "ask." Additionally, I have separate rules that I use to monitor direct cmd.exe startup since I use a number of .bat scripts that run at startup and/or demand.

You can use these Eset rules as a guide in your HIPS factoring in variations in rule syntax used.

 

@Martin_C

Does running SUA with an allow Admin elevation (and ask for admin credentials) has any security benefits over running Adminstrator with UAC on (also asking for credentials)?

I considered running SUA with allow admin elevate after credentials because MS explicitely mentions SUA as a security border and explictely mentions UAC is not a security border (but when checking which processes are involved internally, I really don't see much difference)

Thanks

Kees

 

@Minimalist : You are welcome.

@Windows_Security : With Enigma0x3 UAC bypass fresh in memory, I would never use anything but SUA. (I have always used it anyway)
I really hope that Microsoft will get through the list of known UAC bypasses, hopefully with Creators Update. And react quickly upon new findings.
But realistic speaking, there's always the possibility of a as of yet unknown bypass suddenly surfacing.
With SUA you know that you are not in trouble, if it happens.

 

Don't let Scripts bother you !

Have a look in here https://www.wilderssecurity.com/threads/what-is-the-use-of-script-defender.273325/#post-1683493 for my & Rmus etc & others posts about Scripting etc etc, including

I've had AXSD since 98SE days, & added in lots of extensions over the years, & also blocked cscript.exe & wscript.exe from running by renaming them.

 

Did you end up trying NoLanguage Mode out? If so, how did it go for you?

 

Didn't get up the nerve to try it yet. In NoLanguage mode you can't run anything from the PowerShell shell including the command to verify that you set the language mode to NoLanguage.

My past and present concern was blocking .Net based Powershell malware. More so presently since it has been "weaponized" through exploit kits such as TheFatRat. Using ConstrainedLanguage mode took care of that. Most malware developers are not skilled C or assembler language programmers; if they have any programming skills at all.

I was an IBM mainframe system programmer many moons ago writing drivers and system utilities using assembler. It's not easy stuff to develop. Everything today is object oriented which is akin to a "cut and paste" coding method.

 

Ah here we go. Thanks!

 

Correction to something I posted previously.

AMSI does not scan command shell scripts. To do so, the amsi.dll would have to be injected into cmd.exe which it is not. In contrast, amsi.dll is injected into powershell.exe.

BTW- the entire AMSI processing is contained in amsi.dll. Disable it and you disable AMSI.

 

I think it's more about the techniques that were used. So called "in-memory" payloads could also be used on a home user machine. So it's very simple, you need to block code injection via exploit or malicious process. You also need to restrict access to system tools like netshell, powerhell and other tools. So I agree with your "overthinking" comment.

 

https://threatpost.com/fileless-malware-campaigns-tied-to-same-attacker

 

The fact that Kaspersky mentioned:

In the article somewhat confirms my original suspicions that these attacks might be nation state backed.

​

 

No problem for Appguard? Also Office 365 ATP I think would stop this.

 

https://securityintelligence.com/news/security-tools-must-adapt-to-fileless-nonmalware-attacks/

 

https://www.virusbulletin.com/blog/2017/03/vb2016-paper-one-click-fileless-infection/

 

http://securityaffairs.co/wordpress/58508/cyber-crime/fin7-group-phishing.html

 

Mshta.exe appears to be the favorite vector these days to launch malicious payloads from Word docs.. Recently saw a Spora ransomware variant do the same.

 

Yes, I noticed that also. Also noticed that OS built-in tools are getting exploited more and more.

 

https://www.infosecurity-magazine.com/news/fin7-chomps-into-restaurants/

 

For all its sophistication, any AV running on Win 10 that is deploying its AMS interface would be able to detect the obfuscated .js script in the Word delivery phase. That is as long as a signature has been created for it. Or, by heuristics/behavior if you're lucky.

The DNS memory injection is intriguing though. Sure we will be seeing more of this in the future.

Ref.: http://blog.morphisec.com/fin7-attacks-restaurant-industry