AppGuard 4.x 32/64 Bit - Releases

The video shows a Home Group and a *.wtf script.

A Windows Script File (WSF) is a file type used by the Microsoft Windows Script Host. It allows mixing the scripting languages JScript and VBScript within a single file, or other scripting languages such as Perl, Object REXX, Python, or Kixtart if installed by the user.

 

I thought the .ink bypass was fixed.

 

There are about 50 vulnerable processes that ship with Windows, plus multiple write-execute (vulnerable) directories in System Space...

 

Thank you! I thought it was like any other windows scripting file.

 

It appears it was only fixed for cmd.exe. The video creator states on a Polish security forum that it is a simple *.lnk bypass.

 

Without seeing the actual script, it is all mere speculation...

 

Regardless, they both bypassed AG. I already sent Barb an email. I probably want hear from her until tomorrow though.

 

cmd.exe is Guarded. The .ink bypass we had several months back is what made BRN finally start Guarding cmd.exe I think there must be more to it than that.

 

Sorry. That's what I meant - for Guarded Apps. Since cmd.exe is the only Windows host process included in Guarded Apps by default, then only cmd.exe would be protected against the *.lnk bypass with the default install of AppGuard.

I'm just repeating what the video creator states on a Polish security forum. Without the actual files, it is nothing but a guess as to how he\she accomplished the bypasses.

I have raised this very issue of vulnerable processes (other than cmd.exe) shipped with Windows and the ability to abuse them and writeable directories in System Space to BRN quite a few times.

 

I wanted to write the same after seeing the video.

Maybe BRN should at least add more "vulnerable apps" to the list.
Powershell = powershell.exe, powershell_ise.exe
Windows Scripting Host = wscript.exe, cscript.exe

 

@mood

@Barb_C

There is a whole bunch that should be added to Guarded Apps or handled differently by AppGuard:

http://blog.jpcert.or.jp/.s/2016/01/windows-commands-abused-by-attackers.html

https://github.com/subTee/ApplicationWhitelistBypassTechniques/blob/master/Limits.txt

https://github.com/subTee/ApplicationWhitelistBypassTechniques/blob/master/TheList.txt

Adding all items to User Space is a pain since you have to add both the System32 and SysWOW64 directories. Plus, for NET assemblies you have to add each one from each version of NET Framework - and that is a pain because of the design of the current AG user-interface. It took me between an hour to hour and a half to locate all the processes using UltraSearch and enter them into Guarded Apps & User Space.

I have added all of the processes covered in these articles without a single problem; the vast majority of home users have absolutely no need of any of these processes.

If you search the web regarding vulnerable processes shipped with Windows, then you will find a lot of infos on this topic.

 

As far as the bypasses, it is not something I would fret about. If it does bother anyone, then just combo AG with NVT ERP.

BRN will get it sorted out...

 

I was informed all scripts are blocked in Locked Down Mode, and run Guarded in Medium/Protected Mode. wscript.exe, and cscript.exe threats should be mitigated without being on the Guarded Apps List. That's what I have been informed in the past anyways. AG obviously failed in this test though. I use to add cscript.exe, and wscript.exe to my Guarded Apps List just in case this added some extra policy protection I was not aware of. I was actually going to write BRN asking if there was any benefit in adding cscript.exe, and wscript.exe to the Guarded Apps List since it's my understanding that the handling of scripts is hard coded into their KMD, but I never got around to it. I started adding them to the User-space a few months ago instead so I would be sure they would not be allowed to run.

 

They can be abused by *.lnk file. The scripting can be built-in to the *.lnk file...

And in the second video, the person clearly shows Windows Scripting Host Process (wscript.exe) bypassing AG...

 

Thank you for the list. I add most vulnerable Windows processes to the User-space now instead of the Guarded Apps List. I add them to the Guarded Apps List only if it's essential for me to allow them to run. It would be counterproductive in that case to add them to the User-space because one would have to disable AG to allow them to run. One should always avoid configurations that require them to totally disable their security for everyday use.

I add all vulnerable Web Applications, and third party applications that must be allowed to run the the Guarded Apps List. That way they are allowed run, but prohibited from conducting risky behavior. Risky behavior would be writing to the System Space, Writing to the Registry, Writing to other Process Memory, Parent Child rules are not monitored, etc..

 

Yes, that's what I informed Barb in the email in regards to the second video. wscript.exe was clearly allowed to run.

 

I never needed one - except csc.exe one time - when using one of the Windows Control Panel apps. Had to go into User Space tab and switch from "Yes" to "No." Other than that, the only time I've seen any of these processes execute (a whole lot I might add) is when testing malwares.

 

csc.exe is a funny thing. I learned quite a bit about it using Bouncer. Applications use it to connect to the internet, and Windows uses it to diagnose internet connectivity problems. I have no ideal why. I have wondered if maybe applications can abuse csc.exe to get around some firewalls. It's something I need to look into more. I have an application called typeaccents which allows me to type in many different languages, and it constantly dials home (I don't allow it internet access though). If csc.exe is blocked then it can't even attempt to dial home. I wish I could post the logs from Bouncer I had of these behaviors, but I don't have Bouncer installed right now. The restraint on the config file is so small now that it no longer suites my needs. I will definitely buy a license for Bouncer very soon. Bouncer has become so powerful that there is very little you can't do with it.

 

Virtually all NET assemblies can be abused. vbc.exe and RegAsm.exe are two that are often used by malwares. They can all be used to make GUI-less (hidden) network connections - just like cmd.exe, powershell.exe, wscript.exe, etc, etc.

 

After updating AppGuard to the newest level, the tray icon doesn't change when I set it from locked down to protected mode. Does anyone have the newest exe so I can reinstall?

 

https://blueridgenetworks.s3.amazonaws.com/UpdateFolder/AppGuardSetup_4_3_14_5.exe

 

Thanks

 

I added a lot of them in ERP to the Blacklist or as a Vulnerable process.
And yes, it's a pain to add them in AG. An import/export-feature would be nice.

The maximum number of Guarded Apps in AG is 128. I only added powershell, wscript, and a few more as a Guarded App.
I let ERP handle the bunch of executables from these lists.

I added cscript.exe and wscript.exe and some more executables after reading about it in this thread some time ago.
After seeing the video it was a good decision to add them.

 

Uninstalling and reinstalling the new version seemed to work, no problems.

 

Yes, I am noticing the same (with the new version) trying to change from 'Protected' to 'Allow installs' via task bar right-click. There is either a delay, or needs two attempts, and right now I can't change it at all via task bar right-click, and if I change it via main panel this is not reflected on the task bar.