MRG Effitas Online Banking/Browser Security Q2 2015

It is not so on my SS 8 .312 installation. I have reset same to default settings multiple times and this is always the setting. Again, might explain why Eset failed to detect any simulator activities since MRG used ver. .312.

 

Hmm I could be wrong. But I remember a few posts (that I am unable to find atm) where users have mentioned that when they revert back to the defaults using the button in the GUI, it resulted in that some settings that actually were enabled by default, got disabled using that button.

Edit: Yes! Found it: https://forum.eset.com/topic/1955-question-about-default-settings/?p=12864

Don't ask me why it happens, if it is a bug, by design or whatever, and why it still exists in the software. I also don't know if this issue affects all users.

In any case, you can go ahead and check that AH checkbox since it really is enabled by default after installation.

 

Only if MRG used the magic button, see my post above

 

It is enabled by default on my 8.319 installation, and as I remember it was on previous also.

 

Unfortunately, "magic button" advanced heuristics on file execution doesn't protect against dll injection. For this test, I injected Eset's own hook into the browser.

Detailed DLL Operation Report
***********************************************************************************
Starting the 'Inject DLL' Operation...

Process = Iexplore.exe
Inject DLL = C:\Program Files\ESET\ESET Smart Security\eplgHooks.dll
Injection Method = CreateRemoteThread

Step 1 => Opening target process [4428 - Iexplore.exe] for DLL Injection
Success

Step 2 => Writing the DLL Path Name [C:\Program Files\ESET\ESET Smart Security\eplgHooks.dll] into target process
Success

Step 3 => [Defeat ASLR] Calculating the LoadLibrary function address on target process
Successfully got the address of Kernel32.dll on target process
Address of Kernel32.dll [Target Process] = 0x0000000077920000
Address of LoadLibrary [Target Process] = 0x0000000077936590

Step 4 => Injecting the DLL into target process using the method 'CreateRemoteThread'
Waiting for Remote Thread to Terminate...
Address of Injected DLL [C:\Program Files\ESET\ESET Smart Security\eplgHooks.dll] in target process = 0x00000000747B0000

Successfully Injected the DLL into target process !!!

For anyone ambitious, here's a link on how to create your own reflective DLL for test purposes along with a .exe to run it. It will allow you to inject using process id. You can compile the DLL using Visual Studio 2010: http://securitycafe.ro/2015/02/26/upgrade-your-dll-to-reflective-dll/

-EDIT- Note that CreateRemoteThread DLL injection uses virtual memory versus reflective DLL injection that uses the targeted process's own memory to store the source DLL payload. However, the Eset HIPS rule I created was able to detect the above step 2, DLL path name memory injection. Therefore I am somewhat confident that a Eset HIPS rule would prevent reflective DLL memory injection.

 

I don't believe exploits were used in this test. Tools like MBAE don't watch for "dll injection", they try to stop shellcode/malware from running in the first place. Apparently these simulators use the "reflective dll injection" method, because it's a technique not often used by malware AFAIK, and might be able to bypass certain HIPS.

 

Yes I hope so.

To be honest, I didn't even know this technique was used by malware, I thought it was more related to exploits. So Zemana should be able to add protection against this, since it's simply one of the "dll code injection" techniques.

And even if it failed to block DLL injection, I wonder why it couldn't spot the API hooking. Zemana is designed to block banking trojans that are already active on the system. Same goes for, SpyShelter, Trusteer and HMPA.

 

MRG "sleathed" the hooking:

hooked either the HTTPSendrequestW function or the EncryptMessage function, either via debug registers, or protecting the hook.

 

Thanks for your testing, keep it up!

To clarify. With "magic button" I was referring to the "default" button in the GUI, as there would be a chance it would disable AH on file execution like I assume was the case for you, and for FleischmannTV and hqsec as you see in the thread on the ESET forum. (i.e AH could magically get disabled without that the user notice or expect it to happen when they use the default button).

 

Personally, I don't put a lot of faith in Eset's non-signature non-firewall malware protection except through web filtering via their network filter. At that level, it is solid including exploit protection. That is why I also use Emsisoft's EAM for its behavior blocker and have numerous Eset HIPS rules.

My wish is Eset would build a lot more flexibility and sophistication into the HIPS. In its present form, it is without a doubt the most basic and inflexible HIPS I have ever used. I doubt any changes will happen since Eset doesn't want to be bombarded with HIPS rule creation support issues and complaints. The exact reason Emsisoft is dumping Online Armor.

 

Below is an excerpt of a bit more sophisticated technique along with comments about packer/encryption detection bypass methods. Note the author's comments on what he thinks about heuristics. Author's grammar could be improved a bit though. Ref.: http://securityxploded.com/bypassing-antivirus-using-code-injection.php


Concept of Code Injection - Ingeneric way to bypass AV

BBecause exe files are going to detected by AVs( at least if you pack them with the publicly exposed packers/encryptors). So we have to think in a another way.

And the another way is: split the exe into two parts (not physically)

1. The core code (the actual code that performs a specific task for eg. Bind shell)
2. The interface - a mechanism that will inject the code into memory and execute that code.

So the functioning is something like this:

http://securityxploded.com/images/injector_screen5-injection-technique.jpg

Note that from the above explanation we know that shellcode/code into a file is not going to be detected by AV because AV don�t know how to decode shellcode. (Don�t talk about Heuristic, I know AV vendors are joking ?)

Important Note: you may be thinking that why I am saying encoded shellcode because if you use metasploit shellcodes there signatures may be in AVs. If you encode the shellcode with any available encoder in metasploit then AVs not able to decode it in a file and not able to detect it (if you don't understand it read the whole stuff again ?). Although in some cases (Eg. Avast may be with others also) AV not alert if you use shellcodes that are not encoded because AV think that txt file are lame files. But if you force fully scan the file than AV alert.

Second part of the concept is the interface that will inject the code into a process. Code injection is not a new concept (dll injection is one of the most popular example).

Note: All the things are generic and are not specific to any tool or shellcodes. Metasploit and shellcodes are used only to demonstrate the concept. You can also inject your codes "that are detectable to AV in exe mode" with this method and can bypass AV.

Things that you can do with this method:

1. Can backdoor a process
2. Can provide many backup shells (every type)

We can use publically available tool (malicious) without fear and too many other things limited to your wild imaginations.

 

BTW, I've read the Webroot vs Trusteer rapport (from MRG), and all testing methods were explained a bit more intensively. Basically, seems like Zemana can't block this dll injection method, and it also doesn't block API hooking via the several advanced methods that were used. Trusteer also failed this test. Webroot passed because it simply blocked the code injection part.

I have no idea why F Secure and Avira passed the simulator test, do they have a behavior blocker, or safe browser? And if not, did they simply flag the simulator as malicious? This is something that the MRG report doesn't explain, and this is my biggest gripe. Another example: Zemana managed to block 100% of ITW malware samples, while Avira failed. So is Zemana's cloud AV better than Avira's? Perhaps Sveta MRG can explain this.

 

F-Secure and I strongly suspect Avira IS have a locked down browser mode. I know Eset will be introducing one in ver. 9 of Smart Security although beta testing of it has not gone well.

Again, I am not a big fan of AV browser lockdown banking modes since all of them have had numerous problems per user forum complaints. - EDIT- In other words, I am questioning MRG's usability claims.

Also, I am all for making browsers more secure. However, the browser manufacturers should be doing so, not the AV software vendors. Every time they touch the browser they muck it up to the point the browser is actually more insecure than the original version. Case in point is the recent SSL scanning features they have incorporated; aka "Kapersky Makes You Vulnerable To A Freak Attack" and numerous other discussions in Wilders and elsewhere.

 

For reference, there is a good prior Wilders discussion of MRG's use of a simulator here for anyone who has read it: https://www.wilderssecurity.com/thre...ty-assessment-project-q3-2013-q1-2014.365079/

I also want to state that a myth is being perpetrated here. And it's a very dangerous myth. The myth is that an armored browser can protect your Internet e-commerce activities on an infected PC. Malware depending on its severity can install a backdoor, it can escalate privileges, plus a whole range of other very nasty malicious activities. In other words, it basically owns your PC at this point. The very last thing a person should be doing on a known or suspected infected PC is any type of Internet e-commerce activities.

I offer the following scenario:

1. The malware either directly or through clever phishing has the user install the malware's root certificate. If AV vendors can install root certificates to support their SSL protocol unencrypting activities, malware most certainly can.
2. The malware proceeds to install its own network adapter filtering driver at the same time disabling any existing security software network drivers that might be installed.
3. The malware though its network driver then redirects outbound traffic to its man-in-the-middle server. Note that all this occurring at the network protocol level after the outbound traffic has left the browser.
4. The MITM server captures the network traffic, decrypts it, and extracts all the sensitive info it needs. It then routes the original encrypted network traffic to the final intended destination.

None of the above involves any browser manipulation and therefore will not be protected by an armored browser.

 

Guess MRG is short for Match Results to Generosity (of Sponsor)

 

Actually, you showed a way to prevent MITB and MITM that is equally effective and doesn't require an armored browser: https://www.wilderssecurity.com/threads/kareldjags-tip-ssl-eye-view-mitm-check.378569/

 

Like I said, this is a "flaw" with the MRG reports, they don't explain how these apps pass the test. And the funny thing is, F Secure and Avira both failed this test in the first quarter.

I'm also not a fan of armored browsers like Wontok, I like to use my own browser. But they do seem to keep passing all the tests. BTW, what about using a sandboxed browser (via Sandboxie), wouldn't it also pass the simulator test? Because apps running outside the sandbox can't inject code into sandboxed apps.

 

F-Secure's behavior blocker is called deepguard. Old whitepaper: https://www.f-secure.com/documents/996508/1030745/deepguard_whitepaper.pdf

 

Interesting stuff, so looks like it has been improved. But looks like F Secure also has a dedicated "banking protection" module, so I'm still not sure what blocked the simulators.

 

the banking mode in f-secure configures the firewall to only allow communication w/that site while it's active. e.g., if you were to go to, say, wellsfargo.com, you'd see a slide down notifier and while it's active, you wouldn't be able to open another tab and visit say, facebook or wilders or whatever til you tell f-secure you're done banking.

there may additional protective functionality while in banking mode, but they don't provide any detail about it.

 

No, according to this: http://forums.sandboxie.com/phpBB3/viewtopic.php?f=4&t=9794&p=63320&hilit=DLL+%26+Script+Execution+blocking#p63320. I assume it still applies to Sandboxie?

 

EMET and MBAE EAF bypass using reflective DLL injection: http://casual-scrutiny.blogspot.com/2015/01/simple-emet-eaf-bypass.html .

Note: EAF protection did stop straight up reflective DLL injection. Author did a bit of trickery to get past EAF.

 

Apps running in the same sandbox can inject code into another process, but normally malware will run outside the sandbox. BTW, did you receive my PM?

How is this related to this test? Like I said, exploits were not used if I'm correct. And even if exploits were used, I believe that stuff like ransomware and banking trojans are never running from in-memory.

 

I also want to state that I am all for "simulated" malware tests. However, the way MRG does this test really doesn't reflect real world browser manipulation:

Methodology Used in the Q2 2015 Online Banking Certification – Simulator Test

5. A clone of the system as it is at the end of 4 is created, and the system is started.
6. The simulator is started onto the clean systems with protection installed.
7. Each simulator test is conducted by:

a. Starting a new instance of Internet Explorer (or the safe browser) and navigating to a financial website. Where the security application offers a secured or dedicated banking browser, this is used. If the security application is designed to protect Internet Explorer, only that component is going to be tested.
b. Trying to inject the simulator into the browser process.
​

At this point, we have malware resident in the system that for all practical purposes and can do whatever it wants. It could inject svchost.exe or anything else and go virtually undetected. Again if this is undetected 0-day malware that has entrenched itself into the system, the game is pretty much over as far as any security protections go.

If MRG wants to pursue along these lines, forget the simulator and actually infect the test system with Zeus, Citadel, or one or more of the banking malware nasty's; preferably one with an exploit component. Reboot and perform a few tasks so the malware gets firmly entrenched. Then test the armored browser's performance.

Finally, this type of testing is not fair for many AV products whose browser protections are designed to monitor inbound Internet traffic; the normal method a person would be subjected to a browser malware attack.

I strongly suggest MRG for their next banking security test do something along the lines of creating a web page with a script to execute a shell to do reflective DLL injection using PowerShell w/altered execution privileges or the like. Or, download same from the browser and attempt to execute it from an Internet based source.

 

To be honest, that doesn't sound like effective protection against banking trojans who simply hijack the browser, but I might be wrong.