AppGuard 4.x 32/64 Bit - Releases

Yes. Read/Write.

No. It just made me feel better.

Are there any negatives to adding the AV's exe to Power Apps?

 

Thanks.

I removed egui.exe from Power Apps.

 

I agree with what Peter2150 said about removing egui.exe from Power Apps - it's unnecessary. I too have nothing in Power Apps other than what BRN put there.

Applying start/run restriction to the sandbox(es) by adding the sandbox container folder to user space will work well for sandboxing guarded applications that reside within the Program Files folder, e.g. web browsers. Executables downloaded inside the sandbox will be prevented from launching. Documents downloaded inside the sandbox that are opened using an application within the Program Files folder will open sandboxed and guarded.

If you use Sandboxie for software testing, you will need to suspend start/run restriction in order to run programs that have been downloaded or installed into the sandbox. The easiest way is to temporarily allow user-space launches from the tray icon menu and/or reduce the protection level to Install.

Personally, I don't use Sandboxie for software testing, as I find it too restrictive. Software that requires a reboot, or installs drivers or services, can't be installed inside a sandbox, so much of the testing I do can't be tested using Sandboxie.

 

Thanks.

 

Hello again, sorry to bump my thread. Can anyone or Barb C give me their opinion on making my vpn ( private internet access ) PIA manager a power app.
Would my browsers still be fully protected ?
Each time the vpn is blocked , the location is different

12/02/13 16:17:03 Prevented process <rubyw.exe | c:\program files\pia_manager\pia_manager.exe> from launching from <c:\users\xxxxx\appdata\local\temp\ocr76f4.tmp\bin>.

12/02/13 16:15:37 Prevented process <rubyw.exe | c:\program files\pia_manager\pia_manager.exe> from launching from <c:\users\xxxxx\appdata\local\temp\ocr24ef.tmp\bin>.

12/02/13 16:14:08 Prevented process <rubyw.exe | c:\program files\pia_manager\pia_manager.exe> from launching from <c:\users\xxxxx\appdata\local\temp\ocrc977.tmp\bin>.

thanks

 

Yes, you will need to add c:\program files\pia_manager\pia_manager.exe as a power app in order for it to be able to run rubyw.exe from a randomized location in user space.

It shouldn't impact browser protection but you can test this by trying to save a web page to a system space folder. If AppGuard guarded apps protection for the browser is working, it won't be allowed.

 

You are brilliant pegr. Tried that using the vpn and it was blocked.
Thanks for your advice and expertise, I really appreciate it

 

You are most welcome.

 

Quick question. I found the explanation of AppGuard:
http://antivirus.about.com/od/antivirussoftwarereviews/gr/appguard.htm

Is this true and compared to Threatfire:
http://antivirus.about.com/od/antivirussoftwarereviews/gr/threatfire.htm

If this all that is saying on the links is true, how come AppGuard is more secure than Threatfire?
What is a myth and what is a fact?

 

If you don't mind, I'm going to respond using a Q&A format.

Q: Will AppGuard protect a machine that is already infected prior to installation?
A: No, AppGuard does not use blacklisting so it is unable to detect and clean an existing infection. AppGuard should only be installed on a clean machine.

Q: How do I know my machine is clean?
A: If an infection is suspected then all usual steps should be taken to identify and remove the malware first, including running on-demand AV scans.

Q: Why do I have to lower AppGuard protection in order to install something?
A: Because AppGuard is so effective at preventing malware during normal machine operation that protection needs to be lowered to install software.

Q: How do I know that a software download that I want to install doesn't contain malware?
A: By downloading only from trusted sources, hash checking and on-demand AV scanning of executables, etc.

Q: Does AppGuard interfere with the ability to download files from the web?
A: No, it doesn't prevent files from being downloaded, but it will prevent any downloaded executables from running.

Q: Should AppGuard be used as a sole means of protection?
A: No, for the reasons stated above. A layered defence is always best. AppGuard is compatible with all other security software that I've tested.

Q: Is AppGuard a sandbox?
A: No, AppGuard is not a sandbox. A sandbox isolates software within a virtual container.

Q: If AppGuard isn't a sandbox, what is it?
A: AppGuard is based on the concept of a trusted enclave. It prevents untrusted software from compromising the enclave via policy restriction, not isolation.

Q: Wouldn't an intelligent behaviour blocker like ThreatFire be better?
A: ThreatFire only blocks when a certain threshold of badness has been reached based on evaluation of behaviour. Some damage may already have occurred.

Q: But isn't this similar to what Webroot SecureAnywhere does?
A: Yes, but WSA uses a journalling technology so it is able to reverse any damage. AFAIK ThreatFire doesn't have this capability.

Q: Where can I get ThreatFire?
A: ThreatFire is discontinued. It may still be possible to get hold of the last version but it won't be updated to cope with new threats as they emerge.

 

As usual great post, pegr

 

Hi, Pegr, big thanks for such detailed review of Appguard, but I'm still confused, you said that Appguard doesn't prevent files from being downloaded, but it will prevent any downloaded executables from running.

But from what I've seen it can prevent download files I remember when was the first time I tried AppGuard and by default it was actually preventing files from being downloaded, i had to enable it manually.

Also, does it mean AppGuard will not protect you against downloaded files if they are malware, and I'm not talking about executables...

So if AppGuard can fully protect/block/prevent drive-by downloads, why is antivirus needed if you really don't need antivirus since there is no infection since AppGuard prevented all of them?

Also, if you test AppGuard on malware domain list against exploits, and all forms of malware, AppGuard will always be bulletproof (if in Lockdown or High mode)-right?
So, what's the need of an antivirus if there is no infection on your computer since AppGuard blocks everything?

For example my friend only has AppGuard and Comodo Firewall for protection-he says that AppGuard does block and it already did protect him from all forms of malware.

And how do you know when something is "drive-by download"?

 

What would be the difference between AppGuard and Applocker or SRP? Process memory protection etc?

 

Hi CoolWebSearch,

As per Pegr's guide, aside from downloading from trusted sources, checking hashes/uploading hashes to VT, one can use an AV alongside AppGuard if it's on "Install Mode" to check if one's installers are not packed with malware.

 

I think they have the same strategy. But the usability and convenience of Appguard is way ahead of Applocker IMO.

 

But also AppGuard does not rely on internal Windows security mechanisms, unlike Applocker who does-one sucessfull privilege escalation vulnerability exploitation-and your defense is broken, that's why AppGuard is much more secure.

From my understanding AppGuard blocks kernel exploits and all forms of malware-it doesn't matter if they are executables or in any other form (bat, pdf, java, whatever)!

 

But it seems unnecessary to do all this and to use any AV whatsoever, since AppGuard will block/blocks all forms of malware.

 

The only time that AppGuard will prevent files from being saved is if the target folder lies in system space. Providing the target folder lies in user space, AppGuard won't prevent the download. The whole point of AppGuard is to protect system space, which is why system space folders are write protected against guarded apps, e.g. web browsers.

The solution is to ensure that all folders where data is to be saved lie in user space, using AppGuard configuration to move folders from system space to user space where necessary. An example of this is Sandboxie. The sandbox folder has to have write permission for Sandboxie to work but if the sandbox container folder is in its default location of c:\sandbox, it is in system space and has to be explicitly given read/write permission within AppGuard.

All malware involves code execution, so I assume that what you are referring to here is embedded malware within a data file, where the data file is not in itself an executable but is loaded into an application that could act as a host to run the embedded code. AppGuard will protect providing that the application that loaded the data file is guarded. It's not just Internet-facing applications that present a risk if run unguarded. All applications that have the potential to execute code from within data files should be guarded. This includes things like document readers, media players, office applications, etc.

Interestingly, this highlights a potential weakness of AppGuard that about.com failed to mention. User space launches are either denied or automatically guarded but most applications are installed within the Program Files folder, which lies in system space. As system space executables are unguarded by default, it is the responsibility of the user to ensure that AppGuard is set up correctly after installation.

All untrusted system space executables should be added to the Guarded Apps tab, if not already present as part of the default set added by BRN. Failure to ensure that applications that present risk run guarded could potentially lead to a bypass. That said, the same caveat applies to data files as to executables. Don't a open data file if you don't trust the source.

biscuits has already answered this. AppGuard will prevent drive-by downloads but it will not protect against deliberate user action where the protection level was lowered to install something. Additional steps are needed to help identify and prevent malware before it gets a chance to do damage. For many people this will involve the use of an AV, but it can also be done in other ways too: BB, HIPS, AE, sandboxing, etc, according to user preference.

Something to understand about AppGuard is that it doesn't concern itself with the intent of an application. AppGuard blocks any behaviour that might compromise the system if allowed. It doesn't matter whether the intent behind the behaviour was good or bad; if the behaviour violates the policy, it is blocked. All of this happens silently and automatically without involving the user in decisions that they might not be qualified to make. This makes AppGuard suited to inexperienced users, as well as to those experienced users who just want their security apps to run quietly in the background without bothering them.

The problem with blacklisting, where the aim is to classify an app as good or bad, is that it can never be totally reliable and mistakes can occur, by which time the system may have been compromised. Nonetheless, it is clearly necessary to determine the status of an application when installing something. Different methods of determining badness involve varying degrees of user involvement in the decision making process, so let's take a look at how other approaches handle this.

AV: AVs fully automate the process. A default-allow approach is used and the user only gets notified once the determination of badness has been made by the software. The only decision left to the user is whether to trust the AV's determination and what to do about it: ignore, delete, quarantine, repair, etc. Modern AVs typically use a combination of approaches, not just relying on signature detection but also taking into account behaviour, reputation, cloud-based statistical analysis, etc. This makes AVs especially suited to inexperienced users.

BB: Intelligent BBs such as ThreatFire partially automate the detection process, but not as much as an AV because they are predominantly or entirely behaviour based. Unlike classical HIPS that alerts on individual behavours, BBs have a judgement module that looks at combinations of behavours and scores them on a rating system. Only when the score exceeds a certain threshold will an alert be raised. It is then left to the user to interpret the result. BBs are rarely found as standalone applications these days, because this technology has been incorporated into the feature set of modern AVs.

HIPS: Classical HIPS typically alerts on a set of individual behaviours that it has been designed to monitor. It is left to the user to interpret the results. This requires a higher degree of knowledge and skill on the part of the user than an AV or BB, and may not be suited to inexperienced users. Classical HIPS programs typically incorporate whitelisting to reduce the number of alerts.

AE: Anti-executables are similar to classical HIPS, but with reduced monitoring capability, focusing more on preventing the execution of unknown programs, rather than monitoring their runtime behaviour. As an AE can usually be set to alert rather than automatically deny execution of programs not on its whitelist, it can still provide some additional protection when installing software. Anti-execution based on whitelisting is also very effective at preventing drive-by downloads.

Sandboxes: Application sandboxing and other kinds of virtualization also works automatically without requiring the user to make decisions about what to allow. The only restrictions on behaviour are those necessary to contain the application within the boundaries of the sandbox or virtualization layer. This provides the user with a means to run untrusted programs safely, but it is entirely up to the user to determine the status of the application. Without a blacklisting component, the sandboxing or virtualization application can't assist with the determination. Its role is solely to isolate an untrusted application from the real system.

It is highly recommended to supplement AppGuard with at least one other of these alternative approaches.

You don't need to. A drive-by download is something that takes place without the user having deliberately initiated the action. AppGuard is particularly effective at preventing drive-by downloads from executing.

 

Good idea!

 

We're hoping to improve this in the future. One thing that we're experimenting with is to have a few new flags in the trusted publisher policy:

• Inherit: In the medium protection level, if this flag is set, and a trusted publisher app launched from user-space launches another user-space application, the child user-space application will inherit the trusted publisher policy (instead of the user-space policy) even if it is not digitally signed.
• Install: In the medium protection level, if this flag is set, and a trusted publisher app is launched from user-space, AppGuard will automatically switch to Install Protection Level.

Of course this only helps with trusted publisher apps located in user-space.

For user-space apps not published by a trusted publisher, we are considering popping up a dialog letting the user know that AppGuard blocked it and remind them to set the protection level to Install.

 

Ok, big thanks.
Does AppGuard also block dll.injections and similar attacks?
I don't think so-isn't that firewall function?

Also, what does AppGuard not block than?

 

No worries. I didn't think it was gruff.

 

I think that it's better that Barb_C answers this.