Reply to thread

Message

Forgive my naive post in this thread. I thought that enabling safe search mode would stop DLL hijacking?
[SPOILER="Registry key"]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
"SafeDllSearchMode"=dword:00000001
[/SPOILER]
___________________
EDIT 1
According to Microsoft it is enabled by default now
[SPOILER="SafeSearchDLL order"]
Safe DLL search mode is enabled by default.

If SafeDllSearchMode is enabled, the search order is as follows:
The directory from which the application loaded.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
[/SPOILER]
--------------------------
EDIT 2

I am understanding it now, by starting an application in a User folder, the replacement DLL hijacks the DLL loading because it is in the "The directory from which the application loaded."

Luckily my WDAC policy only allows Microsoft signed (and Syncback) DLL's to execute in user space.

<blockquote data-quote="ForgottenSeer 97327" data-source="post: 1014079">Forgive my naive post in this thread. I thought that enabling safe search mode would stop DLL hijacking?[SPOILER=&quot;Registry key&quot;][HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]&quot;SafeDllSearchMode&quot;=dword:00000001[/SPOILER]___________________EDIT 1According to Microsoft it is enabled by default now[SPOILER=&quot;SafeSearchDLL order&quot;]Safe DLL search mode is enabled by default.If SafeDllSearchMode is enabled, the search order is as follows:<ol>
<li data-xf-list-type="ol">The directory from which the application loaded.</li>
<li data-xf-list-type="ol">The system directory. Use the <a href="https://learn.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getsystemdirectorya" target="_blank">GetSystemDirectory</a> function to get the path of this directory.</li>
<li data-xf-list-type="ol">The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.</li>
<li data-xf-list-type="ol">The Windows directory. Use the <a href="https://learn.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getwindowsdirectorya" target="_blank">GetWindowsDirectory</a> function to get the path of this directory.</li>
<li data-xf-list-type="ol">The current directory.</li>
<li data-xf-list-type="ol">The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.</li>
</ol>[/SPOILER]--------------------------EDIT 2I am understanding it now, by starting an application in a User folder, the replacement DLL hijacks the DLL loading because it is in the &quot;The directory from which the application loaded.&quot; <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite117" alt=":eek:" title="Eek!&nbsp; &nbsp; :eek:" loading="lazy" data-shortname=":eek:" /><img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite110" alt=";)" title="Wink&nbsp; &nbsp; ;)" loading="lazy" data-shortname=";)" /> Luckily my WDAC policy only allows Microsoft signed (and Syncback) DLL&#039;s to execute in user space. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite114" alt=":cool:" title="Cool&nbsp; &nbsp; :cool:" loading="lazy" data-shortname=":cool:" /></blockquote>

[QUOTE="ForgottenSeer 97327, post: 1014079"] Forgive my naive post in this thread. I thought that enabling safe search mode would stop DLL hijacking? [SPOILER="Registry key"] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager] "SafeDllSearchMode"=dword:00000001 [/SPOILER] ___________________ EDIT 1 According to Microsoft it is enabled by default now [SPOILER="SafeSearchDLL order"] Safe DLL search mode is enabled by default. If [B]SafeDllSearchMode[/B] is enabled, the search order is as follows: [LIST=1] [*]The directory from which the application loaded. [*]The system directory. Use the [URL='https://learn.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getsystemdirectorya'][B]GetSystemDirectory[/B][/URL] function to get the path of this directory. [*]The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. [*]The Windows directory. Use the [URL='https://learn.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getwindowsdirectorya'][B]GetWindowsDirectory[/B][/URL] function to get the path of this directory. [*]The current directory. [*]The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the [B]App Paths[/B] registry key. The [B]App Paths[/B] key is not used when computing the DLL search path. [/LIST] [/SPOILER] -------------------------- EDIT 2 I am understanding it now, by starting an application in a User folder, the replacement DLL hijacks the DLL loading because it is in the "The directory from which the application loaded." :eek: ;) Luckily my WDAC policy only allows Microsoft signed (and Syncback) DLL's to execute in user space. :cool: [/QUOTE]

Top