Fileless Infections from Exploit Kit: An Overview

From https://blog.malwarebytes.org/exploits-2/2014/09/fileless-infections-from-exploit-kit-an-overview/:

 

The only surprising thing IMO is that it took this long for such things to appear ITW.

I do wonder if antivirus software might have a shot at heuristic detection of the injected thread (assuming no privilege escalation etc. was involved).

 

Well, perhaps it took this long because it's much easier to infect PC's with standard disk-based exploits, who can permanently infect the machine. I do believe that highly skilled hackers are probably using these type of exploits to infect corporate PC's to remain stealth. But you can also use rootkit techniques for that. But anyway, cool that apps like MBAE/HMPA are able to stop this.

 

It's not harder. It's just not necessary most of the time.

How?

Unless I know how it does it, I don't care that it does it.

 

Trade secret, probably. Such are the hazards of dealing with proprietary software, all the more so in IT security.

That said I very much doubt they're using shellcode signatures or other such silliness.

 

Everyone has his own priorities, of course. As I am a normal user and not a wannabe Vupen intern, as long as it does it, I don't care how it does it.

 

I still don't get it, didn't we already discuss this? Or do you mean that you want access to MBAE's source code?

I'm not a developer or expert, but if I understood it correctly, tools like MBAE/EMET/HMPA hook into the memory of protected apps (using IAT/inline hooks) in order to monitor from which memory areas, code (or shellcode) wants to run/execute (from the heap or stack). If they notice anything funny, they will simply block it and terminate the process.

 

@vojta

I wouldn't touch Vupen.

@Rasheed187

Did we? I don't recall, sorry.

I don't need source code, just methodology.

The important bit is how they notice anything funny.

 

Yes we did. But that's the thing, it's already "funny" when shell-code gets executed from memory areas that are marked as non-executable. That is what stuff like DEP and ASLR are trying to prevent. But to bypass this, attackers developed ROP attacks. I also do not know the details, so perhaps I did not explain it correctly, but you have to be a developer to know all this stuff.

Here is some more info about exploit methods, of course MBAE/HMPA/EMET try to stop this:

http://neilscomputerblog.blogspot.nl/2012/06/stack-pivoting.html

 

I know how the attacks work, I'm more curious about the defense. I imagine it mostly comes down to Control Flow Integrity, ie: defined rules about how the code can behave in memory to make ROP difficult. With EMET this has proved fairly simple to bypass, I'm curious about these solutions.

 

@ Hungry Man

If you read this stuff, you will know how tools like EMET/MBAE/HMPA work. Of course all this stuff is bypassable in theory.

www.syssec.rub.de/media/emma/veroeffentlichungen/2014/07/29/antiROP-RAID14.pdf
www.cs.columbia.edu/~vpappas/papers/kbouncer.pdf

 

I've read research and bypasses for all three of the technologies mentioned there. Like I said, they attempt to implement coarse grained performant CFI. But that's not what I'm asking for - I want to know what MBAE is doing.

 

Well, this is getting a bit weird, especially because I know you have a lot of technical know how. It's just a fact that in the papers I linked to, it's explained quite clearly, what type of methods tools like MBAE and HMPA are using to protect against exploits. I don't think you need me to explain it to you in a simple way.

 

It explains what tools like MBAE do. So, there's specific rules set up across all of these tools, including EMET, like not allowing a return into an instruction that is not call proceeded. That's implemented in all of the ones mentioned, as well as EMET, and is generically bypassable using kernel32.dll (you can get turing complete ROP using only gadgets that meet that requirement.)

But that is just one method for enforcing CFI.

You can enforce CFI in many ways. It's like a sandbox - some sandboxes work one way, another works a totally separate way.

But what it's checking, how it enforces CFI, is totally critical to understanding how well it protects against attacks. And I don't know of any details on how MBAE enforces CFI - do you?

 

@ Hungry Man

I wonder if that is true, are there really that MANY ways to enfore CFI? From what I've read, EMET (for example) uses 5 anti-ROP methods and in the ROPGuard paper it's explained how this is implemented. So you now already know HOW it tries to enfore CFI.

Which ones is MBAE using and how is it implemented? You will never know the full details unless the developer tells you (or you do some extensive exploit testing), but the developer has already made it quite clear that he does not feel like making competitors and hackers any wiser, which I understand.

 

Also, when it comes to the technical implementation details, we already know that EMET/MBAE/HMPA all use IAT/inline hooks to redirect API calls, so in fact they decide if the protected app is allowed to call some API function, after they performed the anti-ROP (and other) checks.

HMPA even makes use of so called "hardware-assisted control-flow integrity", made possible by the "Last Branch Recording" feature supported by recent Intel CPUs. This makes it harder for hackers to fool anti-exploit apps.

 

There are probably an infinite number of ways of enforcing CFI, many of which are entirely ineffective.

Also, the intel hardware support is for performance, not security. The major problem with CFI is that it's incredibly slow.

 

That's exactly my point, why focus on ineffective methods, there must be a reason that the developers of EMET (which is based on ROPGuard) have chosen about 5 to 10 methods to enforce CFI, probably because they make the most sense.

And it's also quite clear that MBAE and HMPA have taken some ideas from EMET, and probably improved some methods. So if you know how EMET works, you also know (on a "global" level) how MBAE/HMPA work. So that's why I don't understand when you (with your background) are asking questions like "how does MBAE stop exploits".

Of course full implementation details will not be given, all this stuff can be bypassed but why make it any easier for hackers? Why deliver everything on a plate?

 

Yes it's for performance, but a developer has told me that it can also stop more advanced exploit attacks, which can bypass software based CFI. So it's also a security feature, but don't ask me for details, I'm sure you can find some more info on the web.

 

EMET's methods aren't particularly good. They're chosen because they're known - no one's created new ones, or, if they have, they're "intellectual property".

This is not clear at all. How is this clear? Has MBAE or HMPA come out and said "We use THIS form of CFI" ? Not that I'm aware of.

Just because their goal is to enforce some type of restriction does not mean they work the same way at all, even if the implementation uses some specific type of hooking.

As far as I know, this isn't the case, but I could be wrong. I would imagine that the improved performance *allows* one to make more finely grained rules on control flow, but that's all. But I don't know the details of that - I've only seen it mentioned at a conference as a performance increase.


Without an open methodology I see absolutely 0 reason to trust the code. EMET may be closed source, but they back up their claims. They explain why they enforce things the way they do, and even how they do it.

 

Like I said before, they are probably chosen because they make the most sense. If you search for CFI, you will find the same techniques being mentioned over and over again. So I highly doubt that there are tons of ways to stop memory corruption, at least not in a way that can be easily implemented, without any major overhead.

The developer of MBAE has said that some protection methods are similar to EMET, and some of them are unique to MBAE. And if you check out the HMPA "exploit testing tool", you will see similarities between EMET and HMPA. Of course implementation might be slightly different, but who cares anyway? This is only interesting if you want to code a competing tool, or want to bypass protections.

 

Well, this is coming from a developer. Search for it on the web, I don't know the details, but it makes sense to me.

When you say "reason to trust the code", you're probably talking about how easy it is to bypass anti-exploit tools. Well, there is no such thing as 100% security. At the end of the day all that matters is their ability to protect against "in the wild" exploit-kits and even zero days.

Now we're just running around in circles. See my other posts in this thread.

 

I agree with Hungry Man, though I'm using MBAE.
EMET is open for its technique so many professionals have had interest, then they examined it and consequently improved its robustness (not only Bromium reported weakness).
MBAE OTOH, don't disclose them 'cause they still don't get a patent but once the patent is granted, they should.
Obscurity don't help much considering many attacker are reverse-engineering security products.

Rasheed, I'm also not techy and have only very limited knowledge of programming, but as HM said there are/can be many ways to stop exploits/ROP, and also note there are/will be many variants of ROP.
There're also many techniques to bypass DEP and/or ASLR (and in Linux there're some more mitigation and bypasses of them).
As to hooking, it's not a way to mitigate but just a means which those tools use.

I also agree that EMET's technique are adopted not because they are most effective, rather they are focusing on certain technique which is known & used.
E.g.
VirtualProtectEX is used to overwright access protection option on memory thus enables an attacker executes arbitrary code on stack: MemProt focuses on this.
Many ROP attack use 'ret' to repeatedly call functions: Caller focuses on this.
Stack pivoting is used to chain heap-overflow to ROP: StackPivot focuses on this.
In short, they are not so much general and might not be useful against future exploit.

MBAE would be better for java-exploit thanks to layer3 protection, but when it comes to memory-only malware I don't know which is better.
Audit by outsider will help making their product more robust, and simple fact that MBAE have been blocking every ITW exploits is NOT enough because they sell it also for corporate user where targeted attacks matters.

 

Lack of credible info about MBAE is something they need to fix pronto. If you're going to offer paid and proprietary, you MUST do an independent review by a trusted 3rd party at minimum.

 

I guess I'm trying to make it clear that MBAE has literally no relation to any other product, except that it is trying to accomplish similar goals. Those goals have almost nothing to do with the way you get to them. There is no reason to believe that MBAE uses any specific technique, other than that one developer said that some technique they use may be similar to one in EMET.