M0944: Restrict Library Loading
Prevent abuse of library loading mechanisms in the operating system and software to load untrusted code by configuring appropriate library loading mechanisms and investigating potential vulnerable software.
Analyst context for executives and security teams
Restrict Library Loading is an ICS mitigation aimed at reducing the chance that software loads untrusted code through operating system or application library mechanisms. For leaders, the practical issue is control over what code can run inside critical applications: if library loading is poorly governed, defenders may have limited assurance that approved industrial software is executing only trusted components.
Executive priority
Prioritize this where ICS reliability, audit evidence, and change control depend on trusted software execution. The ATT&CK mapping to IEC 62443 SR/CR 7.7 and NIST SP 800-53 CM-7 makes this useful for compliance readiness and control validation. Executives should ask whether critical engineering, operator, and supporting systems have documented library-loading restrictions, whether vulnerable software is investigated, and whether exceptions are tracked through change management.
Technical view
SOC, IR, and engineering teams should validate this mitigation against T0874 Hooking, where API calls may be redirected for execution or privilege escalation. Because ATT&CK provides no official detection guidance and no platform list for this mitigation, teams should focus on proving control implementation: which applications and operating systems permit library path controls, signed/trusted library enforcement, application control, and investigation of software known to be vulnerable to unsafe loading behavior. The related technique description references Windows API functions and DLLs, but local platform scope must be confirmed before assuming coverage.
Likely telemetry
- Software and asset inventory for systems running critical ICS applications
- Configuration evidence for operating system and application library-loading controls
- Application control or allowlisting logs, where deployed
- Process module or library load events, where available
- Change management records for approved software, patches, and library exceptions
Detection direction
- Do not treat this mitigation as detection coverage by itself; ATT&CK provides no official detection text for M0944.
- Validate whether telemetry can show unexpected or unapproved library loads in the environments where such events are collectible.
- Tune review processes around legitimate software updates, vendor maintenance, and engineering tool changes to reduce false positives.
- Use the T0874 relationship to prioritize monitoring around applications where API hooking or redirected library calls would materially affect execution or privileges.
- Identify blind spots where legacy ICS software, unsupported systems, or vendor-managed assets prevent library-load visibility or enforcement.
Mitigation priorities
- Inventory critical ICS software and determine where library-loading behavior can be configured or constrained.
- Enable appropriate operating system and application mechanisms to prevent loading untrusted libraries where supported.
- Investigate and prioritize remediation for software with vulnerable or unsafe library-loading behavior.
- Pair restrictions with change control so approved updates and vendor components are documented rather than handled as informal exceptions.
- Map implementation evidence to IEC 62443 SR/CR 7.7 and NIST SP 800-53 CM-7 where those frameworks apply.
Analyst notes and limits
This is a mitigation object, not a technique, and ATT&CK does not specify platforms, tactics, aliases, or official detection content for it. The strongest relationship context is its mitigation of ICS technique T0874 Hooking, whose description includes API redirection and DLL-based examples. Use that relationship to drive validation, but confirm actual operating systems, applications, and engineering constraints locally.
The supplied ATT&CK fields do not prove active exploitation, attribution, business impact, or detection coverage. Platform scope is not specified for the mitigation, so any environment-specific control design requires local asset, software, and vendor evidence.
Restrict Library Loading
Prevent abuse of library loading mechanisms in the operating system and software to load untrusted code by configuring appropriate library loading mechanisms and investigating potential vulnerable software.
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.
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.0 | Current bundle | 8763f66c4b8c… |
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 M0944Open 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.