AppGuard 4.x 32/64 Bit - Releases

***Update***
Barb said she discovered a bug which explains why i'm not seeing Java in my Guarded Apps List. Hopefully they will have a fix for me to test in the next build, but she did not say when the fix would be available for me to test. Keep up the good work guys of finding bugs! AppGuard should be pretty solid after we get done going through it with a fine toothed comb. I'm very thankful for those that sacrifice their time to help make sure we have a great product to use!

 

They found what I didn't (regarding ImDisk) and more than I expected after so many useless spams [and unsubstantiated theories].

I'm unfamiliar with the issue(s) you uncovered regarding java [I try to avoid it like a plague] and while we may not see the new features right away - I for one am looking forward to the time they add those diagnostics and reporting to AG in case it can't do something for some reason! If that and other things (like the java issue CE helped them find) happen as I hope (though it may not be in this phase) this beta period could end up being a huge step forward. Between CE, Mr. X and the folks at BRN identifying problems like these IMHO you've done well! So, as CE says, keep it up! Let's annoy them until they blacklist us...err well, maybe not that much... on that note, do you get a bonus for dealing with us silly folk Barb? If not, you should...where do I sign?

P.S. the one(s) who helped you test the darned ImDisk likely deserves a bonus as well Unless (t)he(y) called me crazy, in which case, well. Nevermind on that thought!

 

Bouncer is a crazy powerful kernel mode driver. You can probably mitigate anything with it, but it takes some time to learn to use it. I have to say it's easier for me to use than Smart Object Blocker though. I like it because it can be used without a service, or GUI. It requires no application to run at all. Everything is done in the kernel. It's KMD works similar to AppGuard though so they may not be compatible on everyone's machine. Who knows they may fight, and kill one another on the next man's machine lol

 

+1
Thank you syrinx for your priceless input and help.

 

I only have Java installed right now to test AG with. I got rid of Java about a year ago. I should have gotten rid of it a lot sooner. I found replacements for applications I use to use that required Java. I pushed really hard for BRN to add Java to the Guarded Apps List by default in case someone using Java opened a java exploit, or dropper using scripting outside the browser. I don't want to give any specifics how it can be used as a bypass since it will take some time for their clients to upgrade to the latest build of AG. I hope most of their clients do not have Java installed.All Java executed inside the browser has always been protected though.

I would say my emails to Barb, and BRN can be a burden at times. I send them quiet often during development periods. I'm sure they are probably swamped when they receive them. I try to report as much as possible since I never know when the next development period may be.

I think the next development period will make some good changes to make AG more user friendly. I sent them my recommendations, and some others did as well. I think BRN wants to go to one mode of operation so I requested they give all the functionality of Locked Down Mode in the settings. I have always preferred granular control in the settings over having different levels of Protection. Granular control allows the user to enable, and disable what ever they want. One Mode of operation will mean less coding, less documentation, less support request, and lower operation cost for BRN. I think the key will be granular control of everything instead of having different Modes of operation. It will be more evident how AG works if granular control of everything is given in the settings. Currently the user has to allow all signed files in the user-space in Medium Mode instead of only allowing those on the Publisher's List. If you want to use Medium Protection Mode to allow your applications to update then you have to allow all other Publishers to execute in the user-space also. The user-space executions will be with very limited rights, but I still prefer not to allow them at all. The user should be able to only allow files signed by Publishers on the Publisher's List, or not allow signed files at all. I think it's all about granular control. I think one mode of operation with complete control is the way to go. That's not counting Install Mode, and OFF though. There would be three modes counting them.

 

@Barb_C

*.jar files optimally should not be permitted to launch from User Space by default - same as *.bat, *.vbs, *.js, etc, etc

Java-based malware uses embedded *.jar files to install malware onto system - from emails, documents, etc.

Adwind RAT is an example.

Something to consider...

 

@Mister X - it was @marzametal that mentioned netsh.exe - not I. I'm not sure of the intent of adding netsh.exe to User Space - it appears to be disable profile change.

 

That's one of the attacks I was referring to, but if javaw.exe is Guarded then the embedded .JAR file can not drop the payload then. It will not be allowed to write to System Space, Program Files, C:\, Registry, or other Processes Memory. That's why I pushed so hard for Java Runtime Environment to be Guarded by default.

 

Sorry for the stupid mistake, yes you're right.

 

Java Runtime Environment is bad ju-ju all the way around since it is a virtual machine.

JRE should be Guarded - as well as Flash - and the user should also use an anti-exploit.

It is tricky to elicit the full run sequence without the proper utilities; perhaps BRN needs to investigate some actual samples to determine what exactly is needed in AppGuard in the instances of commonly exploited applications (eg - JRE, Flash, etc).

I am surprised Flash is not Guarded by default.

 

I can tell you that adding all these vulnerable processes to User Space (both System32 and SysWOW64 paths), only caused (2) blocking events. In other words, for the vast majority of users they just aren't needed.

netsh.exe uses command-line scripting to change the network configuration. In that regard it is a "vulnerable process." Since cmd.exe is Guarded, it is debatable whether or not there is any increased security by adding netsh.exe to User Space. I suppose there is, but that is a question for BRN.

However, by design, NVT ERP is much better suited - both in terms of notification and convenience [Allow\Block] - to deal with the processes below in a way that doesn't affect usability for the advanced user.

NOTE: List below is incomplete.

• cscript.exe (VBS, VBE, ...)
• wscript.exe (VBS, VBE, ...)
• mshta.exe (HTML applications)
• regsvr32.dll (DLLs)
• mmc.exe (Management Console Plugins)
• regedit.exe (Registry scripts)
• regedt32.exe (Registry scripts)
• rundll32.exe (DLLs)
• rundll.exe (DLLs)
• powershell.exe (PowerShell scripts)
• msiexec.exe (MSI installers)
• java.exe (JAVA applications)
• javaw.exe (JAVA applications)
• javaws.exe (JAVA applications)
• vssadmin.exe (Volume Shadow Copy)
• csc.exe (NET Framework)
• vbc.exe (NET Framework)
• jsc.exe (NET Framework)
• InstallUtil.exe (NET Framework)
• IEExec.exe (NET Framework)
• DFsvc.exe (NET Framework)
• dfshim.dll (unless you use Smart Object Blocker or Bouncer)
• PresentationHost.exe

Source: Excubits blog and Emsisoft thread at Wilders

 

I've also added mmc.exe in User Space = Yes. Works well for me in LUA because it prevents access to Administrative Tools. I like it, it's not for everyone though.

If you use a VPN, you will understand why I chose this approach. If you don't, then leave it out and rely on NVT to monitor your stuff (depending if you run LUA or just Admin). Still waiting for NVT to allow settings to commit in LUA. Guess I will be waiting forever.

 

I agree with you. I use ERP for such task. And thank you for the list provided.

 

According to BRN flash is Guarded since the user's Web Browser is considered the parent. The Flash Plugin is part of the Web Browser. It's the same with Java Script inside the Browser. If a Java attack originates from the Browser it is Guarded.

 

Thanks. I don't use a VPN and precisely I rely on ERP to monitor and I run just like Admin.

 

@Mister X , @Cutting_Edgetech , @marzametal, @Windows_Security , @itman, @pegr, @guest - and whomever I might have missed.

We should, together, make a list of "vulnerable processes" - and why they are vulnerable.

The list I have is essentially complete for the "worst offenders", but there are some arcane ones not on the list - and I just don't have the time to research them all.

Just a thought...

 

That makes sense. I didn't consider the run sequence, but that is correct. Parent => Child in AppGuard.

The PROBLEM is FLASH can be EXPLOITED OUTSIDE the BROWSER !!!!

http://www.gmanetwork.com/news/stor...ser-may-not-be-enough-to-secure-your-machines

For greatest security, all widely-distributed, commonly exploited applications should be Guarded by default - regardless of Parent => Child relationships.

 

The other day I brought this finding, at least new for me (read the subsequent posts):
https://www.wilderssecurity.com/thre...as-anti-executable.369503/page-9#post-2560005

So what do you think about diskpart and diskmgmt.msc

 

I know treating mmc.exe as a vulnerable process will block execution of diskmgmt.msc. However, I do not know if this will prevent modifications to file system or disk.

 

Disabling Volume Shadow Copy in Windows Services blocks mods. One has to enable that service to perform any changes.

 

I believe we need a separate thread just to categorize in a list all vulnerable processes. I don't want this thread hijacked.

 

Yes. It is related to AppGuard, but not AppGuard-specific. So I won't mention it here any further.

 

On that new thread we could mention and discuss in depth all programs we use or know that list suit them. Please be my guest as you came up with this idea in the first place.

 

AFAIK all the scripts you have listed above are covered by AG. If you have some test results that says otherwise then let me know. I use to add them to the Guarded list, but discovered they did not need to be added. I think they are hard coded into AG's kernal mode driver. Cruel Sister tried using some malware samples on AG recently in Medium Protection Mode, and wscript was blocked from running. She did not have to add wscript.exe to the Guarded List in order for AG to block the script. She ran some signed malware in Medium Mode, and the malware was unable to do anything because AG blocked the needed .dll file to execute the attack. The best thing to do would be to try samples that use those scripts as the dropper for the payloads, and try them. I don't have a test machine at the moment so i'm not will to try that right now lol

VSSadmin.exe, csc.exe, InstallUtil.exe, IEExect.exe, DFsvc.exe, and PresentationHost.exe are not covered by AG with default settings. AppGuard should stop the attack before it is able to gain access to those resources though. I always add them to the user-space myself if i'm not using Bouncer, or ERP. It's faster to block them with Bouncer because I don't have to list the path for each one. There are multiple of the same executables in the .NETFramwork, and with AG you have to add every single one by path to block them all. In bouncer it will block by process name without having to list the path of each one. If somehow malware bypasses one line of Security it should stop the malware from gaining access to those resources limiting the damage done by the attack.

Edit 2/9/16 @ 12:29
I brought this up to Barb before. I will send her an email tomorrow, and request that she check with the developer to see if Guarding scripts like wscipt.exe, cscript.exe, etc. will enhance security, or are they already Guarded in AG's KMD. If so in what scenario would they be allowed to run, and when would they be blocked. I think it's best to add anything vulnerable that is not needed to the user-space as long as it does not cause stability problems.

Edit 2/9/16 12:37
I forgot that you was only talking about blocking them by adding them to the user-space. Guarding them is not the same of course. Since I have personally seen most of those scripts blocked it's questionable whether they need to be added to the user-space. It would be good to know under what conditions would AG block them without making them part of the user-space.

 

I use PDF EXChange Viewer, and it is not Guarded by default. I switched from Foxit Reader because it seemed kind of bloated to me, and AG caused some issues with it's updater. They had a poll not too long ago, and I think the majority of users here are using PDF EXChange Viewer now. I think they should add it to the Guarded Apps List by default since so many users are using it now. It hard to say if any attackers are attacking it in the Wild yet though. I doubt they will consider adding it this development period though. They are occupied trying to fix the remaining bugs that have been reported.