Solved! Go to Solution.
@User91352085 Do you have a default/high/low risk process policy enabled? If so, and you are only putting this exclusion into your "default process policy", but have not placed it into your "high risk" policy set, or "low risk" (in the event you have scanning enabled there; unnecessary if scanning is disabled), then you have gaps in your exclusion attempt and this is highly likely to be the cause of your detection.
In the event this is not the case, then we may need a copy of your policy .xml in order to review your configuration.
Was my reply helpful?
If this information was helpful in any way, or answered your question, will you please select "Accept as Solution" in my reply, or give kudos as appropriate, so together we can help other members?
A few things to check:
1. What happens if you create an EICAR as a .txt file instead of .com? You may want to check your VSE policy and ensure you have it set to detect all file types and not just specific ones. On that note it's also worth checking you don't have an exclusion for a certain file type
2. Do you see you policy settings applied to the system if you check the local VSE console?
Thank you for the response. Creating EIRCAR.txt has the same result as EIRCAR.com.
I can confirm that the on-access scan policy is set to detect all file types and "Overwrite client exclusions" is enabled.
Despite being an Administrator in ePO I am unable to unlock/view certain VSE interface options on my local machine. However if I log in as a local administrator I can view the exceptions etc. (is that a feature?)
I can confirm that the exceptions defined in ePO are appearing on the local client - I can't count how many times have confirmed the file path/spelling etc.
Based on the McAfee log files, it is definitely On-Access Scanning that is removing the files rather than any DLP policy etc.
The removal occurs regardless of whether I create the files as local admin or not.
What I have noticed is that being logged in as local admin, the files SEEM to take longer to be detected - I'm able to open the EIRCAR.txt a few times before it gets wiped - by all accounts it still seems to be on-access scanning that detects it. When I check the Threat Event log in ePO - I can see the incidents but the "Exception" colmn is always blank.
😞
"Despite being an Administrator in ePO I am unable to unlock/view certain VSE interface options on my local machine. However if I log in as a local administrator I can view the exceptions etc. (is that a feature?)" > Indeed, this is as per design. Only administrators can view the settings within VSE console.
Is the location you dropping the EICAR local?
What does you exclusion look like? What does the exact Threat Event Log entry for file location state?
Yes, the file is being created on my local machine:
C:\excludedfolder
My machine is the only machine in a new policy I created in ePO for testing purposes - the intention to use this for all Pentesting workstations. It was a duplicate of our our default policy.
Exception is simply defined by name/location: C:\excludedfolder\ (also exclude subfolders). Exclude on read/write are both checked.
Threat Event Log detects:
Threat Target File Path: C:\excludedfolder\eircar.com
Please note, for the benefit of this forum post I am referring to the folder in question as "excluded folder" - that is not what it is called on my system or in the exception (but the 2 diefinitely match, I've even copied from Threat Event Log and pasted into the exclusions list) I'd hope this is unlikely but are there any specific folder names that McAfee would ignore exlclusions for i.e. c:\iamavirus\
As part of investigation, I saved the file in a pre-existing excluded folder (duplicated when I created this new policy):
%programdata%\appname\
The same this is occuring - it is not just an issue with my specific exclusion 😞
@User91352085 Do you have a default/high/low risk process policy enabled? If so, and you are only putting this exclusion into your "default process policy", but have not placed it into your "high risk" policy set, or "low risk" (in the event you have scanning enabled there; unnecessary if scanning is disabled), then you have gaps in your exclusion attempt and this is highly likely to be the cause of your detection.
In the event this is not the case, then we may need a copy of your policy .xml in order to review your configuration.
Was my reply helpful?
If this information was helpful in any way, or answered your question, will you please select "Accept as Solution" in my reply, or give kudos as appropriate, so together we can help other members?
Feel very sheepish. Yes, yes we do. low and behold adding further exceptions to the high-risk policy has resovled the problem.
Thank you!
@User91352085 Very glad we were able to get it resolved!
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA