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

Children
  • 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é

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

  • 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

     

    Mitigation   LoadLib
    Platform     6.1.7601/x86 v583 06_3a
    PID          8472
    Application  C:\Program Files\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe
    Description  Adobe Acrobat Reader DC 17.9
    EIP          5AEF4A58 (hpvpldrv09.dll)
    Heap address 20BB0000
    Length       512KB
    20BB0000  4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00  MZ..............
    20BB0010  B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00  ........@.......
    20BB0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    20BB0030  00 00 00 00 00 00 00 00 00 00 00 00 D8 00 00 00  ................
    20BB0040  0E 1F BA 0E 00 B4 09 CD 21 B8 01 4C CD 21 54 68  ........!..L.!Th
    20BB0050  69 73 20 70 72 6F 67 72 61 6D 20 63 61 6E 6E 6F  is program canno
    20BB0060  74 20 62 65 20 72 75 6E 20 69 6E 20 44 4F 53 20  t be run in DOS
    20BB0070  6D 6F 64 65 2E 0D 0D 0A 24 00 00 00 00 00 00 00  mode....$.......
    20BB0080  DA 55 9C 8C 9E 34 F2 DF 9E 34 F2 DF 9E 34 F2 DF  .U...4...4...4..
    20BB0090  97 4C 67 DF 80 34 F2 DF 97 4C 71 DF FA 34 F2 DF  .Lg..4...Lq..4..
    20BB00A0  B9 F2 89 DF 9D 34 F2 DF 9E 34 F3 DF D5 34 F2 DF  .....4...4...4..
    20BB00B0  97 4C 76 DF 4B 34 F2 DF 97 4C 60 DF 9F 34 F2 DF  .Lv.K4...L`..4..
    20BB00C0  97 4C 63 DF 9F 34 F2 DF 52 69 63 68 9E 34 F2 DF  .Lc..4..Rich.4..
    20BB00D0  00 00 00 00 00 00 00 00 50 45 00 00 4C 01 04 00  ........PE..L...
    20BB00E0  91 64 B4 4E 00 00 00 00 00 00 00 00 E0 00 02 21  .d.N...........!
    20BB00F0  0B 01 09 00 00 50 06 00 00 16 01 00 00 00 00 00  .....P..........
    20BB0100  E0 88 04 00 00 10 00 00 00 60 06 00 00 00 00 10  .........`......
    20BB0110  00 10 00 00 00 02 00 00 05 00 00 00 00 00 00 00  ................
    20BB0120  05 00 00 00 00 00 00 00 00 90 07 00 00 04 00 00  ................
    20BB0130  00 00 00 00 02 00 00 00 00 00 10 00 00 10 00 00  ................
    20BB0140  00 00 10 00 00 10 00 00 00 00 00 00 10 00 00 00  ................
    20BB0150  A0 D9 06 00 70 00 00 00 FC D3 06 00 28 00 00 00  ....p.......(...
    20BB0160  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    20BB0170  00 00 00 00 00 00 00 00 00 30 07 00 D8 38 00 00  .........0...8..
    Process Trace
    1  C:\Program Files\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe [8472]
    "C:\Program Files\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" /p /h "C:\Users\justine.scott.L83045\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.Outlook\O7T7GNLV\Invoice - 108685 - Bovey Tracy  Chudleigh Practice - 160617_0734.pdf"
    2  C:\Program Files\Microsoft Office\Office14\OUTLOOK.EXE [5880]
    3  C:\Windows\explorer.exe [5164]
    4  C:\Windows\System32\userinit.exe [5296]
    5  C:\Windows\System32\winlogon.exe [676]
    winlogon.exe
  • Hi Gary

    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 [5296]
    5  C:\Windows\System32\winlogon.exe [676]
    winlogon.exe

    Thumbprint
    124afc63523f51c4844e3e7fad64003a03341eb59d021aab845a1925a80365de

    Regards,

    André

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

    https://github.com/stephenfewer/ReflectiveDLLInjection

    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