CrashStealer: the new macOS malware that impersonates Apple Crash Reporter

Researchers at Jamf Threat Labs have identified a new macOS infostealer dubbed CrashStealer, which uses a valid Apple Developer ID and a notarization ticket to bypass Gatekeeper and distribute itself as a fake application called Werkbit Setup. The malware, written in C++ and first detected in early July 2026, is designed to steal login credentials, cryptocurrency wallets, and any sensitive data it finds on the system or in the victim's browsers. Its most unsettling particularity is not what it collects, but how it presents itself: its dropper is signed and notarized by Apple, which in theory should guarantee the application is legitimate.

The ability of attackers to obtain a valid Developer ID and pass the notarization process is not new, but it remains relatively uncommon among commodity infostealers. Most macOS malware families are distributed as unsigned binaries, which triggers at least a visible Gatekeeper warning. CrashStealer has crossed that line, and in doing so it places itself in a category that is harder to detect for non-technical users. The downloaded application, once installed, impersonates Apple's built-in crash reporting component (Apple Crash Reporter), a deliberate choice that adds visual legitimacy to the deception.

The infection chain step by step

The research published by Jamf on July 13 describes an attack chain that unfolds in at least two stages, with a level of sophistication above typical commodity macOS malware.

The first delivery is a disk image (.dmg) distributed under the name Werkbit Setup. The image is signed with a valid Apple Developer ID and has gone through Apple's notarization process, which means that when the user opens it for the first time, macOS does not display any security warning and Gatekeeper allows execution. The application bundle inside the image is packaged to visually imitate the crash reporting component integrated in macOS, reinforcing the perception of legitimacy for the user.

Once the user decides to run the application, it makes a call to a GitHub API. The response is an obfuscated script that, after being decoded, turns into a downloader-installer that fetches the real CrashStealer payload from a server controlled by the attackers. Using GitHub as an intermediary is not accidental: traffic to GitHub is perceived as legitimate by network monitoring tools and corporate proxies, making early detection difficult.

The second stage begins when the payload downloads and executes on the system. CrashStealer then displays to the user a native dialog box that faithfully imitates a system authentication request. The dialog asks the user for their account password, presenting itself as a routine operating system verification. If the user enters their password, CrashStealer captures it and validates it. If the password is correct, the malware proceeds with its main objective: stealing credentials, wallets, and sensitive data.

What exactly it steals

Once CrashStealer has confirmed the user's account password, its real goal is to capture everything of value on the system. Jamf's researchers detail several priority targets.

First, credentials stored in web browsers. Chrome, Safari, Firefox, Brave, and other popular browsers save passwords and session tokens in local databases protected by the system keychain. CrashStealer can extract those credentials, giving it access to all the user's online accounts, from email to banking.

Second, cryptocurrency wallets. The malware family searches for browser extensions associated with popular wallets (MetaMask, Phantom, Trust Wallet, and similar) and exfiltrates seed phrases and private keys. This makes CrashStealer an especially severe threat for users with significant cryptocurrency holdings, or for Web3 developers who store deployment keys on their workstations.

Third, system keychain data, which contains credentials for native applications, certificates, API tokens, and other secrets. If the victim has access to corporate databases, production systems, or cloud infrastructure from their Mac, all those secrets can be compromised.

Fourth, specific system files. CrashStealer searches for file patterns associated with desktop wallets (Electrum, Exodus, Bitcoin Core), SSH credentials, project .env files, AWS keys, Kubernetes configurations, and other files that in development environments contain the secrets that grant access to critical infrastructure.

What makes CrashStealer different

Jamf Threat Labs points out three technical characteristics that distinguish CrashStealer from typical commodity macOS malware.

The first is the native C++ implementation. Most macOS infostealers are written in Objective-C or in scripting languages (Python, JavaScript). Writing in C++ gives attackers low-level control over execution and makes static analysis by security tools harder. The resulting binary is more difficult to reverse engineer and to understand for analysts.

The second is the use of AES-GCM encryption on the client side for exfiltrated files. CrashStealer encrypts stolen data before exfiltrating it, which protects the loot even if the exfiltration channel is intercepted or monitored. For defenders, this means capturing network traffic does not deliver data in the clear; you have to break the encryption or compromise the endpoint before exfiltration.

The third is analysis resistance. The malware incorporates control-flow flattening, encrypted strings, and multiple layers of anti-debugging. These techniques are not new in Windows malware, but they are relatively rare in macOS, which suggests the operators behind CrashStealer come from the Windows world and have ported their techniques. For macOS analysts, this means adapting tools and mentalities.

What Apple has done and what remains

After confirming that a Developer Team ID had been used to distribute the malware, Jamf Threat Labs reported the incident to Apple. Apple's response was to revoke the Developer ID immediately, which invalidates the signed binary on systems where the revocation has been processed. In practice, that means Gatekeeper will block new infections with the same binary, but it does not affect machines already compromised, nor variants of the malware with other Developer IDs.

This response is correct and expected, but it reveals a structural problem in Apple's notarization model. The notarization process is a barrier that raises the cost of infection, it does not prevent it. An attacker with the resources to purchase a Developer ID ($99 per year) and pass Apple's review (which is automated for most applications) can distribute signed malware for weeks or months before revocation arrives. For users, the only reliable signal of legitimacy remains the source of the download: if an application arrives through an unsolicited channel, it is not legitimate no matter how well it is signed.

Apple could harden the process in several ways: more frequent manual reviews for newly issued Developer IDs, post-notarization monitoring that detects anomalous behavior in distributed binaries, and proactive revocation of Developer IDs associated with known indicators of compromise. None of these measures are trivial, but the growing volume of notarized malware justifies the debate.

How to protect yourself in practice

For individual users, the defense remains the same as always, though reinforced by an understanding of the new threat model.

The first rule is to download software only from expected sources. If an application arrives via email, social media, or an advertisement, it is not legitimate even if it is signed. The software supply chain starts at the origin, not at the cryptographic signature.

The second rule is to distrust unexpected password dialogs. macOS asks for passwords for administrative actions (installing software, changing system preferences, accessing certain functions). If a password dialog appears without the user having initiated an administrative action, it is a red flag. macOS authentication shows the source of the dialog at the top (the name of the process or application requesting it); a legitimate dialog always clearly identifies who is asking.

The third rule is to enable FileVault. If an attacker has physical access to the machine, FileVault encrypts the disk contents and protects keychain and wallet data. CrashStealer steals data from the running system, but FileVault adds a layer of protection for data at rest.

For system administrators managing fleets of Macs, defense gets more complicated. CrashStealer uses valid Developer IDs and passes notarization, so application control tools based on signed binary whitelists will not detect it. EDR tools for macOS that monitor behavior (not just signature) are the only viable defense in this new scenario. Products like Jamf Protect, CrowdStrike Falcon, SentinelOne, and Microsoft Defender for Endpoint monitor process execution, keychain access, and calls to sensitive APIs, which lets them detect CrashStealer even when it is signed.

Concrete detection rules that security teams should deploy include: monitoring keychain access by processes not signed by Apple or by unknown developers, alerts on calls to the GitHub API from suspicious processes, and DNS traffic analysis to detect domains associated with data exfiltration.

Implications for the macOS trust model

CrashStealer is not the first notarized macOS malware, nor will it be the last. The trend points to attackers professionalizing their operations on macOS and learning to leverage Apple's own defenses as trust vectors. Notarization was designed to raise the barrier to entry for malware, and it has done so, but operators willing to invest the $99 and wait out the review cycle are finding the path profitable.

For security professionals defending Mac endpoints, the message is clear: binary signature is no longer a reliable signal of legitimacy. Tools and policies must evolve toward behavior monitoring, anomaly detection at runtime, and applying the principle of least privilege in day-to-day operations. The "install and sign" macOS model, comfortable for years, is falling short against attackers who know how to play inside it.