AppGuard 3.x 32/64 Bit

I took the risk and installed EMET 3.5 TP yesterday and indeed it works like charm together with AG
Anyway, thanks for answer. Have a nice day!

 

I gather that you were running a browser sandboxed. Unless you observed a loss of functionality with the browser, then those events can be ignored.

 

Yes. Anything launched or loaded by a guarded application will inherit the Guard policy from the parent app. This concept of inheritance as it applies to application security policy is a Blue Ridge patent.

 

I'd recommend "ignoring" this message. Refer to the help topic on the AppGuard User Interface about how to ignore a message.

 

I'm sorry, but I can't answer your question about whether the scan is genuine or false, but I can explain why AppGuard was blocking some of the scan actions.

The reason that you are seeing these blocking messages is because when you launched the program, it was Guarded. You may want to consider installing this program into the Program Files directory. In that case it will not be Guarded unless you explicitly add it to the AppGuard Guard list (which I am not recommending).

If you want to leave the program in user-space and if you trust this program, you could designate it as a power application or launch it as unGuarded.

Also, if you do launch a user-space program as unGuarded, when the suspension timeout expires, the application will become Guarded.

 

Thanks for replying Barb. Good to have a Q & A person on deck. I want uninstall AppGuard on our older PC. Do I just use Add/Remove or do you have an uninstall tool?

 

Just use Add/Remove! Why are you uninstalling?

 

Thanks.

I'm trying to find the source of very regular annoying alarms in the form of chimes. I'm deleting programs 1x1 in a 'witch hunt' for the culprit. It's AG's turn to take the 'witness stand'.

 

AppGuard does not have any chimes!

 

Hi Barb_C,

Did you see my post here:
https://www.wilderssecurity.com/showpost.php?p=2133316&postcount=1763 ?
I am asking as the release of Windows 8 is now upon us....

 

Though it does have enough bells and whistles for most users

 

Don't worry. Appguard wasn't lynched. I found the culprit. But these notices are a bit of a worry to me. I haven't a clue what they mean. e.g. - a bit scary to a novice like me as it says Microsoft(C): I am convinced they shouldn't be blocked but I dont know what to do.

.

 

In the near future, I am thinking about adding a Paid VPN Service to my setup. Please list your VPN Service company name along with any AppGuard compatibility settings that you had to make.

Thanks in Advance.

 

They mean that Microsoft(C) Register Server is attempting to write to a part of the registry that is protected by AppGuard in respect of guarded applications. Unless you have evidence that something isn't working properly, you can ignore them. If you really need to allow this, remove Microsoft(C) Register Server from the guarded applications list.

 

Thanks 4 that reassurance Pegr.

 

You're welcome.

 

Hi pegr,

Is MS register server not responsible for registering DLL's? If so is it a good idea to run it unguarded? Would that not potentiality allow a process to load and execute a malicious DLL?

Alternate views welcomed as always.

Thanks

 

I think this Microsoft(C) Register Server process -
10/26/12 20:13:32 Prevented <Microsoft(C) Register Server> from writing to <\registry\machine\software\classes\wow6432node\clsid\{f414c262-6ac0-11cf-b6d1-00aa00bbbb58}\inprocserver32>.

..... is genuine because the system is only a week old & MS is maybe checking I'm genuine. I'd let it through then block it again in a day or two but I cannot find "<Microsoft(C) Register Server> through AG's "Add program" tool & so i fear I might mess up.

 

Hi Chris,

Yes, it is responsible for registering DLLs and could therefore potentially be used to register a malicious DLL. As you correctly state, this is why it isn't a good idea to run it unguarded unless running it guarded is preventing the system from functioning correctly.

As a general principle, AppGuard exceptions should not be made automatically in response to blocked events unless the blocking is preventing something from working properly. Most blocked events are harmless and can be ignored. Any time an AppGuard exception is made to overcome a blocked event, AppGuard protection is potentially weakened a little with a corresponding increase in risk.

I wasn't advocating removing Microsoft(C) Register Server from the guarded applications list; I was simply explaining that one of the protections that is applied to guarded applications is the blocking of writes to certain parts of the registry. The intended purpose was solely to help AaLF get a better understanding of what AppGuard does and how it works.

Kind regards

 

I think that we will be releasing an update to 3.4 by the end of the day. It will address the MBRGuard problem, but is still considered beta for Windows 8. There will be NO need to update unless you are running on Windows 8. The only change to the installation is that an additional file has been digitally signed. For that reason we will not be updating the "phone home" version number so that AppGuard will not announce that an update is available. For those that are using Windows 8, we recommend uninstalling the previous version, rebooting and installing the newest version. I will make an announcement when it is available on our web site.

 

The MS Register Server process is a genuine part of the Windows operating system. It is, as Chris said, responsible for registering DLLs. You don't need to use AppGuard's Add Program feature because it was automatically added to the guarded applications list as part of the original AppGuard installation. If you need to remove it from the guarded applications list (not recommended) just uncheck the checkbox.

It is a known good application but the reason it needs to be guarded is because of its potential for misuse by malware, which makes it unsafe if given full access rights to the registry. This illustrates a difference between a policy restriction application like AppGuard and a classical HIPS or anti-executable. Classical HIPS/AE denies the unknown; policy restriction restricts the unsafe. AppGuard is based on the concept of a trusted enclave as I explained in a previous post. Processes that should be guarded include applications that are Internet facing and applications that load documents that can contain embedded executable code.

 

I think that PEGR and Chris both addressed your question, but I wanted to "chime" in (pun intended) as well to let you know that I agree with both of them. Although regsvr32.exe is a Microsoft product it can be used by bad guys to install malicious software and that is why it is Guarded in all protection levels (except for "Install" and "Off).

 

Thought so, just checking

 

Thanks 4 those responses. I may hold the outdated concept that "it" is a nominative pronoun rather than jargon but even I can see & appreciate the beauty of appGuard.

Be nice if in the future one could right-click on an alert line and get choices such as "allow once".

 

Many of the protections can be temporarily suspended from the context menu accessed by a right-click from the AppGuard system tray icon (e.g. lowering the protection level to "Install" in order to install or update software, suspending guarded execution, etc). This still has to be done before a blocked event occurs though; it is by design and is one of the ways in which AppGuard differs from a classical HIPS or anti-executable.

A classical HIPS/AE in interactive mode would display a prompt that leaves the decision to block or allow with the user. AppGuard does not do this: it automatically blocks any potentially dangerous behaviour that could compromise the security of the trusted enclave. This is similar to the way a classical HIPS functions in policy mode. The purpose of the alert is to notify the user of the action that AppGuard has taken after the behaviour has already been blocked.

For expert users who like to have full control over the operation of their system, and who have the required level of expertise to make correct security decisions, a classical HIPS/AE may be preferred. For average users who may lack the necessary expertise, the policy restriction approach is preferable because it removes the need for user involvement in decision making. Automatic policy restriction is also better for those expert users who, whilst having the necessary level of expertise to make security decisions, prefer their security programs to operate quietly in the background without them having to get involved in manually shaping the policy.

Most blocked events are harmless and can be ignored. On the rare occasions that an AppGuard blocked event stops something from working properly, there is sufficient customization available within the program to overcome this.