Hi,
It seems like each time we upgrade to a newer version of ENS on Windows sytems (most recently from ENS 10.6.1 February Update to ENS 10.6.1 April update, and from ENS 10.6.1 April update to ENS 10.6.1 June update PoC on a handful of machines), the first time we log into one of those systems with an account with admin rights we see a bunch of "access denied" messages scrolling by in a command window. Most often they scroll by and disappear before anyone can screenshot them, but a couple fo times we've manged to capture part of the output. I've attached one of the screenshots. What is causing this?
Thanks,
Chris
Hello @cpborders ,
As per the screenshot it seems the command prompt is running without admin privilege, and any task running within this cmd if it requires authorization then it will fail.
1. The upgrade > Are you trying to invoke the setup from cmd ?
- If yes then open cmd with administrator and then give it a try.
2. Are you running the standalone installation of ENS ? or deploying from EPO.
If standalone, you have to verify the logs in windows and user temp for ENS update.
- If upgrading from epo then Masvc and McScript logs within programdata\mcafee\agent\logs will help you to find the cause of failure.
Hello @YashT
These are all ePO-managed deployments. As to how the installs were affected, we're not trying to invoke from CMS. In some cases it is an upgrade job I run from ePO against the system, in other cases I have built a package containing ENS and the ePO agent that we execute locally on brand new systems. I think on all of the affected systems the package that we execute locally may have been used, but I am not sure.
I will have a look at those log locations and post any findings.
Hello @cpborders
Thanks for your post.
I m not sure but could be the issue with the Package which is already used.
Please try to check the logs and see how it goes.
Was my reply helpful?
If you find this post useful, please give it a Kudos! Also, please don't forget to select "Accept as a Solution" if this reply resolves your query!
@vivsI checked, but it looks like any pertinent log data has already rolled over. Are there any other locations I should take a look at
@vivsI looked in the Endpoint Security self-protection activity log. I think the output below is pertinent. I simply logged into the system as the user listed below; I did not "run" cmd.exe; it started running as soon as I logged in.
5/21/2020 10:36:58 AM mfeesp(4856.9900) <SYSTEM> ApBl.SP.Activity: AACC\is-cpborders ran C:\Windows\System32\cmd.exe, which tried to access the file C:\ProgramData\McAfee\Endpoint Security\McAfeeSettingsBackup\ESP\ESP_Config_Setting.xml, violating the rule "Core Protection - Protect core McAfee files and folders", and was blocked. For information about how to respond to this event, see KB85494.
5/21/2020 10:36:58 AM mfeesp(4856.9896) <SYSTEM> ApBl.SP.Activity: AACC\is-cpborders ran C:\Windows\System32\cmd.exe, which tried to access C:\ProgramData\McAfee\Endpoint Security\McAfeeSettingsBackup\ESP\, violating the rule "Core Protection - Protect core McAfee files and folders", and was blocked. For information about how to respond to this event, see KB85494.
5/21/2020 10:36:58 AM mfeesp(4856.9896) <SYSTEM> ApBl.SP.Activity: AACC\is-cpborders ran C:\Windows\System32\cmd.exe, which tried to access the file C:\ProgramData\McAfee\Endpoint Security\McAfeeSettingsBackup\TP\TP_Config_Setting.xml, violating the rule "Core Protection - Protect core McAfee files and folders", and was blocked. For information about how to respond to this event, see KB85494.
5/21/2020 10:36:58 AM mfeesp(4856.9900) <SYSTEM> ApBl.SP.Activity: AACC\is-cpborders ran C:\Windows\System32\cmd.exe, which tried to access C:\ProgramData\McAfee\Endpoint Security\McAfeeSettingsBackup\TP\, violating the rule "Core Protection - Protect core McAfee files and folders", and was blocked. For information about how to respond to this event, see KB85494.
5/21/2020 10:36:58 AM mfeesp(4856.9896) <SYSTEM> ApBl.SP.Activity: AACC\is-cpborders ran C:\Windows\System32\cmd.exe, which tried to access C:\ProgramData\McAfee\Endpoint Security\McAfeeSettingsBackup\, violating the rule "Core Protection - Protect core McAfee files and folders", and was blocked. For information about how to respond to this event, see KB85494.
5/21/2020 10:36:58 AM mfeesp(4856.9908) <SYSTEM> ApBl.SP.Activity: AACC\is-cpborders ran C:\Windows\System32\cmd.exe, which tried to access C:\ProgramData\McAfee\Endpoint Security\RenamedLogcfg\Logcfg\, violating the rule "Core Protection - Protect core McAfee files and folders", and was blocked. For information about how to respond to this event, see KB85494.
5/21/2020 10:36:58 AM mfeesp(4856.9904) <SYSTEM> ApBl.SP.Activity: AACC\is-cpborders ran C:\Windows\System32\cmd.exe, which tried to access C:\ProgramData\McAfee\Endpoint Security\RenamedLogcfg\, violating the rule "Core Protection - Protect core McAfee files and folders", and was blocked. For information about how to respond to this event, see KB85494.
5/21/2020 10:36:58 AM mfeesp(4856.9900) <SYSTEM> ApBl.SP.Activity: AACC\is-cpborders ran C:\Windows\System32\cmd.exe, which tried to access C:\ProgramData\McAfee\Endpoint Security\, violating the rule "Core Protection - Protect core McAfee files and folders", and was blocked. For information about how to respond to this event, see KB85494.
I did some tests today to see if this issue follows the manner in which I am installing the agent and ENS. Long story short, it does not. Between each step I used the removal tool, rebooted, reinstalled, rebooted, logged in as a non-privileged user, signed out, then logged in as a privileged user where I would receive the "access denied" messages scrolling in a command window. For the purposes of testing I logged into the system with the same privileged user account that I have noted using in items 1 and 2 below. I've attached screenshots numbered for each step of what I could capture.
1. Manually install the package I had built containing both the ePO agent and ENS on the system. This required privileged user credentials.
2. Install agent package I had created via News Systems --> create and download installation package in ePO. This required privileged user credentials. Then I used an ePO job to push ENS to the system.
3. Push agent to system via New Systems --> push agents and add to ePO system tree. This used a service account that is not the same as the privileged user account mentioned in the above. The I used an ePO job to push ENS to the system.
It seems counter intuitive to me that I would not receive these "access denied" messages when I log in to the system as a user without administrative rights, yet I do receive these messages when I log in to the system as a user with administrative rights. I would have expected the opposite to have been true.
3rd screenshot.
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA