AppGuard 4.x 32/64 Bit - Releases

Hello,

Thanks to everyone for the feedback concerning the settings in AppGuard for compatibility with HitmanPro.Alert ...

 

When closing a portable version of PaleMoon (which also happens to be inside a box with Sandboxie) protected by AppGuards latest beta it keeps popping up saying that:

Code:

02/15/16 17:31:45 Prevented process <sessionstore.js | C:\Windows\System32\cmd.exe> from launching from <D:\Apps\Temp\__delete_browser_01d16840a5e3eef2\drive\D\Apps\palemoon\user\palemoon\profiles\default>.

At that point in the sandboxie stage, all the processes are closed and sandboxie is only trying to delete the temporary files/folder, not launch anything inside so I'm not sure why it's showing up as a blocked event.

It doesn't cause any issues so it's not a big deal but I'm just curious as to why AG thinks it's trying to launch. The procmon logs don't seem to indicate anything odd was even attempted.

Has anyone else seen something like this?

Code:

<event>
<ProcessIndex>133</ProcessIndex>
<Time_of_Day>5:31:45.1214362 PM</Time_of_Day>
<Process_Name>cmd.exe</Process_Name>
<PID>3732</PID>
<Operation>CreateFile</Operation>
<Path>D:\Apps\Temp\__Delete_Browser_01D16840A5E3EEF2\drive\D\Apps\PaleMoon\User\Palemoon\Profiles\Default\sessionstore.js</Path>
<Result>SUCCESS</Result>
<Detail>Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened</Detail>
</event>

<event>
<ProcessIndex>133</ProcessIndex>
<Time_of_Day>5:31:45.1243805 PM</Time_of_Day>
<Process_Name>cmd.exe</Process_Name>
<PID>3732</PID>
<Operation>QueryAttributeTagFile</Operation>
<Path>D:\Apps\Temp\__Delete_Browser_01D16840A5E3EEF2\drive\D\Apps\PaleMoon\User\Palemoon\Profiles\Default\sessionstore.js</Path>
<Result>SUCCESS</Result>
<Detail>Attributes: A, ReparseTag: 0x0</Detail>
</event>

<event>
<ProcessIndex>133</ProcessIndex>
<Time_of_Day>5:31:45.1258000 PM</Time_of_Day>
<Process_Name>cmd.exe</Process_Name>
<PID>3732</PID>
<Operation>SetDispositionInformationFile</Operation>
<Path>D:\Apps\Temp\__Delete_Browser_01D16840A5E3EEF2\drive\D\Apps\PaleMoon\User\Palemoon\Profiles\Default\sessionstore.js</Path>
<Result>SUCCESS</Result>
<Detail>Delete: True</Detail>
</event>

<event>
<ProcessIndex>133</ProcessIndex>
<Time_of_Day>5:31:45.1263013 PM</Time_of_Day>
<Process_Name>cmd.exe</Process_Name>
<PID>3732</PID>
<Operation>CloseFile</Operation>
<Path>D:\Apps\Temp\__Delete_Browser_01D16840A5E3EEF2\drive\D\Apps\PaleMoon\User\Palemoon\Profiles\Default\sessionstore.js</Path>
<Result>SUCCESS</Result>
<Detail></Detail>
</event>
[code]

 

Thanks @Peter2150 - you da man !

 

Palemoon is just attempting to write to its profile using sessionstore.js.

That is what AG Activity Report shows.

AppGuard blocking sessionstore.js script execution from flash drive (D = User Space) is expected behavior.

Block does not break anything.

Block event can be safely ignored.

 

Except that's not what is happening, it specifically says from launching in the AG alert during the sandboxie delete phase (Palemoon and other related processes have already closed by this point) and nothing was even attempting to execute it. Basically, this is a false positive.

The procmon logs also support that it wasn't being launched or opened and only four operations specific to the file were even attempted around the time the alert pops up in AG: CreateFile, QueryAttributeTagFile, SetDispositionInformationFile, and CloseFile.

I expect it's just a minor bug with the new java protection. It's certainly not a big deal but ignoring a potential bug in a beta, even a small one that might not have real impact, would just be silly.

What I was really trying to find out was if anyone else had seen something similar with the new java related protections or do I need to go hunting for a reason why it's happening on my end?

Update: Looks like it might be something specific on my end, a quick VM test didn't result in this false positive appearing. /sigh

Update2: Just spent quite a bit of time trying to recreate the issue in a VM by installing everything from my live system and importing or redoing rules to be identical. No joy. So please don't bother testing it until I can isolate it. I suppose I'll have to take even more time down the line to try it on my real hardware again (My time will be sparse this week), one piece at a time and try to figure out the catalyst. /cry

 

hjlbx, recently pointed out that it's not a good ideal to always block task scheduler due to trim issues with SSD, and other needed maintenance. I was thinking in the future it should be made possible to whitelist safe task scheduler task by whitelisting their command lines strings. That way safe expected task can be allowed, and everything else would be blocked by default. It has already been recommended that support for whitelisting command line strings, and using wildcards should be supported. For everyone's information I have never had any problems with task scheduler being blocked that i'm aware of.

 

@Cutting_Edgetech

Earlier in this thread I posted this question to @Barb_C - for clarification of schtasks.exe block:

AppGuard blocks schtasks.exe, but does not block tasks created in Task Scheduler - what is the difference ?

So, I mistakenly thought AppGuard would block Optimize Drives (SSD TRIM), but it does not.

 

I thought Task Scheduler, and schtasks.exe was the same thing. I will have to look to see what the difference is.

 

Tech Fortress is AOL's brand of AppGuard. It is has more Trusted Publishers (AOL's other partners) and does not have Administrative Controls. Otherwise, the protection is the same.

 

Sorry, we do a merge when updating the policy and I guess the assumption is that these are new publishers (vs. deleted previously). I'm sure we can come up with a smarter way of doing this in the future.

 

If AG blocked tasks defined in Task Scheduler, then a lot of softs would not even start-up at user logon nor update (COMODO, for example uses Task Scheduler).

Virtually everything shipped with Windows in Task Scheduler is required for proper on-going system maintenance and functioning.

Blocking schtasks.exe or at.exe - apparently - doesn't block any of that.

 

Task Scheduler = taskschd.msc

schtasks.exe = command line utility to do the most of the same as Task Scheduler

 

I always wondered how blocking schtasks.exe did not block all the things you just mentioned. I will have to do some reading to learn the difference.

 

Ok, thank you! I will read more into it also.

 

Quick question about a few programs that I have yet to add to the guarded apps list and wanted to see if they should or need to be added before doing so.

dnscrypt-proxy.exe (the installed process of running dnscrypt through command prompt)
NVT ERP
NVT Radar Pro
Hitman Pro Alert
Windows Firewall Control
Malwarebytes (and formally malwarebytes anti-exploit however since I now us HMP I don't have it on my pc, but just curious)

Again, I've run Appguard for a while now with no problem and as they say if it ain't broken don't fix it, but I suppose I could be missing out on some overlooked security measures. Anyhow thanks for your time everyone.

 

AppGuard all by itself will protect physical system.

NVT ERP is good to monitor vulnerable processes - like interpreters and rundll32.exe.

HitmanPro.Alert protects the browser and is important for shellcode exploits.

WFC is the last line of defense and would alert user to app attempting to connect to network.

The additions you mention just supplement AppGuard and create a multi-layered security config. It is unlikely an attack could bypass each layer - that is the strategy.

 

Thanks for your reply.
Absolutely agreed, which is why I run them layered, but I was inquiring about actually adding those programs to the GuardedApps tab in the customized settings of Appguard and if it that would have any benefit security wise

 

I would add all security apps including its related modules (services, gui's, drivers) to Power Apps (not Guarded). This way they have free way to do their job.

 

Gotcha. I actually remember an old thread dedicated to just Appguard apps and I think you and I discussed this befroe, but I've since been testing other programs and completely forgot. Thanks for the reply!

 

You're welcome.

 

i wouldn't, unless absolutely necessary (if AG block their processes or features) ; putting them as power app will give them full power , and if exploited, full power to the exploit.

 

I agree. I have NVT ERP, HMP.A, HMP, WFC - and none are added to Power Apps.

I tested all of them in doing their intended job to protect system - and they all functioned without problem without adding to Power Apps.

I have nothing in Power Apps.

If need be, I lower AppGuard to Install, perform any needed update, and then re-enable Lock Down mode.

Once in a while you will see a block event to registry, log, dat, etc writes - but those don't break any functionality. Those are easy to allow by adding the path to Exception Folders - Read\Write.

 

Fair enough but I prefer adding them to Power Apps, because I "think" and "feel" exploitation of those security apps is highly unlikely.

 

Sorry, we couldn't recreate this. Though I do see that the list gets sorted differently each time.