Fileless malware detection

You did not understand " current session passwords ".

 

I'm sorry but I do not know what you mean, because anti-exploit tools are specifically designed to stop zero day attacks. And they do it "out of the box" without you having to configure stuff, at least when it comes to MBAE/HMPA. So it does not make a lot of sense to compare HIPS/behavior blockers with anti-exploit.

 

I am not an expert but I think they just cover known exploits. If a malware will use a new zero day exploit, it might bypass these tools. This is in contrast to classical HIPS where a typical payload executable will almost always be intercepted.

Not denying the usefulness of these tools but nothing is fool proof.

 

That's where "layers" seem to work best imo.

 

I don't see any performance issues when having dlls monitored by SRP. In fact I don't see any difference if I enable/disable that option. OTOH the problem might be noticeable on older computers.

 

Yes, same here, no slow downs at all.

 

Thank you both for confirming no loss of performance with the .dll option enabled, definitely good to know as I never did try enabling it.

 

This is incorrect. The purpose of exploit mitigation is to prevent zero-day exploits without previous knowledge of specific vulnerabilities, but rather by using proactive techniques that target the way exploits behave. Sure nothing is fool proof and there will always be new exploit techniques coming up, but the point is that exploit mitigation raises the bar so much that it blocks the vast majority of known and unknown (i.e. zero-day) exploits generically.

 

I did not say any thing different.

 

I have one question about truly fileless infections. What needs to be done to remove infection? Is closing and reopening infected application (process) enough or should we reset the system and wipe whole memory? If reseting the system is a must, than we should probably disable hybrid shutdown on Windows 8 and do full shutdown instead (that's how I do it).

 

So I believe. Then, why Defense+ in paranoid mode should not intercept fileless malware ?

 

Because it is not the typical executable that is intercepted by classical HIPS. Out of their scope.

 

I am not sure but I think for this specific one, just closing and relaunching the IE was enough.

 

from https://blog.malwarebytes.org/exploits-2/2014/09/fileless-infections-from-exploit-kit-an-overview/
So if closing an app will not kill the process, killing it from task manager (or Process Explorer) should probably kill an exploit.
If process survives when app is closed, can that process communicate with new process that is launched when app is reopened? Or does malware become benign since it's trapped in non active process?

 

Sorry, my previous post imply alone explain . I mean: well configured HIPS monitor all the process and the activities in the system. So, Why they can't detect fileless malware' s activities ?

 

They monitor main stream executables and the executable involved here is not one of them.

Just for an example, most HIPS don,t intercept a dll loading. So if a dll comes through a network exploit and is loaded into the browser, in the memory, without writing to disk, it will not be intercepted.

 

So how does it checks the dlls? By signatures or what?

 

@Peter2150

I am not 100% sure if HMPA's monitoring is that advanced. I'm not saying that it isn't, just that I'm not sure. AFAIK HMPA is injecting its own dll into the browser, some critical system processes as well as newly spanned processes and by monitoring all these processes it can detect if the new process is attempting to manipulate the other ones.

In the fileless scenario however the browser loads a malicious dll directly into itself in the first stage. This is where I am not sure if HMPA could detect that. However it can prevent things from getting to this stage in the first place by blocking the memory corruption that precedes this; as would EMET and MBAE I reckon.

This is at least how I understand it and I have to stress that I could be completely wrong.

 

The difference between HIPS /anti-exe and anti-exploit tools is that the first do not care if the payload is malicious or not, they block everything, making it less suitable for regular users. Anti-exploit tools make use of more advanced methods trying to decide if a payload is triggered by some exploit (memory corruption) or not.

And MBAE/HMPA have added "application lockdown" features, so that they can still stop payloads when "exploit mitigations" are bypassed, sort of like anti-exe, but I don't know the details. Another advantage that they have is the ability to stop exploits/payloads in an earlier stage, that's why they can stop file-less/in-memory malware.

 

Yes correct, I know what Peter2150 means, but what he refers to is more related to the "safe browsing" feature, not to blocking exploits.

 

Since CWS asked me to reply his question here and allowed to paste part of his PM, I'll reply his question.

Surely I said they protect you from same category of exploit, RCE, but note I also said they works on different stages and in different way.
MBAE protects RCE on the earlier stages, but SBIE OTOH, only protects system from the result of RCE, usually it is drive-by malware.
So the number of threats they can protect are never equal.

As to Chrome, it is not equal too. SBIE can care about downloaded executables while Chrome not.
Chrome can prevent some in-mem malware attack (but remember, this type of attack is not observed except the FBI Tor exploit) if you enable strict site isolation, SBIE not. Read sandboxie technical discussion thread again, I already explained those things.

Also, you confused my statement. What I said is Chrome only have basic memory protection like DEP and ASLR, though it also has some more memory protection called partitioning, but it's not about its sandbox. Memory protection had nothing to do with its sandbox. So if Chrome's memory protection was bypassed, sandbox protection comes in.

 

That depends on your definition, heap spraying or NOP sled will look anomaly and cause increased memory consumption (haven't we discussed it in another thread?), but maybe it's different from what you mean.
Arbitrary code simply means arbitrary code though it's limited by the process' privilege, so don't need to alter browser behavior. Just make its activity looks like normal browser behavior to avoid detection by AV or interception by HIPS.

 

I'm not sure what you mean, but in Angler case it prevents IE exit so IE just hide its UI, don't really exit so this lurking process can communicate with other process and actually being active, I think.

I think most HIPS can intercept dll loading by intercept any of LoadLibray function besides some commonly combined function such as SetWindowsHookEx as long as it is on disk, but this strategy won't work for some "stealth" dll injection techniques.