AppGuard 4.x 32/64 Bit - Releases

The only thing I do with HMP.A and AppGuard is to put CryptoGuard's folder into exception and User Space=Yes. I believe those have been the advice in the past.

 

In my case I only have the c:/windows/cryptoguard folder as exception Guarded Apps>Settings.

 

Me too, i just put HMPA in Power Apps to avoid potential (and future) conflicts.

 

The User Space = Yes is only to plug the hole introduced because of the exception rule. At least, that's what I understood.

 

OK, I don't remember that recommendation. I haven't had issues yet, but then I've not been infected either!

 

Yep I exclude all other security softs in each security soft. In the case of HMPA I trust you, it probably is a good thing to put in Power Apps.

 

Don't add HMP.A to Power Apps. It isn't necessary.

 

C:\Windows\CryptoGuard folder should be made an Exception folder on the Guarded Apps tab > Settings > Add to the list and set it to Read\Write.

It is so backup files can be written to this System Space folder (C:\Windows\Cryptoguard) when HMP.A detects a file-encrypting infection. For HMP.A technicals ask Mark or Erik.

 

It isn't necessary. It is not recommended. Programs should be added to Power Apps only in the case of breakage that cannot be solved any other way.

If you don't understand why then I will re-explain it.

 

@Lockdown "of course" is correct. You do not need to place an application in Power Apps unless something is being blocked that can not other wise be taken care of "which it states this in the Power Apps section".

An example, I'm running Norton Security and Norton Wifi Privacy beside Appguard. Both NS and NWP are running just fine with no other exceptions needed. Norton Power Eraser on the other hand "built into NS" was blocked while trying to run, I took care of this by placing it in User Space. I have absolutely not had one application break to the point of needing Power Apps yet.

 

It's amazing, you still miss the point. I simply don't trust any app, so I will always need HIPS. It's mostly Memory Guard that makes AG interesting to me, I think more HIPS should offer this. Simply auto-block memory reading and writing and you probably don't have to worry about code injection attacks anymore.

I do the same, I block all processes that are not white-listed with EXE Radar, the goal of this approach is to block malware delivered via exploits. But when I do decide to install some app, I still need HIPS to monitor for suspicious behavior. But not everyone sees the need for this, depends on how paranoid someone is.

This is the stuff that gives me a headache.

 

IMO, security does not get any better then Appguard. Having Lockdown here to help guide with his extensive knowledge is a huge plus.

 

You miss the whole point of security, sorry , i will be rude, but i can do nothing for stupid paranoia, if you trust nothing stop using a computer and go back to paper & pen.
And did you ask yourself maybe your favorite HIPS soft has a backdoor and can compromise you? maybe hit tells you only what you need to see, and hide what you shouldn't see.? how can you trust your security software but not the rest, did you code it, or analyze every lines of it?

ERP in lockdown mode is basically what Appguard does, but unlike AG , ERP doesn't monitor dlls/drivers. However SoB does it.

do you know what is a hash checksum? what is Sha256 or 512? how to compare checksums? if yes you won't need an HIPS because you would know that the apps is legit by just comparing its hash.
The vendor gives the hash > you compare it to the one of the installer you just downloaded > if equal = safe , if different = suspicious. I don't need an HIPS mate, i need only the source hash.

 

I'm afraid as usual you missed the point again, like I said you're brain is wired in a different way. Who are you to say that you don't need behavioral monitoring? It's a matter of preference, if you want to blindly trust all the apps that you run/install, that's cool with me. And of course you will have to trust your security tools, even though I also monitor them for unnecessary outbound connections.

And I'm afraid a "hash checksum" doesn't tell anything about if some app is safe. You must have a short memory, I already explained that because of certain behavior I chose not to use "legit tools" like Maxthon and EagleGet. But anyway this is the AG topic, so enough about this.

I wanted to know if Memory Guard could protect against Dridex. I'm not refusing to accept anything, I'm just saying that I prefer ERP's approach when it comes to AE, much simpler. But Memory Guard is interesting to me, this is something that I miss in my setup. And I don't need reHIPS, I'm already using SpyShelter remember?

 

The underlined should be self explanatory, but just in case, in simple terms "do not open spam email"....

Memory Guard with memory read/write protection is one of the main features I love about this product. I can place applications such as VMware in Guarded apps, this helps block against potential exploits via the VM while I'm testing ect.

Seriously, you do not need all those applications, Appguard set correctly will lock you down. It is a matter of preference using those that you are though, and your system.

 

I suspect it will NOT block Atom Bombing as described in the initial report, but we will not know until I can obtain a functioning sample.

So the honest answer without creating any paranoid-user read-between-the-lines-and-make-up-nonsense scuzzlebutt is "I don't know."

I should also point out that AppGuard will more than likely block the execution of the surreptitiously downloaded Dridex. I say should because it depends upon the method used to execute it.

If you think that AppGuard's protections are guaranteed to prevent a User Session infection when a user launches unknown files, then you are mistaken. The only thing with a virtual guarantee is not to download and launch unknown files. If you don't trust a file 100 %, then don't execute it on your system. If you are paranoid that something like a Chrome or Firefox installer or Windows Update .msi and all files of that class might be infected, then you really should talk to someone about that... or just use virtualization or rollback softs. The first suggestion is preferable. Once that is sorted out, then turn to virtualization and rollback softs.

And a final, and important point, is that program installers cannot be launched under AppGuard protections - otherwise they will fail to install. Well, you could do it - but what's the point since the install will fail. You can do it with portable apps.

For many malware, if you have already installed it on your system, then it is too little, too late even if the program is added to the Guarded Apps list.

The whole foundation of AppGuard's protections are based upon:

1. Known vulnerable programs are added to the Guarded Apps list
2. Block anything newly introduced to the system
3. The user is highly confident that a program to be launched or installed is safe

 

Short answer=the atom table aspect will not be blocked by AG but the ROP stage *will/should* be. So yes, AG has protections vs this exploit if the targeted [or exploited] app is guarded or is a child of such a guarded app under current attack vectors. These could also be argued for with the included AE stage as already mentioned but I was actually responding with just memprotect in mind. Yet once again that's only IF the BFE is 'properly registered' to handle the location said app runs from, otherwise AG remains oblivious (as does the BFE) and you can't 'depend' on any protection from things running in such areas. Thankfully these areas are few and far between.

So congrats Blue-Planet, you've purchased a promising 'but sadly under-kept' technology with a bit much remaining in the way of potential loopholes...
doh, I suspect you didn't know that before the payout?!

//unrelated and oh what in the world could these be?
000083C404B8010000008B
000083C404B801000000E9
C6470800B801000000E9
Nothing, because AG is ~SO PERFECT~ in all respects. They're just here for FUN of course and they have no meaning at all *cough*!

 

Maybe you right, i don't see how , maybe you PM me and describe me. hahahaha

It is not about blindly trust or not , it is about knowledge of the said soft. And i exteremly rarely uses obscure softs from nowhere.
what surprise me is that you say "I simply don't trust any app,i always need an HIPS" , i wonder how you can stay on Windows with that statement.

I tried maxthon long time ago but nor eagleget , what malware-kind of behavior they do?
I talk about security only, about if a program is a malware or not; i don't talk about privacy-related things which is another story.

 

Maxthon modified browser hooks, the same stuff that banking trojans are doing, and EagleGet installs a driver for no good reason. And HIPS/BB is the reason why I can stay on Windows, because I can control app behavior in to detail. That's why I say there is no true security on Android, you just don't have a clue what those apps are up to.

Yes, if I could disable the AE I would probably buy it. Too bad that MemProtect doesn't come with a userfriendly GUI.

 

OK, so that part I did miss. AG won't auto-protect against possible malicious actions from apps during install, because you have to completely disable AG? I thought that it would always protect Guarded Apps. My approach is simple, if you're not white-listed, you can't run, EXE Radar takes care of this. Exploitable apps run sandboxed, so if AE is bypassed, Sandboxie takes care of that. If I install or run software I "semi-trust" such an app, behavior is still monitored with SpyShelter. If I see stuff that I don't like, I block and terminate it.

 

This doesn't look like fun, if you always have fear to install a program

 

AppGuard protections block installations. That is one of its primary methods of protecting the system. To install any program, AppGuard protections must be set to Allow Installs or OFF. That's why we give the general recommendation that users should have an antivirus installed - and we go no further than that basic recommendation as covering the topic extensively opens a can of worms and invariably leads to debates that we do not want. It's up to the user to decide for themselves how to configure their systems. "To each his own..."

Installations are not Guarded otherwise they would be blocked from writing to protected areas of the registry and System Space. In a nutshell, the installer would be prevented from installing the program. The program might still launch if the installer is run Guarded, but when you reboot the system, the program will be "inert" on the system as it will not auto-start.

99.999 % of HIPS users cannot differentiate between a malicious install from a safe install based solely on the HIPS alerts themselves. On top of it, many users will select the installation option in the lower right corner of the SpyShelter alert which creates allow rules without any user intervention or further alerts. The one advantage that SpyShelter has over other HIPS is the file query that is available in the alerts. However, it is worthless against FUD stuff and if the user doesn't use it.

Even if a user does suspect a malicious install or run, and decides to terminate the run sequence in one of the alerts, it could very well be too little, too late. For a single example, once Cerber is launched, if the user does not terminate the run before a certain point in the run sequence using SpyShelter, their system is going to be encrypted.

So it all comes back to the same principles:

1. Don't download and install unknown\untrusted files in the first place
2. Block whatever is newly introduced to the system; if it is not allowed, then it is blocked

A. Clean install the OS
B. Install required drivers and desired softs using known safe installers
C. Install AppGuard
D. Lockdown the system
E. Keeping the system static is the safest option
F. If you are going to install a new soft, verify that the installer is safe

The typical advanced AppGuard user is not a "user that wants to use stuff." Meaning they don't do all the stuff that a typical home user does. You could say they do the exact opposite for the most part.

A certain mentality and set of user behaviors are required to successfully protect a system using AppGuard since it is default-deny.

I will point out the obvious - a HIPS is essentially default-deny if you select block\terminate in the very first execution alert. That would be my course of action for any unexpected alert that is not connected in any way to a program that is already installed on the system. For vulnerable programs like browsers, office suite programs, etc I pay particularly close attention to any alerts - always at the ready to select "block\terminate."