[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fIcInqa3B0DXN5E8h3_6q1nCIjQxJd-L3en_YpsnYPms":3},{"id":4,"question":5,"answer":6,"answerHtml":7,"slug":8,"keywords":9,"article":10,"status":34,"aiModel":39,"aiConfidence":39,"updatedAt":52,"createdAt":52,"_status":51},556,"How can Process Monitor be used to identify DLL hijacking vulnerabilities in an application?","Process Monitor can filter for operations like `CreateFile` and `LoadImage` with paths containing `.dll`, and exclude results of `SUCCESS` to show only `NAME NOT FOUND` events. This reveals which DLLs the application tries to load from its directory but cannot find. For example, testing NDP461-KB3102438-Web.exe showed it attempted to load `CRYPTSP.dll` with a `NAME NOT FOUND` result, indicating a potential hijacking point. By placing a malicious `CRYPTSP.dll` in the same directory and rerunning the application, Process Monitor confirms successful loading (Result: SUCCESS), as detailed in the [Rattler testing article](\u002Fnews\u002Fautomated-dll-hijacking-vulnerability-identification-tool-rattler-testing).","\u003Cp>Process Monitor can filter for operations like `CreateFile` and `LoadImage` with paths containing `.dll`, and exclude results of `SUCCESS` to show only `NAME NOT FOUND` events. This reveals which DLLs the application tries to load from its directory but cannot find. For example, testing NDP461-KB3102438-Web.exe showed it attempted to load `CRYPTSP.dll` with a `NAME NOT FOUND` result, indicating a potential hijacking point. By placing a malicious `CRYPTSP.dll` in the same directory and rerunning the application, Process Monitor confirms successful loading (Result: SUCCESS), as detailed in the [Rattler testing article](\u002Fnews\u002Fautomated-dll-hijacking-vulnerability-identification-tool-rattler-testing).\u003C\u002Fp>\u003Cp>\u003Ca href=\"\u002Fnews\u002Fautomated-dll-hijacking-vulnerability-identification-tool-rattler-testing\">Read the related One Day Sec article\u003C\u002Fa>\u003C\u002Fp>","how-can-process-monitor-be-used-to-identify-dll-hijacking-vulnerabilities-in-an--1777482946477","Process Monitor, DLL hijacking identification, NAME NOT FOUND, LoadImage, CreateFile",{"id":11,"title":12,"slug":13,"description":14,"content":15,"contentHtml":30,"cover":31,"author":32,"views":19,"readingTime":33,"status":34,"publishedAt":35,"seo":36,"tags":41,"qaPairs":42,"meta":48,"updatedAt":49,"createdAt":50,"_status":51},137,"Automated DLL Hijacking Vulnerability Identification Tool Rattler Testing","automated-dll-hijacking-vulnerability-identification-tool-rattler-testing","Learn how to use Rattler for automated DLL hijacking vulnerability identification. Explore principles, examples, and testing with the Explorer Suite installation package.",{"root":16},{"type":17,"format":18,"indent":19,"version":20,"children":21,"direction":29},"root","",0,1,[22],{"type":23,"format":18,"indent":19,"version":20,"children":24,"direction":29},"paragraph",[25],{"mode":26,"text":27,"type":28,"style":18,"detail":19,"format":19,"version":20},"normal","\u003Chtml>\u003Chead>\u003C\u002Fhead>\u003Cbody>\u003Ch2>0x00 Preface\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>Recently, Chris Le Roy from SensePost open-sourced a tool called Rattler, which can be used to automatically identify whether a DLL has preloading vulnerabilities (also understood as DLL hijacking vulnerabilities; this term is consistently used as DLL hijacking vulnerability in this article). Although DLL hijacking vulnerabilities are no longer a new technology and can be traced back to 2010, I am very interested in automation and have conducted further research on this.\u003C\u002Fp>\u003Cp>This article will clarify the principles of DLL hijacking vulnerabilities, analyze examples, test the automated tool Rattler, share insights, and test a software with this vulnerability—the Explorer Suite installation package.\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>The Explorer Suite installation package includes CFF Explorer, which is free and commonly used for editing PE file formats. It was last updated on November 18, 2012, and is a relatively niche tool.\u003Cbr>For analyzing PE file formats, it is recommended to use the author's other more professional tool: Cerbero Profiler.\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>----------\u003C\u002Fp>\u003Cp>Chris Le Roy's blog address introducing Rattler:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fsensepost.com\u002Fblog\u002F2016\u002Frattleridentifying-and-exploiting-dll-preloading-vulnerabilities\u002F\u003C\u002Fp>\u003Cp>Chris Le Roy also introduced Rattler at BSides Cape Town, with a brief introduction as follows:\u003C\u002Fp>\u003Cp>http:\u002F\u002Fwww.bsidescapetown.co.za\u002Fspeaker\u002Fchris-le-roy\u002F\u003C\u002Fp>\u003Ch2>0x01 Introduction\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Ch3>Root cause of DLL hijacking vulnerability\u003C\u002Fh3>\u003Cp>Program does not specify the full path of the DLL when calling it\u003C\u002Fp>\u003Ch3>SafeDllSearchMode\u003C\u002Fh3>\u003Cp>Starting from Windows XP SP2, SafeDllSearchMode is enabled by default. Its existence is to prevent DLL hijacking vulnerabilities that existed during the XP era\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Method to forcibly disable SafeDllSearchMode:\u003Cbr>\u003Cbr>Create registry entry\u003Cbr>HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Session Manager\\SafeDllSearchMode\u003Cbr>Set value to 0\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>When a program calls a DLL without specifying its full path, the system follows a fixed search order to locate the DLL\u003C\u002Fp>\u003Cp>If SafeDllSearchMode is enabled, the program searches for the DLL file in the following locations in order:\u003C\u002Fp>\u003Cp>The directory from which the application loaded\u003C\u002Fp>\u003Cp>The system directory\u003C\u002Fp>\u003Cp>The 16-bit system directory\u003C\u002Fp>\u003Cp>The Windows directory\u003C\u002Fp>\u003Cp>The current directory\u003C\u002Fp>\u003Cp>The directories that are listed in the PATH environment variable\u003C\u002Fp>\u003Cp>If disabled, search for DLL files from the following locations:\u003C\u002Fp>\u003Cp>The directory from which the application loaded\u003C\u002Fp>\u003Cp>The current directory\u003C\u002Fp>\u003Cp>The system directory\u003C\u002Fp>\u003Cp>The 16-bit system directory\u003C\u002Fp>\u003Cp>The Windows directory\u003C\u002Fp>\u003Cp>The directories that are listed in the PATH environment variable\u003C\u002Fp>\u003Cp>For details, see:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fmsdn.microsoft.com\u002Fen-us\u002Flibrary\u002Fms682586(VS.85).aspx\u003C\u002Fp>\u003Ch3>KnownDLLs\u003C\u002Fh3>\u003Cp>Registry location:\u003C\u002Fp>\u003Cp>HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\KnownDLLs\u003C\u002Fp>\u003Cp>The KnownDLLs registry key contains a list of common system DLLs, such as usp10.dll, lpk.dll, shell32.dll, user32.dll\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>If the registry key\u003Cbr>HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\ExcludeFromKnownDlls\u003Cbr>is created and a specific DLL name is specified, it can disable the protection of DLLs with the same name in the KnownDLLs list\u003Cbr>A restart is required for the changes to take effect\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch3>SafeDllSearchMode + KnownDLLs\u003C\u002Fh3>\u003Cp>The combination of these two can be used to prevent hijacking of system DLLs\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>System DLLs refer to the DLL list included under the KnownDLLs registry key after excluding the ExcludeFromKnownDlls entry\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>If the called DLL is 'uncommon,' meaning it does not appear in the KnownDLLs list, then regardless of whether SafeDllSearchMode is enabled, the first search order for DLLs is the program's current directory. This creates a DLL hijacking vulnerability:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>By placing a DLL with the same name in the same directory as the program in advance, it will be loaded preferentially during the process startup, achieving hijacking\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Microsoft has not yet provided a direct fix for the DLL hijacking vulnerability mentioned here. In my opinion, the reasons are as follows:\u003Cbr>\u003Cbr>1. This is a developer's oversight; using absolute paths can avoid this issue\u003Cbr>2. The prerequisite for exploitation is that the attacker can already place files in the same directory, which indicates the system has already been compromised\u003Cbr>3. If directly fixed, it may affect older versions of the program, resulting in poor compatibility\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>This article greatly helps clarify the above sequence:\u003Cbr>http:\u002F\u002Fwww.freebuf.com\u002Farticles\u002F78807.html\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch2>0x02 Exploitation Example\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>Next, we will create an example with a DLL hijacking vulnerability to demonstrate how to exploit it\u003C\u002Fp>\u003Cp>Test dll:\u003C\u002Fp>\u003Cp>Using a dll template, specific code omitted. A calculator will pop up upon successful loading\u003C\u002Fp>\u003Cp>The C++ code for the test program is as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>#include \"stdafx.h\"\u003Cbr>#include \u003Cwindows.h>\u003Cbr>\u003Cbr>int main()\u003Cbr>{\u003Cbr>\tHMODULE hDllLib = LoadLibrary(_T(\"Kernel32.dll\"));\u003Cbr>\tif (hDllLib)\u003Cbr>\t{\u003Cbr>\t\tFARPROC fpFun = GetProcAddress(hDllLib, \"GetVersion\");\u003Cbr>\t\tDWORD dwVersion = (*fpFun)();\u003Cbr>\t\tDWORD dwWindowsMajorVersion = (DWORD)(LOBYTE(LOWORD(dwVersion)));\u003Cbr>\t\tDWORD dwWindowsMinorVersion = (DWORD)(HIBYTE(LOWORD(dwVersion)));\u003Cbr>\t\tprintf(\"version:%d,%d \\n\", dwWindowsMajorVersion, dwWindowsMinorVersion);\u003Cbr>\t\tFreeLibrary(hDllLib);\u003Cbr>\t}\u003Cbr>\tHMODULE hDllLib2 = LoadLibrary(_T(\"CRYPTSP.dll\"));\u003Cbr>\tFreeLibrary(hDllLib2);\u003Cbr>\treturn 0;\u003Cbr>}\u003C\u002Fwindows.h>\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>The program calls Kernel32.dll and CRYPTSP.dll respectively via LoadLibrary\u003C\u002Fp>\u003Cp>\u003Cstrong>Actual test:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Rename the test DLL to Kernel32.dll, place it in the same directory as the program, and run it as shown in the figure\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770017977625_0_b926652d0c.png\">\u003C\u002Fp>\u003Cp>Since Kernel32.dll appears in the KnownDLLs list, the Kernel32.dll in the same directory as the program will not be loaded\u003C\u002Fp>\u003Cp>Then rename the test DLL to CRYPTSP.dll, place it in the same directory as the program, and run it as shown in the figure\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770017986915_1_53be10ecc3.png\">\u003C\u002Fp>\u003Cp>Since CRYPTSP.dll is not in the KnownDLLs list, the CRYPTSP.dll in the same directory as the program is loaded, successfully launching the calculator\u003C\u002Fp>\u003Ch2>0x03 Practical Exploitation\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>This section demonstrates how to use Process Monitor to identify DLL hijacking vulnerabilities in programs, using the example of NDP461-KB3102438-Web.exe mentioned by Chris Le Roy in his blog about Rattler\u003C\u002Fp>\u003Cp>The blog address is as follows:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fsensepost.com\u002Fblog\u002F2016\u002Frattleridentifying-and-exploiting-dll-preloading-vulnerabilities\u002F\u003C\u002Fp>\u003Cp>Download address for NDP461-KB3102438-Web.exe:\u003C\u002Fp>\u003Cp>http:\u002F\u002Fwww.microsoft.com\u002Fzh-cn\u002Fdownload\u002Fdetails.aspx?id=49981&amp;134b2bb0-86c1-fe9f-d523-281faef41695=1&amp;fa43d42b-25b5-4a42-fe9b-1634f450f5ee=True\u003C\u002Fp>\u003Cp>Configure Process Monitor with the following settings:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Include the following filters:\u003Cbr>Operation is CreateFile\u003Cbr>Operation is LoadImage\u003Cbr>Path contains .cpl\u003Cbr>Path contains .dll\u003Cbr>Path contains .drv\u003Cbr>Path contains .exe\u003Cbr>Path contains .ocx\u003Cbr>Path contains .scr\u003Cbr>Path contains .sys\u003Cbr>\u003Cbr>Exclude the following filters:\u003Cbr>Process Name is procmon.exe\u003Cbr>Process Name is Procmon64.exe\u003Cbr>Process Name is System\u003Cbr>Operation begins with IRP_MJ_\u003Cbr>Operation begins with FASTIO_\u003Cbr>Result is SUCCESS\u003Cbr>Path ends with pagefile.sys\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Reference:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fmsdn.microsoft.com\u002Flibrary\u002Fff919712\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Setting 'Exclude Result is SUCCESS' will only display NAME NOT FOUND items, meaning only DLLs that failed to load are shown. This displays DLL names not included in the KnownDLLs list, which can be used to identify vulnerable DLL paths.\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>As shown in the figure\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770017992050_2_1dd129750a.png\">\u003C\u002Fp>\u003Cp>After launching NDP461-KB3102438-Web.exe, observe Process Monitor as shown\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770017996541_3_41cb5501b1.png\">\u003C\u002Fp>\u003Cp>It can be seen that during startup, NDP461-KB3102438-Web.exe attempts to load CRYPTSP.dll and shows NAME NOT FOUND, indicating the file cannot be found and loading fails.\u003C\u002Fp>\u003Cp>Now rename the test DLL to CRYPTSP.dll and place it in the same directory as NDP461-KB3102438-Web.exe.\u003C\u002Fp>\u003Cp>Open Process Monitor, set Filter to remove the 'Exclude Result is SUCCESS' option, then launch NDP461-KB3102438-Web.exe again and record.\u003C\u002Fp>\u003Cp>As shown below, C:\\test\\CRYPTSP.dll is successfully loaded with Result as Success, indicating successful DLL hijacking.\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770018001668_4_428f065c60.png\">\u003C\u002Fp>\u003Cp>As shown in the figure below, the program successfully launched the calculator during execution\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770018008664_5_a4fbcdfaf6.png\">\u003C\u002Fp>\u003Ch2>0x04 Program Automation Implementation\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>Using Process Monitor to view DLL hijacking vulnerabilities is a relatively straightforward method. However, for larger programs that load numerous DLLs, manual searching is impractical and labor-intensive. Therefore, automating the above process to automatically detect and exploit vulnerabilities can significantly improve efficiency. This is the problem that Rattler solves.\u003C\u002Fp>\u003Cp>Project address:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fgithub.com\u002Fsensepost\u002Frattler\u003C\u002Fp>\u003Cp>\u003Cstrong>Approach:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Enumerate the list of DLLs called by the process and parse out the DLL names.\u003C\u002Fli>\u003Cli>Rename the test DLLs to match the names in the list.\u003C\u002Fli>\u003Cli>Restart the program and check if the process calc.exe is successfully created. If successful, it indicates a vulnerability exists; otherwise, it does not.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>\u003Cstrong>Actual testing:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Compile Rattler using Visual Studio.\u003C\u002Fp>\u003Cp>Place payload.dll in the same directory.\u003C\u002Fp>\u003Cp>payload.dll download address:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fgithub.com\u002Fsensepost\u002Frattler\u002Freleases\u002Fdownload\u002Fv1.0\u002Fpayload.dll\u003C\u002Fp>\u003Cp>Run the command in an administrator Command Prompt:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Rattler.exe NDP461-KB3102438-Web.exe 1\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Since NDP461-KB3102438-Web.exe requires administrator privileges to run, the Command Prompt also needs administrator privileges.\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>As shown below, automatically find the list of DLLs with preloading vulnerabilities.\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770018013134_6_d60645f773.png\">\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>During the repeated process launches, calc.exe was not properly closed, so the results obtained are more than the actual results.\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>\u003Cstrong>Additional note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>The downloaded NDP461-KB3102438-Web.exe is usually located in the Downloads folder. Therefore, by pre-placing CRYPTSP.dll in that directory, CRYPTSP.dll can be loaded during the user's download and execution of NDP461-KB3102438-Web.exe.\u003C\u002Fp>\u003Cp>Simultaneously, since installing NDP461-KB3102438-Web.exe requires administrator privileges, CRYPTSP.dll also gains administrator privileges at that moment.\u003C\u002Fp>\u003Ch2>0x05 Verification Test\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>After mastering this method, test other programs, such as the CFF Explorer installation package Explorer Suite.\u003C\u002Fp>\u003Cp>Download address:\u003C\u002Fp>\u003Cp>http:\u002F\u002Fwww.ntcore.com\u002Fexsuite.php\u003C\u002Fp>\u003Cp>Similarly, use Process Monitor to observe the operations of CFF Explorer's installer ExplorerSuite.exe during startup\u003C\u002Fp>\u003Cp>As shown in the figure, locate the list of DLLs loaded by ExplorerSuite.exe during startup\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770018015480_7_500ea52cad.png\">\u003C\u002Fp>\u003Cp>Actual testing shows that renaming payload.dll to apphelp.dll or dwmapi.dll can trigger the payload and launch the calculator\u003C\u002Fp>\u003Cp>\u003Cstrong>Automated program testing:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>As shown in the figure, obtain the list of DLLs vulnerable to hijacking\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770018017645_8_3fab6ad578.png\">\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>During repeated process launches, calc.exe closes normally, so the results are accurate\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch2>0x06 Defense\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Ch3>1. Issues developers should pay attention to:\u003C\u002Fh3>\u003Cul>\u003Cli>When calling third-party DLLs, use absolute paths with LoadLibrary API. Similar cases include other APIs like LoadLibraryEx, CreateProcess, ShellExecute, etc. Place all required DLLs in the application directory, not in system directories or other locations\u003C\u002Fli>\u003Cli>Use absolute paths when calling system DLLs.\u003C\u002Fli>\u003Cli>Call API SetDllDirectory(L\"\") at program startup to remove the current directory from the DLL loading order.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>\u003Cstrong>Additional note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Starting with the KB2533623 patch for Windows 7, Microsoft updated three new APIs to address DLL hijacking issues: SetDefaultDllDirectories, AddDllDirectory, RemoveDllDirectory. Using these APIs together can effectively avoid DLL hijacking problems.\u003C\u002Fp>\u003Cp>However, these APIs can only be used on Windows 7 and Server 2008 with the KB2533623 patch installed.\u003C\u002Fp>\u003Cp>For details, see:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fsupport.microsoft.com\u002Fzh-cn\u002Fkb\u002F2533623\u003C\u002Fp>\u003Ch3>2. Issues users need to be aware of:\u003C\u002Fh3>\u003Cul>\u003Cli>Check for suspicious DLLs in the browser download directory to prevent them from hijacking downloaded installers.\u003C\u002Fli>\u003Cli>For \"untrusted\" programs, it is recommended to use Process Monitor or Rattler to check for DLL hijacking vulnerabilities.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>0x07 Summary\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>During my research on the principles of DLL hijacking vulnerabilities, I took a slight detour. Some materials mentioned that\u003C\u002Fp>\u003Cp>if a process attempts to load a DLL that does not exist, the process will still try to load this DLL from the current directory, which SafeDllSearchMode cannot prevent.\u003C\u002Fp>\u003Cp>This raised the following questions for me:\u003C\u002Fp>\u003Col>\u003Cli>What exactly are the 'non-existent DLLs' mentioned here? Are they DLLs that do not exist in the system? However, CRYPTSP.dll is a DLL included by default in the system.\u003C\u002Fli>\u003Cli>What exactly is the 'DLL hijacking that SafeDllSearchMode cannot prevent'? Does DLL hijacking have multiple types? How many are there?\u003C\u002Fli>\u003C\u002Fol>\u003Cp>Fortunately, these issues were ultimately resolved. I hope this article can also help those with similar doubts.\u003C\u002Fp>\u003Cp>Using the automated DLL hijacking vulnerability identification tool Rattler to test common tools can quickly identify existing vulnerability locations. It is efficient, convenient, and worth testing and using.\u003C\u002Fp>\u003C\u002Fbody>\u003C\u002Fhtml>","text","ltr","\u003Chtml>\u003Chead>\u003C\u002Fhead>\u003Cbody>\u003Ch2>0x00 Preface\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>Recently, Chris Le Roy from SensePost open-sourced a tool called Rattler, which can be used to automatically identify whether a DLL has preloading vulnerabilities (also understood as DLL hijacking vulnerabilities; this term is consistently used as DLL hijacking vulnerability in this article). Although DLL hijacking vulnerabilities are no longer a new technology and can be traced back to 2010, I am very interested in automation and have conducted further research on this.\u003C\u002Fp>\u003Cp>This article will clarify the principles of DLL hijacking vulnerabilities, analyze examples, test the automated tool Rattler, share insights, and test a software with this vulnerability—the Explorer Suite installation package.\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>The Explorer Suite installation package includes CFF Explorer, which is free and commonly used for editing PE file formats. It was last updated on November 18, 2012, and is a relatively niche tool.\u003Cbr>For analyzing PE file formats, it is recommended to use the author's other more professional tool: Cerbero Profiler.\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>----------\u003C\u002Fp>\u003Cp>Chris Le Roy's blog address introducing Rattler:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fsensepost.com\u002Fblog\u002F2016\u002Frattleridentifying-and-exploiting-dll-preloading-vulnerabilities\u002F\u003C\u002Fp>\u003Cp>Chris Le Roy also introduced Rattler at BSides Cape Town, with a brief introduction as follows:\u003C\u002Fp>\u003Cp>http:\u002F\u002Fwww.bsidescapetown.co.za\u002Fspeaker\u002Fchris-le-roy\u002F\u003C\u002Fp>\u003Ch2>0x01 Introduction\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Ch3>Root cause of DLL hijacking vulnerability\u003C\u002Fh3>\u003Cp>Program does not specify the full path of the DLL when calling it\u003C\u002Fp>\u003Ch3>SafeDllSearchMode\u003C\u002Fh3>\u003Cp>Starting from Windows XP SP2, SafeDllSearchMode is enabled by default. Its existence is to prevent DLL hijacking vulnerabilities that existed during the XP era\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Method to forcibly disable SafeDllSearchMode:\u003Cbr>\u003Cbr>Create registry entry\u003Cbr>HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Session Manager\\SafeDllSearchMode\u003Cbr>Set value to 0\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>When a program calls a DLL without specifying its full path, the system follows a fixed search order to locate the DLL\u003C\u002Fp>\u003Cp>If SafeDllSearchMode is enabled, the program searches for the DLL file in the following locations in order:\u003C\u002Fp>\u003Cp>The directory from which the application loaded\u003C\u002Fp>\u003Cp>The system directory\u003C\u002Fp>\u003Cp>The 16-bit system directory\u003C\u002Fp>\u003Cp>The Windows directory\u003C\u002Fp>\u003Cp>The current directory\u003C\u002Fp>\u003Cp>The directories that are listed in the PATH environment variable\u003C\u002Fp>\u003Cp>If disabled, search for DLL files from the following locations:\u003C\u002Fp>\u003Cp>The directory from which the application loaded\u003C\u002Fp>\u003Cp>The current directory\u003C\u002Fp>\u003Cp>The system directory\u003C\u002Fp>\u003Cp>The 16-bit system directory\u003C\u002Fp>\u003Cp>The Windows directory\u003C\u002Fp>\u003Cp>The directories that are listed in the PATH environment variable\u003C\u002Fp>\u003Cp>For details, see:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fmsdn.microsoft.com\u002Fen-us\u002Flibrary\u002Fms682586(VS.85).aspx\u003C\u002Fp>\u003Ch3>KnownDLLs\u003C\u002Fh3>\u003Cp>Registry location:\u003C\u002Fp>\u003Cp>HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\KnownDLLs\u003C\u002Fp>\u003Cp>The KnownDLLs registry key contains a list of common system DLLs, such as usp10.dll, lpk.dll, shell32.dll, user32.dll\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>If the registry key\u003Cbr>HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\ExcludeFromKnownDlls\u003Cbr>is created and a specific DLL name is specified, it can disable the protection of DLLs with the same name in the KnownDLLs list\u003Cbr>A restart is required for the changes to take effect\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch3>SafeDllSearchMode + KnownDLLs\u003C\u002Fh3>\u003Cp>The combination of these two can be used to prevent hijacking of system DLLs\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>System DLLs refer to the DLL list included under the KnownDLLs registry key after excluding the ExcludeFromKnownDlls entry\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>If the called DLL is 'uncommon,' meaning it does not appear in the KnownDLLs list, then regardless of whether SafeDllSearchMode is enabled, the first search order for DLLs is the program's current directory. This creates a DLL hijacking vulnerability:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>By placing a DLL with the same name in the same directory as the program in advance, it will be loaded preferentially during the process startup, achieving hijacking\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Microsoft has not yet provided a direct fix for the DLL hijacking vulnerability mentioned here. In my opinion, the reasons are as follows:\u003Cbr>\u003Cbr>1. This is a developer's oversight; using absolute paths can avoid this issue\u003Cbr>2. The prerequisite for exploitation is that the attacker can already place files in the same directory, which indicates the system has already been compromised\u003Cbr>3. If directly fixed, it may affect older versions of the program, resulting in poor compatibility\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>This article greatly helps clarify the above sequence:\u003Cbr>http:\u002F\u002Fwww.freebuf.com\u002Farticles\u002F78807.html\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch2>0x02 Exploitation Example\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>Next, we will create an example with a DLL hijacking vulnerability to demonstrate how to exploit it\u003C\u002Fp>\u003Cp>Test dll:\u003C\u002Fp>\u003Cp>Using a dll template, specific code omitted. A calculator will pop up upon successful loading\u003C\u002Fp>\u003Cp>The C++ code for the test program is as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>#include \"stdafx.h\"\u003Cbr>#include \u003Cwindows.h>\u003Cbr>\u003Cbr>int main()\u003Cbr>{\u003Cbr>\tHMODULE hDllLib = LoadLibrary(_T(\"Kernel32.dll\"));\u003Cbr>\tif (hDllLib)\u003Cbr>\t{\u003Cbr>\t\tFARPROC fpFun = GetProcAddress(hDllLib, \"GetVersion\");\u003Cbr>\t\tDWORD dwVersion = (*fpFun)();\u003Cbr>\t\tDWORD dwWindowsMajorVersion = (DWORD)(LOBYTE(LOWORD(dwVersion)));\u003Cbr>\t\tDWORD dwWindowsMinorVersion = (DWORD)(HIBYTE(LOWORD(dwVersion)));\u003Cbr>\t\tprintf(\"version:%d,%d \\n\", dwWindowsMajorVersion, dwWindowsMinorVersion);\u003Cbr>\t\tFreeLibrary(hDllLib);\u003Cbr>\t}\u003Cbr>\tHMODULE hDllLib2 = LoadLibrary(_T(\"CRYPTSP.dll\"));\u003Cbr>\tFreeLibrary(hDllLib2);\u003Cbr>\treturn 0;\u003Cbr>}\u003C\u002Fwindows.h>\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>The program calls Kernel32.dll and CRYPTSP.dll respectively via LoadLibrary\u003C\u002Fp>\u003Cp>\u003Cstrong>Actual test:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Rename the test DLL to Kernel32.dll, place it in the same directory as the program, and run it as shown in the figure\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770017977625_0_b926652d0c-1.png\">\u003C\u002Fp>\u003Cp>Since Kernel32.dll appears in the KnownDLLs list, the Kernel32.dll in the same directory as the program will not be loaded\u003C\u002Fp>\u003Cp>Then rename the test DLL to CRYPTSP.dll, place it in the same directory as the program, and run it as shown in the figure\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770017986915_1_53be10ecc3-1.png\">\u003C\u002Fp>\u003Cp>Since CRYPTSP.dll is not in the KnownDLLs list, the CRYPTSP.dll in the same directory as the program is loaded, successfully launching the calculator\u003C\u002Fp>\u003Ch2>0x03 Practical Exploitation\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>This section demonstrates how to use Process Monitor to identify DLL hijacking vulnerabilities in programs, using the example of NDP461-KB3102438-Web.exe mentioned by Chris Le Roy in his blog about Rattler\u003C\u002Fp>\u003Cp>The blog address is as follows:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fsensepost.com\u002Fblog\u002F2016\u002Frattleridentifying-and-exploiting-dll-preloading-vulnerabilities\u002F\u003C\u002Fp>\u003Cp>Download address for NDP461-KB3102438-Web.exe:\u003C\u002Fp>\u003Cp>http:\u002F\u002Fwww.microsoft.com\u002Fzh-cn\u002Fdownload\u002Fdetails.aspx?id=49981&amp;134b2bb0-86c1-fe9f-d523-281faef41695=1&amp;fa43d42b-25b5-4a42-fe9b-1634f450f5ee=True\u003C\u002Fp>\u003Cp>Configure Process Monitor with the following settings:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Include the following filters:\u003Cbr>Operation is CreateFile\u003Cbr>Operation is LoadImage\u003Cbr>Path contains .cpl\u003Cbr>Path contains .dll\u003Cbr>Path contains .drv\u003Cbr>Path contains .exe\u003Cbr>Path contains .ocx\u003Cbr>Path contains .scr\u003Cbr>Path contains .sys\u003Cbr>\u003Cbr>Exclude the following filters:\u003Cbr>Process Name is procmon.exe\u003Cbr>Process Name is Procmon64.exe\u003Cbr>Process Name is System\u003Cbr>Operation begins with IRP_MJ_\u003Cbr>Operation begins with FASTIO_\u003Cbr>Result is SUCCESS\u003Cbr>Path ends with pagefile.sys\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Reference:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fmsdn.microsoft.com\u002Flibrary\u002Fff919712\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Setting 'Exclude Result is SUCCESS' will only display NAME NOT FOUND items, meaning only DLLs that failed to load are shown. This displays DLL names not included in the KnownDLLs list, which can be used to identify vulnerable DLL paths.\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>As shown in the figure\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770017992050_2_1dd129750a-1.png\">\u003C\u002Fp>\u003Cp>After launching NDP461-KB3102438-Web.exe, observe Process Monitor as shown\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770017996541_3_41cb5501b1-1.png\">\u003C\u002Fp>\u003Cp>It can be seen that during startup, NDP461-KB3102438-Web.exe attempts to load CRYPTSP.dll and shows NAME NOT FOUND, indicating the file cannot be found and loading fails.\u003C\u002Fp>\u003Cp>Now rename the test DLL to CRYPTSP.dll and place it in the same directory as NDP461-KB3102438-Web.exe.\u003C\u002Fp>\u003Cp>Open Process Monitor, set Filter to remove the 'Exclude Result is SUCCESS' option, then launch NDP461-KB3102438-Web.exe again and record.\u003C\u002Fp>\u003Cp>As shown below, C:\\test\\CRYPTSP.dll is successfully loaded with Result as Success, indicating successful DLL hijacking.\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770018001668_4_428f065c60-1.png\">\u003C\u002Fp>\u003Cp>As shown in the figure below, the program successfully launched the calculator during execution\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770018008664_5_a4fbcdfaf6-1.png\">\u003C\u002Fp>\u003Ch2>0x04 Program Automation Implementation\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>Using Process Monitor to view DLL hijacking vulnerabilities is a relatively straightforward method. However, for larger programs that load numerous DLLs, manual searching is impractical and labor-intensive. Therefore, automating the above process to automatically detect and exploit vulnerabilities can significantly improve efficiency. This is the problem that Rattler solves.\u003C\u002Fp>\u003Cp>Project address:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fgithub.com\u002Fsensepost\u002Frattler\u003C\u002Fp>\u003Cp>\u003Cstrong>Approach:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cul>\u003Cli>Enumerate the list of DLLs called by the process and parse out the DLL names.\u003C\u002Fli>\u003Cli>Rename the test DLLs to match the names in the list.\u003C\u002Fli>\u003Cli>Restart the program and check if the process calc.exe is successfully created. If successful, it indicates a vulnerability exists; otherwise, it does not.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>\u003Cstrong>Actual testing:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Compile Rattler using Visual Studio.\u003C\u002Fp>\u003Cp>Place payload.dll in the same directory.\u003C\u002Fp>\u003Cp>payload.dll download address:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fgithub.com\u002Fsensepost\u002Frattler\u002Freleases\u002Fdownload\u002Fv1.0\u002Fpayload.dll\u003C\u002Fp>\u003Cp>Run the command in an administrator Command Prompt:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Rattler.exe NDP461-KB3102438-Web.exe 1\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Since NDP461-KB3102438-Web.exe requires administrator privileges to run, the Command Prompt also needs administrator privileges.\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>As shown below, automatically find the list of DLLs with preloading vulnerabilities.\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770018013134_6_d60645f773-1.png\">\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>During the repeated process launches, calc.exe was not properly closed, so the results obtained are more than the actual results.\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>\u003Cstrong>Additional note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>The downloaded NDP461-KB3102438-Web.exe is usually located in the Downloads folder. Therefore, by pre-placing CRYPTSP.dll in that directory, CRYPTSP.dll can be loaded during the user's download and execution of NDP461-KB3102438-Web.exe.\u003C\u002Fp>\u003Cp>Simultaneously, since installing NDP461-KB3102438-Web.exe requires administrator privileges, CRYPTSP.dll also gains administrator privileges at that moment.\u003C\u002Fp>\u003Ch2>0x05 Verification Test\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>After mastering this method, test other programs, such as the CFF Explorer installation package Explorer Suite.\u003C\u002Fp>\u003Cp>Download address:\u003C\u002Fp>\u003Cp>http:\u002F\u002Fwww.ntcore.com\u002Fexsuite.php\u003C\u002Fp>\u003Cp>Similarly, use Process Monitor to observe the operations of CFF Explorer's installer ExplorerSuite.exe during startup\u003C\u002Fp>\u003Cp>As shown in the figure, locate the list of DLLs loaded by ExplorerSuite.exe during startup\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770018015480_7_500ea52cad-1.png\">\u003C\u002Fp>\u003Cp>Actual testing shows that renaming payload.dll to apphelp.dll or dwmapi.dll can trigger the payload and launch the calculator\u003C\u002Fp>\u003Cp>\u003Cstrong>Automated program testing:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>As shown in the figure, obtain the list of DLLs vulnerable to hijacking\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770018017645_8_3fab6ad578-1.png\">\u003C\u002Fp>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>During repeated process launches, calc.exe closes normally, so the results are accurate\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch2>0x06 Defense\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Ch3>1. Issues developers should pay attention to:\u003C\u002Fh3>\u003Cul>\u003Cli>When calling third-party DLLs, use absolute paths with LoadLibrary API. Similar cases include other APIs like LoadLibraryEx, CreateProcess, ShellExecute, etc. Place all required DLLs in the application directory, not in system directories or other locations\u003C\u002Fli>\u003Cli>Use absolute paths when calling system DLLs.\u003C\u002Fli>\u003Cli>Call API SetDllDirectory(L\"\") at program startup to remove the current directory from the DLL loading order.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>\u003Cstrong>Additional note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Starting with the KB2533623 patch for Windows 7, Microsoft updated three new APIs to address DLL hijacking issues: SetDefaultDllDirectories, AddDllDirectory, RemoveDllDirectory. Using these APIs together can effectively avoid DLL hijacking problems.\u003C\u002Fp>\u003Cp>However, these APIs can only be used on Windows 7 and Server 2008 with the KB2533623 patch installed.\u003C\u002Fp>\u003Cp>For details, see:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fsupport.microsoft.com\u002Fzh-cn\u002Fkb\u002F2533623\u003C\u002Fp>\u003Ch3>2. Issues users need to be aware of:\u003C\u002Fh3>\u003Cul>\u003Cli>Check for suspicious DLLs in the browser download directory to prevent them from hijacking downloaded installers.\u003C\u002Fli>\u003Cli>For \"untrusted\" programs, it is recommended to use Process Monitor or Rattler to check for DLL hijacking vulnerabilities.\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>0x07 Summary\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>During my research on the principles of DLL hijacking vulnerabilities, I took a slight detour. Some materials mentioned that\u003C\u002Fp>\u003Cp>if a process attempts to load a DLL that does not exist, the process will still try to load this DLL from the current directory, which SafeDllSearchMode cannot prevent.\u003C\u002Fp>\u003Cp>This raised the following questions for me:\u003C\u002Fp>\u003Col>\u003Cli>What exactly are the 'non-existent DLLs' mentioned here? Are they DLLs that do not exist in the system? However, CRYPTSP.dll is a DLL included by default in the system.\u003C\u002Fli>\u003Cli>What exactly is the 'DLL hijacking that SafeDllSearchMode cannot prevent'? Does DLL hijacking have multiple types? How many are there?\u003C\u002Fli>\u003C\u002Fol>\u003Cp>Fortunately, these issues were ultimately resolved. I hope this article can also help those with similar doubts.\u003C\u002Fp>\u003Cp>Using the automated DLL hijacking vulnerability identification tool Rattler to test common tools can quickly identify existing vulnerability locations. It is efficient, convenient, and worth testing and using.\u003C\u002Fp>\u003C\u002Fbody>\u003C\u002Fhtml>",1007,"Onedaysec",8,"published","2026-02-02T07:51:00.061Z",{"title":37,"description":14,"keywords":38,"ogImage":39,"canonicalUrl":39,"noIndex":40},"Automated DLL Hijacking Vulnerability Tool Rattler Testing Guide","DLL hijacking vulnerability, Rattler tool, automated testing, SensePost, Chris Le Roy, DLL preloading, security testing, Windows vulnerabilities, KnownDLLs, SafeDllSearchMode",null,false,[],{"docs":43,"hasNextPage":40},[44,45,46,4,47],559,558,557,555,{"title":39,"description":39,"image":39},"2026-07-24T15:37:12.757Z","2026-07-23T16:01:44.411Z","draft","2026-07-23T16:13:18.727Z"]