AppGuard 4.x 32/64 Bit - Releases

I'm native polish speaker

 

That's good to know. You may be the Rosetta Stone we need! Lol

 

Is this the Polish forum the AG bypass was Published in? https://safegroup.pl/ I think ichito from Wilders is active on that forum. He may help run that forum for all I know. I think Polish is his native language as well.

 

Okay, so I did a quick test of the malware shown in the video. The lnk file uses power shell to download an executable to c:\windows\temp and runs it from there. The key here is that the user had to click on the .lnk file (which would require some social engineering to accomplish). You might say, well malware could launch the file. And it can but if you tried to launch it as if it was malware entering your system (that is by using a Guarded app to launch it), then AppGuard will thwart the attack! What ever is used to launch the lnk file will be Guarded and so will PowerShell by virtue of our lovely inheritance patent. These were the blocks that occurred when trying to launch the lnk file from cmd.exe.


And the attack failed!

Note AppGuard was running in the default protection level and with the default policy. So our conclusion is that this is not a true bypass of AppGuard because it required the user to click on the lnk file (requiring social engineering). That being said, I see no reason why we shouldn't add Powershell to our policy and go with the belt and suspenders approach to security.

If someone can come up with a way that the lnk file could be executed through an unGuarded application without the user doing something stupid, by all means please challenge our findings. Remember if a Guarded Application is in the process tree, inheritance will come into play and AppGuard will be victorious!!!!

Edited slightly to discuss social engineering: There have been many comments regarding my comment about social engineering not being a valid bypass of AppGuard. Social Engineering is definitely a problem and we do protect against the most prevalent method (email attachments) of social engineering.

 

Yep.

 

Adding cscript.exe and wscript.exe would add additional security, but it might break something as well. Right now we're just blocking their associated files from being launched from user-space. If you Guarded cscript.exe for instance, we would prevent any script that is executed with cscript.exe from writing to protected resources. So even if you allowed a script to launch (or let's say a script from system space is launched with cscript.exe), that script would not be able to write to c:\windows or c:\program files etc. That may cause some side-effects. Remember our goal is to try to be as unobtrusive as possible but at the same time provide extraordinary protection.

 

Social Engineering is probably the most widely used method of infection so it should be treated as a serious threat IMO. If I remember correctly Sony can vouch for that! It's usually the easiest way to infiltrate most networks. All the hacker has to do is convince some unsuspecting employee to click on a bad email attachment.

Edited 4/5 @ 6:18
People downloading torrents will sometimes find these kind of goodies in their download.

 

I guarded cscript, and wscript for years without any problems i'm aware of. All similar security applications i'm aware of either block, or restrict them. (SecureApluse, ERP, VoodooShield, etc..).

 

Is this correct way of adding powershell,exe.

 

I have always added powershell_ise.exe also.

 

God love ya... I wish I could speak Polish.

 

Another vulnerable application that should be at least Guarded is mshta.exe

 

Isn't it added by adding the whole powershell folder to User Space? or do you have each only as Guarded App.

 

Good grief... there is a rather large list. About 30 to 50 (I haven't counted the list) processes shipped with Windows are abused by malwares.

I test malwares regularly. So I can tell you that cmd.exe, vbc.exe, RegAsm.exe, wscript.exe, cscript.exe, PresentationHost.exe, powershell.exe, powershell_ise.exe, wusc.exe, wimc.exe, msiexec.exe, etc - they are all a risk.

 

To effectively add process to User Space on 64 bit system with sysnative, you must add both the process' System32 and SysWOW64 file paths.

For NET assemblies, you must add both the System32 and SysWOW64 file path + each version of NET Framework - e.g. 1.0, 2.5, 3.5, 4.5, etc.

So, for example, with vbc.exe you need to add framework 32 and framework 64 for each version of NET Framework installed on your system as you will find vbc.exe included in multiple versions of NET Framework.

 

Okay thanks.

 

I have a very large list of them I have been using for some time now. It's easier to add them in Bouncer though if they can be blocked instead of Guarded because adding something like vbc.exe to the policy will block it everywhere regardless of path. In AG you would have to add it from several different paths to cover it, and in Bouncer you only have to add it once. My User-Space List in AG is rather long though.

 

This is one of my primary complaints about AG. I hope in some future release they make it more efficient.

 

I requested an option to block by process name regardless of path, but it never made the cut. Maybe next time.

 

By hash would be better, but then they would have to implement some type of "File has changed" Allow|Block alert.

I think they won't do such a thing because of the whole prompt thing...

 

I also recommended by hash when I recommended by process name. I think the option by process name, and hash should be given together. The user could use either one, or both. The hash for all instances of an executable with the same name is not always the same though. I have not seen hashes change very often, but i'm sure we can figure out a good solution.

 

i still get this alert (see attached file):

- AG in Lockdown mode
- App is Ccleaner portable , located on D: partition (partition set as "user-space")
- App is able to run as guarded when i allow "user space launches - Guarded"

now the alert said "may not be protected" so do i conclude it is protected...?

 

@guest

I am able to run D:\CCleaner64.exe either as Guarded or UnGuarded - without any Error Message.

On my system, I don't see that message... AG giving different behaviors on different systems in this matter of non-system partitions.

However, if I run CCleaner Guarded from D:, then it cannot perform any Registry cleanup.

 

running Ccleaner is ok, it is when you add it to the guarded apps that you get the alert box.

 

So only if add to Guarded Apps tab ?