We'd love to hear about it! Click here to go to the product suggestion community
Hi, we have just got exploit prevention installed on-premise, but certain users are having issues opening office docs and PDFs. When they try to do so, the file closes immediately with a message about exploit prevention. Looking in the computer details tab in SEC, it shows the event as LoadLib.
I have had to disable protection for these programs as it's preventing genuine files from being opened. Why is this happening??
Can you paste here the entire event log entry for the detection(s)?
In reply to jak:
hi, the windows event log you mean, or Sophos? where would i find that info?
In reply to fvd_rs:
Yes, the Windows Application Event log:
The description will be of most use here, I assume it has something like:
Platform 6.1.7601/x64 v583 06_45PID 6428Application C:\Program Files\Microsoft Office 15\root\office15\EXCEL.EXEDescription Microsoft Excel 15
etc... It's the rest of the details that will be of most interest.
thanks, so i know what is causing the problem, - we use Enghouse EICC contact center. Not sure if it's that or Sophos which is the issue though? Is sophos flagging it or is it doing something it shouldn't be?
Platform 10.0.14393/x64 v593 06_3a
Application C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe
Description Adobe Acrobat Reader DC 17.9
00F76000-00F77000 4KB C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe 
1 C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe 
"C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" "\\xxx\xxxxxx\xxxxxxx\Desktop\xxxxxxxxxx_095243.pdf"
2 C:\Windows\explorer.exe 
3 C:\Windows\System32\userinit.exe 
4 C:\Windows\System32\winlogon.exe 
1 C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe 
"C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --type=renderer /prefetch:1 "\\\xxx\xxxxxx\xxxxxxx\Desktop\xxxxxxxxxx_095243.pdf"
2 C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe 
3 C:\Windows\explorer.exe 
4 C:\Windows\System32\userinit.exe 
5 C:\Windows\System32\winlogon.exe 
I'm sure the issue is with this DLL being loaded from a remote location:\\Zeasvr\cti\Bin\QMasterHelp.dll
It's ok for a process to load a DLL from a remote location such as this if the process is also in the same share but in this case it's not.
Do you know how this module is being loaded?
Do you need it?
What software is it part of?
I'd probably use a combination of Process Monitor [https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx] and Process Explorer [https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx] to determine why it's being loaded and how. Does it need to be remote?
I do have allmost the same problem.
Loading a DLL from a remote location and the Exploit Alert:
The Application is some time winword.exe and some time it is iexploerer.exe.The DLL is for a LANGENSCHEIDT Application in this remote location.
This happens only on a couple of clients from about 200 protected clients.
Log Event 1:
Platform 6.1.7601/x64 v583 06_3cPID 5284Application C:\Program Files (x86)\Internet Explorer\iexplore.exeDescription Internet Explorer 11
\\sbv.local\data\install\Software\LANGENSCHEIDT_F\Programm\Bib\hotkdl21.dllProcess Trace1 C:\Program Files (x86)\Internet Explorer\iexplore.exe "C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE" SCODEF:1884 CREDAT:3617842 /prefetch:22 C:\Program Files\Internet Explorer\iexplore.exe "C:\Program Files\Internet Explorer\iexplore.exe" -Embedding3 C:\Windows\System32\svchost.exe C:\Windows\system32\svchost.exe -k DcomLaunch
Log Event 2:
Mitigation LoadLibPlatform 6.1.7601/x64 v583 06_3cPID 4672Application C:\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXEDescription Microsoft Word 14\\sbv.local\data\install\Software\LANGENSCHEIDT_F\Programm\Bib\hotkdl21.dllProcess Trace1 C:\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXE 2 C:\Windows\explorer.exe 3 C:\Windows\System32\userinit.exe 4 C:\Windows\System32\winlogon.exe winlogon.exeThumbprint124afc63523f51c4844e3e7fad64003a03341eb59d021aab845a1925a80365de
It is really strange.
In reply to Andre Peterhans:
I don't think these mitigation alerts in this thread are that strange. :)
The LoadLib mitigation will flag processes that load DLLs from remote locations. In this case Winword.exe has loaded the DLL:\\sbv.local\data\install\Software\LANGENSCHEIDT_F\Programm\Bib\hotkdl21.dll
I believe there are rules for this mitigation which permit this sort of remote load of a module such as the exe is in the same remote location as the remote module. This makes sense as it's not so unusual to run applications remotely from a share.
If you are happy with this behaviour as reported and you know what hotkdl21.dll is an happy for Word to load it you can make an exception.
As you can see a thumbprint has been generated and logged to the event log. For this mitigation type of loadlib, the path is significant. When you make an exclusion based on this thumbprint you are just permitting Word to load \\sbv.local\data\install\Software\LANGENSCHEIDT_F\Programm\Bib\hotkdl21.dll. If Word went on to load \\sbv.local\data\install\Software\LANGENSCHEIDT_F\Programm\Bib\hotkdl22.dll, this would be another loadlib mitigation and you would get a different thumbprint.
If you look under:https://cloud.sophos.com/manage/endpoint/config/settings/scanning-exclusionsfor the type: "Detected Exploits", you should see this event and you can authorise it. What isn't great is that you can't see the thumbprint from the shown entry but when you do Authorise it, the policy that goes down will set the value in WhiteThumbprints, under: HKEY_LOCAL_MACHINE\SOFTWARE\HitmanPro.Alert\.
You can see the thumbprint from the server side to confirm but you would need to use the Developer Tools as shown in the screenshot below.
I hope this explains things. Essentially it's a heads up to say this is potentially something you may want to know about, do you want to allow this in the future?
Thank you for this explanations.
For me, it is still some kind of strange. Actually the Clients are all installed the same way and do have the same shares and access rights to the system. It is a difference, if almost all clients are loading this hotkdl21.dll or if only 1 % of the client computer do have this exploit events sometimes. This is what happens in our company.
It doesn't look like, we can make an exclusion in the Sophos Enterpise Console in Exploit Prevention. We don't use the cloud version.
Out of interest, what does that DLL belong to? What is it for?
Are the results OK, if you submit the DLL to https://www.virustotal.com/
I had a quick Google but can't find anything specifically.
With the on-premise version I'm sure you can create the same registry key on the client and restart the HMPA service.
Are all the thumbprints the same from the different clients? Do they all load the DLL from the same location?
I'd be interested to run Process Monitor on a computer that exhibits the mitigation to see the events that lead to the load image event. E.g. in the load image event, what does the stack look like, what module made the load library call. What was going on at the time?
The DLL belongs to a Langenscheidt dictionary for translation german-french, german-italian. We use this application since 2002 and some of our users like it a lot.
The results on virustotal.com are OK.
Since today we know much more, when it happens. If this Langenscheidt dictionary application is started on client, everytime if the user makes an Keyboard entry on word or IE, the Sophos Exploit Alert will close word oder IE. Because just a small number of users are using this Langenscheidt dictionary, all other client computers do not have any exploit alerts.
The alert Pop up from sophos is so small and at lower right corner of the screen and only for about 3 seconds visible. So the users didn't notice, why word was closed.
This happens on Windows 7 Computers and is no problem on Windows 10 Computers. It looks like, not Sophos is working "strange", the word or IE is loading this DLL. We don't know why, because there is no link from this Langenscheidt application to word or IE. Windows 10 works different and doesn't load this DLL.
The thumbprints are the same from the different clients. One for the word and an other one for the IE.
The WhiteThumbprints REG_MULTI_SZ works fine. We just did some succesfull testing and tomorrow the registry with this two thumprints will be loaded on all clients.
I look forward, that Sophos will implement this in the Sophos Management Console and we do not have to take care about registry files. This would be nicer.
Actually it works and we will leave it this way.
Thanks a lot and best Regards,
We are seeing similar issues, linked to Adobe DC, and Outlook.exe, when opening specific pdf attachments. Whilst we could use exclusions, what if the actual attachment did contain malicious code, would we get the same exploit warning? If we exclude both Adobe and Outlook, we would not get any indication of problems
In reply to gary kennington:
Do all clients have the same thumbprint in the HitmanPro.Alert Events?
After winlogon.exe is a thumprint like this:
4 C:\Windows\System32\userinit.exe 5 C:\Windows\System32\winlogon.exe winlogon.exe
I think the reason you're not seeing a path here is the way the library hpvpldrv09.dll is being loaded by AcroRd32.exe. The most common call to load a library into a process is to call LoadLibrary - https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175%28v=vs.85%29.aspx. i.e. you just supply a path and the module is loaded. I assume this is what's happening for the other examples on this page where the path is given and you don't see the first bytes of the module as you do here. Importantly you also get a thumbprint generated for exclusions.
However, The LoadLibrary mitigation must also consider, under the same umbrella, the loading of modules using what's known as reflective DLL injection. Here is a simple test app, that when compiled the exe and dll it would trigger the LoadLibrary mitigation, if it was a "protected" application.
In this cases you don't appear to get a thumbprint which I assume would mean, the only thing to exclude/auth this would be to add the exclusion under:https://cloud.sophos.com/manage/endpoint/config/settings/exploit-mitigation-exclusions
...which would exclude the entire process from mitigation.
I think you would need to email support and ask if the thumbprint generation will be included in the future for all scenarios that trigger a LoadLib mitigation. Then you would be able to exclude just this DLL being injected into the process (for LoadLib) rather than the process performing the loading.
It is a little odd to use that technique, so it would be worth thoroughly investigating that the module loaded and the software it belongs to is legit. If you search for "reflective dll injection" on Google you'll get an idea of why I would be a little cautious.Jak
Is adding thumbprint to register only working solution to avoid crashing Word, Acrobat, ... because of \\*.dll?
Do you know, if there is a new solution for configuration exclusions in sophos exploit prevention?
This regkey is not working stable:
If sophos exploit is updating during the day, the Hitmanpro.Alert WhiteThumbprints key will be deleted and restarts the HitmanPro.Alert Service.
We do have trouble again and again.