There are a few more quick wins for loading DLLs using native .exe files from Windows 10… courtesy of good ol’ LoadLibraryA e.g.:

• fixmapi.exe
  • Copy c:\WINDOWS\System32\fixmapi.exe to your folder
  • Drop malicious mapistub.dll there
  • Run fixmapi.exe
• mshta.exe
  • Copy c:\WINDOWS\System32\mshta.exe to your folder
  • Drop malicious WLDP.DLL there
  • Run mshta.exe
• mshta.exe
  • Temporary change HKCR\clsid\
    {25336920-03f9-11cf-8fd0-00aa00686f13}\InProcServer32
    to point to malicious DLL
  • Run mshta.exe
  • Restore the Registry entry

This is obviously not the end.

There are so many potentials that it gets really boring to enumerate all this stuff:

• Apart from LoadLibraryA, there is LoadLibraryW which is very prevalent.
• There are cases of LoadLibraryExA and LoadLibraryExW that still use parameters that allow abuse.
• There are also functions that allow environment variables to resolve paths for libraries they load – bad choice.
• Pretty much every single .exe that is dependent on statically linked DLLs that are not on the KnownDLL list may be used as a lolbin e.g.
  • certutil.exe relies on certcli.dll
    • certcli.dll in turn relies on certca.dll
      so you can just produce DLLs that include all the exported functions like the original ones and let the certutil.exe load them.
• And there are non-OS binaries that are highly prevalent in various environments that offer lots of opportunities for side-loading or proxy execution.

The possibilities are almost endless. Unless I find something really new/cool I won’t be posting about Lolbins anymore as at this stage I am bored with it 🙂