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 prevision loadlib error when opening office docs

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??



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

    Can you paste here the entire event log entry for the detection(s)?

    Regards,

    Jak

  • hi, the windows event log you mean, or Sophos?  where would i find that info?

  • Yes, the Windows Application Event log:

    The description will be of most use here, I assume it has something like:

    Mitigation LoadLib

    Platform 6.1.7601/x64 v583 06_45
    PID 6428
    Application C:\Program Files\Microsoft Office 15\root\office15\EXCEL.EXE
    Description Microsoft Excel 15

    etc...  It's the rest of the details that will be of most interest.

    Regards,

    Jak

  • 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?

     

    Mitigation   LoadLib

     

    Platform     10.0.14393/x64 v593 06_3a

    PID          13164

    Application  C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe

    Description  Adobe Acrobat Reader DC 17.9

     

    \\Zeasvr\cti\Bin\QMasterHelp.dll

    Code Injection

    00F76000-00F77000    4KB C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe [13004]

    7738E000-7738F000    4KB

    7738F000-77390000    4KB

    1  C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe [13004]

    "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" "\\xxx\xxxxxx\xxxxxxx\Desktop\xxxxxxxxxx_095243.pdf"

    2  C:\Windows\explorer.exe [5624]

    3  C:\Windows\System32\userinit.exe [5776]

    4  C:\Windows\System32\winlogon.exe [692]

    winlogon.exe

     

    Process Trace

    1  C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe [13164]

    "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 [13004]

    "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" "\\xxx\xxxxxx\xxxxxxx\Desktop\xxxxxxxxxx_095243.pdf"

    3  C:\Windows\explorer.exe [5624]

    4  C:\Windows\System32\userinit.exe [5776]

    5  C:\Windows\System32\winlogon.exe [692]

    winlogon.exe

     

    Thumbprint 7fafde36f1abb3b4d70c43803844b522caf72256350ef78fe285d0c5f57fb027

  • 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?

    Regards,

    Jak

  • Hi

    I do have allmost the same problem.

    Loading a DLL from a remote location and the Exploit Alert:

    \\sbv.local\data\install\Software\LANGENSCHEIDT_F\Programm\Bib\hotkdl21.dll

    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:

    Mitigation LoadLib

    Platform 6.1.7601/x64 v583 06_3c
    PID 5284
    Application C:\Program Files (x86)\Internet Explorer\iexplore.exe
    Description Internet Explorer 11

    \\sbv.local\data\install\Software\LANGENSCHEIDT_F\Programm\Bib\hotkdl21.dll
    Process Trace
    1 C:\Program Files (x86)\Internet Explorer\iexplore.exe [5284]
    "C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE" SCODEF:1884 CREDAT:3617842 /prefetch:2
    2 C:\Program Files\Internet Explorer\iexplore.exe [1884]
    "C:\Program Files\Internet Explorer\iexplore.exe" -Embedding
    3 C:\Windows\System32\svchost.exe [852]
    C:\Windows\system32\svchost.exe -k DcomLaunch

    Thumbprint
    9bc4a0f2171e36bf10b4abc3a33d21d2884f0b1a86f241bb23ad072157cd6cb1

    ----

    Log Event 2:

    Mitigation   LoadLib

    Platform     6.1.7601/x64 v583 06_3c
    PID          4672
    Application  C:\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXE
    Description  Microsoft Word 14

    \\sbv.local\data\install\Software\LANGENSCHEIDT_F\Programm\Bib\hotkdl21.dll
    Process Trace
    1  C:\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXE [4672]
    2  C:\Windows\explorer.exe [3812]
    3  C:\Windows\System32\userinit.exe [4016]
    4  C:\Windows\System32\winlogon.exe [748]
    winlogon.exe

    Thumbprint
    124afc63523f51c4844e3e7fad64003a03341eb59d021aab845a1925a80365de

    It is really strange.

    Regards,
    André

  • Hi,

    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-exclusions
    for 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?

    Regards,

    Jak

      



  • Hi Jak

    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.

    Best Regards,

    André

Reply
  • Hi Jak

    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.

    Best Regards,

    André

Children
  • Hi André,

    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?

    Regards,

    Jak

  • Hi Jak

    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,

    André