MRG Effitas Online Banking/Browser Security Q2 2015

I just replied to your PM.

I thought Sanboxie would only prevent specified dll injection? Also doubt it would catch a memory based injection.

Because reflective DLL injection is memory based and as long as exploit tactics are not involved, EMET and MBAE w/EAF protection would prevent the reflective DLL injection into any process they protected.

 

What I'm saying is that if malware is running on the system it will try to inject code into the browser. But it won't be able to do so, because the malware runs outside the sandbox, so SBIE will block this. If malware runs inside the sandbox, then code injection is possible, but there is a big chance that it still wouldn't work correctly, because of limited privileges. Of course this is all theory, so perhaps MRG can test it.

 

Yes correct, but the way I understood it, MRG didn't use exploits in this test. They tested this stuff in a scenario where financial malware (both real ones and simulated) were manually executed. After that code injection + API hooking is used. So if you can block or interfere with at least one of them, you will pass the test.

But if exploits were used, then anti-exploit would simply block the shellcode/malware from running at all. And if anti-exploit would fail, then "reflective DLL injection" is only interesting if the payload would run from in-memory only. Because this would make it hard to detect. Luckily this normally doesn't happen in real life, AFAIK droppers will download and execute malware (ransomware and banking trojans) in a separate process from disk. Security tools should be able to interfere with this.

 

Based on this discussion: http://forums.sandboxie.com/phpBB3/...103790&hilit=reflective dll injection#p103790 Sandboxie will not prevent memory based injections into the browser; inside or outside of the sandbox.

 

The download could override powershell execution privileges(trivial), run hidden, and execute a powershell script to perform the reflective dll injection into the browser. With a bit of tweaking, this should do the trick: http://www.exploit-monday.com/2011/11/powersyringe-powershell-based-codedll.html . Script is encrypted, unencrypts and executes in memory, and is therefore undetectable.

 

on its own, i agree that it wouldn't be enough since that's not at all what it's intended to do (it's supposed to reduce the risk of spoofed banking login pages and the like), but coupled with deepguard, it's fine.

 

You seem to be misunderstanding me. Of course, if it's advanced in-memory malware, that runs from inside the exploited process (browser), then SBIE won't be able to stop this attack. But I'm talking about a different scenario, where malware gets executed from outside the sandbox. If banking trojans can't inject code into the browser, they can't do any damage. I don't know how to explain it any better.

 

You seem to be talking about scenarios that were not tested in this MRG test, why over-complicate stuff? I think you're also a bit confused about what "reflective DLL injection" is all about. If used by malware, it's simply one of the DLL injection methods, so this hasn't got anything to do with exploits. If you use the term "reflective DLL injection" in the context of exploits, then it's a whole different matter.

 

This was discussed here starting at this page in Wilders: https://www.wilderssecurity.com/threads/sandboxie-acquired-by-invincea.357312/page-36. Again, Sandboxie will not protect you against outside of the sandbox into the sandbox process memory injection.

 

I understand what reflective DLL injection is. It was and still is a primary remote code injection method:

At a system level when using Reflective DLL Injection in remote exploitation, the library should be undetectable by file scanners, such as Anti Virus, as it never touches disk. This leaves the main detection surface being the network, although many IDS evasion techniques are available[8] to aid circumventing detection such as polymorphic shellcode.
Ref.: http://www.harmonysecurity.com/files/HS-P005_ReflectiveDllInjection.pdf

And this is the context is should have been used in the MRG tests as I commented previously.

 

Does super-advanced in-memory attack which is file-less need malware to do the evil thing or not?
What about those file-less in-memory attacks?
Craig from Invincea basically told that file-less Angler exploit kit is nothing to worry about, since Sandboxie will fully contain it.
But also, does exploit needs malware in order to to its evil things or not, does it really need to inject dll, and execute malware or not?
And also, does file-less mean to create exploit to do evil things without using and without executing any form of malware?
Can file-less exploit do anything without using and executing any form of malware at all?

 

Read the last Tzuk's post:

So, yes, Sandboxie can fully protect against dll injections as well, by simply blocking them all, but you have to do it/configure it manually.

 

That setting prevents sandboxed programs from accessing certain dlls on your disk, but I am pretty sure it does not prevent a program from outside the sandbox to inject a dll into a program within the sandbox.

 

Here is our answer to multiple posts in this thread.

We have not used any shellcode during the Online Banking Test Q2. Shellcodes are usually (but not exclusively) used during exploits.

We have not used any exploits during the Online Banking Test. Any discussion in this thread regarding exploits has nothing to do with this current test. Anyone interested in anti-exploit mitigations should check https://www.mrg-effitas.com/wp-cont...terprise_security_exploit_prevention_2015.pdf or https://www.mrg-effitas.com/wp-content/uploads/2015/04/MRG_Effitas_Real_world_exploit_prevention_test.pdf

FSecure passed the simulator test because of Deepguard. It detected a new, unknown executable - which is a nice example of why reputation based protection works. According to our tests, the Bankguard protection from FSecure is not very effective.

Avira passed the test because it detected our simulator by signature. Which is odd, but this happened.

We agree it is a problem when someone implements SSL MiTM in an insecure way, but this can be fixed. Also, not many people have been hacked because of the Freak attack on SSL, but a lot of people were protected because an armored browser was used on an infected PC, and only this last line of defense prevented the attack. At the end it always comes down to risks. Installing AV software decreases the risk of malware infection, but AV has vulnerabilities which can be exploited by attackers. See example here: https://lock.cmpxchg8b.com/sophailv2.pdf The question is which risk is greater for you?

Armored browsers can not provide 100% protection. But if it protects 98 user from 100, that is a good thing.

We created test cases with SSL MiTM, see here: https://www.mrg-effitas.com/wp-cont...tification-Project-2014-Q2-Report-Level-1.pdf

We did exactly this test, see both Botnet test and ITW test in the same report.

In our simulator test case, the injector was an .exe file read from the hard disk, and the DLL injected into the browser was also a plain .dll file read from the disk. This was not an in-memory malware attack. But we plan to do something similar in the future. Actually we planned to do this for Q2, but the simulator was still in development.

 

I always thought that SBIE will protect system from malware by preventing it to escape from sandbox. I'm guite sure that in past SBIE couldn't protect sandboxed process from malware running outside of SBIE (keylogers...). Is this some new feature that was added in recent version?

 

MRG .......... Thanks for clarifying. Also from your last posted paragraph, we can conclude that you did not use reflective DLL injection in this test.

See my following post on where you can find an app that does do in memory reflective DLL injection.

 

Here is where you can find a test app to test in memory reflective DLL injection: https://github.com/stephenfewer/ReflectiveDLLInjection

You will have to rummage around in the binaries to find the executable applicable to your OS. I used "inject.x64.exe" to test with. -EDIT- You also need to download the associated test reflective DDL i.e. reflective_dll.x64.dll, and store it in the same directory where the .exe is located. -END EDIT- Just run it using "inject.x64.exe xxxx" where, xxxx is the process id for which you want to inject the test reflective DLL into. I assume this will be the process id for your browser.

-EDIT- For the truly security conscience, you can download the source code and compile with Visual Studio 2012. All the source code has been made VS 2012 compatible. You can get VS 2012 Express here: http://www.microsoft.com/en-us/download/details.aspx?id=34673

Sorry, you need to also include the name of the reflective DDL. Here is the actual run command I used.

C:\Users\xxx\Downloads\inject.x64.exe 3948 C:\Users\xxx\Downloads\reflective_dll.x64.dll
Note: 3948 was the target process id.

Note: You can also run it w/o the .dll to see if your HIPS rule catches the initial attempt to allocate memory in the browser prior to loading the .dll into it. A bit safer for those that worry.
-END EDIT-

Glad to report my previously posted Eset HIPS rule stopped the in memory reflective DLL injection dead in its tracks. I can also report that Emsisoft EAM's behavior blocker caught the attempted reflective DLL injection activity from inject.x64.exe process.

Note: Not all HIPS can detect in memory injection attempts. So you will have to test your own HIPS for same.

 

I am 100% sure we used reflective DLL injection.

In my terminology, an in-memory (non persistent) malware infection works like this:

1. Victim visits a website, victim is redirected to exploit page.
2. The exploit code exploits a vulnerability in the user browser or plugin.
3. So attackers can run their shellcode.
4. The shellcode downloads the malicious DLL through the network (usually encrypted), but does not saves it to the hard disk.
5. The malicious DLL gets loaded into a process (explorer.exe, iexplore.exe) via reflective DLL injection
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

Based on this idea, it is possible to create a persistent in-memory malware, where only the bootstrap code is written to the disk (but it can be detected via regular AV scan):

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.
   
3. The malicious DLL gets loaded into a process (explorer.exe, iexplore.exe) via reflective DLL injection
   
4. 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

In our simulator attack, the DLL was not downloaded over the network, it was on the hard disk. Thus I don't think it is fair to say it was an in-memory malware attack, despite the reflective DLL injection. Every malware is loaded into the memory when it starts, but it does not mean it is an "in-memory only" malware. Reflective DLL injection is one technique to load a DLL. That's all.

 

Agreed. The main difference doing DLL injection using CreateRemoteThread is in normal DLL injection, the DLL is written to virtual disk and loaded into the process from there. Whereas with reflective DLL injection, the DLL is written to the processes own memory and loaded from there. And reflective injection DLL source can be both local i.e. hard disk or external i.e. in-bound network origin.

-EDIT- I guess I should post the exact differences between normal and reflective DLL injection taken from a link ref. I posted in reply #30:

Classic DLL Injection
The most popular way to inject a DLL is to follow the next steps:

1. Open the target process with OpenProcess
2. Find the address of the LoadLibrary function by making use of GetProcAddress
3. Reserve memory for your DLL path in the remote process virtual address space by using VirtualAllocEx
4. Write the DLL path in the previously reserved memory region with WriteProcessMemory
5. Use CreateRemoteThread to create a new thread which will call the LoadLibrary function with the DLL path as a parameter

As it can be seen, the problem with this approach is that the DLL needs to be written to disk in order for it to be loaded with the LoadLibrary function. This presents a significant risk of being detected by the antivirus.
Executing DLLs from memory
An improvement to the previous approach is executing DLLs from memory. Manually, this can be achieved by following the next steps:

1. Write the DLL headers into memory
2. Write each section into memory by parsing the section table
3. Optionally, you can set the protection flags for each section
4. Do any relocation, if necessary
5. Check imports and load any other imported DLLs
6. Call the DllMain entry-point

 

FSecure passed the simulator test because of Deepguard. It detected a new, unknown executable - which is a nice example of why reputation based protection works. According to our tests, the Bankguard protection from FSecure is not very effective.

Deepguard is a behavior blocker w/ some ranking capability built in it appears.

Personally, I wouldn't "bet all my marbles" so to speak on a behavior blocker. The "Achilles Heel" for behavior blockers are shell scripts; especially ones that use encryption as I noted as an example in post #58.

 

Perhaps I was a bit confused, so this would mean that malware can also inject code into sandboxed apps? Sounds a bit weird to me.

It's more dangerous because the malware (payload) is running from memory, so it's easier to evade security tools. However, in most real life attacks, this "in-memory" method is not often used. The thing is, when you close the exploited process (or reboot the PC) the infection is also gone.

 

This is what I was trying to explain to itman. He probably got confused because "Reflective DLL injection" is often used in exploit attacks. But since no exploits were involved in this particular test, there is no reason to mention tools like MBAE and EMET. In this testing scenario, financial malware was basically already able to run on the system, and it was up to AV's, anti-loggers and armored browsers to keep the system safe.

 

This is what I suspected. But this doesn't really give a good impression of a product's pro active protection capabilities. Perhaps it's better to exclude security tools that don't offer a behavior blocker or dedicated "safe browser". Or perhaps it should be clearly indicated how a product managed to pass a test.

Now this would be interesting, because it's quite hard to block in-memory malware.

 

The simulators did use "reflective DLL injection". I think you got confused because reflective DLL injection can also be used as a "in-memory" payload, which is triggered by exploits. But you already gave an example of how it can be used by any app (second link). In the third link you can find another tool, but I don't believe it's offering the reflective DLL injection method.

https://www.offensive-security.com/metasploit-unleashed/payload-types/
https://github.com/stephenfewer/ReflectiveDLLInjection
https://github.com/OpenSecurityResearch/dllinjector

 

I enjoyed the posts of Itman, because they show both knowledge and realism. Maybe his Rasheed-ness could start talking for himself and lower the level of confusion in this thread?