AppGuard 4.x 32/64 Bit - Releases

I B typical then. Okay, so going forward. I'll appreciate that "move", means moving. I was thinking "move" as an addition to default vs in lieu of default. Thanks!

 

Can you give steps to replicate ? On W10 I tried, but cannot; I might be missing step(s). Did you just add powershell to User Space (YES) and un-tick in Guarded Apps list ? Thanks...

 

Looks like
wusa.exe
msiexec.exe
are missing from the original list - should these now be removed from User Space = Yes?

Also, Ihave identified the following as new ...
*mrsa.exe (I don't have this one)
*bcdboot.exe
*bootcfg.exe
*bootim.exe
*bootsect.exe
*ByteCodeGenerator.exe
*debug.exe (I don't have this either)
*regini.exe
*RunLegacyCPLElevated.exe
*UserAccountControlSettings.exe
Are the 'boot' entries safe to add to User Space = Yes?

 

powershell and powershell_ise can be abused by fileless malware (like Poweliks, Kovter, etc) and by malicious macros to download malware to system - plus other malware. Powershell was added to Guarded Apps because it prevents malicious *.lnk files that can abuse it to download malware and persist on system.

AppGuard blocks the creation of the registry run key for Poweliks, Kovter, etc - but does not block the creation of the encrypted keys containing the malware themselves. Blocking the registry run key is sufficient to prevent a persistent system infection - but I have already reported this to BRN and suggested powershell be moved to User Space (YES) per default policy. The easiest way to prevent the encrypted key creation is to move powershell and powershell_ise to User Space (YES). The likelihood of a fileless infection is next to nothing from an exploit using a fully up-to-date browser.

In fact, it is quite easy just to uninstall powershell via Control Panel > Programs and Features > Add\Remove Windows Features. Powershell is a menace.

If you have an office suite in which you can enable macros, it is best policy to keep macros disabled by default. Also, if powershell is in User Space (YES) that is one less avenue available to malicious macros to download malware to system. IF you don't have an office suite installed or an unpaid version in which macros cannot be enabled, then you don't need to worry about malicious macros. That being said, if malware is downloaded to system it will be launched Guarded. You should also have added any office suite to Guarded Apps list; Microsoft Office are auto-added by AppGuard.

 

I have kept both wusa.exe and msiexec.exe in User Space (YES). Malware most definitely abuses msiexec.exe.

I have added all the others - except runonce.exe (AG GUI needs it to start) - to User Space (YES).

Not one block yet.

However, just because I get no blocks of any of the vulnerable processes added to User Space (YES) on my system does not mean that will be the case on anyone else's system -- because it is dependent upon what softs are installed. So, in other words, on my system I don't have any softs installed that call any of the vulnerable processes.


* * * * *

The whole concept behind adding all these processes to User Space (YES) is to protect your system when:

1. An application is exploited and there is an escalation-of-privilege

2. You use "Allow User Space Launches - Guarded\Un-Guarded" - especially unknown\untrusted files

1 = unlikely; so the list is "just-in-case" insurance in case of a true zero-day exploit
2 = if you never use these in tray icon, then you still have "just-in-case" protection from 1

* * * * *

If you are just downloading and opening PDFs and docs while always keeping AG in either Lock Down or Protected mode, then there is little chance the system will be compromised.

 

Powershell = Guarded App (launched from system space via cmd.exe)
(if it's added to User Space or not = same result)

a) execute cmd.exe

b) go to a system space-directory

c1) Launch Powershell
07/23/16 16:25:01 Prevented process <profile.ps1 | c:\windows\system32\windowspowershell\v1.0\powershell.exe> from launching from <c:\users\xxxx\documents\windowspowershell>.
07/23/16 16:25:01 Prevented process <Windows PowerShell> from writing to <c:\%programdata%\microsoft\windows\start menu\programs\system tools\windows powershell.lnk>.

c2) powershell launched from c:\system-space\1\2\
07/23/16 16:39:55 Prevented process <microsoft.powershell_profile.ps1 | c:\windows\system32\windowspowershell\v1.0\powershell.exe> from launching from <c:\users\xxxx\documents\windowspowershell>.
07/23/16 16:39:55 Prevented process <profile.ps1 | c:\windows\system32\windowspowershell\v1.0\powershell.exe> from launching from <c:\users\xxxx\documents\windowspowershell>.
07/23/16 16:39:55 Prevented process <Windows PowerShell> from writing to <c:\system-space\1\2\%programdata%\microsoft\windows\start menu\programs\system tools\windows powershell.lnk>.

d) now %programdata% can be seen in the path.

 

I forgot to ask, which OS - 7 ?

You created custom system space directory in file system: c:\system-space\1\2 ?

On W10 I don't get the write block to programdata - whether I execute from either system32 or sysWOW64 - but I get the other block events.

LOL... it is block event wording typo -- which there have been at least a few confirmed.

 

Much appreciation and respect. Thanks!!

 

OS: Win 8 x64
You have a much newer OS and a newer Powershell-version (v5.0). I have v2.0 (from 2012)
And even if i start Powershell from the start-menu i get this %programdata% in the path.

However, i unticked it now at Guarded Apps and added it to User-Space (Include=Yes)

Problem solved

 

Hmm, I have W10 (upgrade from 8.1) and path reads v1.0 http://s31.postimg.org/a7b3m867v/screenshot.png

 

Powershell is a menace. You did right...

 

Powershell has changed over the years with the various OSes and powershell version updates.

Yours is correct for your OS and powershell version.

If you want to know what PowerShell version you are using, you can run the $PSVersionTable command in PowerShell.

PS C:\> $PSVersionTable

Name Value
---- -----
PSVersion 4.0
WSManStackVersion 3.0
SerializationVersion 1.1.0.1
CLRVersion 4.0.30319.34014
BuildVersion 6.3.9600.17090
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion 2.2

For Win 8\8.1 and 10 correct current version is 5.0.X.

 

Thank you @hjlbx for the great tip on how Guarded Apps list take precedence over User Space (YES),

I have now unticked Powershell in the Guarded Apps list.
Also as I have c:\windows\*\regsvr32.exe added to User Space (YES) I have also unticked Microsoft Register Server (c:\windows\system32\regsvr32.exe) in the Guarded Apps list.

 

regsvr32.exe in User Space (YES) is a good move... it is needed quite infrequently.

 

I wish to thank you @hjlbx for providing your detailed Appguard config in this thread.

I can also say that I have not had any issues what so ever!!!!

I have only needed regsvr32.exe when installing a program which requires a driver/service.

 

+1

 

Okay, I saw v1 #5710 and thought v1.
PSVersion 5.0.10586.494
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.10586.494
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

 

These different powershell versions are confusing.
If i go to "Windows Features" i see: Powershell 2.0
The Pathname says = v1.0
$PSVersiontable = v3.0

Ok, now i know that i have 3.0, not 2.0 as i said before

 

Q: is the wildcard (*) bug for both User Space and Power Apps still fixed.
Or, better just to do full path.

 

Hi @bjm_ There is definitely a bug with using wildcards in User Space, (I believe hh.exe can cause issues) - not correct see below , but the rest i believe are ok. Please follow @hjlbx recommended vulnerable list to enter into AppGuard user space (YES)

I advise you try to execute them once you have entered them into User Space (YES). If issue occurs with any of them, change the ones affected to full path.

I haven't added anything to Power Apps so I don't know.

 

There is still a "long-time bug" with using wildcards for User Space.
But i don't have problems with this kind of rules: c:\windows\*\bitsadmin.exe

 

Hi @mood, out of interest do you have issues with hh.exe not being blocked at times, when using wildcards? Ie c:\windows\*\hh.exe

 

Execution of hh.exe is not a wildcard bug.

 

with c:\windows\*\hh.exe you're not "catching" c:\windows\hh.exe
Add an additional c:\windows\hh.exe rule.

 

Sorry @hjlbx, thanks for the correction, made an incorrect assumption, please see reason below

Thank you @mood, no wonder, I assumed that it was wildcard bug