Trying to speak to this from a VSE perspective, I can assure you the AP log entry is correct - that IExplore.exe is opening the "counters.dat" file with an AccessMask that includes "Execute" privilege. And since the file exists in a folder that matches the rule definition... **\Temp*... you get a hit. But the rule is only set to warn so nothing is actually blocked.
If you didn't see the same behavior with 8.8 Patch 2, it sounds like either -
- IExplore.exe's behavior changed, perhaps in its AccessMask
- the AP rule has changed, being recently enabled for example.
Otherwise, it makes as much sense to me as it does to you .
We have a tool that will give us deeper insight into the calculation/evaluation of the rule being violated; we could look into that (via McAfee Support) and we'd need a comparable data collection with 8.8 Patch 2, assuming Patch 2 really is behaving differently.
I would also note......... I see this issue, only after upgrading to VSE 8.8 Patch 4. I currenlty have BOF Disabled, I still see it...We are in a mixed IE9 & IE11 Environment, Not sure yet if we see it on both. We are in the process of standardizing with IE11. As our IE11 Deployment is pretty much at the same time as the VSE 8.8 P4 Deployment. i would also note our IE Favorites are redirected to a network share, Not sure why this would have anything to do with it but who knows...
I do believe however, its an IE10 & IE11 issue as I believe they changed the index.dat situation....
I have not found a solution
Message was edited by: pwolfe on 4/21/14 6:07:15 PM GMT-08:00
We also observe thousands of events with counters.dat detected as run from TEMP by IE.
We consider this as false-positive, however it not possible to exclude .dat files, and excluding IE process is not a good idea.
No solution yet
Still hundreds and thousands of events.....
A year later and no solution? We updated to patch 4 this past Monday and we are getting lots of these events as well. Nothing in patch 2, but everything in patch 4. Something changed in patch 4 to allow this. Did somebody open up an SR?
Did someone found a workaround for those alerts? At least did someone build a SQL query to delete those events from the database?
*monday bump* No solution for this yet?
We see counters.dat events from both the "Common Standard Protection:Prevent common programs from running files from the Temp folder" and the "Anti-spyware Maximum Protection:Prevent execution of scripts from the Temp folder". The first one increased a lot since upgrading to VSE patch 4.
Still no solution to this? same issue appeared here on 8.8 patch 4
Having exact same issue as described in this topic. Anyone found a solution?
McAfee support ignores my ticket?