cancel
Showing results for 
Search instead for 
Did you mean: 

ENS: Adaptive Threat Protection not triggered

Jump to solution

Hi.

Most likely I did everything wrong.

For example, I want to make ENS triggering on actions like modifying extension or creating files with .exe, .vbs, .bat extensions.

After I turn on there rules and tried to simulate by myself to provocate ENS triggering - I had nothing.

I tried to create files with with .exe, .vbs, .bat extensions or modified extension.

1 Solution

Accepted Solutions
McAfee Employee akatt
McAfee Employee
Report Inappropriate Content
Message 2 of 5

Re: ENS: Adaptive Threat Protection not triggered

Jump to solution

It would appear we are referring to an Access Protection rule, as opposed to configuration of Adaptive Threat Protection, correct?  If yes, then the following should help:

 

1.  Drill down into the ENS Access Protection policy

2.  Create a new Access Protection rule:
         --Give it a name
         --Select Report (never block using custom rules until the behavior can be reported)
         --Click "Add," under the Executables section, and enter a rule name (Example:  Block .BAT)
         --Select Include and enter * for the File name or path (this translates to monitor all processes)
         --Save and then scroll down to the Subrules section, and click Add
         --Give the subrule a name, and for the Subrule type, select Files
         --Select the desired operations we want to prevent (Example:  Select write)
         --For the Targets section, click Add, and make sure the Inclusion status is set to Include
         --Make sure the drop down menu is set to "File path."
         --For the "File, folder name, or file path" field, enter:  *.BAT
            --NOTE:  For this same field, you can also enter something like  *.BAT, *.COM, *.EXE, *.ETC if our intentions are to target multiple file extensions for preventing write activity.
           --NOTE:  Make sure here that the inclusion status is NOT set to EXCLUDE.  Otherwise for any process, we would be saying to ignore the write activity to the designated extensions, but block for all other extensions.
           --Save the sub-rule and the save out of the policy, and then assign that policy to some test systems, so that we can begin to log violations and determine the behavior of the rule.

**WARNING**
Access Protection is quite powerful, in that if you want, you can block all processes from performing any read/write activity.  Don't do that.  It becomes less risky with ENS due to built-in McAfee Agent trust, but with something like VirusScan Enterprise, you can "brick" a system and no longer will you be able to access Windows, until the product can be removed or disabled within safe-mode without networking.

Always use caution with custom rules, and always ONLY set the Report function until logging and events can be obtained and reviewed, to determine if the rule might cause any unwanted issues.  We can easily set the block when desired.

The above rule will effectively prevent write access to any .BAT file (or multiple extension-types if added), by any process.  Since we are monitoring all processes, we have to be very careful about selecting the "Read" operation as an operation to prevent.  For example, never set the rule to monitor all processes, and then also set the sub-rule to include *, and then also select the read option.  In doing so, we are telling Access Protection to prevent all read access of any process for any file-type...this can be disasterous. 

Another gotcha (which is briefly mentioned above), is the Inclusion/Exclusion status for the file-types defined within the sub-rule.  If we create a rule for all processes, and then also define something like *.txt within the sub-rule for the file path, we are saying that we want AP to monitor all processes that access .txt files, and then of course we would select the actual operations we want to monitor/prevent.  No worries here.  However, if we simply switch that Include status within the sub-rule to Exclude, we have effectively whitelisted processes that access .txt files, but in-turn we are blocking the processes from performing the selected operations with all other file-types.

Apologies for the lengthiness, but just want to ensure that I am not handing anyone a loaded gun.  Always keep the safety on unless ready to fire, by using the Report option only, and if assistance is needed with understanding the generated events, we can certainly help explain.


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?





4 Replies
McAfee Employee akatt
McAfee Employee
Report Inappropriate Content
Message 2 of 5

Re: ENS: Adaptive Threat Protection not triggered

Jump to solution

It would appear we are referring to an Access Protection rule, as opposed to configuration of Adaptive Threat Protection, correct?  If yes, then the following should help:

 

1.  Drill down into the ENS Access Protection policy

2.  Create a new Access Protection rule:
         --Give it a name
         --Select Report (never block using custom rules until the behavior can be reported)
         --Click "Add," under the Executables section, and enter a rule name (Example:  Block .BAT)
         --Select Include and enter * for the File name or path (this translates to monitor all processes)
         --Save and then scroll down to the Subrules section, and click Add
         --Give the subrule a name, and for the Subrule type, select Files
         --Select the desired operations we want to prevent (Example:  Select write)
         --For the Targets section, click Add, and make sure the Inclusion status is set to Include
         --Make sure the drop down menu is set to "File path."
         --For the "File, folder name, or file path" field, enter:  *.BAT
            --NOTE:  For this same field, you can also enter something like  *.BAT, *.COM, *.EXE, *.ETC if our intentions are to target multiple file extensions for preventing write activity.
           --NOTE:  Make sure here that the inclusion status is NOT set to EXCLUDE.  Otherwise for any process, we would be saying to ignore the write activity to the designated extensions, but block for all other extensions.
           --Save the sub-rule and the save out of the policy, and then assign that policy to some test systems, so that we can begin to log violations and determine the behavior of the rule.

**WARNING**
Access Protection is quite powerful, in that if you want, you can block all processes from performing any read/write activity.  Don't do that.  It becomes less risky with ENS due to built-in McAfee Agent trust, but with something like VirusScan Enterprise, you can "brick" a system and no longer will you be able to access Windows, until the product can be removed or disabled within safe-mode without networking.

Always use caution with custom rules, and always ONLY set the Report function until logging and events can be obtained and reviewed, to determine if the rule might cause any unwanted issues.  We can easily set the block when desired.

The above rule will effectively prevent write access to any .BAT file (or multiple extension-types if added), by any process.  Since we are monitoring all processes, we have to be very careful about selecting the "Read" operation as an operation to prevent.  For example, never set the rule to monitor all processes, and then also set the sub-rule to include *, and then also select the read option.  In doing so, we are telling Access Protection to prevent all read access of any process for any file-type...this can be disasterous. 

Another gotcha (which is briefly mentioned above), is the Inclusion/Exclusion status for the file-types defined within the sub-rule.  If we create a rule for all processes, and then also define something like *.txt within the sub-rule for the file path, we are saying that we want AP to monitor all processes that access .txt files, and then of course we would select the actual operations we want to monitor/prevent.  No worries here.  However, if we simply switch that Include status within the sub-rule to Exclude, we have effectively whitelisted processes that access .txt files, but in-turn we are blocking the processes from performing the selected operations with all other file-types.

Apologies for the lengthiness, but just want to ensure that I am not handing anyone a loaded gun.  Always keep the safety on unless ready to fire, by using the Report option only, and if assistance is needed with understanding the generated events, we can certainly help explain.


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?





Highlighted

Re: ENS: Adaptive Threat Protection not triggered

Jump to solution
Thank you!
I did all what you said with policy.
I created test folder with files: test.vbs, test.exe, test.ps1, test.bat.
And ENS: Threat Prevention only reported not blocked. All files successful ran and modified without any blocking.
McAfee Employee akatt
McAfee Employee
Report Inappropriate Content
Message 4 of 5

Re: ENS: Adaptive Threat Protection not triggered

Jump to solution

@Schopenhauer Great!  So, the reporting confirms that the actions are now successful.  To enforce the block, we would need to edit the rule, and then select the block option.  Of course, based on the reporting, we just want to make sure that no wanted applications would be prevented from performing normal operations, so if necessary, only apply the block policy to a test system, and then review the behavior after setting the block.


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?

Reliable Contributor Daveb3d
Reliable Contributor
Report Inappropriate Content
Message 5 of 5

Re: ENS: Adaptive Threat Protection not triggered

Jump to solution

ATP only triggers on contained applications.  Depending upon your configuration, this is probably when the process reputation is untrusted.  So if you are just doing general activity you'll want to use Access Protection or Expert rules.  

More McAfee Tools to Help You
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • Visit: Business Service Portal
  • More: Search Knowledge Articles
  • ePolicy Orchestrator Support
  • The McAfee ePO Support Center Plug-in is now available in the Software Manager. Follow the instructions in the Product Guide for more.