cancel
Showing results for 
Search instead for 
Did you mean: 
pierce
Level 13
Report Inappropriate Content
Message 1 of 8

VsTskMgr.exe and mfeann.exe producing tons of access protection events

Jump to solution

Just reviewing my access protection logs and since the 1st of this month I have 20,000 a day alerts for vstskmgr.exe and mfeann.exe tiggering the policy: Common Standard Protection:Prevent modification of McAfee files and settings

Should I just add these 2 processes to the exception list for this rule?

thanks,

Pierce

1 Solution

Accepted Solutions
McAfee Employee wwarren
McAfee Employee
Report Inappropriate Content
Message 6 of 8

Re: VsTskMgr.exe and mfeann.exe producing tons of access protection events

Jump to solution

Hi Folks,

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.

William W. Warren | S.I.R.R. | Customer Success Group | McAfee
7 Replies
bakerrl
Level 11
Report Inappropriate Content
Message 2 of 8

Re: VsTskMgr.exe and mfeann.exe producing tons of access protection events

Jump to solution

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

https://kc.mcafee.com/corporate/index?page=content&id=KB51126&actp=search&viewlocale=en_US&searchid=...

Access Protection Rules trigger when installing the McAfee Agent

https://kc.mcafee.com/corporate/index?page=content&id=KB53365&actp=search&viewlocale=en_US&searchid=...

pierce
Level 13
Report Inappropriate Content
Message 3 of 8

Re: VsTskMgr.exe and mfeann.exe producing tons of access protection events

Jump to solution

Thanks bakerrl,

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.

pierce
Level 13
Report Inappropriate Content
Message 4 of 8

Re: VsTskMgr.exe and mfeann.exe producing tons of access protection events

Jump to solution

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.

Highlighted

Re: VsTskMgr.exe and mfeann.exe producing tons of access protection events

Jump to solution

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.

McAfee Employee wwarren
McAfee Employee
Report Inappropriate Content
Message 6 of 8

Re: VsTskMgr.exe and mfeann.exe producing tons of access protection events

Jump to solution

Hi Folks,

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.

William W. Warren | S.I.R.R. | Customer Success Group | McAfee

Re: VsTskMgr.exe and mfeann.exe producing tons of access protection events

Jump to solution

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 EventsDay
39023-Nov
253324-Nov
2458525-Nov
91026-Nov
54627-Nov
4503228-Nov
6895729-Nov
6901830-Nov
859741-Dec
875032-Dec
19913-Dec
490354-DecChecked in 8.7 hotfixes
43073425-Dec
41589016-Dec
23758057-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.

Re: VsTskMgr.exe and mfeann.exe producing tons of access protection events

Jump to solution

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.


More McAfee Tools to Help You
  • Subscription Service Notification (SNS)
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • eSupport: Policy Orchestrator
  • Community Help Hub

      New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

    • Find Forum FAQs
    • Learn How to Earn Badges
    • Ask for Help
    Go to Community Help

    Join the Community

      Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

    • Get helpful solutions from McAfee experts.
    • Stay connected to product conversations that matter to you.
    • Participate in product groups led by McAfee employees.
    Join the Community
    Join the Community