Tuning AV Exclusions with ProcMon

[robg3381]

So I'm trying to troubleshoot a situation where a server admin is claiming McAfee AV is causing some performance impact on a server.  As such, I got onto the server and ran Process Monitor for a little while.  I still am seeing McShield listed as the process hitting certain path's which I entered into that policy.  I can confirm the policy is applied to the endpoint by looking at the policy locally in ENS on the machine. 

What I'm wondering here is if I'm looking at ProcMon incorrectly or something.  What "operations" (in ProcMon) are to be to consider McShield as "scanning" the file/folder?  I see several entried for QueryOpen, CreateFile, & CloseFile.  I'm interpreting this as "scanning".  Am I incorrect? 

Any clarification would be helpful.

[vnaidu]

@robg3381 

If you are using VSE then follow the KB article for information on how to use Procmon KB5098 and KB50981. You may also find the below link which might be of a good help.

https://service.mcafee.com/webcenter/portal/oracle/webcenter/page/scopedMD/s55728c97_466d_4ddb_952d_...

[robg3381]

Thanks Venu.  But I'm not sure this addresses my question.  Also I'm on ENS (posting in the ENS community) 10.6.  There is no KB5098, but I have checked KB50981 prior to posting and it provides an example of operation contains IRL_MJ_READ, but no context in terms of if that means the file is being "scanned" by mcshield.  TS102057 (link you provided) mostly just provides information on how to capture a procmon (which isn't an issue).

When I trigger a manual scan of a directory, I see a series of the following operations on the directory.  What I'm looking for is someone that might be more familiar with this and can tell me if one (or all) are indicative of Mcshield "scanning" a file/folder. 

FASTIO_NETWORK_QUERY_OPEN

IRP_MJ_CLOSE

IRP_MJ_CLEANUP

FASTIO_QUERY_INFORMATION

IRP_MJ_CREATE

IRP_MJ_SET_INFORMATION

IRP_MJ_CLOSE

IRP_MJ_DIRECTORY_CONTROL

[vnaidu]

@robg3381 

Dear Rob,

I think you are getting confused or deviated, the examples that you have mentioned are nothing to do with McShield.exe as it tries to scan an object during I/O operations. And to clarify your question, I have to take an example within the list you have provided. Please be informed that the below is what happens. 

IRP_MJ_CLEANUP is sent when the last user handle is closed;
when the last reference goes away and the FILE_OBJECT is
about to be torn down, IRP_MJ_CLOSE is sent. You can
receive I/O requests from kernel components between IRP_MJ_CLEANUP
and IRP_MJ_CLOSE.

[akatt · Accepted solution]

IRP_MJ_READ would be an indication that McShield had a need to check the file, which we would then assume was due to a need to "scan" the file.

The provided list of advanced procmon outputs are all indicators that McShield was asked to read a file, but just because McShield performs these actions, doesn't necessarily mean that a scan took place.  My personal opinion is that we could have done a much better job with the KB.

When implementing file/folder exclusions, McShield still has to read the excluded files/folders in order to determine whether or not those files/folders should then be passed to the engine for scanning against the DATs (as the engine resides within McShield, and the DATs are loaded within the engine). 

When using file-type exclusions, or when using the low-risk processes policy to define a process, and also when unchecking scan on read/write within the low-risk processes policy, McShield is never asked to check the exclusions, as the Anti-Virus filter driver is intelligent enough to ignore activity incurred by the excluded file-types or low-risked processes, and as such McShield is never asked to check (read) the files with the excluded type, or the disk activity incurred by the low-risked process.

Procmon is still very useful, though, to hunt for exclusions, but personally I have always directed customers to just use the standard Procmon output, and simply check McShield reads against any files or folders.

To help with comparing results, you could first implement a file exclusion for a test.txt file, and then collect a Procmon with advanced output while causing activity with the excluded file.  Then, instead of a file exclusion, use a file-type exclusion for txt files, and record the results.

You could also consider using the McAfee Profiler, which only shows you what all is being scanned (things that are actually passed to the engine for scanning):
https://kc.mcafee.com/corporate/index?page=content&id=KB69683

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?

[robg3381]

Thanks akatt.  What you wrote made sense.  I'll have to re-review what I'm seeing as I had implemented a "test" policy which I put in a few processes as low-risk and then on the low-risk policy, unchecked the scan on read/write.  After I implemented the policy on the system I was still seeing procmon activity for it which confused me and I thought perhaps Mcshield (like you said) was asked to check a file - but not necessarily an indicator that it in fact was scanned. 

Would you recommend then a combination of ProcMon and Profiler?  I started using Profiler and was advised to instead use ProcMon as it details more overall activity, but perhaps Profiler is the better tool for confirming that mcshield actually scanned it?  But if we're looking for defining processes and paths needing to be excluded, maybe using ProcMon is a better tool?

[akatt]

@robg3381 

Just to concur with Jess, yes, Profiler is normally the "go-to" for checking whether or not implemented exclusions are working as intended.  Procmon, in my mind, is more of a hunting utility for when we are not too sure what exclusions might help with a scanning performance issue.  There are often times when I also want to see absolutely all registry/network/file activity that is happening on the system, and of course Procmon is great for that.  Profiler won't show us that perhaps another real-time scanning product is enabled, and the two applications are fighting for file access, and the system is incurring a large performance hit due to that.

In terms of the low-risk process additions that you mentioned, make sure that the OAS policy to first enable the default/low/high-risk feature is set.  I often see this missed, since ePO allows modification of all policies at any time.

For VSE, the option is within the Default Processes Policy in ePO, or it can be accessed through the properties of the On-Access Scanner within the local VSE console.

For ENS, the option is within the On-Access Scan policy under "Process Settings," or within the local console under the Threat Prevention>On-Access Scan section.

It will list as "Configure different settings for High risk and Low Risk."

[jess_arman]

@robg3381 I would second akatt's recommendation of utilizing McAfee Profiler in order to test your exclusions. ProcMon can be misleading as McShield is a front process for a many actions of the "scanner", and is not limited to an actual scan of files. Often you may see McShield touching a file in ProcMon, but it isn't always clear what was a scan, and what is an examination of the file to check for exclusion matching. 

McAfee Profiler will only output information about what is gettings scanned--so if it's showing in the relevant parts of the report, then there are gaps in the exclusion.

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?