AppGuard 4.x 32/64 Bit - Releases

Appguard was mostly a corporation-oriented software, and we all knows that most corporations runs Windows in admin account

 

That's a shame, doesn't other people configure AppGuard to there requirements and want to backup those alterations?

Don't they have an IT department?

 

We are beta testers here at Wilders. Most of what we recommend is considered for all versions.

I am not sure, but I don't think BRN runs an official Enterprise beta testing program.

In fact, AppGuard Enterprise is being updated now - almost finished.

IT Admins don't have time for beta testing...

 

ok not sure this is where this post should go but since AppGuard deals with PowerShell I am posting here. if it needs to be moved, please do so.
ok ms started installing pester on win 10. it is open source. I am wondering why? what normal home user would need to or is it for devs of other software.
I have this blocked as of now but not sure if it should be. not sure but it almost looks like an update or something. I do know AppGuard didn't give any pop ups for it.

 

@boredog

"Pester is a test framework for PowerShell. It provides a language that allows you to define test cases, and the Invoke-Pester cmdlet to execute these tests and report the results."

https://blogs.technet.microsoft.com/heyscriptingguy/2015/12/14/what-is-pester-and-why-should-i-care/

If you have added powershell.exe and powershell_ise.exe to User Space (YES) and un-ticked powershell in Guarded Apps, then you don't need to worry about pester.

Besides, pester shouldn't ever execute on your system even if you do not add powershell and powershell_ise to User Space (YES).

 

I had added the 32 & 64 bit PowerShell to user space but had not unticked power shell in guarded apps. thanks for the tip. I had already read about it online but which dev is using them I wonder? I know someone tried. and they still reside in my program 86 folder. if they are not needed why don't we just delete them? anyway I could easily see a bad guy using them, can't you? and I am now talking about someone that is not using AppGuard.
also they must have tried to execute on my system because another security software blocked them.

 

Pester is a bat file located in C:\Programs (x86) - so it should not have been executed by anything that I am aware of. All the other pester files are powershell scripts (.ps1).

 

When running system in Shadow Defender's Shadow Mode, I have seen AppGuard tray icon context menu and pop-up mis-behave.

For example, during malware testing in Shadow Mode:

1. AG Tray Icon > Allow User Space Launches - Guarded

Sometimes you have to do the above 2X to enable

2. If AG blocks something, sometimes the pop-up will not appear

I have been running in Shadow Mode enough to confirm that this is, indeed, the case on my specific system.

So, just a FYI if you use Shadow Defender. It might happen on your system; it isn't an AG flaw.

 

Ok, I think I see the problem now. If the malware is able to create a new folder it can drop a file inside that folder because it's no longer a protected path. If it's new path is C:\newfolder\ then the path would have to be added to the user-space just like you have to do with the sandbox folder at C:\sandbox\ for Sandboxie. They will have to forbid folders from being created at some paths. I have not tested this yet, but i'm pretty sure it will work. Good find!

Edited 7/20 @ 3:18 pm

 

Informative, thanks for your reply.

 

Can anyone confirm these one more time ?

1. Add sc.exe to User Space (YES).

2. Open an elevated\Admin cmd console.

3. Type sc

4. sc.exe might or might not run.

I am interested if anyone can get either sc.exe to run in Admin cmd console while it is in User Space (YES).

I am trying to pin this one down.

 

In my test sc.exe was stopped:

Code:

07/21/16 20:21:00 Prevented process <sc.exe> from launching from <\Device\HarddiskVolume1\windows\system32>.

Windows 8.1 Enterprise x64
Admin acc.

 

Hi hjlbx I have carry out your request and followed your instructions to the letter,

sc - runs when using the following - when added to userspace YES c:\windows\*\sc.exe

I removed c:\windows\*\sc.exe from userspace Yes

Then added to user space YES :-

c:\windows\system32\sc.exe

c:\windows\syswow64\sc.exe

sc.exe - blocked - Access is denied - when full path is added. Regardless whether you are in root c:\, c:\windows\system32 or c:\windows\syswow64

I think something is wrong when replacing the fullpath with wildcard's.

 

Thanks mate.

Sometimes it will be blocked by AG other times it will not.

I cannot isolate why it is happening.

Right now, I cannot get sc.exe to run in Admin cmd console; "Access is Denied" + AG pop-up, toaster, and logged.

Flaking out on me ! ... AG being flaky sometimes !!! Errrr....

 

What OS ?

What account - limited Admin ?

 

windows 10 pro 64bit - standard user account, no problem anytime!

I believe there is an issue with using wildcards instead of the full path.

When you add c:\windows\*\sc.exe to user space YES

sometimes sc.exe gets blocked when you go to c:\windows\syswow64

Sc.exe runs in root c:\ or c:\windows\system32

Very strange indeed

Don't have this problem if you enter the full path in User Space YES

c:\windows\system32\sc.exe
c:\windows\syswow64\sc.exe

 

100% blocked.

 

Thanks guys -- this one has me vexed. Quirky behavior.

 

Q: trying to launch Power Shell (as test) from W10 All apps menu. AG throws similar toaster with Guarded Power Shell or User Space Power Shell. Curious for help understanding why User Space Power Shell was offered as better. Thanks

 

AppGuard is blocking the execution of the User Space powershell scripts:

07/22/16 23:37:27 Prevented process <microsoft.powershell_profile.ps1 | c:\windows\system32\windowspowershell\v1.0\powershell.exe> from launching from <c:\users\hjlbx\documents\windowspowershell>.
07/22/16 23:37:27 Prevented process <profile.ps1 | c:\windows\system32\windowspowershell\v1.0\powershell.exe> from launching from <c:\users\hjlbx\documents\windowspowershell>.
07/22/16 23:37:26 Prevented process <kmcnvucv.z3n.ps1 | c:\windows\system32\windowspowershell\v1.0\powershell.exe> from launching from <c:\users\hjlbx\appdata\local\temp>.

* * * * *

• %UserProfile%\Documents\WindowsPowerShell\profile.ps1This is for the current user only and all shells.
• %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1This is for the current user only and only for the Microsoft.PowerShell shell.
• kmcnvucv.z3n.ps1 - I'm not sure what that script does specifically.

These powershell scripts are to customize - for example - the appearance of the powershell console among quite a few other things like aliases and snap-ins. The general concept is the same as user profiles for browsers.

Basically, blocking those scripts just means that you cannot edit the default powershell profile - unless you exclude them from User Space. A user would also need to change the default Windows script execution policy for powershell to unrestricted.

Powershell and powershell_ise can be abused by malware and exploits; if not needed, both should be moved to User Space (YES).

 

Okay, so default Guarded Power Shell + User Space (Yes) Power Shell. And User Space (Yes) serves as a layer of protection if Power Shell is not needed. I'm sure not calling Power Shell as normal activity.

 

If you add powershell to User Space (YES), then don't forget to un-tick it in the Guarded Apps list. The Guarded Apps list takes precedence over User Space (YES).

 

it takes precedence I unticked it now...

And after powershell is blocked i noticed this:
07/23/16 12:54:52 Prevented process <Windows PowerShell> from writing to <c:\%programdata%\microsoft\windows\start menu\programs\system tools\windows powershell.lnk>.

= it should be c:\programdata\ not c:\%programdata%\

 

Guarded Apps takes precedence over User Space (Yes). That's why AG default is Guarded...? Maybe, a usability trade off for new AG user.

 

Typical user does not need powershell and powershell_ise; they both should be moved to User Space (YES).