codesign is a macOS tool for signing and verifying code, and attackers can abuse it to sign, modify, or validate malicious binaries using legitimate system functionality. Defenders should monitor unusual signing activity, unexpected certificate use, and binaries that appear newly signed but come from untrusted paths. Enforcement should focus on trust and provenance, not the tool itself.
What codesign means in a macOS attack path
On macOS, codesign is part of the trust model, because it marks software as coming from an expected signer and helps the operating system decide whether a binary should run. That makes it useful to defenders, but also attractive to attackers who want malware to look legitimate.
The abuse pattern is not that the tool is inherently malicious. The danger is that a legitimate signing workflow can be used to create binaries that appear trusted, especially when defenders rely too heavily on the presence of a signature instead of validating provenance, path, and expected signer.
Why legitimate signing becomes dangerous
codesign matters in incident response because a newly signed binary can look clean at a glance while still being adversarial. If an attacker can sign or re-sign code using a trusted context, they may reduce user suspicion, complicate triage, and increase the chance that other checks are deferred.
This is especially risky when the binary originates from an unexpected location, when certificate use does not match the environment, or when the signature is technically valid but operationally suspicious. A valid signature is evidence about trust, not proof that the software is safe.
How defenders verify exposure and provenance
Exposure review starts with inventory: which Macs run signing-related tooling, which developers or build systems legitimately use it, and which endpoints should never be producing signed binaries. That baseline helps distinguish normal build activity from abuse.
Defenders should also check whether suspicious binaries were introduced through internet-facing download paths, removable media, staging directories, or other locations that do not fit the organisation’s normal software release flow. When a file is newly signed, the key question is whether the signer, path, and release process all make sense together.
Monitoring should include certificate and signing telemetry, command-line auditing, and alerts for unsigned-to-signed transitions that do not line up with a known build or packaging process. NIST guidance on control families such as access control, audit, and system integrity is a useful baseline for structuring that review, and the MITRE ATT&CK Enterprise Matrix helps map this kind of living-off-the-land abuse to observable techniques.
Remediation, detection, and trust restoration
If abuse is suspected, the response should focus on trust restoration rather than just deleting the binary. That means identifying what was signed, which account or process performed the signing, whether any signing material was exposed, and whether the same signer has been used elsewhere in the fleet.
Detections should look for unusual invocation patterns, newly appearing signed artifacts in nonstandard paths, and binaries whose provenance does not match the expected software supply chain. The most important post-event question is whether the attacker only abused the tool, or also compromised the signing workflow, certificate material, or surrounding build trust.
For broader guidance on binaries and dual-use utilities, NHIMG’s Living off the Land Guide is a useful reference point for understanding how legitimate system tools become execution paths. The related Meta Muse agent hijack 2026 case also illustrates how local abuse on macOS can turn trusted functionality into an access problem.
Risk and Threat Considerations
codesign is risky because it sits inside the trust boundary that users and defenders often rely on to distinguish legitimate software from malicious software. If attackers can use it to sign or validate code, they can blur that boundary and make malicious binaries easier to launch, distribute, or defend as “normal”.
Failure mechanism: The attacker abuses a legitimate signing workflow or trusted certificate context to create or preserve the appearance of authenticity, while the payload itself remains malicious or modified.
Impact: Detection becomes harder, provenance checks become less reliable, and a signed binary may gain more execution trust than it deserves, increasing the likelihood of persistence or follow-on compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Signing misuse is best detected through review of audit telemetry and command activity. |
| SI-7 — Software, Firmware, and Information Integrity | codesign directly affects software integrity and trust decisions for executables. | |
| Recommendation — Review signing-related audit events to spot unusual code-signing activity and investigate anomalous binaries. Verify software integrity and provenance before allowing signed macOS binaries to execute. | ||
| MITRE ATT&CK | T1036 — Masquerading | Abusing legitimate signing can make malicious binaries appear trustworthy or benign. |
| Recommendation — Hunt for binaries that imitate trusted software through deceptive names, signatures, or packaging. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Unusual signing and certificate use are visible through centralized logging and review. |
| CIS-10 — Malware Defenses | Signed malware still requires behavioral and provenance-based defenses. | |
| Recommendation — Centralize and review logs that capture code-signing activity and certificate use. Detect suspicious binaries by combining malware defenses with provenance checks. | ||
Practitioner Guidance
What to watch for: Treat signing activity as a high-value audit signal, not a routine background event. Unusual signer use, unexpected file locations, and binaries that become signed late in their lifecycle deserve immediate review because they often indicate either abuse of the tool or compromise of the surrounding release process.
Governance implication: Ownership should sit with the team that controls build and release trust, not just endpoint operations. The practical rule is simple: validate provenance first, then signature, because a valid signature without an expected origin can still be a security problem.
Related resources from NHI Mgmt Group
- How should teams govern device access when they manage macOS, Windows, and Linux separately?
- How should security teams respond when macOS malware steals passwords or Keychain data?
- Why do macOS infostealers create IAM risk beyond the endpoint?
- What do security teams get wrong about macOS malware detection?