What Kind of Malware Can Bypass Anti-Exes?

This was my point to HungryMan since day 1 but he insists AEs and things like SRPs CAN still be bypassed in the sense that let's say a malware is so advanced that it first goes executes from RAM and continues its business there to avoid being denied disk execution, exploits admin rights, then starts loading stuff and doing anything it wants to, up to an including turning off the SRP with its stolen admin elevation.

 

Everybody here is focusing more on the side of "how a malware can execute itself if there's some anti-exec software installed onto the system". So, somebody talked about in-RAM execution (two nice examples can be Slammer and CodeRed worms, two kind of real-world infections)

However, looks like nobody is taking care about at least another fundamental thing: an anti-executable software is used to just decide whether something CAN be executed, or it CAN'T.

The point is that once the executable has been executed, nothing can be done anymore.

So, let's say you trust a specific executable. What happens if *that* executable, coming from a trusted source, has been infected by a file infector virus? Who will detect that infection? Surely not an anti-executable software, which is bypassed by design as it already did its job.

You'd say: "yeah, but that executable was signed with a trusted certificate".

Sure, but:

1) nobody can really say whether the certificate has been stolen or not (last incident about this was Flame)

2) if people would just use anti-executable software, who can really detect a file infector activity? So, who can actually exlude whether the developer of that trusted executable didn't already has his computer infected by a file infector? He just signed the executable, and published it online

There are other missing questions that could be posed to better focus this argument.

I think that an anti-executable software can be actually a useful security solution, though if joined together with another kind of security software. Otherwise, it can be used as a exclusive security solution only in specific situations where the user can't download anything on the system, can't surf the web, can't plug USB devices

 

And latest "news" Tiban?

http://news.drweb.com/show/?i=2508&lng=en&c=5

 

I think we've all made it pretty clear that exploits could occur within the anti-exe trusted policy (non-persistent attacks in general).

Also, if we trust an exe that we shouldn't, then yes, your AE will fail. Just like allowing "unknown" exe that we choose to run anyways. This is not a software bypass, that's social engineering. Because on this token alone, I could have TOLD you it was malware and some other hacker convinced you otherwise despite a 100% infection count on VirusTotal or every piece of gear you have throwing a warning. So yes, poses the question: can any software protect against user stupidity. The answer, only a complete locked down computer: agreed. However, an AE with a user with zero priv would be a partial ticket to the goal, correct?

Remember, not all AE use whitelists/certs or can be modded not to. So ultimately you are saying trojans can bypass a true/full default-deny hash system. Yes, but mentioned already and again, not a true bypass: PEBKAC.

 

I know for me personally, the question was always and still is: "What kind of malware can bypass true whitelist-based security measures; as in a full blown default-deny environment in which only installed software is allowed to execute." My SRP is and always will be set up with no exceptions.

Let me also remind everyone why the social engineering model of bypassing AEs doesn't worry me all that much...

1. I've always been an advocate for at least being an intermediate user before you implement a true whitelist-based prevention measure.

2. The most common AE model I advocate for (and use personally consistently across my machines) is a true whitelist measure enforced with no exceptions by Windows Software Restriction Policies (or AppLocker in the near future). Because I do not use nor specifically advocate for prompt-based whitelist measures (call them whatever you want), and since my AE set-up is just default deny everything, I am much less prone to social engineering to begin with.

3. I do not use nor have I ever advocated for the use of AE alone. I recommend pairing it with some form of real-time monitor or at least very routine scans of your machine. HitmanPro and MalwareBytes' make a good team of scan-only applications for checking to ensure no inactive malware (can't execute)slipped on your machine.

Now, as for what CAN potentially bypass the model(s) I'm advocating...

It seems from what I'm hearing (and how I'm understanding it) that the only two theoretical possibilities are:

1. Persisting only in RAM. This alone is not very threatening unless they also make use of # 2.

2. Execute in RAM, exploit another process that is already whitelisted, and then use an admin elevation exploit to communicate to higher integrity processes and do some damage.

Those most likely are possible, but to me the other question here is who is more right...HungryMan or Melf?

Is this malware technique really just as viable, reliable, and easy to implement as writing to the disk? Could hackers so trivially switch to this if AE use was widespread? Would this really make AE useless and just achieving "security through obscurity"...

...Or, are administrator privileges/tokens very well guarded by Windows, and in reality much more difficult to exploit than HungryMan implies? If it is difficult to exploit than as Melf says, they may be able to borrow a process, but they won't be able to do anything significant with it, other than perhaps loading a phishing program into memory in hopes you're stupid and a reboot will knock that out regardless.

For me, the question still remains very open...

 

My only 'true' security software is Deep Freeze/Drive Vaccine (depending on computer) and Anti-Executable - the tried and true from Faronics.
http://www.faronics.com/standard/anti-executable-2/

 

Melf.

No.

I think you do have to choose a "cut-off" for your paranoia level at some point. You have to trust something, or install nothing.

 

The idea that persistence is the end goal for all attacks is incorrect. Persistence is nice, not necessary. And I still maintain that you can achieve persistence through various techniques like spawning a thread under the name of another process (yes, you can do this) or just simple IPC or using any of the million things that an AE simply can not stop because it would break programs.

I don't know how many ways to say it. There is nothing for hackers to "switch to" in terms of their methods. Their attacks already start in RAM it's only a matter of keeping them there.

As for social engineering it's nto worth discussing. Social engineering is all about trust and the way you 'trust' an AE is not the way you trust a sandbox and it's different from trusting an AV. Users develop a rapport with a product blah blah blah, not worth it.

 

IMO,

The weak spot of Anti Executables is that code and data are mixed in the most commonly used media formats like webpages containing javascript, pdf's containing programming logic, XML also containing executable code, images containing logic.

When a programmer is able to hide code (often referred to as an egg) in legitemate data, this code can be triggered by bad programming practises or errors in the framework (the operating system, browser or plug-in) in which the data/code is running (hunt for the egg). All of this happens in memory. As Hungryman points out the key issue is to keep it there and not let it save code to a place where it survives re-boot.

I use AE (SRP/AppLocker) combined with intergrity level containers and access control list settings of directories and the features of the OS (Win7) plus EMET to keep me safe from ram based intrusions. It is not a 100% solution, but good enough in daily practise (using safe hex).

 

Yes, sometimes is social engineering. Sometimes it's the source which was unknowingly infected, breaking the trustworthy chain at the early beginning.

That's not the point anyway. The point is that a pure anti-executable software, by design, relies for its final decision on the user himself - who is always the weakest point.

PEBKAC, this is the reason why there are security solutions which don't rely only on the user's decision, but they are able to check in depth the goodness of a specific file. Antivirus scanners don't just rely on user's decision to execute or not a specific file. They are able to run a thorough scan of the file, looking for infections hidden into the code. Behavior blockers don't just ask the user "do you want to run this software or not?", they go through a full behavior analysis scan before giving back their decision

 

Or you can rely on some security solution that at least run some kind of more advanced and deeper scan on the file content than just asking you if do you feel confident enough in running x software or not

 

I think even HungryMan would agree that presently AEs would block more malware than any AV...this isn't a AE vs use an AV thread...

The argument is really...

* Is AE stop malware from doing something critical

* Is AE easily bypassable if hackers needed to do so (aka it became widespread)

* Is this just security thru obscurity

 

I believe I mentioned something about it before. We can put it into perspective. AEs are not widely used by home users, but they are, and should, widely used by enterprises. So, in this perspective, and if we consider some "news" about this or that infection happening in certain infrastructures, did they happen due to bypassing this kind of security? I haven't heard of anything like that; only due to stupidity, even in the case of exploits, because the exploits still need to execute something. One example is Stuxnet, which used a known Windows exploit back then... an AE would have prevented the infection, regardless of the exploit being successful.

So, if anyone can present me with any valid data and facts, that these security measures are useless/pointless... by all means do it so.

Anyway, the answer to the question posed in this thread is basically this: ALL malware can bypass it, if you consider the user believes the process/etc is trustworthy.

But, the real question should be: Should we rely solely on AEs? The answer would be NO. The layered security doesn't have to necessarily be an antimalware application, for those who dislike them, but it can be O.S hardening, browser hardening, etc.

Otherwise, we can also ask: What kind of malware can bypass everything? The answer would most likely be that, with time, everything is bypassable, and therefore useless.

It's actually quite interesting. The other day I saw a documentary about chemicals, and whether or not they were dangerous to our health. What many failed to understand is that, you can't just look from the perspective of one chemical, but the interaction of them all. Alone, they may be harmless, but when in mixed with another chemical... watch out for the combination... So, in this specific case, the combination would be the layered approach. I mean, we can't just think from the perspective of an AE, or just browser hardening, or just O.S hardening, etc., but the combination, right?

For instance, an AE could be bypassable, but a hardened browser (including sandboxes, exploits mitigations) could prevent the exploit, to begin with. So, if the exploit is prevented, no infection will even occur. A browser could be bypassable, but an AE would stop it; or, maybe the AE would also be bypassable at the same time, but some other security implement would deal with it...

 

Some real good advice/info here... I've come to expect no less from Moonblood.

But I must point out again that we're not talking about weakness in the user. We're talking about AEs being bypassed using techniques that HungryMan advocates are not only possible, but can done/switched to trivially. You bring up a good point though that I overlooked - businesses DO use SRPs quite widely either enforced by Windows or Novell I suppose. If SRPs are easily bypassable using RAM-only attacks, why aren't businesses suffering widespread?

 

By the way most AE's have counterrmeasures to recognise/intercept data structures which contain both data and code, as Rich tests with AE (the program) has prooved often.

Bottem line for me: the security level reached with whitelisting (preferably with default deny unknown) provides a much higher level of seurity than for instance blacklisting or behavorial blocking.

 

Nobody talked about AE vs AV.

Again, what I'm saying here is why an anti-executable solution by itself can be a reliable solution only in very few specific circumstances, otherwise my opinion is that an AE *must* be used alongside other security solutions (AV, sandbox solutions, behavior blockers)

 

I didn't have under consideration the stupidity of people, within infrastructures that should be well protected. I rather mentioned the stupidity of not using AEs. With the example I gave - Stuxnet - even though the initial exploit was successful, the actual infection could have been stopped, if the systems were protected with an anti-execution policy.

-edit-
Which by the way, makes me want to ask the following: Were the Stuxnet developers, a state sponsored malware, counting on this infrastructures professionals stupidity, and therefore didn't even try to bypass any possible AE they could be using? Wouldn't they want to have AEs under consideration, and have ways to bypass them in the code? I haven't heard anything about it. Have you? If it's so trivial to bypass AEs, then don't you think that these state-sponsored malware would have code that allowd them to bypass anti-execution policies?
-end of edit-

But, it can be anything, actually. Imagine that someone working at an enterprise goes to a regular and trustworthy source, because they need to download a document. It could be a PDF file, for example. Now, this PDF file/other document is stored at a server that they have no control over - it belongs to a third-party. Maybe it belongs to a business partner.

Someone hacked into those servers and placed a tampered PDF file. The enterprise employees can't really upload the file to an online service, due to privacy reasons. Their anti-malware application doesn't flag anything. Of course, this is not obvious reason that it's a safe file. So, maybe the PDF will exploit a known vulnerability in an older Adobe Reader version, but Adobe Reader X, which has a Protected Mode, will render it useless. Or, maybe it's this company policy to use the built-in browser's PDF reader (Google has it, Firefox has an extension) to open the PDF files, and the exploit won't work against those. At this point, no real reason for an AE to even kick in.

Heck, but maybe the exploit is successful... but, then again, the anti-execution protection solved the situation. Or, maybe the PDF file was opened in an isolated environment.

Maybe that business partner has been hacked for long time, and these employes have been downloading malicious files for a long time, but a properly secured system took care of the situation, and no one ever noticed something... until, maybe some careful system admin looks into the security applications logs, etc... or, maybe no one is going to bother with that, at all.

The point is: From the moment you download something from a trustworthy source, we can't really say it's about user stupidity, home user or otherwise, because it isn't, IMHO.

Then, we also have people claiming about trivialities. I have heard something similar about browser's sandboxes in the past. But, no one really ever proved any of the "talking". If it's so trivial, why don't they prove their claims?

Being bypassable, and nothing protects you 100%, doesn't equal to being trivial to bypass.

So, are AEs easily bypassable? Anyone claiming that should prove it, IMHO. I cannot claim that XYZ security measure is weak without providing evidence. If it's so trivial even a mediocre programmer should be able to bypass them.

 

With all due respect, that's 100% BS.

Do you actually know how Sandboxie works? Any installed/downloaded file will not run, even if it matches the name of the process that's allowed to run in the sandbox.

So, if you allow firefox.exe to run, then any file getting into the sandbox with that same name, won't run, at all.

Where did you get that info from?

 

I stand corrected, even though I must have seen this message a hundred times!

 

hi

Last year i have posted a remark against AE propaganda by linking a SANS paper
https://www.wilderssecurity.com/showpost.php?p=1832453&postcount=29

I`ve used the white list approach in the past with Abtrusion Protector in combo with SSM, and of course security by restrictions is a reliable approach.
On the other hand, it is more interesting on some environments like internet caffee, administrations, hotels, or corporate.
More over there, is no need to use this soft to get the same level of protection, as this can be done by Windows hardening in order to be closed to a read only system which consequently is far fro being suited for entertainment.

I`ve tested AE and bypassed it in different ways, without using Terminator methods (Metasploit, as no license for CANVAS). Then what? Tell me which OS, which software that is immune from Insecurity...
In the past Faronics has organized a contest...and they failed.
It is the same with AE, but Software as Security is a religion for so many users...

EraserHW (nice to see that Prevx is more noticed by R. and D. efforts than Marketing ) has pointed some possible ways, and a collision for a same file-one legitimate and one infected-is one possibility.
There is often implementation weaknesses in some products (hooks, ACL etc) for instance that helps to find a bypass method.
Most of all this editor has proved its bad faith, especially when DeepFreeze has been demonstrated as vulnerable vs some bootkits.
Therefore why spending one hour to stress test their product, to report the vulnerability or weaknesses and in the same way to improve their product without any official nice words from them?

Rgds

 

/agree 200%

I've read about people that think they can bypass Windows SRP by renaming an exe as a .jpg. Lol...try it...not gonna work.

As for some of these ways to bypass AEs...I'm sure vulnerabilies exist...I'm not as concerned about the vulnerabilities because those can be patched...

What I'm concerned about is HungryMan's theory/statement/opinion/whatever you want to call it. If AEs really stop malware authors from doing nothing critical, what's the point?

 

Because that's not true. The two 'arguments' put forward in this thread:

1. "AE's don't stop 'execution' in memory, therefore they can't stop malware." This overlooks the absolutely critical point that malware authors, almost always, seek persistence in their malware. And to achieve persistence you have to write to disk and then execute. Without persistence or a 'proxy for persistence' (such as malware being distributed from a website that a user will regularly visit and be continually reinfected) there's really no point in writing the malware in the first place.

2. "AE's won't stop compromise of supposedly trusted executables. That's absolutely true. Other mitigation solutions are required for this.

 

Because it's so easy to get. Persistence is great because:
1) You can remain after a reboot, which allows you to embed further into the OS ie: botnet/ rootkits.
2) Your window of time expands

That's fine. But persistence isn't necessary. I'm not denying that malware today doesn't try to maintain itself on the system or that an AE isn't effective against malware today. I'm saying that malware could easily be designed to work without persistence and it would be very effective - if I can control your browser session I'll likely get everything I need and I don't need to reboot.

Of course, botnets are really profitable. You can sell CPU cycles from a million computers for quite a lot. So many attackers will want persistence.

So what does an AE do about that? Honestly, I don't see it doing a whole lot.

Well... why? First of all, the malware *has* already executed. It's already done that. That's the first thing it did lol that's how exploits work.

Second, all the malware has to do is write a registry entry for startup or use task schedule or some other thing. Why can't it do this from the address space of the program it's exploited? It probably can. I would think so at least. I mean, the exploited program is that same program with that programs read/write access. Why would it not be able to do what it could always do?

An AE in a business is used to reinforce business policy. In a business when the user is given a computer:
1) They likely are not admin on the computer/ can't install what they aren't allowed to based on company policy
2) The system doesn't belong to them

The AE reinforces company policy ie: whitelisting what a user can do with their property.

From a security standpoint on a business machine an AE would be used to prevent, say, installing Adobe Reader when the IT Admin has handed the computer to someone who will never work with Reader.

The user is unable to get around this and therefor they've eliminated a huge security issue because there's no gaping attack surface.

From a user who has admin/ owns the system there is no benefit here. They will simply install it.

AE is fine as an administrative tool.

And it's fine against the current threat landscape. It'll be very effective at preventing today's malware because today's malware wants persistence and the vast majority of users don't use an AE. It doesn't make sense to have multiple strains of the same malware, one that gets persistence when it can and one that avoids AE. ZeroAcess is a great example - instead of attempting to bypass PatchGuard or get around it in some way as it used to the developers realized its far less work to simply not bother and use the same method for both 32bit and 64bit system.s

 

Right...but this is precisely what HungryMan disagrees with. According to him, persistence is over-rated and they can do plenty of damage without it supposedly.

Such as blacklist measures? Sandboxes? EMET? What else besides integrity control built into Windows Vista/7 already?