DET0152: Detection Strategy for Hijack Execution Flow: Dylib Hijacking
DET0152 is a MITRE ATT&CK detection strategy for Dylib Hijacking, a macOS-related execution-flow hijacking behavior where an attacker may get code run by a...
Analyst context for executives and security teams
DET0152 is a MITRE ATT&CK detection strategy for Dylib Hijacking, a macOS-related execution-flow hijacking behavior where an attacker may get code run by abusing how an application searches for dynamic libraries at runtime. The business issue is not the library file itself; it is whether critical macOS endpoints can prove that applications are loading expected code from expected paths. If that evidence is missing, SOC and incident response teams may struggle to distinguish normal application behavior from stealthy execution.
Executive priority
Prioritize this where macOS endpoints support privileged users, developers, administrators, or business-critical workflows. Leaders should ask whether endpoint telemetry, application inventory, and IR procedures can show which dylibs are loaded by important applications and whether unexpected library paths are investigated. This supports operational resilience, audit evidence for endpoint monitoring, and incident decision-making when stealthy execution is suspected.
Technical view
The supplied ATT&CK relationship says this detection strategy detects T1574.004 Dylib Hijacking, associated with stealth and execution on macOS. SOC and detection engineering teams should validate visibility into dynamic library load activity, executable-to-library relationships, file path context, and application search-path behavior. Because the official detection text is not provided for DET0152, local validation should be based on whether telemetry can identify unexpected dylib names, locations, or load paths relative to known-good application behavior without assuming every unusual load is malicious.
Likely telemetry
- macOS endpoint process execution events
- Dynamic library or module load events, where available
- File creation or modification events for dylib files
- Application bundle and executable path metadata
- Code signing, notarization, or publisher metadata where collected
Detection direction
- Map coverage specifically to T1574.004 rather than treating it as generic malware detection.
- Baseline expected dylib load paths for important macOS applications and investigate deviations in unusual directories or relative search paths.
- Correlate dylib file creation or modification with subsequent application execution and library loading.
- Use code-signing or publisher context to reduce false positives, but do not rely on signing status alone as proof of safety.
- Tune for developer and application-update workflows, which may legitimately create or load changing libraries.
Mitigation priorities
- Start with asset and application visibility for macOS systems that matter most to the business.
- Ensure endpoint logging and EDR policies retain process, file, and library-load context sufficient for investigation.
- Harden application and file-system permissions so untrusted users cannot write to locations searched by sensitive applications.
- Use application control, code-signing policy, and software management controls where appropriate to reduce unauthorized code loading risk.
- Include dylib hijacking checks in macOS incident response playbooks and detection validation exercises.
Analyst notes and limits
The ATT&CK object itself has no official description, detection text, platforms, or tactics. The practical guidance here is derived from the stated relationship to T1574.004 Dylib Hijacking, whose supplied context identifies macOS and the stealth/execution tactics. Treat this as a coverage-validation prompt rather than a complete detection specification.
This take cannot assert active exploitation, specific adversaries, detection efficacy, or vendor coverage. Local environment evidence is required to determine whether relevant macOS telemetry is collected, normalized, retained, and actionable.
Detection Strategy for Hijack Execution Flow: Dylib Hijacking
No official description is available in the imported ATT&CK source object.
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.004 | Dylib Hijacking Sub-technique | This object detects Dylib Hijacking. |
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 | aa21e4fbc005… |
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 DET0152Open 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.