AppGuard 4.x 32/64 Bit - Releases

I had the same error. I think I just restored configuration files and upgraded Adguard

 

I think something went wrong during the installation, but I have not had a chance to confirm that yet. I had to work with 10 other computers yesterday.

 

The only partition on this machine is C:\. It's a fresh install of Windows 10 also. I think this may be something else.

 

I will have to try uninstalling AG, and installing again after I send my bug report. I think it should still be reported, even if a reinstall fixes the problem. I don't see why the installation became corrupt to begin with.

 

Remember to delete brnfilelock.sys from services and all the remnant folders left behind. For example, the xmls are left behind after uninstall.

I also delete the AppGuard prefetch.

I use UltraSearch to locate all the remnants, then do a CCleaner registry clean-up.

 

I don't know. I will try to uninstall, and install AG again before trying that. I had to work with 10 other computers yesterday, and the deadline to upgrade to Windows 10 is today. I will have a chance to trouble shoot it more after I get caught up. I could have gotten this done a long time ago, if it was not for a critical Microsoft update bug I have been dealing with.

 

I will do all of the above.

 

@mood

appguardpolicy.xmls were crafted using xml notepad.

Try xml notepad and you will have a much easier time dealing with the AG xmls.

 

I opened appguardpolicy.xml with xml notepad, saved it under a different name = now the file is in a human readable format

 

@mood

By now I'm sure you know in xml notepad you can view appguardpolicy.xmls - the one from Program Data (for all users) and AppData\Roaming (for current user) - in xml notepad in development mode and xml mode = as it appears in Internet Explorer.

xml notepad works a lot better than notepad++ for the task, but notepad++ makes much more sense for someone that does a lot of coding.

 

@mood

You customized your W8 drive root file system tree: c:\system-space\1\2 ?

 

After searching this thread to find out why i created this directory i found it: #5706
Yes, i created this directory for testing powershell.

And if i'm testing AG, it's clearer for me to have this kind of directories in the Activity Report
examples:
c:\system-space\test
d:\user-space\test
d:\user-space_include=No\test

 

@mood

Yeah, I get that... it makes sense to better identify the Activity Report entries.

 

Q: should wushowhide.diagcab (kb3073930) run w AG Locked Down. I ask because wushowhide calls C:\WINDOWS\system32\msdt.exe, and ERP Lockdown blocks msdt.

 

But if you are blocking it with ERP, then it can't run.
Maybe you have to whitelist the command-line in ERP first, if you have msdt.exe in your vulnerable list.
Isn't this a question for the ERP-Thread, or is AG blocking it somehow?

 

Sorry, with ERP disabled. Just wondering why AG is not blocking and commented that ERP does.
Tried wushowhide launch with AG Locked Down, w/wo ERP disabled. Just wondering AG + wushowhide. Should wushowhide.diagcab (kb3073930) run w AG Locked Down.

 

AppGuard does not block the execution of *.cab files from User Space per default policy.

*.cab files don’t include a mechanism for installing files onto systems; they are only compressed file archives. That being said, *.cab files are not normally scanned by AV engines - so malc0ders will use them to avoid detection.

So, since their is no persistence on the system without creating an auto-run, there is really no need to block *.cab files outright - and I assume this was BRN's rationale.

Besides, it is executed Guarded - but then there is a UAC prompt to elevate privileges. So msdt.exe will run with highest privileges. I'd be interested to see if AppGuard will block and record the events in Activity Report for any Windows Update changes made with wushowhide.diagcab.

@bjm_ - can you let me know if AG blocks any changes made using wushowhide.diagcab ?

*.sfx = self-extracting *.cab files - which can drop malicious executable files in User Space. AppGuard does not block the self-extraction - because it doesn't block *.sfx files per default policy. AppGuard will block any executable file execution if unsigned (Protected and Lock Down modes). If signed and running AppGuard in Protected mode, the execution will be Guarded.

In the case of wushowhide.diagcab it is extracted natively by Windows and executes msdt.exe.

I will look into any *.cab file associated risks further and let you know.

 

Ok, i was typing something but someone was faster than me
Anyway, i see in this .cab-file powershell-files (.ps1) and a .dll.
If the cab-file is extracted to User-Space it should be blocked for sure. (executing of powershell-skript + an unsigned dll in User-Space)

 

I have to check the difference between Microsoft's *.diagcab and a generic *.cab file.

Perhaps a generic *.cab file can be used to call a trusted process from System Space, get that trusted process to download additional malware to User Space - or - maybe even get it into System Space (remember the *.lnk-powershell.exe-*.wfs video from January ?).

I don't think so... *.cab files are simply a specific archive type - like *.zip, *.7z, etc; the use of *.cab files to deliver executables to a system undetected -- because most AV scan engines don't scan archives to minimize scan resource usage.

If the executables are downloaded to User Space, then there is little problem - it will be blocked from executing - unless digitally signed while using Protected mode or un-signed if the user chooses to run it by employing "Allow User Space Launches - Guarded."

If the executables can be written to System Space, then that is a definite AppGuard bypass.

I will look into it...

 

I did a quick lookup of *.diagcab files and Windows Trouble Shooting Platform (msdt.exe).

http://cybersyndicates.com/2015/10/...oting-packs-and-application-whitelist-bypass/

From what I see, it uses powershell to modify the system. Since powershell is a Guarded App, then there should be no persistent system modification; you would have to run the troubleshooter in Install mode.

Can anyone confirm this ?

Also, if a malicious *.diagcab is executed, then powershell will be blocked from creating auto-run.

 

Okay, I don't know about nuts n' bolts under the hood, other than I can launch wushowhide from desktop, click Advanced n' uncheck, observe searching for updates and view hidden updates.

 

It's all right... AppGuard is working as designed. *.diagcab files are not blocked in Lock Down mode.

 

After looking at these files with 7-Zip, they have the "same format". Files are stored with "MSZip".
The only difference is, that the extension .diagcab is associated with msdt.exe (doubleclicking wushowhide.diagcab = msdt.exe and then maybe powershell-scripts are being executed )
(But i can't doubleclick now on such a file to verify it )

 

Okay, Thanks

 

Why does AG continue to block 'whatever' when it is in Off mode? Isn't Off Off. When I turn anything off, it does not operate anymore...that's why there is an Off and On. I guess Blue Ridges' definition of Off is different.

Same with Install mode. That's why most people when installing use Off instead as it is still better than Install mode.

Thanks,
Robert