AN0607: Analytic 0607
Detection focuses on unauthorized modification of Mach-O binaries to include LC_LOAD_DYLIB headers pointing to malicious dylibs. Behavior is identified via a chain of file metadata changes, removal of code signatures, and subsequent anomalous dylib loads at runtime. Correlation of file changes with lack of authorized updates and process memory mapping of unrecognized or unsigned libraries is crucial.
Analyst context for executives and security teams
This analytic matters because it targets a macOS persistence or execution-enabling pattern: tampering with Mach-O binaries so they load an unexpected dynamic library. For leaders, the practical issue is trust in endpoint software integrity. If business-critical macOS systems can run modified binaries with removed signatures and unrecognized libraries, incident responders need evidence that distinguishes authorized software updates from unauthorized binary modification.
Executive priority
Prioritize this as a macOS endpoint integrity and incident readiness question: can the organization prove when application binaries changed, whether the change was authorized, and whether unsigned or unrecognized libraries were loaded afterward? This is relevant to SOC coverage, audit evidence for software integrity controls, and response decisions around whether a macOS host should be isolated, rebuilt, or treated as an authorized update exception.
Technical view
SOC and detection teams should validate whether telemetry can correlate three evidence points on macOS: file metadata changes to Mach-O binaries, removal or absence of expected code signatures, and runtime mapping/loading of unfamiliar or unsigned dylibs. Because the supplied ATT&CK object provides no tactic mapping and no separate official detection logic, implementation should focus on correlation and allowlisting of known software update paths rather than single-event alerts.
Likely telemetry
- macOS file integrity or EDR file metadata change events for Mach-O binaries
- Code-signing status or signature validation results before and after binary modification
- Process execution telemetry showing the modified binary running
- Runtime library load or process memory mapping telemetry for dylibs
- Software update, package management, or change-management records to distinguish authorized updates
Detection direction
- Correlate binary file changes with later loading of LC_LOAD_DYLIB-referenced libraries that are unrecognized or unsigned.
- Tune around authorized software updates so normal vendor or administrative changes do not overwhelm analysts.
- Treat removed or missing signatures as higher-value only when paired with suspicious file modification and anomalous dylib load behavior.
- Validate coverage specifically on macOS; do not assume Windows or Linux telemetry applies to this analytic.
- Investigate blind spots where EDR records process starts but not library loads, memory mappings, or code-signature state.
Mitigation priorities
- Maintain reliable macOS endpoint telemetry for file integrity, code-signing state, process execution, and dylib loading.
- Define approved software update and administrative modification workflows so detections can compare binary changes against authorized activity.
- Use application control, software integrity validation, and least-privilege administration where appropriate to reduce unauthorized binary modification opportunities.
- Ensure incident response playbooks include collection of modified binaries, associated dylibs, signatures, hashes, and update history before remediation.
Analyst notes and limits
This is a detection analytic object for ATT&CK release 19.1 with platform scope limited to macOS. The useful defensive value is in correlation: file changes alone or unsigned libraries alone may be noisy, but the sequence of binary modification, signature removal, and anomalous dylib loading is more decision-relevant.
No ATT&CK tactic, relationship context, or separate official detection field was supplied. This take is therefore limited to the official description and external reference. Local baselining is required to determine which binaries, signers, update mechanisms, and dylibs are expected in a given environment.
Analytic 0607
Detection focuses on unauthorized modification of Mach-O binaries to include LC_LOAD_DYLIB headers pointing to malicious dylibs. Behavior is identified via a chain of file metadata changes, removal of code signatures, and subsequent anomalous dylib loads at runtime. Correlation of file changes with lack of authorized updates and process memory mapping of unrecognized or unsigned libraries is crucial.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 830b253322af… |
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 AN0607Open 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.