AppGuard 3.x 32/64 Bit

As I already said, new version has option that fixes this vulnerability.

Developer also made some tests on his own:
https://www.wilderssecurity.com/showpost.php?p=2199178&postcount=1686

 

With Sandboxie version 4.01 beta

I only have to add :

sandboxierpcss.exe
sbiesvc.exe

c:\sandbox folder to the folder exception list under the guarded apps tab with read/write permissions.

Question, what is safer adding sbiesvc.exe to Power Apps or Memory Guard with ReadWrite?

It will work either way, for me.

 

+1

 

Thanks Pete, do you or anyone else use the beta version 4.01. xx of SBIE? A lot has changed with it. I know I don't have to add anything to PowerApps anymore. These two sandboxiedcomlaunch.exe and sandboxiecrypto.exe do not have to be included at all.

Wanted to know how to configure it correctly for AG.

 

Oh yeah, I forgot the last time this happened it was inert upon reboot. Still wonder how it is allowed to execute in the first place.

 

Remember though you need Power Apps for x64. Memory Guard exceptions won't work. SBIE4 might solve that but for now...........

 

The test may have been lacking in some detail as to what happened to Appguard after the Rogue was allowed to run. We don't know whether Appguard's service was completely killed or not. The Appguard tray icon disappeared so the rogue was at least able to kill AppguardGUI.exe (that is if this is the service that runs the tray icon). AppGuardAgent.exe could have very well been killed. I don't believe the rogue should have been allowed to run to begin with. Also if AppguardAgent.exe was killed it would have not been contained. MBR protection would have been the only other defense at that point. MBR guard was tested against 5 different rootkits recently, and it only stopped 2 of them if I remember correctly.

The tester's techniques appear to be conducted in a controlled manner, and have merit. I would recommend the tester show that the AppGuardAgent.exe has been killed after the rogue kills the tray icon to prove AG was fully bypassed (that is if MBR does not partially stop the threat). I believe the tester proved Appguard was at least partially bypassed if not fully bypassed. If I had my test machines right now then I would run my own test to see for myself if AppguardAgent.exe was killed. The test was run using VMware. I would run the test on a live machine instead of VMware to see if I get the same results. I don't believe VMware would have made a difference in this case. Usually if there is a difference the Malware will detect that it is being executed in a virtual machine, and will not compromise the Machine. In this case the machine was compromised.

On another note we do not get to see any video of the test being conducted by these 3rd party testers like AV-comparatives, AV-Test.org, etc.. How do we know they were conducted correctly for sure? At least this person went through the trouble of recording his or her test so we can see how they were conducted.

 

jfyi: third-party testers collect data/logs too and for certain tests they even have videos for each test case as a proof. the results are usually scrutinized by the tested companies and they contact the testers if they have any disputes or see mistakes. that's also one of the reasons why there is usually a delay before you see results published, as first some week time is given as preview so the results can be verified to be correct before users see them. almost all vendors visit regularly testing labs to see e.g. their work / testing systems etc.

 

I actually believe the test results of some of these professional third party organizations have a lot of validity to them, and hold merit. In fact I have made many post stating this when many other users on the forum said their test results were either worthless or didn't reflect real world scenarios. I was only using my statement as an example for other's reasoning for discrediting any test done by anyone other than a known professional test organization. Even when it seems obvious that their test have been conducted in a manner that should produce valid results. Questions could have been asked as to why the tester did not show if AppGuardAgent.exe was killed by showing the processes running after the Rogue killed the AppGuard tray icon. I only saw one user ask this question. I've seen nothing thus far to justify being disrespectful to the tester. I've seen a pattern of testers often becoming a target of disrespect instead of offering them advice or constructive criticism. Also, i'm a huge AG fan. I have been using AG since early version 1 beta release so I have no incentive to be bashing AG. I was one of the first beta testers of AG outside of BRN itself.

 

I sent samples of malware to Barb_C. But I also wanted to warn users AppGuard to implicitly did not trust any program. Blackhole exploit kit is a popular exploit pack.

 

Yes, for a moment I thought superman was doing the test. Joke aside, I barely could see what each setting was for. Therefore, someone not already knowing where each setting is, won't know what the guy is doing.

Resolution didn't help either.

 

Hello, Long time no see (and I apologize immensely for that!). Although I have not been on this board recently, customer support is always available via the AppGuard support email address (AppGuard@BlueRidgeNetworks.com). Even though I have been away, there is a team here at Blue Ridge that usually responds to those email support tickets in a timely manner.

In the next few days, I plan on reviewing the posts on this thread since the beginning of the year and answer those that haven't been addressed (thanks to Pegr, Jmonge, Dbone, Safeguy, SpaceGhost, Peter2150, Arcanex and the many others that filled the gap during my absense I don't believe that there are many outstanding issues that I need to address).

And lastly, as many of you have guessed, we have been focusing on the enterprise version in recent months, but I believe that the development team is going to get the go ahead very soon to work on another release of Consumer AppGuard (yea!). It will most likely be a minor release (not 4.0 for those that are waiting 4.0) which fixes the "phone home" issue and some other minor bug fixes. I will let you know more details as soon as I am notified.

 

AaLF, what OS are you running? I'm not sure why, but on Win7 64 bit, I am seeing the icon for removable media drives as set in my autorun file.

If you trust the flash drive, you could "Allow USB Launches" from the AppGuard tray menu.

 

AppGuard stops suspicious applications from running: AppGuard stops applications located outside of the Program Files and Windows folders unless they are published by a trusted vendor or on the AppGuard Guard List. Specifically, the following AppGuard protections accomplish this:

Drive-by Download Protection: Stops suspicious programs from launching. Depending on the protection level, AppGuard stops or Guards applications located outside of the Program Files and Windows folders unless they are published by a trusted vendor or on the AppGuard Guard List.

InstallGuard: Prevents installation of programs from untrusted vendors.
​

AppGuard stops vulnerable applications from performing high-risk activities which may be exploited by malware: AppGuard simply blocks these activities – usually with no adverse side effects. Occasionally, when an application actually intends to perform a high-risk activity, AppGuard may block a legitimate action. In that case, the AppGuard protection level can be reduced in order to accommodate the program’s operation. Specifically, the following AppGuard protections accomplish this:

Guarded Execution: Guarded Applications are prevented from performing high-risk activities that might be exploited by malware.

MemoryGuard: Prevents programs from writing to or reading from other processes’ memory.

Privacy Mode: Prevents browsers from reading private folders.
​

Additionally, MBRGuard protects the computer’s master boot record.

Regarding which applications to Guard: Any application that processes data or files originating from outside its host ought to be guarded. Any user-application can be guarded as long as it follows Microsoft's recommended best practices and does not write to the HKLM registry hive or to certain system directories. Not all applications follow these practices so any applications that are added to the Guard List should be tested while guarded to ensure that AppGuard does not interfere with their desired operation. Sometimes AppGuard will block an operation, but the guarded application still runs normally. In this case you may want AppGuard to disable all alerts or Ignore some of the messages for this application.
Also any applications or services that run in the System context should not be Guarded.

An application may actually consist of several executables. It may not be necessary to add all of the executables to the Guard List. If an executable is never called directly (i.e. it is always called from a parent process), then it is only necessary to add the parent process to the Guard List. AppGuard’s patented technology automatically Guards any application that is invoked by a Guarded parent process.

 

Because AppGuard does not do scans, a fast machine is not required. Your machine should be fine. The recommended system requirements are:

• Minimum 1.80 GHz 1.00 GB of RAM
• 10 MB Hard Disk free space.

 

If you are not planning on installing software from a web site, I would recommend using the Locked Down setting. This will absolutely stop any nasties that are trying to get into your system via the browser. That being said, I think most people use the High protection level and have not been compromised.

 

The license is for 3 computers total. Also, we have had some users install on their clients or customers PCs.

 

Good idea! Not sure why we didn't think of that. We'll try it in our lab and perhaps add windows update to our default policy in the next release.

 

You are correct!