MRG Effitas Online Banking/Browser Security Q2 2015

I thought that the confusion was already lowered? You should read the post from Zoltan_MRG. And yes, the posts from itman were quite informative, but it also lead me to believe that he was confused about what this test was all about.

 

The third link allows you to use different thread creation methods. MRG used CreateRemoteThread.

 

Another comment.

Per MRG:

6. Because the DLL was never written to the disk, nor can it be detected on the network, the regular AV has no chance to block it

I believe Eset, default configuration, might be able to detect this. As best as I can determine, all Eset exploit and memory protection which BTW is only for the browser and related plug-in/add-ons exists at the network level. I believe that protection is incorporated into one of their filter drivers for the network adapter.

Only way to know for sure is to do said network testing in your next banking comparative testing.

Also, is this not rootkit activity?

1. Windows starts, malicious bootstrap code starts
2. The bootstrap code downloads the malicious DLL through the network (optionally encrypted), but does not saves it to the hard disk.

 

If you look at this report: https://www.mrg-effitas.com/wp-cont...terprise_security_exploit_prevention_2015.pdf you can see Eset's exploit protection was bypassed multiple times. And it was bypassed because of the use of in-memory malware (Bedep) by Angler EK.

The rootkit definition is a bit vague, and I am for sure some people will say this is rootkit, others will say this is not. I don't think this is a rootkit, because the bootstrap code is not hidden from average users by any hooks or special tricks.

 

Per above report:

Whenever malware had a chance to start, but was blocked later (e.g. by behaviour analysis), we marked this as a fail (“malware starts, but blocked later” category), given that some malicious action could have already been taken by the malware.

Eset uses a virtual sandbox while analyzing. So any malicious activity would have been blocked.

 

Bedep starts in memory after the exploit in a way that there is usually no new process being created at all (except when it drops new malware and starts it). I doubt that the Bedep start will trigger any sandbox analyses at all. And during the test, whenever I watched Bedep activity, Eset did not notify me about any threats or blocked anything. Remember, there is no solution which protects against everything ...

 

A lot of Angler's payloads are delivered using Shellcode. Whether Kapersky would have caught this one, I don't know. Most BBs and heuristics would not. Primary reason I use a HIPS. Also most corp. environments use a fully configured HIPS.

This instance of Angler exploited CVE-2014-6332 in an interesting way. This vulnerability is exploited in general using array re-dimensioning in VBScript. What's noteworthy in this case is the back-and-forth communication between the VBScript and the JavaScript code:

1. The VBScript itself is "hidden" in heavily obfuscated JavaScript, which appends a "VBScript" object to the HTML body.
2. The VBScript, when executed, calls a JavaScript routine that enumerates the IE and Windows versions and then calls another JavaScript routine that returns a base64 decoded Shellcode.

The exploitation of our machine resulted in a Bedep trojan running in memory.

 

Sophos has a great recent posting in Angler exploit here: https://blogs.sophos.com/2015/07/21/a-closer-look-at-the-angler-exploit-kit/ . Here it uses shell code to load the Bepep tojan.

Go to section 3.3 and note the following:

3.3 Shellcode analysis

After resolving the base address for kernel32, the shellcode parses the export address table to find the functions it requires (identified by hash). It then uses LoadLibraryA API to load winhttp.dll, and parses those exports to find the functions it needs:

Module & Functions (imported by hash reference)

kernel32.dll

CreateThread, WaitForSingleObject,
LoadLibraryA, VirtualAlloc,
CreateProcessInternalW, GetTempPathW,
GetTempFileNameW, WriteFile, CreateFile,
CloseHandle

winhttp.dll

WinHttpOpen, WinHttpConnect,
WinHttpOpenRequest, WinHttpSendRequest,
WinHttpReceiveResponse,
WinHttpQueryDataAvailable, WinHttpReadData,
WinHttpCrackUrl, WinHttpQueryHeaders, WinHttpGetIeProxyConfigForCurrentUser,
WinHttpGetProxyForUrl, winHttpSetOption,
WinHttpCloseHandle

There is the dll load into browser memory. You should never see that dll, web proxy auto discovery, loaded into browser memory. It runs under explorer.exe -EDIT- or anything else that does ah doc Internet access e.g. rundll32.exe, etc. plus malware.. Also checking for signed dlls won't help you here since it's a valid signed and registered dll.

-EDIT- If you always keep ActiveX Filtering enabled i.e. FlashPlayer disabled, you have stopped Angler on the front-end. Or, just get rid of FlashPlayer like everyone else is currently doing. And most importantly, don't have it enabled when doing on-line banking!

Decoding the outermost obfuscation layer reveals the next trick used by Angler – anti-sandbox checks. It uses the XMLDOM functionality in Internet Explorer to determine information about files present on the local system. It does this in order to detect the presence of various security tools and virtualization products:

 

Hi Zoltan! I am really interested in fileless malware. In your opinion what is the best defence against such malware. Also I think it will be a good idea for mrg efitas to have a dedicated test of fileless malware. They are bypassing even the classical HIPS.

Thanks

 

The good question is not how to protect yourself against fileless malware, but how to protect yourself from any malware. Usually there are four main sources of infections: Web based exploit kits, document based exploits, download malware and run, and flashdrive malware.

The best protection against web based exploit kits today is:

• Use Chrome
• Remove unnecessary plugins (e.g. Silverlight, Java (already removed from Chrome))
• Patch your browser/browser plugins always
• Enable click-to-play for Flash
• Install a software which can protect against exploits, like EMET, Hitmanpro Alert, or Malwarebytes Anti-exploit
• Use an adblocker

The best protection against document based exploits:

• Patch MS Office/Adobe reader/Foxit/whatever you use
• Install a software which can protect against exploits, like EMET, Hitmanpro Alert, or Malwarebytes Anti-exploit

To protect against regular malware:

• Don't download and run software from untrusted sources (e.g. illegal torrent sites).
• Use a decent AV

Protect against malware on flashdrive:

• Use a decent AV

If you follow these rules, you are very well protected against all malware.

And I know there are tons of other malware infection routes, and millions of additional protections, but I wanted to keep this list simple, and usable for home users.

 

Nice list. One important addition, also for home users, use an Ad Blocker.

 

Below is a McAfee corp. HIPS rule for monitoring PowerShell usage along with ideas on how it can be expanded to detect code injection. Using an endpoint solution is worthy of consideration just for the more powerful HIPS that they provide. In any case at a minimum, you should be monitoring PowerShell usage in your retail HIPS software. You can also use this McAfee expert template as a loose guide for configuring your retail HIPS. Ref: http://pwndizzle.blogspot.com/2014/03/custom-mcafee-hips-rules-that-actually.html

For example to track Powershell usage but exclude a known admin user:

Rule {
tag "Powershell execution"
Class Program
Id 4004
level 3
Target_Executable { Include { -path "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe" } \
{ -path "C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe" }
}
user_name { Exclude "domain\\john" }
directives program:run
}

OpenProcess is often used when performing code injection, the catch is that it's also used by legitimate programs. You can try detecting code injection of explorer.exe for example by using the open_with_ directive, this Intel post has a good explanation but be wary of the false positives; https://software.intel.com/en-us/articles/intercepting-system-api-calls .
Taken from the link above the directive permissions you'll want are:

PROCESS_VM_OPERATION // For VirtualAllocEx/VirtualFreeEx
PROCESS_VM_WRITE // For WriteProcessMemory
PROCESS_CREATE_THREAD // For CreateRemoteThread

 

Say what, I agree. When you explicitely advice people to keep UAC on you get a thumbs up

 

You forgot to mention the most important mitigation. Funny how people always ignore this one.

Make sure all your software is fully patched by ensuring you always apply the latest updates available. No it won't protect you against any 0-day bad guy, but will do so against any remediated ones.

 

I came across an interesting recent malware analysis that contains all the elements discussed in this thread: https://warroom.securestate.com/index.php/real-world-malware-analysis-part-4-dynamic-analysis/

Malware origin is a bit obscure. I couldn't find a reference where the author got it from. The malware downloads to an AppData directory; another area that needs protection via a HIPS rule. The malware appears to be able to detect sandboxing. It disguised itself as a legit app, putty.exe. It loaded from AppData a hidden reflective dll into its own memory upon execution. It then established an Internet connection using winhttp.dll. It also made notable system changes.

So if your AV behavior blocker or heuristics didn't catch this thing upon execution, chances are you're screwed. Your anti-exploit won't do you any good since it only protects things specifically defined to it. Finally, I don't know if outbound firewall monitoring would be able to detect the malware's connection since it appears to be able to cloak that. Note however proper HIPS rules that do protect the registry would have mitigated a lot of damage. This bugger was installing certificates so you can guess what it was up to.

http://warroom.securestate.com/wp-content/uploads/2015/06/regshot2.png

-EDIT- A couple of links from MS about winhttp.dll. The second one is most interesting. Shows how you can access web page data via a script using winhttp.

http://blogs.technet.com/b/askperf/archive/2007/09/07/under-the-hood-winhttp.aspx
https://msdn.microsoft.com/en-us/library/aa384071.aspx

And if you haven't figured it out yet, you can use winhttp to establish SSL connections:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa384076(v=vs.85).aspx

 

To be honest, I'm a bit confused, I now see what you mean. According to Zoltan_MRG, the DLL was loaded from disk by the simulators, so probably that's why you assumed it was not truly "reflective". Perhaps Zoltan_MRG can explain it one more time?

http://security.stackexchange.com/questions/20815/detecting-reflective-dll-injection

 

Can you perhaps test this tool against IE (or other browser) running sandboxed, with Sandboxie?

 

I am not a Sandboxie fan. Have no desire to install it.

Just download the DLL injector from here: http://securityxploded.com/remotedll.php. Then give it a whirl since you have Sandboxie installed. Just make sure you inject a 64bit dll into a 64bit browser and 32bit dll into a 32bit browser, etc.. You can remove the injected dll with the same tool if Sandboxie doesn't catch it. Eset caught PUA crap in the 32bit test injector tool after the download unzipped, so beware of that. I quarantined that one. Also download the portable version to play it safe.

The non-reflective 64bit dll injection test (remember I tested both types) slipped right by Eset real-time AV protection w/heuristics which uses virtual sandboxing.

 

Before people start ditching their AV solution or loosing sleep over tests of this type, I will say the following. The MRG simulator test is nothing more than a test of resident 0-day malware prior to installation of the AV software. Does this situation occur in the real world? Yes, unfortunately it does.

Does that apply to your individual installation? That's up to you to decide. It most certainly does not apply to the installation of AV software immediately after OS installation on a clean HDD. If your PC is malware free when you install a different AV solution, it doesn't apply.

Most conventional AV solutions are designed to protect the bad stuff from getting into your PC. Therefore if your AV solution passed received 100% for MRG's In-the-wild Real Financial Malware test and passed all Botnet tests*, you can be reasonably assured you can safely conduct on-line banking activities. However, no AV solution will 100% guaranty that it can prevent an infection. So for the truly security conscious or if you have paranoid tendencies, you can do the following. Add software that detects 0-day resident malware upon execution by it's behavior e.g. Emsisoft Anti-malware; by the malware's attempts to modify other processes e.g. a HIPS with proper rules added to protect vulnerable apps; or by using both like I do. But I do have paranoid tendencies when it comes to my PC security

* Eset Smart Security and Zemana Anti-Logger

 

I will ask in the Sandboxie thread.

 

Finally, I will say to anyone interested in the armored browser approach, do it right and check out this: http://www.zeusgard.com/home. Or, build your own bootable browser on a read only USB stick. Note: that Zuesgard only works on a wired connection or you have to also buy their WI-FI adapter. Also from its reviews, it either works on your PC or it doesn't with those being your only two options. Macs appear to have the most trouble with it.

You can have the most malware infested PC on the planet and still do safe online banking using the read only media bootable browser technique. The Live CD concept has been around for years.

 

I need to set the record straight about a MRG comment made in reply #79 that Eset's exploit protection was not up to par.

NSS Labs recently completed unsolicited testing of exploit protection for multiple consumer endpoint(AV) solutions. They used a test platform similar to that used by MRG; WIN 7 and IE9. NSS labs continuously monitored for in-the-wild exploits for a period of two months:

This test includes a total of 1291 attacks used by threat actors in active campaigns during the course of the test.​

Eset Smart Security ver. 8 effectively scored 100% in that testing; the highest of any vendor tested. That is good enough for me.

ref.: https://www.nsslabs.com/sites/default/files/public-report/files/2015-04 EPP Stack Consumer Test Report - ESET Smart Security 8 - Exploits-3.pdf

 

Here is another interesting article about a new banking trojan:

https://securityintelligence.com/shifu-masterful-new-banking-trojan-is-attacking-14-japanese-banks/

 

This what you are saying is not true according to this article according to the same website:
https://www.nsslabs.com/reports/consumer-avepp-comparative-analysis-exploit-protection-edition-1
https://www.nsslabs.com/sites/defau...012_EPP_CAR_Consumer_Exploit_Protection_0.pdf

You said that Eset scored 100% in exploit testing, but what about all other software products?
Can you give me the links of exploit protections from all other vendors that were recently tested (beside Eset), because I can't find them.
Big thanks in advance.
Also, HMPAlert blocks everything that Eset blocks and even more than Eset, this is why I'll stick with HMPAlert, just in case.

 

The links you posted are old tests; dating back to 2012. That comparative exploit test was for Eset ver. 5; prior to any specific exploit and memory protection being included in the product.

Here is the link where you can find the most recent product tests: https://www.nsslabs.com/reports/categories/end-point-protection . Note that this was not a comparative test. Each product results posted separately.