What Kind of Malware Can Bypass Anti-Exes?

I imagine you could get persistence with a script by changing some User space autorun registry entry to launch the scripted file. But this will first load the scripting program, which would make it quite "non-stealth". Unless the program can be launched with command line switches that "stealth" it (which would be a major security flaw imo). So I would say that anti-executables protect against "not completely obvious persistence".

By rights management, rather than UAC (which I assume as a bare minimum these days), there would be further privilege restriction eg firewall, Chrome's tabs, firewall, Sandboxie, DefenseWall. I used to include anti keylogging in there, but not since I learned how useless these are (i.e. see here).

 

I think I can now paraphrase the argument on the other side of the fence:

Sandboxie on its own offers more complete protection to all possible threats than a standalone anti-executable on its own.

This comparison is apples vs oranges, but it is correct for what it is. Anti-executables are extremely simple in scope and the logic reduces primarily to one simple rule, whereas Sandboxie is a carefully crafted collection of policy restriction and virtualization rules that are collectively designed to give maximum security with as little inconvenience imposed to the user as possible.

Other than the apples vs oranges nature of this comparison, the specific downside in this case is that this inconvenience is not tolerable to some. I do not personally like using Sandboxie because I don't like to constantly approve what should be and what should not be in the Sandbox.

I loved DefenseWall on XP because it felt more comfortable to me in terms of the decisions I was asked to make. For me, Ilya had managed to find that "sweet spot" of extremely high protection with extremely high convenience.

After reading experiences of others on Wilders with Appguard I thought that it might be the Win 7 x64 answer to DefenseWall, but after using it I found that it did not find this "sweet spot" for me, erring too far on the "block everything" side for me (something like 600 block events after 2 weeks of intermittent and very safe use with no risky behaviour on my part).

An anti-executable is just a single bullet point that lets me address one specific vulnerability, which must then be combined with other tactics to address the full gamut of vulnerabilities that more total solutions like Sandboxie, Appguard and DefenseWall offer. I use other things to achieve a total level of protection that is just as good as these packages, but the overall convenience of use, for me, is greater.

In summary, apples may be better than oranges, but apples and strawberries together give me the nutrition I need without juice running down my chin.

 

Hi Melf,

It's quite commonplace that AppGuard will generate a lot of blocking events due to the way it works. AppGuard is based on the concept of a trusted enclave. The set of policy restrictions applied is entirely dependent on whether an application is inside or outside the trusted enclave, not the way the application is used. It isn't a question of safe or risky behaviour on the part of the user; it's the trustworthiness of the application itself that determines what behaviour will be blocked.

One reason why AppGuard generates so many blocking events in respect of guarded applications is because programs don't always follow best practice coding guidelines and sometimes try to get more privileges than they actually require to function. For example, a guarded application may try to open a file in system space for write access when it only needs read access. AppGuard will block write access to system space by a guarded application but will allow read access.

The greater majority of blocking events do not impact the ability of programs to function correctly and can be ignored. This is stated by Blue Ridge Networks and is something that I have found to be true in two and a half years of using AppGuard. On the rare occasion that a blocking event does interfere with the operation of a guarded application, a blocking event exception rule can usually be made or, failing that, the application can be temporarily or permanently unguarded.

I suspect that most of the blocking events you saw were MemoryGuard blocking events in respect of guarded applications. These can nearly always be ignored with no detriment to the ability of the application to function correctly. To prevent these from becoming a nuisance, generic ignore message rules of the type: "Prevented <Program X> from writing to memory of <*>" can be created in order to prevent them from being displayed or written to the Windows event log.

If you ever get round to trying AppGuard again in the future, you might be pleasantly surprised that, with a little configuration, just how quiet and unobtrusive AppGuard can be.

Kind regards

 

Worried about in memory intrusions, have a look at Crystal Anti-Exploit protector , it also has limited AE capabilities https://www.wilderssecurity.com/showthread.php?t=327142

 

The problem for me is that when something goes wrong with a program I'm running, I can't tell whether it's a bug in the program or in AppGuard, because every program I run generates a lot of blocking events. The signal to noise is not good. I could filter them out, but then I may well filter out the blocking event I needed to see.

For example, after installing AppGuard I noticed intermittent issues with latency and sound in a game that I was playing. The issues don't seem to be there anymore. Maybe it was just a coincidental bug in the game that got patched? Maybe my ISP was having a bad couple of weeks? Or maybe AppGuard was interfering with a "non-critical" DLL that the program used? I have no good way to tell.

Of course you are right that many programs are poorly written from a design standpoint, and so may ask for "too many" privileges. To establish a good benchmark then, let's consider the use of Google Chrome when browsing safe websites. The Chrome team has created a fantastically secure product that I am pretty sure will not do anything untoward even when looking at a risky website, let alone a safe one. If Chrome is getting blocked by AppGuard when looking at safe websites, AppGuard is being silly, and the Blue Ridge team should adjust their "paranoia" slider somewhat.

Thanks for that one, it looks promising. I think I will give it a try in the next couple of days. Can you describe how the AE component is limited?

 

Which protection level were you using? In my experience, Locked Down generates a huge number of alerts. If you did have the protection level set to Locked Down, you could try reducing it to High or Medium and see if that helps. Personally, I find Locked Down too restrictive. If a blocking event isn't impacting program function then the blocking event message can be ignored, and filtered out in order to reduce the noise if it is causing annoyance. In my experience, most blocking events are generated by MemoryGuard and these can usually be ignored. If blocking events are generated and the program isn't working properly then clearly some AppGuard configuration is needed to overcome the problem. It's usually fairly easy to tell though when AppGuard is blocking something significant.

There have been reports of this happening when the protection level is set to Locked Down. If you didn't have the protection level set to Locked Down, have you tried the recently released AppGuard version 3.4.2 to see if it fixes the problem?

As I said previously, a set of policy restrictions is applied to each program solely on the basis of its trust classification within AppGuard. Whether the program is being used to engage in safe or risky behaviour by the user is irrelevant. The program itself has been classified as safe or risky, and that's what matters.

 

It only checks the guarded applications for process creation and whitelisting/blacklisting of executables and dll's started by the guarded application. Not a system wide AE, more an AE shield over some threat gate applications (e.g. webbrowser).

 

I was operating on the default, which I believe is High. I tried Locked Down and was quite scared by the number of blocked events, so switched back.

How recently is recently? The was during May. Have they eased back on their...blocking enthusiasm... in the last few weeks?

In my view, blocking those functions on Chrome is a false positive. Chrome doesn't do anything risky. Popular applications with good security design (i.e. Chrome) should be used as a bare minimum benchmark for sane blocking level by security apps, imo.

 

It isn't a question of how safe Chrome is in itself, or how well it is coded; it's the potential for misuse that matters. If a browser, running as a guarded application, exhibits behaviour that violates AppGuard policy then the behaviour will be blocked. It doesn't matter what the browser or the user was doing at the time; the behaviour is blocked because of its potential to exploit the system.

The question of false positives doesn't arise as the concept only has meaning in relation to security programs whose goal is detection of badness. It is inapplicable to virtualization programs and policy restriction programs like AppGuard. Both of these classes of programs apply their security models to running processes without making any judgement regarding intent.

The strength of AppGuard is the automatic, silent blocking of behaviour that has the potential to be exploited by malware. It is left to the user to decide whether a blocked behaviour was necessary for the application to function, in which case an exception can be made.

AppGuard provides very strong protection but I understand that the security model it uses may not suit everyone.