{ "id": "e72e6157-7278-47ba-aef3-7ceda81c8b6c", "created_at": "2026-04-06T00:16:21.984981Z", "updated_at": "2026-04-10T03:24:30.27699Z", "deleted_at": null, "sha1_hash": "d34ff66f242ec64e6a0eb7fbceaedf4df9bb8204", "title": "Dynamic-Link Library Security - Win32 apps", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 64223, "plain_text": "Dynamic-Link Library Security - Win32 apps\r\nBy stevewhims\r\nArchived: 2026-04-05 15:25:44 UTC\r\nWhen an application dynamically loads a dynamic-link library without specifying a fully qualified path name,\r\nWindows attempts to locate the DLL by searching a well-defined set of directories in a particular order, as\r\ndescribed in Dynamic-Link Library Search Order. If an attacker gains control of one of the directories on the DLL\r\nsearch path, it can place a malicious copy of the DLL in that directory. This is sometimes called a DLL preloading\r\nattack or a binary planting attack. If the system does not find a legitimate copy of the DLL before it searches the\r\ncompromised directory, it loads the malicious DLL. If the application is running with administrator privileges, the\r\nattacker may succeed in local privilege elevation.\r\nFor example, suppose an application is designed to load a DLL from the user's current directory and fail gracefully\r\nif the DLL is not found. The application calls LoadLibrary with just the name of the DLL, which causes the\r\nsystem to search for the DLL. Assuming safe DLL search mode is enabled and the application is not using an\r\nalternate search order, the system searches directories in the following order:\r\n1. The directory from which the application loaded.\r\n2. The system directory.\r\n3. The 16-bit system directory.\r\n4. The Windows directory.\r\n5. The current directory.\r\n6. The directories that are listed in the PATH environment variable.\r\nContinuing the example, an attacker with knowledge of the application gains control of the current directory and\r\nplaces a malicious copy of the DLL in that directory. When the application issues the LoadLibrary call, the\r\nsystem searches for the DLL, finds the malicious copy of the DLL in the current directory, and loads it. The\r\nmalicious copy of the DLL then runs within the application and gains the privileges of the user.\r\nDevelopers can help safeguard their applications against DLL preloading attacks by following these guidelines:\r\nWherever possible, specify a fully qualified path when using the LoadLibrary, LoadLibraryEx,\r\nCreateProcess, or ShellExecute functions.\r\nUse the LOAD_LIBRARY_SEARCH flags with the LoadLibraryEx function, or use these flags with the\r\nSetDefaultDllDirectories function to establish a DLL search order for a process and then use the\r\nAddDllDirectory or SetDllDirectory functions to modify the list. For more information, see Dynamic-Link Library Search Order.\r\nWindows 7, Windows Server 2008 R2, Windows Vista and Windows Server 2008: These flags and\r\nfunctions are available on systems with KB2533623 installed.\r\nhttps://msdn.microsoft.com/en-us/library/ff919712.aspx\r\nPage 1 of 3\n\nOn systems with KB2533623 installed, use the LOAD_LIBRARY_SEARCH flags with the\r\nLoadLibraryEx function, or use these flags with the SetDefaultDllDirectories function to establish a\r\nDLL search order for a process and then use the AddDllDirectory or SetDllDirectory functions to modify\r\nthe list. For more information, see Dynamic-Link Library Search Order.\r\nConsider using DLL redirection or a manifest to ensure that your application uses the correct DLL.\r\nWhen using the standard search order, make sure that safe DLL search mode is enabled. This places the\r\nuser's current directory later in the search order, increasing the chances that Windows will find a legitimate\r\ncopy of the DLL before a malicious copy. Safe DLL search mode is enabled by default starting with\r\nWindows XP with Service Pack 2 (SP2) and is controlled by the\r\nHKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Session\r\nManager\\SafeDllSearchMode registry value. For more information, see Dynamic-Link Library Search\r\nOrder.\r\nConsider removing the current directory from the standard search path by calling SetDllDirectory with an\r\nempty string (\"\"). This should be done once early in process initialization, not before and after calls to\r\nLoadLibrary. Be aware that SetDllDirectory affects the entire process and that multiple threads calling\r\nSetDllDirectory with different values can cause undefined behavior. If your application loads third-party\r\nDLLs, test carefully to identify any incompatibilities.\r\nDo not use the SearchPath function to retrieve a path to a DLL for a subsequent LoadLibrary call unless\r\nsafe process search mode is enabled. When safe process search mode is not enabled, the SearchPath\r\nfunction uses a different search order than LoadLibrary and is likely to first search the user's current\r\ndirectory for the specified DLL. To enable safe process search mode for the SearchPath function, use the\r\nSetSearchPathMode function with BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE. This\r\nmoves the current directory to the end of the SearchPath search list for the life of the process. Note that\r\nthe current directory is not removed from the search path, so if the system does not find a legitimate copy\r\nof the DLL before it reaches the current directory, the application is still vulnerable. As with\r\nSetDllDirectory, calling SetSearchPathMode should be done early in process initialization and it affects\r\nthe entire process. If your application loads third-party DLLs, test carefully to identify any\r\nincompatibilities.\r\nDo not make assumptions about the operating system version based on a LoadLibrary call that searches\r\nfor a DLL. If the application is running in an environment where the DLL is legitimately not present but a\r\nmalicious copy of the DLL is in the search path, the malicious copy of the DLL may be loaded. Instead, use\r\nthe recommended techniques described in Getting the System Version.\r\nThe Process Monitor tool can be used to help identify DLL load operations that might be vulnerable. The Process\r\nMonitor tool can be downloaded from https://technet.microsoft.com/sysinternals/bb896645.aspx.\r\nThe following procedure describes how to use Process Monitor to examine DLL load operations in your\r\napplication.\r\nTo use Process Monitor to examine DLL load operations in your application\r\nhttps://msdn.microsoft.com/en-us/library/ff919712.aspx\r\nPage 2 of 3\n\n1. Start Process Monitor.\r\n2. In Process Monitor, include the following filters:\r\nOperation is CreateFile\r\nOperation is LoadImage\r\nPath contains .cpl\r\nPath contains .dll\r\nPath contains .drv\r\nPath contains .exe\r\nPath contains .ocx\r\nPath contains .scr\r\nPath contains .sys\r\n3. Exclude the following filters:\r\nProcess Name is procmon.exe\r\nProcess Name is Procmon64.exe\r\nProcess Name is System\r\nOperation begins with IRP_MJ_\r\nOperation begins with FASTIO_\r\nResult is SUCCESS\r\nPath ends with pagefile.sys\r\n4. Attempt to start your application with the current directory set to a specific directory. For example, double-click a file with an extension whose file handler is assigned to your application.\r\n5. Check Process Monitor output for paths that look suspicious, such as a call to the current directory to load\r\na DLL. This kind of call might indicate a vulnerability in your application.\r\nSource: https://msdn.microsoft.com/en-us/library/ff919712.aspx\r\nhttps://msdn.microsoft.com/en-us/library/ff919712.aspx\r\nPage 3 of 3", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://msdn.microsoft.com/en-us/library/ff919712.aspx" ], "report_names": [ "ff919712.aspx" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775434581, "ts_updated_at": 1775791470, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/d34ff66f242ec64e6a0eb7fbceaedf4df9bb8204.pdf", "text": "https://archive.orkl.eu/d34ff66f242ec64e6a0eb7fbceaedf4df9bb8204.txt", "img": "https://archive.orkl.eu/d34ff66f242ec64e6a0eb7fbceaedf4df9bb8204.jpg" } }