wietze / hijacklibs Goto Github PK

I'm working on parsing your Sigma feed into rules that we convert internally into Splunk queries and there are two primary formatting problems with the sigma rules here:

1.) They do not include a UUID
2.) The date format should be yyyy/mm/dd instead of yyyy-mm-dd

Some DLLs part of this project are normally signed, e.g. by Microsoft. Even though vulnerable applications might not do anything with the signature, knowing a DLL is normally signed my help identifying potentially malicious DLLs.

As such, it should be investigated whether an an optional field with signature info (e.g. is_signed, signer_name, etc) can be added.

Hello,
thanks for your amazing project!
One point: In our data hhc.exe sometimes loads hha.dll from %SYSWOW64%. This location is missing in the yaml file.

hi there,

i was quite happy when i stumbled across this project and attempted to use the csv file provided via the gh pages api directly in a siem query (splunk/sentinel) to build a dll (search oder) hijacking detection. unfortunately i had to make the experience that the format as-is isn't really usable. full paths would be required to facilitate matching against log events. this can of course be done in the siem queries, but would ideally already be provided via the api, so that a simple lookup is enough. i must admit, that i tried and failed at enhancing api/hijacklibs.csv (so no pr, sorry) and due to missing experince in that field can't even tell whether this is easily possible in the first place. i reverted to creating a new repo and using a gh workflow to generate and provision csv files in a suitable format on a schedule (github.com/hRun/HijackLibsExport). it's not perfect and probably will never be, as some variables like %VERSION% can of course not be replaced statically, but it is enough to make implementing the use case in a well-functioning way possible (beating microsoft defender's built-in capabilities :P). i'd be happy if you'd have a shot at checking whether the same functionality/format could be implemented in the gh pages.

cheers,
hRun

Zoom loads the version.dll from %SYSTEM32% folder.

%LOCALAPPDATA%\AppData\Local\CiscoSparkLauncher

https://hijacklibs.net/entries/3rd_party/cisco/ciscosparklauncher.html

"%LOCALAPPDATA%" stands for "\AppData\Local"

File Path: C:\Windows\system32\wbem\wbemprox.dll
ExpectedLocations:

• '%SYSTEM32%\wbem'
• '%SYSWOW64%\wbem'

Update: The same issue happens with fastprox.dll and wbemsvc.dll.

Hi,

Thanks for your work collecting DLL Hijacking possibilities.
It seems like the Mozilla Firefox install directory was moved from %PROGRAMFILES%\Mozilla\Firefox to %PROGRAMFILES%\Mozilla Firefox\
(see https://support.mozilla.org/en-US/kb/custom-installation-firefox-on-windows -> "Choose where Firefox is installed")

I've opened a pull request (#60 ) to change it.

Vulnerable dll - LDVPOCX.OCX

Vulnerable exe - ldvpreg.exe

Vulnerable exe/dll - vivaldi.exe and vivaldi_elf.dll

Reference:

• https://decoded.avast.io/threatintel/apt-treasure-trove-avast-suspects-chinese-apt-group-mustang-panda-is-collecting-data-from-burmese-government-agencies-and-opposition-groups/

Hello,

I see that right now the project primarily tracks the executable names (and their SHA256s) which are abused by TA's to load some malicious DLL. I would like to suggest that this project be extended to track the names of the DLLs that can be loaded by these executables aswell.

The reason for this suggested extension is as follows:

• There are often a large number of SHA256s of the loading executable that can be dropped by an attacker to load an arbitrary DLL (e.g. lots of vulnerable versions of the EXE).
• The initial EXE usually does not have to retain its name, e.g. I could rename chrome_frame_helper.exe to foo.exe and it would still successfully load chrome_frame_helper.dll

By contrast - the loaded DLL's name usually must remain the same in order for the legitimate executable to load it.

Thanks,
Tom

https://github.com/wietze/HijackLibs/blob/main/yml/microsoft/external/aclui.yml https://github.com/wietze/HijackLibs/blob/main/yml/microsoft/built-in/aclui.yml

Since it's is easy to rename the vulnerable executable, it would be great to add PE header information to the specification so that detections can be written for the original filename info.

Teams, during an update staging process, will occasionally bring their own DLL along with them:

\AppData\Local\Microsoft\Teams\stage\d3dcompiler_47.dll

Hi,

I wasn't entirely sure how to fill the template yaml for these two.
But the following two libraries can be included for DLL hijacking.

QT <5.14 (https://kb.cert.org/vuls/id/411271)
Uses the variable qt_prfxpath which seems to default to: C:\Qt. Causing a Phantom DLL lookup.

OpenSSL (https://www.kb.cert.org/vuls/id/567764)
The variable OPENSSLDIR causes an openssl.cnf lookup which can be abused. Compiled libraries pointing OPENSSLDIR to an user write-able folder can cause a vulnerability. The openssl.cnf can point to a malicious DLL, as demonstrated here (https://www.exploit-db.com/docs/50747)

I don't really know if these two are fit for this project. Or how to fit them in the template. Please let me know if you find them suitable candidates.

Include binaries that are only injectable when certain environment variables are set, per this article: https://www.wietzebeukema.nl/blog/save-the-environment-variables
(hopefully you haven't already done this, or I'll be embarrassed)