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. 

  • 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

    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.
  • Hello Kushal, thank you for the reply. Yes we already tried setting an Exploit Mitigation for:




    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.
  • 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:\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: