1 of 1 people found this helpful
No. You should not add those to the exclusions list. I would investigate why this is happenning. Usually this means you have malware attempting to modify those settings.
There was an issue with VSE 8.5i triggering an Access Protection rule but that has been fixed in later versions.
VsTskMgr triggers an Access Protection rule in VSE 8.5i when attempting to update Sitelist.xml
Access Protection Rules trigger when installing the McAfee Agent
Funny enough I am trying to update the sitelist.xml (I am migrating users from an old ePO to a new ePO server by force install the agents.
But this is with VSE 8.8 and Agent 4.5 to agent 4.6.
Ill keep looking into this, its not every user, out of 400 only a handful are generating these, but some are having issues updating dat's so maybe it is sitelist.xml related as well.
Ok I have reset my policy excecptions back to mcafee defaults, i originally removed mfeann.exe and vstskmgr.exe from the exclusions (i had added to try to supress these.).
The McAfee default includes mfeann.exe in the exception listing so removing this was a very bad idea! went from 20,000 threat events to review to 250,000 threat events in the space of a few hours...
will investigate the vstskmgr.exe issue.
I am recieving numerous alerts also. I am getting them for 8.8 P1 and 8.7 P5 with hotfixes HF638179 and Hotfix 643440. Most of mine are triggered by and in house application but there are others.
I replaced the application with "appx.exe"
appX.exe C:\Program Files\McAfee\VirusScan Enterprise\VsTskMgr.exe Common Standard Protection:Prevent termination of McAfee processes Action blocked : Terminate
appX.exe C:\Program Files\Network Associates\Common Framework\naPrdMgr.exe Common Standard Protection:Prevent termination of McAfee processes Action blocked : Terminate
appX.exe C:\Program Files\McAfee\VirusScan Enterprise\mfeann.exe Common Standard Protection:Prevent termination of McAfee processes Action blocked : Terminate
appX.exe C:\Program Files\Common Files\McAfee\SystemCore\mcshield.exe Common Standard Protection:Prevent termination of McAfee processes Action blocked : Terminate
appX.exe C:\Program Files\Network Associates\Common Framework\FrameworkService.exe Common Standard Protection:Prevent termination of McAfee processes Action blocked : Terminate
I moved some lab machines to a group where I had a policy to say log only .. don't block.. I enforced the policy and observed warns events in the log ... But the Mcafee services never went down.. so this seems to prove that appx.exe is not really trying to stop the Mcafee services. For overnight I have excluded appx.exe from "Common Standard Protection:Prevent termination of McAfee processes".
I think this is a 8.7 P5 re-release and hotfixes and 8.8 P1 issue. I am going to do more testing but I recomend others check the amount of access protection events you are recieving before your EPO database files up.
I am going to open a case with Mcafee when I get more data tommorow but I think this is a big problem.
The Access Protection rule you're seeing get violated checks for the permission level being sought by the offending process.
We don't check whether a termination attempt is occurring, we check and take the configured action based on the level of access that process has requested.
Thus, if you set the rule to warn and not block, you more-than-likely won't see the targeted process get terminated. It's not trying to do that, but it is seeking the ability to be able to do so - and that's why the rule is violated.
We can't let the attainment of that privilege to go unnoticed, because if we do, it'll be too late to try and stop that process if they do decide to terminate us.
To reduce the noise you'll need to decide whether you can trust that application or not. If not, and you can't live with the noise, disable the "Report" option in the rule configuration. Or, you could engage the vendor of that application and find out why they are acquiring the TERMINATE process privilege when they don't need it.
Thanks for your reply wwaren, I think there is more to it than this .. My entire EPO databased doubled in 1 night since I checked in the 8.7 hotfixes.
I turned off self protection (for only lab computers) , I then turned off logging... in both cases Mcafee services remain running.
I ran a report on Event 1092, I used the eval group to upgrade some computers to the hotfixes before Dec 4, you can see below that when I moved the packages to current, these events grew.
Threat Events Day 390 23-Nov 2533 24-Nov 24585 25-Nov 910 26-Nov 546 27-Nov 45032 28-Nov 68957 29-Nov 69018 30-Nov 85974 1-Dec 87503 2-Dec 1991 3-Dec 49035 4-Dec Checked in 8.7 hotfixes 4307342 5-Dec 4158901 6-Dec 2375805 7-Dec
I respectfully disagree, something is wrong with the hotfixes for 8.7 and 8.8 P1. I have openned a case with Mcafee.
If it's only happening in a few environments, I(we) need to find out if we have a policy incorrect.
I encourage others to see if they have seen such a growth in these events.
I guess I have to withdraw my "respectfully disagree" . I openned a case with Mcafee. The application we use is a desktop shell for limited access to the desktop. The explantation wwarren gave is similar to Mcafee.
"Appx.exe is trying to get elevated permission". I suspect each log on, log off was causing these events.
The confussion in the self protection is that I thought if I excluded a process it would shut down MCafee services... in my case, I proved my good application does not. You won't know until you test it.
The next step is that I am going to remove the VS 8.7 hotfixes and VS 8.8 P1 from some test machines and see if the events continue.
By my excluding the "appx.exe" process, my events have gone down from 250,000 per hour to less than 100 per hours... I ran a purge of events 1092 for 14 days before... phew SQL database explosion averted .
To others with these types of events, you may have home grown applications that look like they are trying to stop Mcafee services. I suggest exporting the Threat Event log for event 1092 (or other execessive events) and look at the data for the man source.
You may have had some events before but much much more after the patches/hotifxes.
Each one will have to be testing investigated to see if it really is trying to terminate Mcafee processes.