When Installing Microsoft Teams Hips is triggered for signature 7066. I attempted to create an exception from the Threat Event, but HIPs still blocks it. Teams.exe triggers 7066, "Prevent Common Executable's From Running In User Profile Folder."
I have even tried adding Teams.exe in the Trust Applications Policy, but it still blocks it. When I turn HIPs off, it works just fine. So I am confused as to why a rule created from the threat event does not even work. Something seems to be triggering that is not being recorded in the event.
Thank you in advance for any advise.
Solved! Go to Solution.
Signature 7066 is a custom signature (not a McAfee default signature), so if you have a concern about the signature itself, you would need to contact your internal team that created the signature.
In regards, to the IPS exception issue you're asking about, I think it would be best to open a Service Request with McAfee Support to further discuss the specifics so that the event and exception details are not on public display. I suspect it's just a configuration issue with the IPS exception (compared to the IPS event details).
Adding a fix to my own submission.
Signature 7066 is a custom signature created by the over arching organization I support.
I was able to make the exception (created from the threat event) work by removing the description from the exception.
Hope this helps someone with a broken exception.
Signature 7066 is a custom signature (not a McAfee default signature), so if you have a concern about the signature itself, you would need to contact your internal team that created the signature.
In regards, to the IPS exception issue you're asking about, I think it would be best to open a Service Request with McAfee Support to further discuss the specifics so that the event and exception details are not on public display. I suspect it's just a configuration issue with the IPS exception (compared to the IPS event details).
The first thing you might want to check is to ensure the new policy has burned into the endpoint. Just because you hit save in the ePO doesn't mean that the updated policy is not applied on the Endpoint.
Good TTP when new policies are created for a problem (HIPS/ENS/VSE/PA) is to do one or more wakes--up on the endpoint and ensure you waited at least 5 minutes after saving in the ePO.
Example- In the ENS/HIPS Firewall, in a LAG/CAG name, we put the Date/Time stamp in the name, this way the end user can open the Firewall, view the LAG/CAG and see if the DATE/Time stamp changed in the rule name to ensure they have the latest and greatest change of policy. Nothing worst than trying to figure out why a exclusion or FW Signature isn't working when you know you did it right, only to find out the endpoint didn't get the change policy yet.
Adding a fix to my own submission.
Signature 7066 is a custom signature created by the over arching organization I support.
I was able to make the exception (created from the threat event) work by removing the description from the exception.
Hope this helps someone with a broken exception.
New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.
Thousands of customers use our Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership: