AppGuard 4.x 32/64 Bit - Releases

I asked Barb about HTA files a while back, and she informed me AG blocks HTA files in the user-space in post #4881.

 

Worth noting that Kovter is not using a .hta file to trigger the execution of mshta.exe. The program is being directly started by wmiprvse.exe.

Speaking of .hta files, one easy way to shut them down is just change the file association as noted here: https://www.reddit.com/r/Malware/comments/4iqjdv/locky_being_distributed_as_hta_file_055_on/

 

hey @Barb_C did you forget about this? Or just consider it too big a challenge?

 

It does not really matter what Kovter executes in the run sequence. All that matters is that one of Kovter's parent processes is a Guarded App.

I will use the most commonly exploited program - the browser - as an example.

Browsers are Guarded Apps with limited file system and registry access rights.

(NOTE: All internet-facing and the most commonly exploited programs should be added to Guarded Apps - browsers, MS Office programs, Adobe products, etc. This topic deserves its own discussion - so I won't go into any further detail except for this basic statement.)

If a browser is exploited, then any of its child processes will inherit the same limited file system and registry access rights.

So, even if an exploited browser executes the white-listed processes from System Space, they will not be able to modify protected areas of the file system or registry.

In the case of Kovter, browser.exe → other_process.exe → mshta.exe → wmiprsve.exe → and so on will not be able to modify areas and objects protected by AppGuard's policies.

Even in the case of fileless malware that abuses NET Framework objects to run powershell scripts - even with powershell and powershell_ISE added to User Space (blocked from executing) - those NET Framework objects cannot modify the areas of the file system and registry protected by AppGuard.

If malware deposits malicious objects into User Space, then it cannot execute in Lock Down mode. It can execute in Protected mode, but only if it is digitally signed. And even if does execute, then it executes Guarded - with limited file system and registry access rights. Consequently, it cannot modify the system such that it will auto-start.

I have seen AppGuard protect the physical system against nasty exploits that abused System Space processes with my own eyes. While AppGuard will not prevent nor stop the exploit itself, it will block the payload or block in-memory only malware from modifying the system so that it can persist on the system.

* * * * *

The whole concept of adding vulnerable processes to User Space is simply to prevent those processes from executing. If you prevent them from executing, then you remove them from the run sequence. It's just an additional layer - above and beyond - AppGuard's built-in protection policies.

As long as you have Guarded Apps properly configured and run in Lock Down mode, AppGuard provides high physical system protection; there is no absolute need to add all vulnerable processes shipped with Windows to User Space.

However, if you add those vulnerable processes which you never use on your system, then it won't hurt anything. The trick is figuring out what you need and don't need as far as vulnerable Windows processes are concerned.

For the typical user, they have no regular need of any of the vulnerable processes. The exceptions to this are corner cases involving program installations and use of some utilities. In those cases, the user has a number of options - dependent upon what is needed:

• Temporarily exclude the vulnerable process from User Space
• Temporarily Allow USB Launches - UnGuarded,
• Temporarily Set AppGuard to Allow Installs
• Temporarily Set AppGuard to OFF
• Add the vulnerable process to Guarded Apps

After completing the desired\required task, simply re-enable AppGuard's protections (reverse the above actions).

* * * * *

Before this post degenerates into something not intended, let me clearly state that I am not going to debate that AppGuard can be bypassed or not bypassed.

As far as I am concerned, with adequate pen-testing, it probably can be bypassed - or at least seriously messed with. In all likelihood, there is some way - within the entirety of most typical Windows-based systems - to mess with AppGuard. In fact, it is almost a certainty since there are multiple layers of vulnerabilities within any typical Windows system. The real question is this - even if you find the "needle-in-the-haystack" vulnerability, can that vulnerability be realistically exploited or not ? And with that question, this post goes off into another direction that I don't want to cover.

The bottom line is this, until someone can produce an actual malware sample or exploit page, that clearly shows a bypass - and can be accessed by or is submitted to the developer for full analysis - there is no evidence.

There's a whole lot of talk about bypasses - but no one ever produces actual samples that can be analyzed.

In that case, talk = 0 and I don't want to take it there.

 

You should submit this directly to AppGuard support; Barb might not be back here for a while...

 

Thanks hjlbx

 

For those that are paranoid about *.reg files, just add both regedit.exe and regedt32.exe to User Space for:

C:\Windows\regedit.exe
C:\Windows\SysWOW64\regedit.exe

C:\Windows\System32\regedt32.exe
C:\Windows\SysWOW64\regedt32.exe

That is all that is required.

If you need either one, just temporarily exclude both file paths from User Space. Do your thing. And then re-include both file paths in User Space.

 

I see I have this entry in User Space as Include=No. I think I must have added it manually. Should I leave it as is?

I thought I read just earlier in this thread you had added all vulnerable processes in Appguard (largely based on Florian's list, which you kindly provided - and as you state here, gradually, just to test nothing was broken) but then had removed them again, leaving only powershell and powershell_ise. Can't find that post now, maybe I dreamt it ... am I right?

I only have those two processes (i.e. the four entries) in Appguard User Space - as well as two vssadmin entries, based also on some earlier comments in this thread, to lock them down.
The many other vulnerable processes (e.g. .NET entries) I personally find easier to manage via NVT ERP (Alert Mode), and I have now added these regedit.exe and regedt.exe entries in ERP as well.

 

@paulderdash

Using NVT ERP is much more convenient and easier to configure, but whether you do it in AppGuard or ERP, the end result is the same = block vulnerable processes from executing.

If I were super-paranoid, then I would add all the vulnerable processes shipped with Windows to User Space in AppGuard or vulnerable process list in NVT ERP.

I tested it. Adding all of them caused no problems. If you need it, unblock it, run it, and then re-block it.

You can do everything in AppGuard alone or combo with NVT ERP for convenience\ease-of-use.

* * * * *

The whole concept of adding vulnerable processes to User Space or NVT ERP vulnerable processes, is to add policies that are above-and-beyond the default AppGuard policies. In other words, a "just-in-case" measure...

 

Yeah.

I dumped all that non-sense and now just use AppGuard + Adguard + WD + WF. Very, very, very few problems compared to the average security config.

 

@SHvFl ReHIPS is only on my secondary machine (for now).

 

What is WD and WF?
Windows Defender + Windows Firewall maybe?

 

Yes, WD = Windows Defender and WF = Windows Firewall.

 

Malware doesn't use regedit.exe to modify the registry. It uses the associated Win API's to do so: https://msdn.microsoft.com/en-us/library/windows/desktop/ms725505(v=vs.85).aspx . Ditto for Powershell. Malware can call the Powershell assemblies from a C# program. And numerous other like instances ...........

 

ok got another dumb question.

In my activity report I get the following.


06/17/16 08:40:55 Prevented process <dismhost.exe | c:\windows\system32\cleanmgr.exe> from launching from <c:\users\xxxx\appdata\local\temp\9be0d78a-635c-46f5-8999-df3d2d09f712>.

06/17/16 08:40:52 Prevented process <dismhost.exe | c:\windows\system32\cleanmgr.exe> from launching from <c:\users\xxxx\appdata\local\temp\287ab9cc-9f99-4518-9215-777d03e6097b>.

06/17/16 08:40:39 Prevented process <dismhost.exe | c:\windows\system32\cleanmgr.exe> from launching from <c:\users\xxxx\appdata\local\temp\58dc0939-0531-49df-b054-1ebbe5df5956>.

06/17/16 08:40:26 Prevented process <dismhost.exe | c:\windows\system32\cleanmgr.exe> from launching from <c:\users\xxxx\appdata\local\temp\3b48114a-1ad7-4755-858b-65daf79cb259>.

From what I remember, this is for disk clean, scheduling up ect and so am wondering why this one is blocked?

Thanks

 

dismhost.exe is copied to the temporary folder and is then executed (parent process=cleanmgr.exe).
But it is User-Space, and dismhost.exe is not signed = Blocked.

 

So I should exclude it? after all it is a legit windows file As far as I know.

 

I run in Lock Down mode, so I just add cleanmgr.exe to Power Apps. That way, I don't have to lower AppGuard protection to Protected mode to run cleanmgr.exe or automatic maintenance.

You could add the dismhost.exe file path in AppData using a wild-card in place of the randomly generated parts of the file path.

 

Is that process not vulnerable to attacks? I also put that in the Power Apps due to a recommendation in the past.

 

I've never heard of cleanmgr.exe being used maliciously... but it is probably possible in some way.

You should just be able to add the file-path to Power Apps:

on W8 and W10

C:\Users\HJLBX\AppData\Local\Temp\D3EB7820-7FD6-494A-A71B-FC688183A231\DismHost.exe

Just use wildcard * or ? in place of alphanumeric part of file path.

 

Thanks!

 

I tried to installed AG Personal v5.2 in VM and this is what I was greeted with:
http://s31.postimg.org/e725rz717/WTF_BRN.jpg

EDIT1: Sorry for the dbl pic, anyways looks like we stay at v4.xx or pay BRN again! I already know what Im gonna do, and it has nothing to do with my wallet!

EDIT2: or maybe a 3rd option,
http://s31.postimg.org/e725rz717/WTF_BRN.jpg http://s31.postimg.org/e725rz717/WTF_BRN.jpg

 

if you have the personal version, so you should have a new license key for it. If you used the v4 license, of course it won't work.

BRN told since ages that licences are lifetime ONLY on the current version you bought and are using, not cross version.

btw, using any AG license in a VM is a bad idea.

 

lmao

 

the 5.2 version is the beta yet.
do You stay with 4.xx ?