{
	"id": "1d56e868-fd7a-4f02-b9d1-aaade8e98a43",
	"created_at": "2026-04-06T00:19:51.04102Z",
	"updated_at": "2026-04-10T03:21:58.710488Z",
	"deleted_at": null,
	"sha1_hash": "355b7e8d57a15db46f68130a3b588d8733db2143",
	"title": "More information about the DLL Preloading remote attack vector",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 55579,
	"plain_text": "More information about the DLL Preloading remote attack vector\r\nBy swiat\r\nPublished: 2010-08-23 · Archived: 2026-04-05 22:38:46 UTC\r\n/ By / August 23, 2010\r\nToday we released Security Advisory 2269637 notifying customers of a remote attack vector to a class of\r\nvulnerabilities affecting applications that load DLL’s in an insecure manner. The root cause of this issue has been\r\nunderstood by developers for some time. However, last week researchers published a remote attack vector for\r\nthese issues, whereas in the past, these issues were generally considered to be local and relatively low impact. In\r\nthis blog post, we’d like to share:\r\nBackground about the vulnerability\r\nInformation to help you make a risk assessment for your environment\r\nAn optional binary update you can install to protect your systems\r\nGuidance for developers\r\nWhat Microsoft is doing\r\nThe vulnerability\r\nWhen an application loads a DLL without specifying a fully qualified path name, Windows will attempt to locate\r\nthe DLL by searching a defined set of directories. We have discussed the DLL search path on this blog and it has\r\nalso been explained well on David LeBlanc’s blog. For the sake of this issue, its sufficient to say that if an attacker\r\ncan cause an application to LoadLibrary() while the application’s current directory is set to an attacker-controlled\r\ndirectory, the application will run the attacker’s code.Development best practicesstate that applications should call\r\nSetDllDirectory with a blank path before calling LoadLibrary(“foo.dll”) to ensure that foo.dll is not loaded from\r\nthe current directory. We are investigating whether any of our own applications are affected by this class of\r\nvulnerability so that we can take appropriate action to protect customers.\r\nMaking a risk assessment for your environment\r\nThe most likely exploit scenario involves an attacker convincing the victim to open a file hosted on an attacker-controlled SMB or WebDAV share. The file itself would not necessarily be malicious or malformed. The key is\r\nthat the file is loaded from a location where an attacker can also place a malicious DLL with the same name as a\r\nDLL the vulnerable application loads.\r\nIf a perimeter firewall prevents a system from making outbound SMB or WebDAV connections to attacker-controlled locations, this issue poses little risk. An attack cannot be automatically launched through email or web\r\nbrowsing attack vectors; a user must choose to open a file. However we recognize that users will often open\r\ntrusted filetypes. We continue to recommend that all outbound SMB is filtered at the perimeter firewall. In\r\naddition, thesecurity advisoryrecommends disabling the WebDAV client service on workstations to prevent\r\noutbound WebDAV connections.\r\nhttps://msrc-blog.microsoft.com/2010/08/23/more-information-about-the-dll-preloading-remote-attack-vector/\r\nPage 1 of 4\n\nA tool you can use to protect your systems\nAnother option for protecting your systems is to deploy a tool that can help prevent exploitation of this issue.\nKnowledge Base article 2264107 offers for download a tool that allows customers to selectively change the library\nloading behavior, either system-wide or for specific applications.\nCustomers can set the following two registry keys: **\nHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\  \nSession Manager\\CWDIllegalInDllSearch  \nHKEY_LOCAL_MA\nSetting the first key will define the system-wide behavior, whereas the second key will set the behavior for one\nparticular application. Note that this is an Image File Execution Option (IFEO), and thus will be valid for all\nbinaries with that same name on the system.\nThe values for these keys have slightly different effects, depending on from where the application is started.\nScenario 1: The application is started from a local folder, such as C:\\Program Files\n0xffffffff Removes the current working directory from the default DLL search order.\n0 Uses the default DLL search path. This is the Windows default, and the least secure setting.\n1\nBlocks a DLL load from the current working directory if the current working directory is set to a\nWebDAV folder.\n2\nBlocks a DLL load from the current working directory if the current working directory is set to a\nremote folder.\nScenario 2: The application is started from a remote folder, such as \\\\remote\\share\n0xffffffff Removes the current working directory from the default DLL search order.\n0 Uses the default DLL search path. This is the Windows default, and the least secure setting.\n1\nBlocks a DLL load from the current working directory if the current working directory is set to a\nWebDAV folder.\n2\nAllows DLL load from the current working directory if the current working directory is set to a\nremote folder. DLL’s that are loaded from a WebDAV share are blocked if the current working\nhttps://msrc-blog.microsoft.com/2010/08/23/more-information-about-the-dll-preloading-remote-attack-vector/\nPage 2 of 4\n\n0xffffffff Removes the current working directory from the default DLL search order.\r\ndirectory is set to a WebDAV share.\r\nScenario 3: The application is started from a WebDAV folder, such as http://remote/share\r\n0xffffffff Removes the current working directory from the default DLL search order.\r\n0 Uses the default DLL search path. This is the Windows default, and the least secure setting.\r\nHow can developers address these issues?\r\nMicrosoft recommends that developers clearly define from where they intend to load specific libraries. This was\r\ndocumented in the specific LoadLibrary application programming interface documentation on MSDN. However,\r\nwe recognize that this guidance may not always have been very clear. We recently published an MSDN article,\r\n“Dynamic-Link Library Security,” that provides specific guidance to developers on how to load these libraries\r\nsecurely.\r\nWhile there are several affected situations, described in detail in the above MSDN article, our general\r\nrecommendations are:\r\nWhere possible, use a fully qualified path name when loading a library;\r\nRemove the current directory from the search path by using SetDLLDirectory;\r\nDo not use SearchPath to locate a library. SearchPath was not intended to look for libraries to be loaded\r\ninto the application process space, and uses an insecure search order;\r\nDo not attempt to load libraries purely to identify the version of Windows. Instead, use GetVersionEx or a\r\nsimilar function offered by the Windows API.\r\nWe’ve also recently drafted additional guidance to help developers understand this issue. You can find that\r\ndeveloper guidance attached to the blog post.\r\nWhat Microsoft is doing\r\nLoading dynamic libraries is basic behavior for Windows and other operating systems, and the design of some\r\napplications require the ability to load libraries from the current working directory. Hence, this issue cannot\r\ndirectly be addressed in Windows without breaking expected functionality. Instead, it requires developers to\r\nensure they code secure library loads. However, we’re looking into ways to make it easier for developers to not\r\nmake this mistake in the future.\r\nMicrosoft is also conducting a thorough investigation into how this new vector may affect Microsoft products. As\r\nalways, if we find this issue affects any of our products, we will address them appropriately.\r\nWe hope this blog helps address any questions you may have. Thanks to Mark Debenham, Anoop KV, Hari\r\nPulapaka, Dou Kaya, Gov Maharaj, David LeBlanc, and Michael Howard for their work on this issue.\r\nhttps://msrc-blog.microsoft.com/2010/08/23/more-information-about-the-dll-preloading-remote-attack-vector/\r\nPage 3 of 4\n\nCheers,\r\nJonathan Ness, MSRC Engineering\r\nMaarten Van Horenbeeck, MSRC Program Manager\r\nMitigations\r\nRisk Asessment\r\nWorkarounds\r\nSource: https://msrc-blog.microsoft.com/2010/08/23/more-information-about-the-dll-preloading-remote-attack-vector/\r\nhttps://msrc-blog.microsoft.com/2010/08/23/more-information-about-the-dll-preloading-remote-attack-vector/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://msrc-blog.microsoft.com/2010/08/23/more-information-about-the-dll-preloading-remote-attack-vector/"
	],
	"report_names": [
		"more-information-about-the-dll-preloading-remote-attack-vector"
	],
	"threat_actors": [],
	"ts_created_at": 1775434791,
	"ts_updated_at": 1775791318,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/355b7e8d57a15db46f68130a3b588d8733db2143.pdf",
		"text": "https://archive.orkl.eu/355b7e8d57a15db46f68130a3b588d8733db2143.txt",
		"img": "https://archive.orkl.eu/355b7e8d57a15db46f68130a3b588d8733db2143.jpg"
	}
}