{
	"id": "53415f57-e3b8-4647-ae78-bc53d38b47fd",
	"created_at": "2026-04-06T01:30:17.384901Z",
	"updated_at": "2026-04-10T03:21:18.575787Z",
	"deleted_at": null,
	"sha1_hash": "b1c353ae8258fcdaa477a5cc93c54a6f1d9efe59",
	"title": "4 Ways Adversaries Hijack DLLs | CrowdStrike",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 77853,
	"plain_text": "4 Ways Adversaries Hijack DLLs | CrowdStrike\r\nBy Falcon OverWatch Team\r\nArchived: 2026-04-06 00:59:52 UTC\r\nDynamic link library (DLL) hijacking is frequently written about by defenders due to its applications in evading\r\nautomated detections. This technique is even more frequently used by adversaries in interactive intrusions. Despite\r\nthe wealth of literature available to increase defenders’ awareness of DLL hijacking, CrowdStrike® Falcon\r\nOverWatch™ threat hunters see adversaries gravitate toward this tradecraft time and again to load malicious code.\r\nPut simply, adversaries do this because it works.\r\nA DLL is a file containing code that can be loaded by an application. The use of DLL files is commonly seen in\r\nthe Microsoft Windows operating system, along with others. According to Microsoft, the purpose of DLL files is\r\nto “promote modularization of code, code reuse, efficient memory usage and reduced disk space.”\r\nWhat is DLL Hijacking?\r\nDLL hijacking is a technique used to load malicious code for the purposes of defense evasion, persistence and\r\nprivilege escalation. Rather than execute malicious code directly via an executable file, adversaries will leverage a\r\nlegitimate application to load a malicious DLL file. This technique may enable malicious code to bypass\r\napplication allowlisting or other automated controls; further, casual inspection of the running process only shows\r\nthe legitimate application running.\r\nOne reason DLL hijacking remains difficult to mitigate with automated defenses alone is the technique offers\r\nadversaries so much flexibility and variability in its implementation. And so, the cat-and-mouse game between\r\ndefender and adversary continues.\r\nThis blog examines four implementations of DLL hijacking, as well as how Falcon OverWatch threat hunters see\r\nthem used in the wild, fine-tune their hunts and augment CrowdStrike’s automated detection capabilities\r\naccordingly.\r\nWatch this short video to see how Falcon OverWatch proactively hunts for threats in your environment.\r\nTo hijack a DLL, an adversary typically needs three things: a malicious DLL, a legitimate application to hijack\r\n(ideally one configured to run with elevated privileges), and working knowledge of Microsoft Windows, including\r\nhow it determines which DLL files an application should load and which actions to take when a DLL’s location is\r\nambiguous.\r\nAdversaries are known to use the following four methods of DLL hijacking, all described in greater detail below:\r\n1. Search order hijacking\r\n2. Relative path DLL hijacking\r\n3. Phantom DLL hijacking\r\nhttps://www.crowdstrike.com/en-us/blog/4-ways-adversaries-hijack-dlls/\r\nPage 1 of 5\n\n4. DLL redirection\r\n1. Search Order Hijacking: Taking Advantage of Predictable OS Behavior\r\nSearch order hijacking — perhaps the DLL hijacking example best known to security testers — is when an\r\nadversary takes advantage of the well-documented behavior of the Windows operating system to “trick” it into\r\nrunning malicious code under a legitimate process.\r\nImagine an application developer creates an executable file written to c:\\app\\app.exe that loads a DLL\r\ncode.dll by name only and relies on Windows to identify the correct location. The developer assumes the DLL\r\nwill be at C:\\shared\\code.dll and that the C:\\shared directory is added to the PATH environment variable\r\nwhen the application is installed. However, a knowledgeable attacker knows the Windows operating system\r\nsearches a predefined list of locations for a DLL when the DLL’s location is ambiguous and not explicitly defined.\r\nThese locations vary depending on how the operating system is configured but often look something like this:\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\nIf an adversary can write a malicious code.dll file to any one of the other locations listed before the PATH\r\nenvironment variable, then the malicious file will be loaded first. Further, if the app.exe file is executed with\r\nelevated privileges, then the adversary’s malicious code will be loaded and executed with the same privileges,\r\nthereby facilitating an unauthorized elevation of privileges.\r\nAdversaries like search order hijacking because it only requires them to drop a single DLL to the right location.\r\nThis technique typically involves exploiting a pre-existing installation and is often done to elevate privileges.\r\nHowever, Falcon OverWatch threat hunters rarely see this technique, likely due to the amount of effort required\r\nfor an adversary to identify vulnerable installed applications.\r\n2. Relative Path DLL Hijacking: Abusing the Search Order by Moving the Executable\r\nOne of the most common DLL hijacking techniques that Falcon OverWatch sees is a variation of search order\r\nhijacking known as relative path DLL hijacking. This is when the adversary writes (and typically renames) a\r\nlegitimate executable file, alongside their malicious DLL, to a folder they have adequate permissions to write to.\r\nThis technique requires a legitimate executable that does not specify an absolute path for DLL files. If an absolute\r\npath is not specified, then Windows operating systems will search for the DLL file following the predefined search\r\norder. As noted above, this search order can vary between operating systems and the settings configured, but one\r\nof the locations that is often early in the search order is the directory from which the application loaded, known as\r\nthe relative path (i.e., ./ ). A number of executable files, including some published by Microsoft, behave this\r\nway.\r\nhttps://www.crowdstrike.com/en-us/blog/4-ways-adversaries-hijack-dlls/\r\nPage 2 of 5\n\nIn one investigation, Falcon OverWatch observed an adversary write a renamed copy of applaunch.exe — a\r\nMicrosoft executable file — to the c:\\users\\public directory. The file was renamed to make it blend in with the\r\nnormal operation of the host. The adversary also wrote their malicious DLL named mscoree.dll to the same\r\ndirectory. When the renamed executable file was launched, it loaded the malicious DLL and executed the\r\nadversary’s code.\r\nTo mitigate attempts to hide attacks in unexpected directories, Falcon OverWatch actively hunts for execution\r\nfrom unusual locations and maintains a list of executable files that might load a DLL from a relative file. These\r\nefforts, combined with looking for rare files across CrowdStrike telemetry, allow threat hunters to detect attacks\r\nthat may otherwise go unseen.\r\n3. Phantom DLL Hijacking: Taking Advantage of Missing DLLs\r\nThe Windows operating system references a surprising number of DLL files that don’t exist. Phantom DLL\r\nhijacking is when the adversary writes a malicious DLL to the location of one of these missing files. This DLL is\r\nthen loaded when the operating system runs the code that references that file.\r\nPhantom DLL hijacking is best demonstrated with an admittedly simple example. The IKEEXT service is present\r\non many versions of Windows, runs at startup and is used for authentication and key exchange in Internet Protocol\r\nsecurity. When it starts, IKEEXT attempts to load the file C:\\Windows\\System32\\wlbsctrl.dll — however, this\r\nDLL doesn’t exist. If an adversary can write a malicious DLL file to this location (or other locations not covered\r\nhere), their malicious code can be executed when the IKEEXT service is (re)started.\r\n'In the above example, note an adversary would need to already have administrative privileges to be able to write\r\nto the System32 directory. This example is a persistence mechanism since the adversary configured the IKEEXT\r\nservice to start when the system boots. Leveraging services that are expected to run on startup would likely evade\r\ndetection by cursory inspection, reinforcing the need for proactive and comprehensive hunting.\r\nMany malicious versions of this file being written will be detected and blocked by the CrowdStrike Falcon®\r\nplatform — usually because they are known to be malicious or they share characteristics with previously observed\r\nmalicious files. Falcon OverWatch hunts for activity that is difficult to detect or prevent. One way hunters do this\r\nis by looking for files being written that are rare or unique across the CrowdStrike telemetry. Low-prevalence files\r\nare considered suspicious and warrant further investigation. If an investigation deems a file malicious, Falcon\r\nOverWatch will not only notify the victim organization but also tag the file as malicious so the Falcon sensor can\r\nautonomously detect future attempts to use the file across the entire Falcon install base. This is true of all\r\nmalicious files identified by Falcon OverWatch.\r\n4. DLL Redirection: Changing the Search Order to Suit the Adversary’s Needs\r\nDLL redirection is perhaps one of the most novel ways to hijack a DLL. Instead of leveraging the predefined\r\nsearch order, in DLL redirection attacks the adversary changes the location at which the operating system searches\r\nfor the DLL file. For example, an adversary can make changes to the registry to modify the search order and cause\r\na program to run a different DLL file.\r\nhttps://www.crowdstrike.com/en-us/blog/4-ways-adversaries-hijack-dlls/\r\nPage 3 of 5\n\nThe MSDTC service, which is used to manage transactions across multiple servers, is another example of a\r\nWindows service that attempts to load a missing DLL and is vulnerable to the phantom DLL hijacking method\r\ndiscussed above. An adversary could write a malicious DLL to the default location\r\nC:\\windows\\system32\\oci.dll and (re)start the MSDTC service to load their malicious code. However, this\r\nwould be quickly detected by Falcon OverWatch, as hunters look for rare files being written to this location. Some\r\nadversaries will therefore attempt the more evasive method of changing the location that Windows checks when\r\nloading this DLL. By modifying the following registry key, an adversary can change the name of the file that\r\nWindows will use when starting the service:\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MSDTC\\MTxOCI\\OracleOciLib\r\nBy default, this key contains the value oci.dll , but an adversary could change this value to any filename —\r\nevil.dll , for example. The adversary would then simply write their file to C:\\Windows\\System32\\evil.dll\r\nand restart the MSDTC service, and their malicious code would be executed. This would bypass the detection\r\ntechnique used above. Falcon OverWatch also looks for changes to registry keys like this, so it would be detected\r\nand investigated.\r\nWhich DLL Hijacking Method Do Adversaries Prefer?\r\nThe most common form of DLL hijacking observed by Falcon OverWatch is relative path DLL hijacking. This is\r\nlikely due to the minimal effort it requires:\r\nThe adversary doesn’t need to know much about their target system, so the amount of reconnaissance\r\nrequired is reduced, and therefore so is the perceived likelihood of being detected.\r\nThey don’t have to tamper with any other part of the system, such as the registry, which they believe\r\nreduces their chances of them being detected.\r\nThey can operate from almost any directory, which increases the search space for defenders, which again\r\nlowers the perceived likelihood of being detected.\r\nWhile DLL redirection and phantom DLL hijacking are less common — likely due to the overhead required to\r\nidentify suitable attack paths — Falcon OverWatch has seen these leveraged by sophisticated state-nexus\r\nadversaries with relative frequency and so they should not be overlooked.\r\nHow Falcon OverWatch Identifies and Prevents DLL Hijacking\r\nAdversaries routinely hijack DLLs to attempt to circumvent automated security controls. Using a global-scale\r\ndataset, Falcon OverWatch threat hunters can quickly and accurately identify these DLL hijacking attempts.\r\nThe power of the Falcon OverWatch threat hunting model is the volume of data that hunters can leverage to\r\nquickly pinpoint whether a particular DLL is malicious, based on its prevalence within a global real-time dataset.\r\nFalcon OverWatch continuously hunts for globally rare DLL files, files written to suspicious locations and\r\nprograms executing from unusual locations. These hunting techniques rely on baselines that come from extensive\r\nreal-time data, something that cannot be replicated by any individual organization in isolation. Falcon OverWatch\r\ncan augment even the most mature security programs with the power of global data. By being part of the Falcon\r\nOverWatch ecosystem, your organization benefits from the efforts of the global threat hunting team.\r\nhttps://www.crowdstrike.com/en-us/blog/4-ways-adversaries-hijack-dlls/\r\nPage 4 of 5\n\nSee for yourself how the industry-leading CrowdStrike Falcon platform protects against modern threats.\r\nStart your 15-day free trial today.\r\nAdditional Resources\r\nRead about the latest threat hunting trends in the 2022 Falcon OverWatch Threat Hunting Report.\r\nLearn more about Falcon OverWatch’s proactive managed threat hunting.\r\nDiscover the power of tailored threat hunting provided by Falcon OverWatch Elite.\r\nFind out why part-time threat hunting is simply not enough.\r\nLearn more about the CrowdStrike Falcon® platform.\r\nSource: https://www.crowdstrike.com/en-us/blog/4-ways-adversaries-hijack-dlls/\r\nhttps://www.crowdstrike.com/en-us/blog/4-ways-adversaries-hijack-dlls/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.crowdstrike.com/en-us/blog/4-ways-adversaries-hijack-dlls/"
	],
	"report_names": [
		"4-ways-adversaries-hijack-dlls"
	],
	"threat_actors": [],
	"ts_created_at": 1775439017,
	"ts_updated_at": 1775791278,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b1c353ae8258fcdaa477a5cc93c54a6f1d9efe59.pdf",
		"text": "https://archive.orkl.eu/b1c353ae8258fcdaa477a5cc93c54a6f1d9efe59.txt",
		"img": "https://archive.orkl.eu/b1c353ae8258fcdaa477a5cc93c54a6f1d9efe59.jpg"
	}
}