AN0985: Analytic 0985
Detects binaries or launch daemons in /System/Library or /Applications with mismatched bundle names, unexpected metadata, or improper installation origin.
Analyst context for executives and security teams
This analytic is about spotting suspicious macOS persistence or masquerading indicators in highly trusted locations: /System/Library and /Applications. For leaders, the value is not that every metadata mismatch is malicious, but that unexpected bundle names, odd application metadata, or improper installation origin in these paths can undermine trust in standard application and system locations where users and administrators may assume software is legitimate.
Executive priority
Prioritize this as a macOS endpoint assurance and incident-readiness control. It supports decisions around whether the organization can prove that applications and launch daemons in trusted macOS paths are expected, properly installed, and explainable during an investigation or audit. The main business question is: can security teams quickly distinguish approved software drift from suspicious or unauthorized binaries in sensitive macOS locations?
Technical view
SOC and detection teams should validate collection and analysis for macOS binaries and launch daemons under /System/Library and /Applications, focusing on bundle-name mismatches, unexpected metadata, and installation-origin anomalies. Because no ATT&CK tactic, relationship context, or official detection logic is supplied, teams should treat this as a detection-validation concept rather than a complete rule. Baseline known-good application metadata and approved installation sources before alerting aggressively.
Likely telemetry
- macOS file inventory for /System/Library and /Applications
- Application bundle metadata, including bundle name and related plist metadata
- Launch daemon inventory and configuration metadata
- Software installation origin or provenance records where available
- Endpoint detection or asset-management records showing application path, name, and metadata changes
Detection direction
- Validate that macOS endpoint telemetry includes binaries and launch daemons in /System/Library and /Applications.
- Compare displayed names, bundle identifiers, and metadata against expected application inventory and approved software baselines.
- Flag improper or unexpected installation origin only when the organization has a reliable source of truth for approved installers and deployment mechanisms.
- Tune for legitimate software updates, renamed applications, administrative packaging errors, and vendor metadata inconsistencies to reduce false positives.
- Because no relationship context is supplied, do not infer a specific ATT&CK technique, campaign, actor, or impact from this analytic alone.
Mitigation priorities
- Maintain an approved macOS software inventory and expected metadata baseline for applications and launch daemons.
- Standardize software deployment and installation-origin tracking so anomalies can be investigated with context.
- Restrict and monitor administrative changes to trusted macOS application and system-library locations according to organizational policy.
- Include these paths and metadata checks in incident response triage for suspicious macOS systems.
- Use findings to improve asset management, endpoint monitoring, and compliance evidence around authorized software.
Analyst notes and limits
This object is a detection analytic, not a full ATT&CK technique entry. Its strongest use is as a validation prompt for macOS endpoint visibility and software-integrity review in trusted paths. The supplied ATT&CK fields identify the platform and the suspicious conditions to look for, but do not provide executable detection logic.
Official detection content, tactics, labels, aliases, and relationship context were not supplied. Local baselines are required to determine what metadata, bundle names, and installation origins are expected. This summary does not assert active exploitation, attribution, impact, or guaranteed detection coverage.
Analytic 0985
Detects binaries or launch daemons in /System/Library or /Applications with mismatched bundle names, unexpected metadata, or improper installation origin.
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 | c018ddf0bb29… |
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 AN0985Open 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.