T1574.001: DLL
Adversaries may abuse dynamic-link library files (DLLs) in order to achieve persistence, escalate privileges, and evade defenses. DLLs are libraries that contain code and data that can be simultaneously utilized by multiple programs. While DLLs are not malicious by nature, they can be abused through mechanisms such as side-loading, hijacking search order, and phantom DLL hijacking.Citationunit 42
Specific ways DLLs are abused by adversaries include:
### DLL Sideloading Adversaries may execute their own malicious payloads by side-loading DLLs. Side-loading involves hijacking which DLL a program loads by planting and then invoking a legitimate application that executes their payload(s).
Side-loading positions both the victim application and malicious payload(s) alongside each other. Adversaries likely use side-loading as a means of masking actions they perform under a legitimate, trusted, and potentially elevated system or software process. Benign executables used to side-load payloads may not be flagged during delivery and/or execution. Adversary payloads may also be encrypted/packed or otherwise obfuscated until loaded into the memory of the trusted process.
Adversaries may also side-load other packages, such as BPLs (Borland Package Library).Citationkroll bpl
Adversaries may chain DLL sideloading multiple times to fragment functionality hindering analysis. Adversaries using multiple DLL files can split the loader functions across different DLLs, with a main DLL loading the separated export functions. CitationVirus Bulletin Spreading loader functions across multiple DLLs makes analysis harder, since all files must be collected to fully understand the malware’s behavior. Another method implements a “loader-for-a-loader”, where a malicious DLL’s sole role is to load a second DLL (or a chain of DLLs) that contain the real payload. CitationSophos
### DLL Search Order Hijacking Adversaries may execute their own malicious payloads by hijacking the search order that Windows uses to load DLLs. This search order is a sequence of special and standard search locations that a program checks when loading a DLL. An adversary can plant a trojan DLL in a directory that will be prioritized by the DLL search order over the location of a legitimate library. This will cause Windows to load the malicious DLL when it is called for by the victim program.Citationunit 42
### DLL Redirection Adversaries may directly modify the search order via DLL redirection, which after being enabled (in the Registry or via the creation of a redirection file) may cause a program to load a DLL from a different location.CitationMicrosoft redirectionCitationMicrosoft - manifests/assembly
### Phantom DLL Hijacking Adversaries may leverage phantom DLL hijacking by targeting references to non-existent DLL files. They may be able to load their own malicious DLL by planting it with the correct name in the location of the missing module.CitationHexacorn DLL HijackingCitationHijack DLLs CrowdStrike
### DLL Substitution Adversaries may target existing, valid DLL files and substitute them with their own malicious DLLs, planting them with the same name and in the same location as the valid DLL file.CitationWietze Beukema DLL Hijacking
Programs that fall victim to DLL hijacking may appear to behave normally because malicious DLLs may be configured to also load the legitimate DLLs they were meant to replace, evading defenses.
Remote DLL hijacking can occur when a program sets its current directory to a remote location, such as a Web share, before loading a DLL.Citationdll pre load owaspCitationmicrosoft remote preloading
If a valid DLL is configured to run at a higher privilege level, then the adversary-controlled DLL that is loaded will also be executed at the higher level. In this case, the technique could be used for privilege escalation.
Security context for executives and security teams
DLL abuse matters because it can make malicious code run inside or beside legitimate Windows software, sometimes with the trust or privilege of that software. For business leaders, the risk is not just malware execution; it is that normal-looking applications may become the launch point for persistence, privilege escalation, and defense evasion, making incidents harder to scope and slower to contain.
Executive priority
Prioritize this behavior where Windows endpoints or servers run business-critical applications, privileged software, legacy tools, or internally developed applications. Leaders should ask whether the organization can prove which DLLs are allowed to load, whether software installation paths are writable by standard users, and whether incident responders can reconstruct DLL load activity during an investigation. This is also relevant to audit evidence for application control, patch/update discipline, secure development practices, and logging coverage.
Technical view
T1574.001 is a Windows sub-technique under Hijack Execution Flow covering DLL side-loading, DLL search order hijacking, DLL redirection, phantom DLL hijacking, DLL substitution, and remote DLL hijacking. SOC and IR teams should validate visibility into legitimate executables loading unexpected DLLs from application directories, user-writable paths, missing-module locations, redirected paths, or remote shares. Because ATT&CK does not provide official detection text for this object, detection engineering should lean on the related DET0201 detection strategy and test environment-specific baselines for trusted applications, signed binaries, application install directories, and unusual module-load chains.
Likely telemetry
- Windows process creation events showing legitimate applications launched from unusual or user-controlled locations
- Image/module load telemetry showing DLL path, loading process, signer, hash, and parent process context
- File creation and modification events for DLLs, BPLs, manifests, redirection files, and application-adjacent payloads
- Registry changes related to DLL redirection or application configuration where available
- Application control, execution prevention, or endpoint protection events for blocked or allowed DLL loads
Detection direction
- Baseline common DLL load paths for high-value Windows applications and alert on DLLs loaded from writable, temporary, application-adjacent, or remote directories when that behavior is uncommon.
- Correlate process execution with new or recently modified DLL files in the same directory as a legitimate executable, especially when the executable appears trusted but the DLL is unsigned, newly observed, or inconsistent with the application package.
- Tune carefully for legitimate application plug-ins, software updates, developer tools, and line-of-business applications that commonly load local libraries to reduce false positives.
- Look for chains of multiple DLL loaders or fragmented DLL functionality, since the ATT&CK description notes that adversaries may split loader functions across several DLLs to hinder analysis.
- Include phantom DLL and substitution cases in testing: missing-module references, same-name replacement of valid DLLs, and redirection mechanisms may not look like obvious process injection.
Mitigation priorities
- Start with secure application development and packaging practices: require explicit library paths, safe DLL loading behavior, and review of applications that search writable directories.
- Apply Restrict Library Loading controls where feasible so processes load only trusted and expected libraries.
- Use execution prevention or application control to limit unauthorized binaries and libraries, while testing business-critical applications to avoid operational disruption.
- Audit Windows application directories, user-writable paths, redirection settings, and software installation hygiene for unsafe DLL loading conditions.
- Keep operating systems and applications updated, especially legacy or end-of-life software that may retain unsafe library-loading behavior.
Additional notes and limits
This object consolidates prior ATT&CK coverage for DLL Search Order Hijacking and DLL Side-Loading into the current DLL sub-technique. The relationship set shows broad use by multiple campaigns and groups, which supports prioritizing the behavior as a common tradecraft pattern, but it does not establish current exploitation against any specific organization. The most useful local validation is whether endpoint telemetry can distinguish expected DLL loading from unexpected library resolution by trusted Windows applications.
Official ATT&CK detection text is not provided for this object. The guidance above is derived from the official description, platforms, tactics, external references, and stated relationships only. Actual detection logic, risk ranking, and control feasibility require local software inventory, endpoint logging configuration, application behavior baselines, and business tolerance for application-control enforcement.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
DLL
Adversaries may abuse dynamic-link library files (DLLs) in order to achieve persistence, escalate privileges, and evade defenses. DLLs are libraries that contain code and data that can be simultaneously utilized by multiple programs. While DLLs are not malicious by nature, they can be abused through mechanisms such as side-loading, hijacking search order, and phantom DLL hijacking.Citationunit 42
Specific ways DLLs are abused by adversaries include:
### DLL Sideloading Adversaries may execute their own malicious payloads by side-loading DLLs. Side-loading involves hijacking which DLL a program loads by planting and then invoking a legitimate application that executes their payload(s).
Side-loading positions both the victim application and malicious payload(s) alongside each other. Adversaries likely use side-loading as a means of masking actions they perform under a legitimate, trusted, and potentially elevated system or software process. Benign executables used to side-load payloads may not be flagged during delivery and/or execution. Adversary payloads may also be encrypted/packed or otherwise obfuscated until loaded into the memory of the trusted process.
Adversaries may also side-load other packages, such as BPLs (Borland Package Library).Citationkroll bpl
Adversaries may chain DLL sideloading multiple times to fragment functionality hindering analysis. Adversaries using multiple DLL files can split the loader functions across different DLLs, with a main DLL loading the separated export functions. CitationVirus Bulletin Spreading loader functions across multiple DLLs makes analysis harder, since all files must be collected to fully understand the malware’s behavior. Another method implements a “loader-for-a-loader”, where a malicious DLL’s sole role is to load a second DLL (or a chain of DLLs) that contain the real payload. CitationSophos
### DLL Search Order Hijacking Adversaries may execute their own malicious payloads by hijacking the search order that Windows uses to load DLLs. This search order is a sequence of special and standard search locations that a program checks when loading a DLL. An adversary can plant a trojan DLL in a directory that will be prioritized by the DLL search order over the location of a legitimate library. This will cause Windows to load the malicious DLL when it is called for by the victim program.Citationunit 42
### DLL Redirection Adversaries may directly modify the search order via DLL redirection, which after being enabled (in the Registry or via the creation of a redirection file) may cause a program to load a DLL from a different location.CitationMicrosoft redirectionCitationMicrosoft - manifests/assembly
### Phantom DLL Hijacking Adversaries may leverage phantom DLL hijacking by targeting references to non-existent DLL files. They may be able to load their own malicious DLL by planting it with the correct name in the location of the missing module.CitationHexacorn DLL HijackingCitationHijack DLLs CrowdStrike
### DLL Substitution Adversaries may target existing, valid DLL files and substitute them with their own malicious DLLs, planting them with the same name and in the same location as the valid DLL file.CitationWietze Beukema DLL Hijacking
Programs that fall victim to DLL hijacking may appear to behave normally because malicious DLLs may be configured to also load the legitimate DLLs they were meant to replace, evading defenses.
Remote DLL hijacking can occur when a program sets its current directory to a remote location, such as a Web share, before loading a DLL.Citationdll pre load owaspCitationmicrosoft remote preloading
If a valid DLL is configured to run at a higher privilege level, then the adversary-controlled DLL that is loaded will also be executed at the higher level. In this case, the technique could be used for privilege escalation.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.