MacOS malware ML needs slice-level features, not Windows assumptions

At a glance

What this is: Iru’s Mach-O analysis finds that macOS malware classification is distorted by signing, slice structure, and build artefacts, making Windows-style feature sets unreliable.

Why it matters: Security teams and identity practitioners should care because signed software, developer credentials, and provenance controls can become both detection signals and attacker bypass paths in macOS environments.

By the numbers:

• Iru analysed 7,138 Mach-O samples, including 3,254 malicious and 3,884 benign files.

Context

MacOS malware analysis becomes difficult when defenders import Windows assumptions into a platform with different binary structure, signing semantics, and distribution pathways. In this case, the core issue is not simply detection quality but feature relevance: a classifier can look accurate while learning provenance signals, build artefacts, or architecture-specific quirks instead of malicious behaviour.

That matters for identity and access governance because macOS signing, notarization, and entitlements are all forms of trust signalling tied to developer identity and software execution rights. When attackers obtain valid Developer ID material or abuse signed-but-overprivileged binaries, they are exploiting the same trust layer defenders may be using as a security signal.

The article’s starting position is typical for macOS research and atypical for Windows-centric analysis: the platform’s trust model forces feature engineering to account for slice-level behaviour, not just file-level labels.

Key questions

Q: What breaks when macOS malware detection reuses Windows feature engineering?

A: The model often learns provenance and build artefacts instead of malicious behaviour. Windows features such as whole-file entropy or raw string frequency do not map cleanly to Mach-O structure, especially when fat binaries carry different slices with different signatures and entitlements. That can make a classifier look accurate while missing the actual execution risk.

Q: Why do signed macOS binaries still create security risk?

A: Signing proves that a binary passed through a trusted distribution path, not that it is safe to run. If an attacker obtains valid signing material or abuses notarization, the same binary can move from suspicious to trusted without changing its malicious behaviour. Defenders must therefore treat signing as provenance evidence, not as a final allow-list decision.

Q: How can security teams tell whether a macOS malware model is actually working?

A: Check whether the model still performs when provenance bias is reduced. A useful test is to validate against different packaging styles, slice-specific features, and samples outside the signed-and-notarized distribution paths that dominate the training data. If accuracy drops sharply, the model is probably learning source bias rather than malware structure.

Q: Who should own macOS malware feature governance in a security programme?

A: Ownership should sit with the team responsible for endpoint detection engineering and platform security, with input from identity and code-signing governance. The key accountability is to ensure that signing status, entitlements, and architecture slices are treated as controlled security inputs, not as passive metadata.

Technical breakdown

Why Mach-O binaries need slice-level analysis

A Mach-O file is often a universal, or fat, binary that contains multiple architecture slices, usually x86_64 and arm64. Many features are slice-specific: entitlements, code-signing status, and even certain symbols may differ by architecture. If a pipeline scores only the whole file, it can blur distinct behaviours into one average. That is especially dangerous for entropy and byte histograms, because compressed assets and compiled code can dominate the score even when the executable logic is structurally different across slices. Treating the file as a single object therefore produces a misleading model input.

Practical implication: extract and score Mach-O features per slice before aggregating the verdict.

Why code signing is a strong but fragile signal

On macOS, code signing and notarization act as provenance signals, not behavioural proof. Because legitimate software is commonly signed and notarized, the presence or absence of signing can separate benign from malicious samples unusually well. But that strength is also the weakness: an attacker with valid signing material can move from the unsigned to the signed category without changing malicious code. In other words, the model may learn who distributed the binary rather than what the binary does. Entitlements help because they expose declared capability, but they still sit inside the same trust pipeline.

Practical implication: never treat signing status as a standalone malice decision rule.

How strings and symbols can mislead malware models

Raw string and symbol extraction often pulls in linker artefacts, loader stubs, and compiler fingerprints that have no direct relationship to malicious intent. Tokens such as lazy binding symbols or architecture-specific loader structures can score highly because they correlate with the dataset, not because they reveal attacker behaviour. The same problem appears in byte histograms, where obfuscation or compression can inflate scores in both benign and malicious software. The useful signals are the ones tied to runtime behaviour, such as process spawning or logging patterns, after the toolchain noise is removed.

Practical implication: filter structural noise before using strings or symbols for detection.

Threat narrative

Attacker objective: Bypass provenance-based detection and execute malicious payloads on macOS endpoints by blending in with trusted software signals.

1. Entry occurs when a malicious macOS binary arrives disguised as apparently legitimate software, including signed or otherwise provenance-looking artifacts.
2. Credential or trust abuse follows when attacker-controlled software benefits from valid signing material or misleading metadata that collapses the defender’s first-line filter.
3. Impact is reached when the binary is classified as benign or trusted despite carrying malware behaviour, allowing execution and theft to proceed.
4. The objective is to bypass macOS provenance checks and execute malicious payloads without triggering conventional signature-based detection.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

macOS trust signals are becoming a governance problem, not just a detection input. This article shows that signing, notarization, and entitlements can dominate model performance precisely because they encode provenance. That makes them useful to defenders, but also easy for attackers to game once signing material is compromised or abused. The practitioner conclusion is that provenance controls must be governed as security assets, not assumed to be proof of benign intent.

Slice-level identity is the right unit of analysis for Mach-O risk. Fat binaries make file-level inspection too coarse for reliable security decisions, because different architecture slices can carry different signatures, entitlements, and runtime properties. This is a classic example of where one object contains multiple trust states. Practitioners should treat architecture slices as distinct security subjects when building detection, triage, and policy logic.

Feature engineering debt is the hidden cost of platform-specific security. Windows-centric feature sets do not translate cleanly to macOS because the platform exposes different trust primitives and different structural artefacts. That means organisations cannot assume vendor- or framework-agnostic malware analytics will generalise. The practical conclusion is that defenders need macOS-specific feature governance, not just more model training.

Declared capability matters more than provenance once attackers can sign code. Entitlements such as debugging, sandbox exceptions, and access to protected resources are closer to actual runtime risk than the mere presence of a signature. This is the bridge to identity governance: the trust boundary sits with software identity and its permitted actions, not with the label attached during distribution. Practitioners should review entitlement-driven access as part of their macOS control model.

Model performance that depends on signed-software bias is not durable security. The dataset’s heavy reliance on notarised software explains part of the separation, which means similar performance may not hold when the sourcing bias changes. That is a governance issue for detection programmes because it can create false confidence in lab results. The right posture is to validate models against distribution paths that mirror the real estate you actually defend.

From our research library:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: macOS Security Guide for Enterprises

What this signals

Provenance bias is the central governance lesson from macOS malware analytics. Detection programmes should expect signed software, notarization, and architecture-specific features to distort model behaviour unless those signals are validated against real endpoint populations. The operational question is no longer whether a model can separate good from bad in a lab, but whether it still holds when the distribution path changes.

Entitlement review is becoming a control point for software identity risk. Permissions such as debugging, library-validation bypass, and protected-resource access expose the real capability boundary of a binary. That means teams should connect endpoint security, application trust, and software supply chain oversight rather than treat them as separate disciplines.

The developer behaviour gap matters here as a parallel signal: only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap. When weak operational discipline meets signed-code trust, attackers gain more room to hide inside normal delivery patterns.

For practitioners

• Implement per-slice Mach-O feature extraction Score x86_64, arm64, and arm64e slices separately, then aggregate results only after comparing slice-specific code signing, entitlements, entropy, and symbol features.
• Treat signing as provenance, not verdict Use signing and notarization as one signal in a broader classifier, and require behavioural confirmation before allowing a binary to be trusted at runtime.
• Filter linker and loader artefacts out of symbol features Remove __la_symbol_ptr, __stub_helper, dyld_stub_binder, and similar structural tokens so your model learns behaviour rather than toolchain noise.
• Review entitlements as capability controls Prioritise entitlements that expand runtime capability, especially debugging, library validation bypass, and protected resource access, because they reveal what the binary is allowed to do.

Key takeaways

• MacOS malware detection fails when defenders assume Windows-style features transfer cleanly to Mach-O binaries.
• The strongest signals in this analysis are provenance markers, but those same signals are easy for attackers to manipulate if they obtain trusted signing material.
• Practical defences depend on slice-level extraction, entitlement review, and removal of toolchain noise before model training.

Key terms

• Mach-O Binary: The executable file format used by Apple platforms, including iOS apps packaged inside an .ipa. It preserves enough structural information for reverse engineers to inspect symbols, segments, and linked frameworks, which means compiled code is not the same as opaque code.
• Fat Binary: A fat binary is a Mach-O file that bundles more than one architecture slice in the same file. Security tooling often needs to inspect each slice separately because signing, entitlements, and runtime behaviour can differ between them, making whole-file analysis too coarse for reliable decisions.
• Code signing: Code signing is the process of attaching cryptographic proof to software so recipients can verify origin and integrity. In CI/CD, it turns release trust into an enforceable control instead of a human promise, and it only works when the signing step is mandatory and protected.
• Entitlement: An entitlement is the permission set that defines what a non-human identity can do after it authenticates. It is usually expressed through roles, policies or access assignments, and unmanaged entitlements are a common reason machine identities become over-privileged over time.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the NHI Foundation Level course, the industry's only accredited NHI security programme, to strengthen how your team governs identities, privileges, and secrets.