wietze / windows-dll-hijacking Goto Github PK

Project for identifying executables and DLLs vulnerable to relative path DLL hijacking.

License: GNU General Public License v3.0

Python 88.05% PowerShell 7.94% VBScript 1.03% Dockerfile 2.99%

windows-dll-hijacking's Introduction

Windows DLL Hijacking

Background

This repo contains all scripts used to find relative path DLL Hijacking candidates on Windows 10 (version 1909), as described in this blog post.

Approach

The approach taken consists of two phases:

The first phase is about identifying which DLLs may be vulnerable to hijacking;
The second phase is about confirming which ones actually do.

Each phase is explained in more detail in the README files of their associated subfolders in this repo.

Used approach,taken from the blog post.

Item	Description
`1_finding_candidates/`	Files for Phase 1, which will result in a CSV file with all possible DLL hijack candidates.
`2_compiling_dlls/`	Files for Phase 2, which will result in a set of files identifying confirmed DLL hijack candidates.
`dll_hijacking_candidates.csv`	A CSV file with all identified relative path DLL Hijacking candidates on Windows 10 (version 1909).
`possible_windows_dll_hijacking.yml`	Sigma rule identifying DLL loads of files in the list of DLL Hijack candidates from a folder other than their expected locations.
`REAMDE.md`	This file.

windows-dll-hijacking's People

Contributors

Stargazers

Watchers

windows-dll-hijacking's Issues

issue with generate_dlls.py

Hey there Wietze,

having some issue here with the python script used to compile the DLLs via docker. see image below... not sure as to why its doing this. any help would be greatly appreciated! Thanks

Problem with run_procmon_scan.ps1

The latest version of procmon does not load the generated PMC filters correctly. Go to archive.org and download an older version of procmon. I am using procmon 3.53 and it works fine.
Thanks wietze

I attempted to test this on my system for learning purposes but for some reason I am not able to build the evil DLL's
As you already are aware the docker image is offline but I attempted to compile one of the files manually.

Any suggestions or clarification why the below will fail?

Compile command:"

$ x86_64-w64-mingw32-gcc -shared -mwindows -o winmm.dll winmm.dll.c winmm.dll.def

Errors:

winmm.dll.c:64:7: error: conflicting types for ‘mmioSeek’; have ‘void *()’
   64 | VOID *mmioSeek(){ generate_fingerprint(__func__); }
      |       ^~~~~~~~
In file included from /usr/share/mingw-w64/include/mmsystem.h:26,
                 from /usr/share/mingw-w64/include/windows.h:86,
                 from winmm.dll.c:1:
/usr/share/mingw-w64/include/mmiscapi.h:222:22: note: previous declaration of ‘mmioSeek’ with type ‘LONG(struct HMMIO__ *, LONG,  int)’ {aka ‘long int(struct HMMIO__ *, long int,  int)’}
  222 | WINMMAPI LONG WINAPI mmioSeek(HMMIO hmmio, LONG lOffset, int iOrigin);
      |                      ^~~~~~~~
winmm.dll.c:65:7: error: conflicting types for ‘midiInGetID’; have ‘void *()’
   65 | VOID *midiInGetID(){ generate_fingerprint(__func__); }
      |       ^~~~~~~~~~~
In file included from /usr/share/mingw-w64/include/mmsystem.h:29:
/usr/share/mingw-w64/include/mmeapi.h:609:26: note: previous declaration of ‘midiInGetID’ with type ‘MMRESULT(struct HMIDIIN__ *, UINT *)’ {aka ‘unsigned int(struct HMIDIIN__ *, unsigned int *)’}
  609 | WINMMAPI MMRESULT WINAPI midiInGetID(HMIDIIN hmi, LPUINT puDeviceID);
      |                          ^~~~~~~~~~~
winmm.dll.c:66:7: error: conflicting types for ‘mciFreeCommandResource’; have ‘void *()’
   66 | VOID *mciFreeCommandResource(){ generate_fingerprint(__func__); }
      |       ^~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/share/mingw-w64/include/mmsystem.h:23:
/usr/share/mingw-w64/include/mciapi.h:868:18: note: previous declaration of ‘mciFreeCommandResource’ with type ‘WINBOOL(UINT)’ {aka ‘int(unsigned int)’}
  868 | WINBOOL APIENTRY mciFreeCommandResource(UINT wTable);
      |                  ^~~~~~~~~~~~~~~~~~~~~~
winmm.dll.c:67:7: error: conflicting types for ‘midiInGetErrorTextW’; have ‘void *()’
   67 | VOID *midiInGetErrorTextW(){ generate_fingerprint(__func__); }
      |       ^~~~~~~~~~~~~~~~~~~
/usr/share/mingw-w64/include/mmeapi.h:598:26: note: previous declaration of ‘midiInGetErrorTextW’ with type ‘MMRESULT(MMRESULT,  WCHAR *, UINT)’ {aka ‘unsigned int(unsigned int,  short unsigned int *, unsigned int)’}
  598 | WINMMAPI MMRESULT WINAPI midiInGetErrorTextW(MMRESULT mmrError, LPWSTR pszText, UINT cchText);

Filtering out SysWOW64

Many thanks for these resources! In the SIGMA rule possible_windows_dll_hijacking.yml this path should/could be filtered out: C:\Windows\SysWOW64\

That is:

    filter:
        EventID: 7
        ImageLoaded:
            - "C:\\Windows\\WinSxS\\*"
            - "C:\\Windows\\System32\\*"
            - "C:\\Windows\\SysWOW64\\*"

wietze / windows-dll-hijacking Goto Github PK

windows-dll-hijacking's Introduction

Windows DLL Hijacking

Background

Approach

Contents

windows-dll-hijacking's People

Contributors

Stargazers

Watchers

Forkers

windows-dll-hijacking's Issues

issue with generate_dlls.py

Problem with run_procmon_scan.ps1

1_finding_candidates

Unable to compile dll files

Filtering out SysWOW64

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent