AppGuard 4.x 32/64 Bit - Releases

Does Appguard protect against word docs with malicious macros in locked down mode? if not is there a command I need to add to user space or depend on a different program for this?

thanks

 

How many of you remove vendors except for BlueRidge?

 

I did.

 

It is recommended to keep macros disabled when manipulating all unknown\untrusted office suite files.

That being said...

If the bad macro malware payload is not digitally signed, then it will be blocked in both Protected and Locked Down modes.

In Locked Down mode, if a malicious macro downloads and attempts to execute even a digitally signed malware, AppGuard will block it.

In Protected mode, a digitally signed malware with a proper certificate would be allowed to execute, but AppGuard would block it from persisting on the system; upon system restart the malware would be inactive\not execute.

Digitally signed malware is rare so it is not something that is a priority concern; most of the digitally signed malware out there are PUPs\PUAs - which most users here at Wilders wouldn't install on their systems in the first place.

 

The Trusted Publisher List is there for user convenience and increased security.

I run in Locked Down mode, but when I want to update softs, I lower AppGuard to the Protected mode level, and then perform my desired software updates.

I do this for programs for which the updaters are digitally signed all the way through the run sequence. In order to use this procedure, you have to add those Trusted Publishers to the list. For some publishers, their installers are digitally signed, but their updaters are not - so adding these publishers to the TPL is pointless. It is trial-and-error on the user's part to figure out which publishers use updaters that are digitally signed all the way through the run sequence.

That way, I almost never have to set AppGuard to "Allow Installs" or "OFF"; the system almost always has AppGuard protections enabled.

Security wise, it is recommended that you always set AppGuard to the highest protection level at which you can successfully achieve an action on the system without breaking anything. Allow Installs and OFF are the options of last-resort.

It is for this very last reason that the Trusted Publisher List was integrated into AppGuard.

However, AppGuard enables the user to operate it as they see fit.

 

Breakouts - it's a topic equivalent to discussing "unicorns and rainbows."

 

so even if I clicked on a digitally signed malware macro in outlook it would be blocked in lockdown mode. that is good to know. is there anything I need to do for wscript files? I already have powershell added to user space, just not sure about wscript.
what if a malware writer was able to use one of those trusted publisher certs to sign a piece of malware?

 

As long as the payload is in User Space it will be blocked. I have never used the Outlook email client, but I expect that downloaded files are placed somewhere in User Space.

AppGuard blocks Windows Scripting Host files as part of its default User Space policy; those file types are blocked from executing. So having wscript.exe enabled or disabled doesn't really matter.

If you don't want wscript.exe or cscript.exe enabled on your specific system - which most home user don't need them, but few disable them - then you can safely add both to User Space (YES). You need to add both the System32 and SysWOW64 file paths. It is easiest to use C:\Windows\*\wscript.exe and C:\Windows\*\cscript.exe.

FYI - make sure your office suite programs are added to the Guarded Apps list. Microsoft Office apps are auto-detected and auto-added to the Guarded Apps list. Other publishers are not and need to be added manually.

 

This is a potential issue only in Protected mode where files with Trusted Publisher certificates are allowed to execute.

The risk that some malc0der will get their hands on an active, valid certificate with the required keys - from Microsoft or Google for example - is extremely unlikely.

I can't quantify the risk number, but I do know just based on common sense that it is a very small number.

 

Realizing my escalated sledgehammer sarcasm proofed to be too subtle, I feel the need to clarify that it was my intention to express that is doesn't matter whether your sandbox folder is on C: or D:. Even a RAMdisk is only for performance reasons and not security.

Yet for extra security I would recommend to put it on a removable drive and disconnect that drive immediately after the sandbox closes. Just imagine that security! Now if we only had on the fly removable RAM, we could put the sandbox folder in the RAM and then we could remove the RAM and reconnect it and all that malware would be gone forever.

Sincerely
FleischmannTV
Enterprise-grade lockdown system expert professional

 

but it matters in how AG function, that was my point, we are in AG thread , not the sandboxie's one and theorizing about its mechanism . i thought it was easy to understand... seems not. i should draw pictures next time.

guest. chief network admin of the Matrix.

 

Now that's funny...

Your IT security bravura has no limits. You should patent it.

 

lol @Lockdown

i would go even further, i would use Windows on Live CD all the time, so i won't care of any security apps ! (i patented it !) /s

 

Thanks, I noticed the file path disappeared after reopening the GUI, and for confirming both paths are covered.

Yep, that's what I do, though strangely I had to add some paths explicitly, like at.exe and schtasks.exe ...

 

Jeff_T Testing/Lockdown

Yes but you did so with an answer that lowers the protection the product you are supporting could have offered.

Jeff_T Testing/Lockdown

Yes but only if you install software inside [same as outside] or the program(s) inside the box creates new files and tries to launch them and in medium AG protection [default] mode, only if they are unsigned. This is a good thing IMO.

Jeff_T Testing/Lockdown

True enough.

Jeff_T Testing/Lockdown

This is a horrid idea IMO, they should instead be added as guarded apps within AG- not excluded!

Jeff_T Testing/Lockdown

Once again, by adding the sandbox folder to user space, the end result is the same. This is all my suggestion entailed so why the argument?

Jeff_T Testing/Lockdown

You certainly did that by REMOVING potential protection points that AG would otherwise be able to provide. IMO if a user is combining products they want the best of both so why stick to the suggestion that reduces the security of your own product when there is another solution available that fixes the problem AND keeps your product in play at all times?

Jeff_T Testing/Lockdown

I disagree but that's another story for a different time.

Jeff_T Testing/Lockdown

Well that's why I got so annoyed, you weren't telling him how to configure Sandboxie, you were telling him how to configure AppGuard, which is your product! And in doing so you opened quite a hole in security that a user could reasonably expect AppGuard to handle.
What's worse is that when I shared and explained an answer that solved the problem and retained greater security via your own product your only worry was...

Jeff_T Testing/Lockdown

I had thought you did but apparently not well enough if you are sticking with the exclusion as the best answer.

Fleischman

As for fleisch, some of what I already covered with Jeff applies to you as well here. Within AppGuard the drive letter does not matter. Only System space and User space matters in this context. Which, once again, is why I suggested simply adding the sandbox folder as user space. While Z:\ would be treated as user space by default within AG, adding the sandbox folder manually results in the same exact behavior and thus protections.

Fleischman

Every single 'escape' I've seen reported is usually just because people don't understand how it works and what opening things up entails or other mistakes by a user. It is not a self-contained VM. I've tested countless configurations and products in combination with it and have yet to see a single 'true' escape. The same cannot be said for AppGuard which was (and remains) unable to protect apps in certain scenarios, in fact it only checks when protection is first started [or restarted/protection mode changed]. So far all they've added is an alert indicating that this could be possible but as it is only shown when protection is engaged that still leaves some small opportunities where it won't even do this much. But this isn't about Sandboxie vs Appguard, it's about resolving an issue someone had with AppGuard in combination with Sandboxie.

In fact that seems to be the same exact thing happening here...by suggesting that he add an exception and keep the sandbox folder in system space, the user is effectively saying 'ignore this' especially in this instance with AG already thinking the sandbox is system space. This may be in part due to do confusion on how system space in defined by AppGuard. So when a user suddenly sees something they thought AG would handle, but didn't because of this exception...suddenly the user will think AG isn't that great after all. The only upside here is that in this scenario Sandboxie will contain any changes regardless of how AG is set up [outside of bad rules in SBIE].

As I explained in my initial post, by default the C:\ is system space. When AG is installed the default xml has special entries which are found then 'checked' on the computer to retrieve the location of expected user space areas such as program data from the registry. This isn't done every time it starts as it then replaces these special 'entries' in the xml with paths. My point is that it can only check for expected entries so if a different product (in this case sandboxie) adds [or has added] a folder on the root of the same drive, AG isn't processing or protecting it as user space. This is good from a usability perspective but can get confusing in relation to a sandbox where people may want to install, test or run highly targeted apps inside. I won't go so far as to say it's a bad move on BRNs part to not just define the system spaces instead though that would solve this particular scenarios problem it would likely create even more issues.

So instead, by manually adding it as user space, we restore all of AGs protections to anything in this area as a user would likely expect it be in the first place.

Yet here we are: Both Jeff & Fleisch think the sandbox should be in user space. I agree, thus my rule suggestion. Yet both continue to argue that continuing to treat sandboxie as system space and adding an exclusion is a good idea? What?!¿

Jeff_T Testing/Lockdown

As I said in my initial post, your suggestion 'would do the trick'. My point all along has been that there was a better way that retained your own products protections. I can't believe I'm stuck wasting my time trying to help the user keep his AG security in place with YOUR product.

/me is so sad for all of those involved in mindlessly defending what turned out to be a bad answer.

 

Like I've said repeatedly, the user asked as question and I answered it. He even openly stated on this forum that the answer I provided solved the issue with his intended use and that he was satisfied.

 

@syrinx

i understand your point of view, i share it; i also would put sandboxie's container on user space, which is better; however :

1- The member (@Infected ) wanted a easy and hassle-free solution to his issue. @Lockdown gave him.
2- when you use Sandboxie, it is used primary protection, AG just backup it. Sandboxie isolate, if something dare to escape, AG then should block it.
3- as i said earlier, AG is strong enough by itself, any of its users don't need extra protection (sandbox, etc...), so @Lockdown is not obligated to solve such issues. He could just ask (as any support team would do) to remove the conflicting soft (Sbie in this case). However he gave answer that satisfied the member's expectations, job done.

now we are in a security forum, so people are more paranoid and tweakers than in any support forums; we like maximized protection with all our installed security softs. I like do the same too; but average joe doesn't care , he just want the products he use to work with the others.

There is a difference between make the products works together and maximizing the products efficiency. In this case it is the first option. However if @Infected want more security at the cost of some hassles , then he can follow your advices.

 

Sorry everyone, I was getting needlessly emotional here. guest has some fair points and while I'm tempted to argue with a few specifics [especially 3 ] I don't think it'd matter at this point. I don't know what else I can say to get my point across that I haven't already said. Not trying to cause drama, I was just really annoyed in this instance. I'd normally blame the alcohol but I was pondering it even while sober this morning so that one won't fly here. Anyway, goodluck all~ yes even you Jeff!

 

It is ok, we all have this "security geeks" behaviors, want the best from our product.
About point 3 , i know, this my observation even if i don't follow it; i like my having my other security apps too
Dont get us wrong , @Lockdown and me got your point, it is just in this case it was not required by @Infected. To do be in a support team is not to make the overall system of the user more efficient, just to make the product they sell to work, other issues than that is irrelevant.

 

I normally don't use Sandboxie, but I have been using Sandboxie with AG on Windows 10 X64 for 2 days without any problems. Im only sandboxing Firefox so far. I have made a few changes to the sandbox settings to make it more restrictive.

I added the C:\sandbox folder to the user-space in AG, and made the C:\sandbox folder an exception folder in AG. I also made SandboxieDcomLaunch.exe, and SandboxieRpcSs.exe a Power App in AG.

I have a lot of overlapping protection between AG, and Sandboxie. It's like having applications sandboxed twice, or having applications run encapsulated twice.

I'm not using Sandboxie with MBAE. I had to uninstall MBAE because I have been having many system, and applications freezes caused by MBAE. This was a problem before I ever installed Sandboxie. I will report them to Malwarebytes when I have time. I work so much right now that I have been inactive on the forum lately. I hope that will change soon.

Edited 1/15/17 @11:30

 

I haven't found that to be necessary for AG and Sbie to work fine together. Did you have problems otherwise?

 

Should Windows Mail (or any Windows Apps, other than Edge) be included in the Guarded Apps list?