Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 15 subscribers
  • Views 5308 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Endpoint Protection not applying global exclusions

TheDrew2022

Evening,

I recently came across an issue I can't figure out how to resolve.

We have an add-in for Excel that causes Sophos Endpoint to kill the program with a "StackExec" (MemProt) exploit prevented in Excel. Up until now we've just added the detection ID to the list of exclusions and it's worked fine. Within 2-3 minutes the clients stop reacting.

This evening I was told by staff the StackExec exploit is back so I added another detection ID exclusion but this time, my endpoint clients didn't pickup the exclusion. I did some testing, tried forcing the endpoint client to redownload policy per a KB from the self help tool. Didn't work.

The only way I could get the exploit prevention to not detect Excel as malicious was to temporarily turn off tamper protection and then disable exploit prevention. Obviously not a solution by any means, and we can't disable exploit prevention across the entire company just to satisfy the accounting team, so I need a fix as the add-in for excel ties into our accounting database and they need the tool to run reports.

As to when this started, we just noticed today after I went to add the exclusion.

Any help or insight is really welcome on this issue as I don't need my boss (IT Director) and the entire accounting team breathing down my neck wanting answers. And yes, we are waiting for the add-in dev to fix the thing but there's no eta of when that will happen.



This thread was automatically locked due to age.
Parents
  • 0

    Morning Glenn,

    I just tried the updated hotfix and it didn't help. Looking at the release notes my issue sounds similar to WINEP-38405 "Resolved an issue where we couldn't exclude some applications from lockdown mitigation by adding a new thumbprint type." except in my case this is "StackExec (MemProt)" mitigation causing the issue.

    I am aware the detection ID does change for this particular issue, and we've added each new detection ID as it changes. Normally I just find the updated detection in Sophos central, add the exclusion by detection ID and things work fine. That's what didn't happen last night, the added exclusion never applied to tested clients despite being listed.

    Last night for testing I also excluded excel from StackExec mitigation, by adding a global exclusion for excel and making sure StakExec (MemProt) was greyed out so disabled. I even tried excluding Excel from any mitigations (greyed out Protect Application), still didn't take.

    As an aside, I've tried to login to the support portal to open a ticket but I'm one of those unlucky folks who's registered (have the email saying I am) but when I go to login, the portal punts me back to the registration form, which if I fill out, says I'm already approved so please login in.

  • 0 in reply to TheDrew2022

    I've reached out to you via PM to follow up. 

    I suggest checking the following registry key as well on one of the local devices to see if you're able to find the thumbprint you've tried excluding. 
    - HKEY_LOCAL_MACHINE\SOFTWARE\HitmanPro.Alert
    - WhiteThumbprints

    Kushal Lakhan
    Team Lead, Global Community Support
    Connect with Sophos Support, get alerted, and be informed.
    If a post solves your question, please use the "Verify Answer" button.
    The New Home of Sophos Support Videos!  - Visit Sophos Techvids
  • 0 in reply to Qoosh

    Hi Kushal,

    Thanks for the followup. I did look into the registry where you suggested I look and I do see all the Thumbprints listed that match the excluded detections.

    I also poked around in HKEY_LOCAL_MACHINE\SOFTWARE\HitmanPro.Alert\_policy_ which mentions excel.exe specifically. It contains over a dozen keys which refer to various versions of Excel, including $programfiles\Microsoft Office\root\Office16\EXCEL.EXE

    Those all reference a specific subfolder in here: HKEY_LOCAL_MACHINE\SOFTWARE\HitmanPro.Alert\_profiles_ and when I look at the key's inside that profile, StackExec has a value of 0, suggesting StackExec mitigation should be disabled for Excel. It also references a Template called Office which has the same key's as the above profile, only difference being that StackExec is a 1 so assuming it's on.

    So from the looks of the registry it should be excluding the specific Detecion IDs/signatures I excluded, but also excluding Excel from StackExec mitigations, both of which should keep Intercept X from stopping excel due to a StackExec violation when loading spreadhseets with this add-in enabled.

Reply
  • 0 in reply to Qoosh

    Hi Kushal,

    Thanks for the followup. I did look into the registry where you suggested I look and I do see all the Thumbprints listed that match the excluded detections.

    I also poked around in HKEY_LOCAL_MACHINE\SOFTWARE\HitmanPro.Alert\_policy_ which mentions excel.exe specifically. It contains over a dozen keys which refer to various versions of Excel, including $programfiles\Microsoft Office\root\Office16\EXCEL.EXE

    Those all reference a specific subfolder in here: HKEY_LOCAL_MACHINE\SOFTWARE\HitmanPro.Alert\_profiles_ and when I look at the key's inside that profile, StackExec has a value of 0, suggesting StackExec mitigation should be disabled for Excel. It also references a Template called Office which has the same key's as the above profile, only difference being that StackExec is a 1 so assuming it's on.

    So from the looks of the registry it should be excluding the specific Detecion IDs/signatures I excluded, but also excluding Excel from StackExec mitigations, both of which should keep Intercept X from stopping excel due to a StackExec violation when loading spreadhseets with this add-in enabled.

Children
Unfiltered HTML