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

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.

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. 

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

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.,

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.

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.