AppGuard 4.x 32/64 Bit - Releases

This is this is the single most bizarre conversation I've ever been involved in. It's hysterical.

Both Barb_C an Fleishman say AG prevents a guarded apps reading or writing to another apps memory and I'm wrong! That's what I've been saying for the last 2 days .

'You've fair cheered me up' as we say in this part of the world. This forum often lacks humour - not today.

Anyway let's say we've been having communication issues? We can then leave it to readers to work it out for themselves.

Cheers

 

I'm currently running all three together with no issues. (Once you set the proper AG rules for sandboxie.)

 

Yes, you can run all three without any conflicts or other issues. You just have to make sure that Sandboxie's container folder is set as an exception folder with write access within AppGuard if it is in the default location of C:\Sandbox. If it has been relocated onto an alternate drive, you don't have to do anything to give it write access because it will then be in user space anyway.

EDIT: When you want to customise read/write permissions (read/write, read-only, deny), you use the Guarded Apps tab. When you want to customise user space launch permissions (include = yes, include = no), you use the User Space tab. This may help to make it clear:

AppGuard 4.x 32/64 Bit

 

Hi

So I installed AppGuard and Sandboxie. Later added to "User space" tab C:\Sandboxie. Also AppGuard was preventing Keepass launch so I added Keepass.exe to Guarded apps. Is it ok and I understand correctly?

Edit: Chrome don't start in Sandboxie so something is not right
Edit: Rules for sandboxie and Chrome https://www.wilderssecurity.com/threads/appguard-4-x-32-64-bit.355206/page-77#post-2397411

 

@meatouph @kjdemuth
Good Morning!

Thank you for sharing your knowledge and insight to my question.
I truly appreciate your answer. Feel free to post additional information
that help me from making a BIG mistake with PC's.
@peqr
The additional detail about AppGuard is truly very helpful.

Many thanks!

 

I'm confused. Are you getting notifications that version 4.0.17.1 is ready for download. Will you post a screenshot of your AppGuard About Box (or send it to AppGuard@BlueRidge.com)?

We haven't changed anything on the "4.0" server. We're using a different server for 4.1.

 

Chris, I'm trying to have a sense of humor about this exchange as well. I didn't like the "finally given some clarity" remark as I've previously responded to this particular question on this thread (or perhaps it was the original AppGuard thread) and if I had the time, I would search for them and reference them here, but too busy for that.

 

Did you check our Website with respect to how to customize AppGuard policy so that it will work with Sandboxie: http://www.appguardus.com/index.php/support/appguard-support

 

Thank you, Chrome works now. What about Keepass I posted #1904, is it right rule? I had to add same rule for qBittorrent

08/05/14 13:15:48 Prevented process <keepass.exe | c:\windows\explorer.exe> from launching from <d:\program files (x86)\keepass>.

08/05/14 16:53:54 Prevented process <qbittorrent.exe | c:\windows\explorer.exe> from launching from <d:\program files (x86)\qbittorrent>.

08/05/14 16:57:08 Prevented process <napisy.exe | c:\windows\explorer.exe> from launching from <d:\program files (x86)\napiprojekt>.

 

You´re both kidding me right? This is getting bizarre indeed. I´m not sure if this is about a "communication issue" anymore. What I´m saying is: EMET works differently compared to Memory Guard, you seemed to agree with that. After that, Barb_C confirmed that AG is not trying to stop exploits with the same exploit mitigation techniques provided by EMET. Please read post #1892 again, FleischmannTV explained exactly what this "issue" is about.

https://www.wilderssecurity.com/threads/appguard-4-x-32-64-bit.355206/page-76#post-2397164

 

Well, what I meant with the "finally" remark, is that in another thread you gave a quite lengthy explanation about the inner workings of the Memory Guard, without clearly indicating that it isn´t offering the same exploit mitigations as EMET. And is this thread you also didn´t seem to understand my point, before FleischmannTV stepped in.

 

I agree with you Rasheed that nobody responded to what you where actually inquiring. You wanted to know if Memory Guard could prevent code execution in, say, the browser's memory or if it just prevents the attacker from injecting into other processes once the browser has been compromised.

AppGuard doesn't prevent the memory attack from happening (that's what you really wanted to know), it simply assumes that it's already in effect and prevents it from spreading further.

So when we are talking about exploits, this differentiation actually matters. I am not sure if MemoryGuard would be of any use against the FBI's TOR browser exploit for example.

 

Is there any news on whether an option is coming to use the bi-directional MemoryGuard like in v3?

 

@ FleischmannTV

Yes exactly, there are all kinds of exploits, standard ones, but also advanced ones, so I´m just trying to figure out if apps like EXE Radar and AG are good enough to stop even the advanced ones, but without any hardcore testing we will probably never know. My feeling is that it´s probably best to use ERP and/or AG combined with EMET or similar tools.

What do you mean with that, what was different about it?

 

The MG in AG 4 (depending on your configuration) blocks Guarded Processes from reading and writing to other processes memory.
The MG in AG 3 did that and also blocked other processes from reading and writing to memory of Guarded processes.
They changed it because of user-friendlyness; the user needed to create more MG exceptions to allow legit application access the the memory of Guarded applications.

 

This had nothing to do with trust or what's better, it was a simple inquiry as to how something works.

 

So what does stop/prevent memory attacks from happening?
Malwarebytes Anti-Exploit and what else?
Anyway, I always wanted to know if AppGuard and Malwarebytes Anti-Exploit can co-exist together on computer...

 

Than how does EMET work compared to AppGuard, what are key differences?

 

Well my misunderstanding of your question certainly wasn't intentional, but when I see a statement like "AG´s Memory Guard is not designed to stop memory corruption/exploitation...", I have to disagree. That's exactly what MG is designed to do (okay, yes a browser may become temporarily infected after going to a malicious website, but the attack will be contained and it will not persist after a reboot - unless you go to the site again and become reinfected).

With respect to answering how AppGuard's exploit mitigations compare to EMET's mitigations, I am not an expert in EMET and don't feel qualified to answer. I just know in a head-to-head test against EMET last year, AppGuard stopped 100% of the malware thrown at it, while EMET only stopped 80%. I will ask our Chief Software Architect to explain how the approaches differ and get back to you (he will certainly know). He's at Black Hat/DefCon this week so it might be a while before he gets back to me (and I to you, but it isn't because I'm avoiding the question).

 

I also want to add, that we would never recommend that you don't use EMET. The fact that the products are using different techniques (I'm basing this on what Rasheed has indicated), is even a better reason to use them in conjunction. If they were using similar techniques then I would say you should just choose the one that works best for you but because they work differently you are actually increasing your protection profile by using them both (vs. an example where you might install two AVs - there would be little point in doing that because they pretty much operate the same way and are going to let the same types of attacks through). Make sense?

 

I just noticed that you are using "d:\program files (x86)" for your program files. Is that your official program files directory (or do you also have a C:\program files (x86) directory)?

It looks like AppGuard is treating "D:\Program Files (x86)" as user space, but if this is your "official" program files directory (by official, I mean that your Windows Environment variables are pointing to that directory), then AppGuard *should* be treating it as system space. Anyway, by classifying it as User-space folder, AppGuard is going to block any program launched from that directory in Locked Down and only allow digitally signed apps to launch in Medium level. The solution is to either Guard every application in that directory (which I don't recommend) or add D:\Program Files (x86) as a protected folder and then exclude it from user-space. This is all documented in the help file, but if you need more assistance, please email AppGuard@BlueRidge.com.

 

Ok, thanks for your help here in advance and I'm very curious what are the methods what are differences in methods between EMET and AppGuard, which allows AppGuard to pass/block all security tests, while the EMET blocks only 80% of them; but I have one more question regarding your answer to Rasheed: you said that: That's exactly what MG is designed to do (okay, yes a browser may become temporarily infected after going to a malicious website, but the attack will be contained and it will not persist after a reboot - unless you go to the site again and become reinfected-but wouldn't AppGuard again contain and block attack when you go to the website again, and every single time when you go to malicious website?

 

Would Appguard still protect, contain and block against digitally-signed malware so that it cannot alter my registry and system directories even on Medium level, because this is the level I use, personally I'd tweak to to Lockdown mode, but I'm just too busy and without time to do this tweak.

 

Given that the objectives of EMET and MemoryGuard are different, if this article is to be believed, it may be easier to bypass EMET's exploit prevention than AppGuard's exploit containment:

http://www.pcworld.com/article/2101...in-microsofts-emet-antiexploitation-tool.html

I read Barb's reply as meaning that each time a malicious website is visited, the browser will become temporarily infected, but it will be contained by AppGuard from doing permanent damage to the system. This reinforces the point that the primary goal of AppGuard is the protection of objects inside the trusted enclave. Objects outside the enclave may become infected but they must never be allowed to compromise objects inside the enclave.

My understanding is that this is why BRN also recommends the use of AV/AM to remove any infections that may be present in user space, which AppGuard will have prevented from invading system space. AppGuard is designed to contain zero-day attacks in real-time in order to give the AV/AM scanner a chance to play catch-up later.