AppGuard 4.x 32/64 Bit - Releases

It's possible I missed it or uploaded a different version. I have about 20 different versions of hardened xmls.

 

Lockdown

Could you please look at my last post #6 in this thread? https://www.wilderssecurity.com/thr...ter-in-addition-to-locky.391770/#post-2650270

Also Was not aware of the downloadable hardened xmls. do these work with all versions of AG

Thanks

 

If you add powershell.exe to User Space (Include=YES) and add it to Guarded Apps (entry is checked), powershell.exe will not be prevented from launching.
You have to uncheck Powershell in Guarded Apps. That's the reason why it is unchecked in your setup.
Further information: #6653

Btw.: to have fewer User-Space entries and to simplify it a little, you can use wildcards:
C:\Windows\*\powershell.exe
C:\Windows\*\powershell_ise.exe

 

mood

I have it added to userspace yes and have it unchecked in guarded apps.

 

I replied in that thread. Add both wscript.exe and cscript.exe to Guarded Apps or disable them by adding to User Space (YES).

Any program in the Guarded Apps list must be unticked when you add it to User Space (YES); the Guarded Apps list takes precedence over the User Space list. Unticking a program "removes" it from the Guarded Apps list. That means if it is in User Space (YES), then it will be disabled from launching when unticked. If it isn't in User Space (YES), then it will be launched UnGuarded when unticked.

For a number of good reasons the hardened xml download link has been removed.

 

I guess this is because it became a 'support issue' for you.
For those who already have hardened their .xml via the various lists over time and subsequent discussions, and understand at least some of the consequences, I presume you would not advise to 'unharden' their existing .xml?
I remember your most recent advice was to experiment and learn. Which is only suitable for tinkerers, of which there are many here on Wilders
As you've said before, more or less vanilla AG, with some tweaks as discussed here, gives more than enough protection already for those who want a more more 'set and forget' solution.

 

The decision to take it down was simple. People were manually importing the hardened xml without knowing how to manually create the policies in the first place. Plus, they weren't thinking about what and why processes were added to User Space (YES) - even though a list has been repeatedly posted with explanations here and at MT. So, the hardened xml, while a convenience, defeats the greater purpose of people learning the protection concepts built-in to the hardened xml policies. The whole "plug-and-play" nature of it makes it too easy for users to "set-it-and-forget-it" and only show up here mostly when they question a block event.

So, basically, from a learning perspective, it was decided that making the hardened xml available did a did-service to some users. Building the hardened policy using the GUI on their own is of greater benefit to them.

I don't mind answering questions about block events, but I do get annoyed after I cover the same very closely related blocks over-and-over with the same user. An example, your browser process is Guarded - it cannot write to C:\Program Files !! After explaining something like this 5 or more times with someone, it's hard to be patient. However, as long as people ask questions I'll do my best to answer them. So fire away with the questions...

As I've stated repeatedly, the hardened xml is valuable in blocking a post-exploit run sequence at a point earlier in the run sequence - and also when someone runs a signed malware from User Space or an unsigned one using "Allow User Space Launches - Guarded." In the latter two cases, once again, the run sequence can potentially be broken.

Since Locked Down mode disables the Trusted Publisher List and will block both unsigned and signed malware, there is no absolute requirement to use the hardened xml. The hardened xml is mostly for a user SNAFU or an exploit. Even without the hardened xml, I have seen AppGuard block a nasty Internet Explorer exploit payload. So once again, the hardened xml is "overkill" protection. Using the hardened xml, the exploit run sequence would have just been blocked earlier.

Everybody can still tinker, they will just have to build their own hardened policies from the ground-up. That little bit of extra effort pays big dividends for the user.

Tinker = practice. Practice, practice, practice...

If the hardened xml works without any serious issue, then there is no need to return to the default AppGuard configuration.

 

Anyway when the next build will be released, the hardened xml , may won't be valid anymore.

learning Kung-fu and hiring a bodyguard isn't the same thing , i rather learn Kung-Fu instead of be dependent of something else.

 

Yes, once 5.X really starts to leave 4.X behind I am quite happy to start from scratch.

I like to think I have learned some kung-fu, having followed the discussion and tweaked from the outset, and not just 'hired the bodyguard' (imported the 'ready made' .xml).

 

@paulderdash i think you indeed learn some kung-fu moves

 

Users must do it themselves to learn.
And at least they must know the "basics":
what is happening after a process is being added to User Space with Include=YES, why can't a Guarded Process write to C:\Program Files\, etc.
(and reading of the help-file of course)
... before they want to do "advanced" things.

 

AppGuard is more complicated than some users think. There's a lot going on. It's important to understand about the policies and protections - and how it affects the system and shows up in the Activity Report. To learn the various settings needed for compatibility with other softs.

Can't learn it by importing a pre-made policy file. Even then, appropriate customization tweaks need to be made for the specific system. So they need to learn all this stuff. That's my take on it.

 

Just curious, does AppGuard 5.2.9.1 protect the MBR?

 

No. The MBR filtering was removed years ago. I know some people feel that it is needed, but in reality it doesn't add anything significant to overall security because AppGuard will prevent all system damage including MBR modification by blocking malicious file execution in the first place when protections are enabled.

If you must have MBR protection, then I suggest you take a look as Cisco Talos MBR Filter.

http://www.talosintelligence.com/mbrfilter/

It's a freeware MBR filtering driver. Just be aware that the uninstall instructions are poorly written. If you delete the key, then you will get a BSOD INACESSIBLE_BOOT_DEVICE.

Ask others who have uninstalled it. I believe @mood uses it.

 

If anyone sees AppGuard blocking a Guarded App from writing to C:\ProgramData, would you please post the logged Activity Report block events here ?

 

Bitsadmin.exe should be added to the Guarded Apps list or disabled by adding it to User Space (YES).

 

Jeff - Are there any other recommended tweaks for the average user. Here are my few from postings in this thread and your last post. I normally try and surf in locked down mode.

Added to Guarded Apps: Command Line Interface for MS Volume Shadow Copy Service, Magical Jelly Bean Keyfinder, 7-Zip, cscript.exe and wscript.exe and bitsadmin.exe

Added to User Space (“Yes”): Windows Powershell, Windows Powershell ISE (32 & 64 bit)(both unchecked in Guarded Apps)

Added exception folder (settings): C:\windows\cryptoguard (folder added by HitmanPro.Alert)

Added to Power Applications: HMP, HMPA, MBAM, Zemana AM Portable and Emsisoft IS

 

MBAM only using as an ondemand scanner all protections off and not running in backfground. Zemana is portable version so not running in background. EIS, AppGuard and HMPA running but very light.

 

Thank you for your answer and explanation Lockdown.

 

[QUOTE="Both it and cscript.exe should be added manually to Guarded Apps at this time or disable them by adding each to User Space (YES). .[/QUOTE]
I tried to add additionally SysWOW64 (cscript.exe and wscript.exe) ? They are missing after re-booting. Normal?
The 32 bit are still their.
Version 5.2.9.1

 

Better do this:
c:\windows\*\cscript.exe

Do that also with wscript.exe.

 

Under guarded apps and/or user space?

 

The SysWOW64-counterpart to System32 is not shown in the GUI but it is automatically protected.

 

In the User Space tab. But mood is probably correct, so I think you don't have to do anything else.

 

Thanks to both of you.

So should I take out the syswow64\ cscript.exe and wscript.exe out of user space?
Do I have to do that wild card thing?