M1044: Restrict Library Loading
Restricting library loading involves implementing security controls to ensure that only trusted and verified libraries (DLLs, shared objects, etc.) are loaded into processes. Adversaries often abuse Dynamic-Link Library (DLL) Injection, DLL Search Order Hijacking, or LD_PRELOAD mechanisms to execute malicious code by forcing the operating system to load untrusted libraries. This mitigation can be implemented through the following measures:
Enforce Safe Library Loading Practices:
- Enable `SafeDLLSearchMode` on Windows. - Restrict `LD_PRELOAD` and `LD_LIBRARY_PATH` usage on Linux systems.
Code Signing Enforcement:
- Require digital signatures for all libraries loaded into processes. - Use tools like Signtool, and WDAC to enforce signed DLL execution.
Environment Hardening:
- Secure library paths and directories to prevent adversaries from placing rogue libraries. - Monitor user-writable directories and system configurations for unauthorized changes.
Audit and Monitor Library Loading:
- Enable `Sysmon` on Windows to monitor for suspicious library loads. - Use `auditd` on Linux to monitor shared library paths and configuration file changes.
Use Application Control Solutions:
- Implement AppLocker, WDAC, or SELinux to allow only trusted libraries.
*Tools for Implementation*
Windows-Specific Tools:
- AppLocker: Application whitelisting for DLLs. - Windows Defender Application Control (WDAC): Restrict unauthorized library execution. - Signtool: Verify and enforce code signing. - Sysmon: Monitor DLL load events (Event ID 7).
Linux-Specific Tools:
- auditd: Monitor changes to library paths and critical files. - SELinux/AppArmor: Define policies to restrict library loading. - ldconfig and chattr: Secure LD configuration files and prevent unauthorized modifications.
Cross-Platform Solutions:
- Wazuh or OSSEC: File integrity monitoring for library changes. - Tripwire: Detect and alert on unauthorized library modifications.
Analyst context for executives and security teams
Restrict Library Loading is a preventive control against attackers getting malicious code loaded by trusted processes through DLL abuse, search-order hijacking, LD_PRELOAD/LD_LIBRARY_PATH misuse, or related execution-flow hijacking. For leaders, the value is reducing the chance that ordinary software startup behavior becomes a persistence, privilege-escalation, or stealth execution path—especially around sensitive Windows components such as LSASS drivers and broadly across execution-flow hijacking scenarios.
Executive priority
Prioritize this where compromise of endpoints or servers would create high incident-response cost, identity risk, or audit concern. The control is most decision-relevant when paired with evidence that trusted library paths are protected, unsigned or untrusted libraries are restricted, and library-load monitoring is actually collected. Executives should ask whether application control, code-signing enforcement, and file integrity monitoring are deployed consistently enough to support resilience and compliance evidence, not just documented as policy.
Technical view
Validate controls against the mitigated ATT&CK relationships: T1574 Hijack Execution Flow, T1574.001 DLL, and T1547.008 LSASS Driver. On Windows, review SafeDLLSearchMode, signed-library enforcement, AppLocker or WDAC policy, protected library directories, and Sysmon DLL load visibility such as Event ID 7 where enabled. On Linux, review restrictions around LD_PRELOAD and LD_LIBRARY_PATH, auditd monitoring of shared library paths and configuration changes, and SELinux/AppArmor policy where used. For IR and SOC teams, the practical question is whether a rogue library placed in a user-writable or misconfigured search path would be blocked, logged, or missed.
Likely telemetry
- Windows DLL load events, including Sysmon Event ID 7 where Sysmon is deployed
- Application control decisions and policy logs from AppLocker or Windows Defender Application Control
- Digital signature or code-signing validation results for loaded libraries
- File integrity monitoring alerts for library directories and configuration files
- Windows configuration evidence such as SafeDLLSearchMode state
Detection direction
- Do not treat this mitigation as covered unless library-load telemetry is enabled and retained on the systems where the risk matters.
- Tune for untrusted or unsigned libraries loaded by trusted processes, especially from user-writable directories or unexpected search paths.
- Correlate library loads with recent file creation or configuration changes in library paths to reduce noise and improve investigative value.
- Validate visibility around LSASS-related driver or DLL loading on Windows systems where T1547.008 is relevant.
- Account for false positives from legitimate software updates, development tooling, and enterprise applications that load custom libraries.
Mitigation priorities
- Start by securing library paths and directories so ordinary users or untrusted processes cannot place rogue libraries in load paths.
- Enable safe library loading practices, including SafeDLLSearchMode on Windows and restricting LD_PRELOAD and LD_LIBRARY_PATH usage on Linux systems.
- Enforce code-signing expectations for libraries where feasible, using signed-library execution controls such as WDAC or equivalent application control policy.
- Deploy application control policies such as AppLocker, WDAC, SELinux, or AppArmor to allow only trusted libraries where operationally supportable.
- Add file integrity monitoring for library directories and configuration files using appropriate tools such as Wazuh, OSSEC, Tripwire, or platform-native monitoring.
Analyst notes and limits
This is a mitigation object, not an adversary technique. Its value is highest when mapped to concrete asset classes and software paths: high-value Windows systems, authentication components, and systems where execution-flow hijacking would support persistence or privilege escalation. Glexia would validate both prevention and evidence: policy state, protected directories, library signatures, application-control outcomes, and monitoring coverage.
The supplied ATT&CK object does not specify platforms or tactics for the mitigation itself and does not include official detection text. Platform-specific guidance here is limited to the official description and related techniques: Windows and Linux are directly described in the mitigation text, while the mitigated Hijack Execution Flow technique spans Linux, macOS, and Windows. Local testing is required to determine operational compatibility and detection coverage.
Restrict Library Loading
Restricting library loading involves implementing security controls to ensure that only trusted and verified libraries (DLLs, shared objects, etc.) are loaded into processes. Adversaries often abuse Dynamic-Link Library (DLL) Injection, DLL Search Order Hijacking, or LD_PRELOAD mechanisms to execute malicious code by forcing the operating system to load untrusted libraries. This mitigation can be implemented through the following measures:
Enforce Safe Library Loading Practices:
- Enable `SafeDLLSearchMode` on Windows. - Restrict `LD_PRELOAD` and `LD_LIBRARY_PATH` usage on Linux systems.
Code Signing Enforcement:
- Require digital signatures for all libraries loaded into processes. - Use tools like Signtool, and WDAC to enforce signed DLL execution.
Environment Hardening:
- Secure library paths and directories to prevent adversaries from placing rogue libraries. - Monitor user-writable directories and system configurations for unauthorized changes.
Audit and Monitor Library Loading:
- Enable `Sysmon` on Windows to monitor for suspicious library loads. - Use `auditd` on Linux to monitor shared library paths and configuration file changes.
Use Application Control Solutions:
- Implement AppLocker, WDAC, or SELinux to allow only trusted libraries.
*Tools for Implementation*
Windows-Specific Tools:
- AppLocker: Application whitelisting for DLLs. - Windows Defender Application Control (WDAC): Restrict unauthorized library execution. - Signtool: Verify and enforce code signing. - Sysmon: Monitor DLL load events (Event ID 7).
Linux-Specific Tools:
- auditd: Monitor changes to library paths and critical files. - SELinux/AppArmor: Define policies to restrict library loading. - ldconfig and chattr: Secure LD configuration files and prevent unauthorized modifications.
Cross-Platform Solutions:
- Wazuh or OSSEC: File integrity monitoring for library changes. - Tripwire: Detect and alert on unauthorized library modifications.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1574 | Hijack Execution Flow | Disallow loading of remote DLLs. This is included by default in Windows Server 2012+ and is available by patch for XP+ and Server 2003+. Enable Safe DLL Search Mode to force search for system DLLs in directories with greater restrictions (e.g. The Safe DLL Search Mode can be enabled via Group Policy at Computer Configuration > [Policies] > Administrative Templates > MSS (Legacy): MSS: (SafeDllSearchMode) Enable Safe DLL search mode. The associated Windows Registry key for this is located at |
| Enterprise | T1547.008 | LSASS Driver Sub-technique | Ensure safe DLL search mode is enabled |
| Enterprise | T1574.001 | DLL Sub-technique | Disallow loading of remote DLLs. This is included by default in Windows Server 2012+ and is available by patch for XP+ and Server 2003+.CitationMicrosoft More information about DLL Enable Safe DLL Search Mode to move the user's current folder later in the search order. This is included by default in modern versions of Windows; the associated Windows Registry key is located at |
All related ATT&CK context
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | ba0ef9fdeecb… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack M1044Open source URL
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.