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

Exploit Mitigation: Prevent Credential Theft / Prevent Privilege Escalation Exclusions?

We are attempting to run an Active Directory migration tool on our domain controllers, the migration tool is called Quest Migration Manager. 

Sophos was originally blocking some of the background processes with the software and throwing CredGuard errors in Event Viewer. After implementing a policy were it excluded several processes and folders with the software, the error in Event Viewer went away. The software is still not working properly, and after much testing it was revealed that when we had "Prevent Credential Theft" and "Prevent Privilege Escalation" unselected in the Runtime Protection>Protect Processes portion of the policy, the software works just fine.

Since this software would need to work on about 6 or 7 domain controllers, our organization is a bit apprehensive about disabling "Prevent Credential Theft" and "Prevent Privilege escalation" on our domain controllers. Does anyone have any idea on where to begin on where we could program an exclusion in for these two processes? 

I have just about every other crucial process with the software in a global exclusion policy but the software just won't work until "Prevent Credential Theft" and "Prevent Privilege escalation" are unchecked. 



This thread was automatically locked due to age.
Parents
  • Hello Justin,

    Thank you for contacting the Sophos Community. I had a look through some of our related support cases and found the following executable to be the one that was detected by Intercept X. Have you tried applying an "Exploit Mitigation Exclusion" so that this executable will not be scanned by Intercept X?

    Application C:\Windows\System32\AelAgentMS64.exe
    https://docs.sophos.com/central/Customer/help/en-us/central/Customer/common/learningContents/StopDetectingExploit.html

    The steps that apply to you will be under "Stop checking for all exploits on an application". 

    If you already have a support case opened with our team, try supplying the Case ID here and I can check on the progress to see which steps were already tried.

    Kushal Lakhan
    Global Community Support Engineer | Global Community Team
    Sophos Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
    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
  • Hello Kushal, thank you for the reply. Yes we already tried setting an Exploit Mitigation for:

    %systemroot%\system32\AelAgentMS64.exe

    and

    %systemroot%\system32\AelAgentMS.cnt

    This is what the software vendor said needed to be excluded. I set these exploit mitigations at both a Global Exclusion AND custom Threat Protection Server policy level, unfortunately neither resolved the issue. Here is our support case ID: #04385642

  • Hello Justin, 

    There is a registry key that will be updated when the exclusion has been received successfully by the endpoint/server. 
    - HKEY_LOCAL_MACHINE\SOFTWARE\HitmanPro.Alert\_policy_

    Try checking this key to verify if the exclusion has been received. You will see a sub-key referencing the "exe name". In the event a reboot has not occurred since the last time a detection was raised, I'd recommend doing so as a precautionary measure to ensure the detection is no longer being cached. 

    If you have already performed these checks however, I recommend continuing on with the support case. I have added a comment to the case now as well. 

    Kushal Lakhan
    Global Community Support Engineer | Global Community Team
    Sophos Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
     
    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
  • There are many types of exclusions depending on what you are trying to achieve.

    The type of exclusion that prevents the hmpalert.dll being injected by the SophosED.sys driver into processes as they launch takes variables such as $desktop, $programfiles. Maybe this would help? Seeing %systemroot% makes me wonder what type of exclusion you have entered.  

    Can you see the paths in a registry value called PolicyInjectionExclusions under the hmpa driver key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\hmpalert

    These are the processes that exempted from having the DLL injected into. I wonder if you have this type of exclusion and if not, would it help?

    To get these, the type is "Exploit Mitigation (Windows)".  Then choose Application Not listed.  From there you can enter the path to the exe and turn off exploit mitigations. That will create the above registry key.  Next time the process starts the hmpalert.dll should not be injected into the process.

  • Hello again Kushal, thanks for the tip. I checked that registry location on our domain controllers and they all show the exclusions I programmed into the policies, so they are definitely receiving the updated policies. 

    Thanks for your assistance though, I'll continue with the support case.

  • Hi there and thank you for the reply. I navigated to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\hmpalert and there was a PolicyInjectionExclusion registry value. In it were three entries I already created an Exploit Mitigation exclusion for.

    C:\Windows\System32\AelAgentMS64.exe
    C:\Windows\System32\AelAgentMS.cnt
    C:\Program Files (x86)\Common Files\Aelita Shared\MigrationManager.exe

    I experimented with having the exclusion be listed as %systemroot%\system32\AelAgentMS64.exe AND C:\Windows\System32\AelAgentMS64.exe but neither seemed to make a difference unfortunately. 

  • I assume these processes would have been restarted after the registry value contained those values?

    For example AelAgentMS64.exe does not have the module hmpalert.dll loaded into it? Thanks.

  • Correct. The devices have been rebooted several times so the processes would have restarted as well. I've manually restarted the processes and services too.

    AelAgentMS64.exe does not have hmpalert.dll loaded onto it.

  • OK, did the original alert at the EP have a thumbprint in the 911 Event ID alert?  In Central, via the alert, I thought you could exclude by thumbprint, which should essentially send this same thumbprint down to the registry value WhiteThumbprints under:

    HKEY_LOCAL_MACHINE\SOFTWARE\HitmanPro.Alert

Reply
  • OK, did the original alert at the EP have a thumbprint in the 911 Event ID alert?  In Central, via the alert, I thought you could exclude by thumbprint, which should essentially send this same thumbprint down to the registry value WhiteThumbprints under:

    HKEY_LOCAL_MACHINE\SOFTWARE\HitmanPro.Alert

Children
  • Yes. Before programming ANY policy exclusions, running the software would generate a Event ID: 911 HitmanPro.Alert in Event Viewer>Windows Applications. 

    After we programmed in the exclusions for the application, the 911 Events stopped. When this alert was generated though, I only saw it on Event Viewer on the device itself. I did not see any alert entries generated within Sophos Central.

    I did see the registry entry for the WhiteThumbprints, but there doesn't appear to be any location where I can enter plugin the value data for this entry in Sophos Central?

  • Hi,

    Whitethumbprints are exclusively generated by our development team. You would need to create a support case (sounds like you have already) and it would need to be sent to development with an example of the EXE in question for them to eval if they can create a thumbprint. Not all requests are accepted because a thumbprint needs to be specific enough that it doesn't allow compromise of the system.

    As another note, exclusions for EXEs don't apply to the InterceptX exploit mitigation detections - so you can exclude a EXE from being scanned by the endpoint but if it stills does an action that would trigger an exploit mitigation then it will still be blocked. Some of the mitigations can have exclusions applied (ie you can unload the driver from those types of EXEs and therefore the EXE can do what it wants) - however, for the specific case of this software I couldn't give you advice on how to craft the right policy without seeing the exact behaviour of the EXE. Support should be able to though.,

    RichardP

    Program Manager, Support Readiness | CISSP | Sophos Technical Support
    Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • Thank you Richard for the explanation. I suppose that explains why all my exploit mitigations were in vain and didn't do anything. I'll follow up with my support ticket to see if they can offer any insight. 

    Thank you everyone for your time and assistance.