AN0090: Analytic 0090
Binaries or applications executed with tampered or unverifiable code signatures. Often tied to Gatekeeper bypasses, App Translocation, or use of unsigned launch daemons by untrusted users.
Analyst context for executives and security teams
This analytic concerns macOS applications or binaries whose code signatures are tampered with, unverifiable, or absent in contexts where trust should matter. For executives and security leaders, the business issue is not just “malware on a Mac”; it is whether the organization can prove that software allowed to run on managed macOS systems is authentic and policy-compliant, especially where Gatekeeper, App Translocation, or launch daemon controls are expected to reduce risk.
Executive priority
Prioritize this where macOS endpoints support privileged users, developers, executives, regulated workflows, or operationally sensitive teams. Leaders should ask whether endpoint controls and SOC processes can distinguish trusted signed software from unsigned or signature-invalid execution, and whether exceptions are documented well enough to satisfy audit, incident response, and software trust requirements. Because no ATT&CK detection logic or relationships are supplied, this should be treated as a validation and control-assurance topic rather than assumed coverage.
Technical view
For SOC, detection engineering, and IR teams, validate visibility into macOS execution events where code-signing status can be assessed. Focus on binaries or applications executed with tampered or unverifiable signatures, and on unsigned launch daemons created or run by untrusted users. Since the object provides no tactic mapping, relationship context, or official detection pseudocode, teams should map this analytic to local macOS telemetry, endpoint policy, and allowlist/exception processes before operationalizing alerts.
Likely telemetry
- macOS process execution records with executable path and user context
- Code-signing assessment results, including invalid, unverifiable, or unsigned status
- Gatekeeper or application assessment events where available
- Launch daemon creation, modification, and execution evidence
- Endpoint security or EDR telemetry showing file provenance and execution context
Detection direction
- Confirm whether collected macOS telemetry includes code-signature validity, not only process names and paths.
- Tune for execution of binaries or applications with tampered, unverifiable, or absent signatures, especially outside approved software management paths.
- Review unsigned launch daemons associated with untrusted users as higher-priority investigation candidates.
- Expect false positives from internal tools, developer workflows, test software, or legacy applications; require documented exceptions and owner approval.
- Because no official detection is provided, validate detections through controlled internal testing and incident review rather than assuming ATT&CK coverage.
Mitigation priorities
- Inventory macOS software execution paths and identify where signed code is required by policy.
- Enforce and document macOS application control, Gatekeeper-related policy, and software approval processes where appropriate.
- Limit the ability of untrusted users to create or modify launch daemons.
- Maintain an exception process for unsigned or internally developed software, including owner, business justification, and review date.
- Ensure IR playbooks include steps to verify code-signing status, provenance, user context, and persistence mechanisms on macOS systems.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for macOS with a narrow description and no official detection text. Its value is primarily as a control-validation prompt: can the organization observe and govern execution of software that fails expected trust checks? Relationship context is not supplied, so this take does not infer associated techniques, threat actors, campaigns, or impact.
This assessment is limited to the official STIX fields, the MITRE external reference, and the stated absence of relationship context. No active exploitation, attribution, detection coverage, or non-macOS applicability is implied. Local telemetry, endpoint configuration, and software exception data are required to determine practical risk and coverage.
Analytic 0090
Binaries or applications executed with tampered or unverifiable code signatures. Often tied to Gatekeeper bypasses, App Translocation, or use of unsigned launch daemons by untrusted users.
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 | 260efffa82f9… |
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 AN0090Open 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.