VSE8.7 latest patch
VSE8.8 latest patch
Why is it that i keep getting following in EPO, well i do know why but could i have it explained
example of an Automatic Response rule
Common Standard Protection:Prevent termination of McAfee
Common Standard Protection:Prevent modification of McAfee files
Common Standard Protection:Prevent modification of McAfee
Common Management Agent files and settings
Then when looking further into the above rule, found following
Processes attempting to Terminate McAfee processes
Processes attempting to Modify McAfee files
1) Are these processes meant to be trying to modify/terminate the McAfee files/processes and if so why?
2) If these processes aren’t meant to be trying to modify/terminate the McAfee files/processes why is VirusScan not detecting them as spyware/virus infections?
Could i just have explained why this happens
I mean create exclusions for them all isnt really theway forward, there must be a explaination to this
Hoping to hear something back
thanks in advance
Some of them would be expected
avast.setup - Avast AV install attempting to uninstall McAfee
6784xdat.exe - DAT update
JetClean.exe, regseeker.exe - Registry clean up tools attempting to access McAfee registry entries
Others i would be more worried of and suggest a virus or malicious software attempting the disable McAfee to prevent detection.
Well the Avast is of'course as you also did say something to expect
The weird thing here is that i have used Getsusp, done full ODS, used malwarebytes but nothing detected
Hmmm now i did a search for the rool1_pk.exe and found (in German) http://www.istdiesedateisicher.de/sha1/B349C5CD5A320279457D8F0BE1E7505070395882_details.aspx
Guess i need to start yet another scan on the system(s)
But what i dont really get is why something like Adobe_Updater.exe would attempt to terminate mcafee processes
The AP rule to prevent termination of McAfee processes is activated whenever we see a process try to interact with one of our protected processes, and explicitly seeks the access mask called TERMINATE_PROCESS, which is a flag the programmers of the 3rd party process pass along in their request for gaining access/info from our protected process.
It's a behavior that processes do not need to engage in but has perhaps become a fairly common programming practice because "nobody cares" to be more particular about the access level they're seeking/acquiring, even to do mundane things in their program, not actually intending to terminate the process.
Well, this AP rule in VSE is here to change that way of thinking because it's not a secure way to program. And of course, it's there to protect our software from malicious coders who would do the same thing but actually intend to terminate us. VSE can't distinguish who's malicious or not, so we block everybody - but we give you the ability to make that choice, by means of exclusions.
You have options available to you to reduce the number of events being generated. You can disable reporting of the event (an ePO tweak), or of the rule itself (a VSE policy tweak), or you can trust the 3rd party process and add it as an excluded process for the specific rule.
And/or, you can take up a request with your 3rd party vendor whose process is unnecessarily seeking the TERMINATE_PROCESS privilege, and tell them not to do that when the privilege is never going to be exercised.
Thank you so much for explaining this to me (and others, i cant be the only one wondering)
This was what i was looking for.
Well as you did say, tweak in EPO, tweak the rule itself or exclusions. Or contact 3rd party might be a pain in the ....
I think working through the list and exclude all known and then lets see what action will be on the rest.
Download the new ePolicy Orchestrator (ePO) Support Center Extension which simplifies ePO management and provides support resources directly in the console. Learn more about ePO Support Center