{
	"id": "2ec1b831-61b5-4cda-9b30-d9318f5a6168",
	"created_at": "2026-04-06T00:22:11.594091Z",
	"updated_at": "2026-04-10T03:21:16.573867Z",
	"deleted_at": null,
	"sha1_hash": "03f6286c6e4eae50d6c39f7258a311915f369f23",
	"title": "DLL Side-loading \u0026 Hijacking | DLL Abuse Techniques Overview",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2788465,
	"plain_text": "DLL Side-loading \u0026 Hijacking | DLL Abuse Techniques Overview\r\nBy Mandiant\r\nPublished: 2020-01-31 · Archived: 2026-04-05 21:52:49 UTC\r\nWritten by: Evan Pena, Ruben Boonen, Brett Hawkins\r\nDLL Abuse Techniques Overview\r\nDynamic-link library (DLL) side-loading occurs when Windows Side-by-Side (WinSxS) manifests are not explicit\r\nabout the characteristics of DLLs being loaded by a program. In layman’s terms, DLL side-loading can allow an\r\nattacker to trick a program into loading a malicious DLL. If you are interested in learning more about how DLL\r\nside-loading works and how we see attackers using this technique, read through our report.\r\nDLL hijacking occurs when an attacker is able to take advantage of the Windows search and load order, allowing\r\nthe execution of a malicious DLL, rather than the legitimate DLL.\r\nDLL side-loading and hijacking has been around for years; in fact, FireEye Mandiant was one of the first to\r\ndiscover the DLL side-loading technique along with DLL search order hijacking back in 2010. So why are we still\r\nwriting a blog about it? Because it’s still a method that works and is used in real world intrusions! FireEye\r\nMandiant still identifies and observes threat groups using DLL abuse techniques during incident response (IR)\r\nengagements. There are still plenty of signed executables vulnerable to this, and our red team has weaponized\r\nDLL abuse techniques to be part of our methodology. For detection and preventative measures on DLL abuse\r\ntechniques, see the “Detection and Preventative Measures” section in this blog post.\r\nEven though DLL abuse techniques are not new or cutting edge, this blog post will showcase how the FireEye\r\nMandiant red team uses FireEye Intelligence to expedite the research phase of identifying vulnerable executables,\r\nat scale! We will also walk you through how to discover new executables susceptible to DLL abuse and how the\r\nFireEye Mandiant red team has weaponized these DLL abuse techniques in its DueDLLigence tool. The\r\nDueDLLigence tool was initially released to be a framework for application whitelisting bypasses, but given the\r\nnature of unmanaged exports it can be used for DLL abuse techniques as well.\r\nCollecting and Weaponizing FireEye Intelligence\r\nA benefit of being part of the red team at FireEye Mandiant is having access to a tremendous amount of threat\r\nintelligence; Our organization’s incident response and intelligence consultants have observed, documented, and\r\nanalysed the actions of attackers across almost every major breach over the past decade. For this project, the\r\nFireEye Mandiant red team asked the FireEye Technical Operations and Reverse Engineering Advanced Practices\r\n(TORE AP) team to leverage FireEye Intelligence and provide us with all DLL abuse techniques used by attackers\r\nthat matched the following criteria:\r\n1. A standalone PE file (.exe file) was used to call a malicious DLL\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 1 of 15\n\n2. The .exe must be signed and the certificate not expire within a year\r\n3. The intelligence about the technique must include the name of the malicious DLL that was called\r\nOnce the results were provided to the red team, we started weaponizing the intelligence by taking the approach\r\noutlined in the rest of the post, which includes:\r\n1. Identifying executables susceptible to DLL search order hijacking\r\n2. Identifying library dependencies for the executable\r\n3. Satisfying API’s exported in the library\r\nDLL Search Order Hijacking\r\nIn many cases it is possible to execute code within the context of a legitimate Portable Executable (PE) by taking\r\nadvantage of insecure library references. If a developer allows LoadLibrary to resolve the path of a library\r\ndynamically then that PE will also look in the current directory for the library DLL. This behavior can be used for\r\nmalicious purposes by copying a legitimate PE to a directory where the attacker has write access. If the attacker\r\ncreates a custom payload DLL, then the application will load that DLL and execute the attacker’s code. This can\r\nbe beneficial for a red team: the PE may be signed and have the appearance of trust to the endpoint security\r\nsolution (AV/EDR), it may bypass application white listing (AWL) and can confuse/delay an investigation\r\nprocess.\r\nIn this section we will look at one example where we identify the conditions for hijacking a PE and implement the\r\nrequirements in our payload DLL. For this test case we will use a signed binary PotPlayerMini (MD5:\r\nf16903b2ff82689404f7d0820f461e5d). This PE was chosen since it has been used by attackers dating back to\r\n2016.\r\nIdentifying Library Dependencies\r\nIt is possible to determine which libraries and exports a PE requires through static analysis with tools such as IDA\r\nor Ghidra. The screenshot shown in Figure 1, for example, shows that PotPlayerMini tries to load a DLL called\r\n“PotPlayer.dll”.\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 2 of 15\n\nFigure 1: Static Analysis of DLL's loaded by PotPlayerMini\r\nWhere static analysis is not feasible or desirable it may be possible to use a hooking framework such as API\r\nMonitor or Frida to profile the LoadLibrary / GetProcAddress behavior of the application.\r\nIn Figure 2 we used API Monitor to see this same DLL loading behavior. As you can see, PotPlayerMini is\r\nlooking for the PotPlayer.dll file in its current directory. At this point, we have validated that PotPlayerMini is\r\nsusceptible to DLL search order hijacking.\r\nFigure 2: Dynamic Analysis of DLL's loaded by PotPlayerMini\r\nSatisfying Exports\r\nAfter identifying potentially vulnerable library modules we need to apply a similar methodology to identify which\r\nexports are required from the module PE. Figure 3 shows a decompiled view from PotPlayerMini highlighting\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 3 of 15\n\nwhich exports it is looking for within the GetProcAddress functions using static analysis. Figure 4 shows\r\nperforming this same analysis of exports in the PotPlayerMini application, but using dynamic analysis instead.\r\nFigure 3: Static Analysis of exports in PotPlayerMini DLL\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 4 of 15\n\nFigure 4: Dynamic Analysis of exports in PotPlayerMini DLL\r\nIn our case the payload is a .NET DLL which uses UnmanagedExports so we have to satisfy all export\r\nrequirements from the binary as shown in Figure 5. This is because the .NET UnmanagedExports library does not\r\nsupport DllMain, since that is an entry point and is not exported. All export requirements need to be satisfied to\r\nensure the DLL has all the functions exported which the program accesses via GetProcAddress or import address\r\ntable (IAT). These export methods will match those that were observed in the static and dynamic analysis. This\r\nmay require some trial and error depending on the validation that is present in the binary.\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 5 of 15\n\nFigure 5: Adding export requirements in .NET DLL\r\nOnce we execute the binary, we can see that it successfully executes our function as shown in Figure 6.\r\nFigure 6: Executing binary susceptible to DLL abuse\r\nDLL Hijacking Without Satisfying All Exports\r\nWhen writing a payload DLL in C/C++ it is possible to hijack control flow in DllMain. When doing this it is not\r\nnecessary to enumerate and satisfy all needed exports as previously described. There also may be cases where the\r\nDLL does not have any exports and can only be hijacked via the DllMain entry point.\r\nAn example of this can be shown with the Windows Media Player Folder Sharing executable called\r\nwmpshare.exe. You can copy the executable to a directory out of its original location (C:\\Program Files\r\n(x86)\\Windows Media Player) and perform dynamic analysis using API Monitor. In Figure 7, you can see that the\r\nwmpshare.exe program uses the LoadLibraryW method to load the wmp.dll file, but does not specify an explicit\r\npath to the DLL. When this happens, the LoadLibraryW method will first search the directory in which the\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 6 of 15\n\nprocess was created (present working directory). Full details on the search order used can be found in the\r\nLoadLibraryW documentation and the CreateProcess documentation.\r\nFigure 7: Viewing LoadLibrary calls in wmpshare.exe\r\nSince it does not specify an explicit path, you can test if it can be susceptible to DLL hijacking by creating a blank\r\nfile named “wmp.dll” and copying it to the same directory as the wmpshare.exe file. Now when running the\r\nwmpshare executable in API Monitor, you can see it is first checking in its current directory for the wmp.dll file,\r\nshown in Figure 8. Therefore, it is possible to use this binary for DLL hijacking.\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 7 of 15\n\nFigure 8: Viewing LoadLibrary calls in wmpshare.exe with dummy dll present\r\nFigure 9 shows using the wmpshare executable in a weaponized manner to take advantage of the DllMain entry\r\npoint with a DLL created in C++.\r\nFigure 9: Using the DllMain entry point\r\nDiscovering New Executables Susceptible to DLL Abuse\r\nIn addition to weaponizing the FireEye intelligence of the executables used for DLL abuse by attackers, the\r\nFireEye Mandiant red team performed research to discover new executables susceptible to abuse by targeting\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 8 of 15\n\nWindows system utilities and third-party applications.\r\nWindows System Utilities\r\nThe FireEye Mandiant red team used the methodology previously described in the Collecting and Weaponizing\r\nFireEye Intelligence section to look at Windows system utilities present in the C:\\Windows\\System32 directory\r\nthat were susceptible to DLL abuse techniques. One of the system utilities found was the deployment image\r\nservicing and management (DISM) utility (Dism.exe). When performing dynamic analysis of this system utility, it\r\nwas observed that it was attempting to load the DismCore.dll file in the current directory as shown in Figure 10.\r\nFigure 10: Performing dynamic analysis of Dism utility\r\nNext, we loaded the DISM system utility into API Monitor from its normal path (C:\\Windows\\System32) in order\r\nto see the required exports as shown in Figure 11.\r\nFigure 11: Required exports for DismCore.dll\r\nThe code shown in Figure 12 was added to DueDLLigence to validate that the DLL was vulnerable and could be\r\nran successfully using the DISM system utility.\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 9 of 15\n\nFigure 12: Dism export method added to DueDLLigence\r\nThird-Party Applications\r\nThe FireEye Mandiant red team also targeted executable files associated with common third-party applications\r\nthat could be susceptible to DLL abuse. One of the executable files discovered was a Tortoise SVN utility\r\n(SubWCRev.exe). When performing dynamic analysis of this Tortoise SVN utility, it was observed that it was\r\nattempting to load crshhndl.dll in the current directory. The export methods are shown in Figure 13.\r\nFigure 13: Performing dynamic analysis of SubWCRev.exe\r\nThe code shown in Figure 14 was added to DueDLLigence to validate that the DLL was vulnerable and could be\r\nran successfully using the Tortoise SVN utility.\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 10 of 15\n\nFigure 14: SubWCRev.exe export methods added to DueDLLigence\r\nApplying It to the Red Team\r\nHaving a standalone trusted executable allows the red team to simply copy the trusted executable and malicious\r\nDLL to a victim machine and bypass various host-based security controls, including application whitelisting. Once\r\nthe trusted executable (vulnerable to DLL abuse) and malicious DLL are both in the same present working\r\ndirectory, the executable will call the corresponding DLL within the same directory. This method can be used in\r\nmultiple phases of the attack lifecycle as payload implants, including phases such as establishing persistence and\r\nperforming lateral movement.\r\nPersistence\r\nIn this example, we will be using the Windows system utility Dism.exe discovered in the Windows System\r\nUtilities section as our executable, along with a DLL generated by DueDLLigence in conjunction with SharPersist\r\nto establish persistence on a target system. First, the DISM system utility and malicious DLL are uploaded to the\r\ntarget system as shown in Figure 15.\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 11 of 15\n\nFigure 15: Uploading payload files\r\nFigure 16: Adding startup folder persistence with SharPersist\r\nAfter the target machine has been rebooted and the targeted user has logged on, Figure 17 shows our Cobalt Strike\r\nC2 server receiving a beacon callback from our startup folder persistence where we are living in the Dism.exe\r\nprocess.\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 12 of 15\n\nFigure 17: Successful persistence callback\r\nLateral Movement\r\nWe will continue using the same DISM system utility and DLL file for lateral movement. The\r\nHOGWARTS\\adumbledore user has administrative access to the remote host 192.168.1.101 in this example. We\r\ntransfer the DISM system utility and the associated DLL file via the SMB protocol to the remote host as shown in\r\nFigure 18.\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 13 of 15\n\nFigure 18: Transferring payload files to remote host via SMB\r\nThen we setup a SOCKS proxy in our initial beacon, and use Impacket’s wmiexec.py to execute our payload via\r\nthe Windows Management Instrumentation (WMI) protocol, as shown in Figure 19 and Figure 20.\r\nproxychains python wmiexec.py -nooutput DOMAIN/user:password:@x.x.x.x C:\\\\Temp\\\\Dism.exe\r\nFigure 19: Executing payload via WMI with Impacket’s wmiexec.py\r\nFigure 20: Output of executing command shown in Figure 19\r\nWe receive a beacon from the remote host, shown in Figure 21, after executing the DISM system utility via WMI.\r\nFigure 21: Obtaining beacon on remote host\r\nDetection and Preventative Measures\r\nDetailed prevention and detection methods for DLL side-loading are well documented in the report and mentioned\r\nin the DLL Abuse Techniques Overview. The report breaks it down into preventative measures at the software\r\ndevelopment level and goes into recommendations for the endpoint user level. A few detection methods that are\r\nnot mentioned in the report include:\r\nChecking for processes that have unusual network connectivity\r\nIf you have created a baseline of normal process network activity, and network activity for a given\r\nprocess has become different than the baseline, it is possible the said process has been\r\ncompromised.\r\nDLL whitelisting\r\nTrack the hashes of DLLs used on systems to identify discrepancies.\r\nThese detection methods are difficult to implement at scale, but possible to utilize. That is exactly why this old\r\ntechnique is still valid and used by modern red teams and threat groups. The real problem that allows this\r\nvulnerability to continue to exist has to do with software publishers. Software publishers need to be aware of DLL\r\nabuse techniques and know how to prevent such vulnerabilities from being developed into products (e.g. by\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 14 of 15\n\nimplementing the mitigations discussed in our report). Applying these recommendations will reduce the DLL\r\nabuse opportunities attackers use to bypass several modern-day detection techniques.\r\nMicrosoft has provided some great resources on DLL security and triaging a DLL hijacking vulnerability.\r\nConclusion\r\nThreat intelligence provides immense value to red teamers who are looking to perform offensive research and\r\ndevelopment and emulate real-life attackers. By looking at what real attackers are doing, a red teamer can glean\r\ninspiration for future tooling or TTPs.\r\nDLL abuse techniques can be helpful from an evasion standpoint in multiple phases of the attack lifecycle, such as\r\npersistence and lateral movement. There will continue to be more executables discovered that are susceptible to\r\nDLL abuse and used by security professionals and adversaries alike.\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nhttps://www.mandiant.com/blog/dll-search-order-hijacking-revisited/\r\nPage 15 of 15",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.mandiant.com/blog/dll-search-order-hijacking-revisited/"
	],
	"report_names": [
		"dll-search-order-hijacking-revisited"
	],
	"threat_actors": [],
	"ts_created_at": 1775434931,
	"ts_updated_at": 1775791276,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/03f6286c6e4eae50d6c39f7258a311915f369f23.pdf",
		"text": "https://archive.orkl.eu/03f6286c6e4eae50d6c39f7258a311915f369f23.txt",
		"img": "https://archive.orkl.eu/03f6286c6e4eae50d6c39f7258a311915f369f23.jpg"
	}
}