Notarized by Apple, still malware: the CrashStealer Mac stealer

Apple's notarization is widely read as a safety verdict: if a Mac app is notarized, the thinking goes, Apple checked it and it is fine to run. That is not what notarization means, and a macOS info-stealer called CrashStealer is the clean proof. It arrives inside a disk image named Werkbit Setup, signed with a real Apple Developer ID and carrying a valid, stapled notarization ticket, so Apple's Gatekeeper check passes it on first launch without a warning. Then it empties the login keychain, browser logins, 14 password managers and more than 80 crypto wallet extensions. Nothing about the signature was forged. That is the whole problem.

Jamf Threat Labs flagged the sample from a VirusTotal upload earlier this year and published its analysis on July 13, with in-the-wild detections reported by early July, according to Security Affairs and The Hacker News. The notable part is not another stealer. It is that the operator paid for trust and got it.

What notarization actually checks

Notarization is an automated pipeline. When a developer uploads a signed app, Apple's service scans it for known malware and confirms the code signing is correct, then issues a ticket the developer staples to the app. There is no human security review, no audit of what the app does, and no judgment about intent. It answers one narrow question: does this binary match anything Apple already knows is bad? A fresh, never-seen stealer signed by a valid developer account answers that question with a clean no and sails through.

So notarization is a known-bad filter, not a trust badge. Gatekeeper enforces it, which means Gatekeeper is only as strong as that filter. CrashStealer did not defeat Gatekeeper. It satisfied it.

How CrashStealer clears the check

The dropper carries a real Apple Developer ID issued in the name Emil Grigorov (WWB7JA7AQV), plus a stapled notarization ticket, which is why it clears Gatekeeper the first time a victim opens it. As is common with abused developer certificates, that identity may have been stolen or fraudulently enrolled rather than belonging to the author. Its second-stage payload is only ad-hoc signed and would fail that check on its own, but by then the trusted front door is already open. Most Mac stealers are AppleScript wrappers driven through osascript; this one is a native C++ binary that locks up what it grabs using AES-256-GCM under Apple's own CommonCrypto. Distribution is a fake meeting client. The Werkbit.app installer hides behind a meeting PIN on the domain werkbit[.]io, stood up in June 2026, so it never lands in front of a casual scanner.

The haul is wide. It reads saved logins out of Chromium browsers and Firefox, lifts the macOS login keychain, and works through the roughly 80 wallet extensions and 14 password managers shown above. The specific brands matter less than the reach: anyone who ran it should treat every secret on that machine as gone.

The genuine signature is also the fastest way to kill it

Here is the part the coverage underplays. Because the Developer ID is real and named rather than forged, Apple holds the off switch. Apple can revoke that certificate and its notarization, and once it does, Gatekeeper will refuse that exact build on any Mac that checks in. Neither Jamf nor the outlets reporting on it said Apple had revoked the signature at the time of writing, which makes reporting the certificate to Apple product security a concrete action rather than a formality. Treat a currently valid signature as not blocked yet, never as permanent trust.

Detection moves from is it signed to what is it doing

Signature-based allowlisting is exactly the control CrashStealer is built to walk past, so the hunt has to be behavioral. The highest-signal tell is a process not signed by Apple that reads the login keychain and browser credential stores. For persistence it plants a LaunchAgent inside ~/Library/LaunchAgents, giving it the file name com.apple.crashreporter.helper.plist so it reads as Apple's own crash reporter, which is how the malware earned its name. Its payloads come down from a GitHub repository, and stolen data goes out to a hardcoded address, both listed below.

One detail matters for tooling: because CrashStealer runs as native C++ rather than AppleScript, detections tuned to catch osascript abuse, the usual macOS stealer signature, will miss it. This is the kind of activity a managed detection practice is meant to catch, where the alert fires on the keychain read and the impersonating LaunchAgent, not on the signature.

Signed and trusted is the soft spot now

CrashStealer is one instance of a pattern we keep writing up: attackers buying the platform's own trust signals instead of breaking them. We saw it when a fake 7-Zip installer rented servers out as residential proxies while file scans stayed quiet, and again with a Mac backdoor built to fool the tool inspecting it. Trusted software-update channels get abused the same way, as with the plugin that shipped clean and backdoored sites through its paid update. The common thread is that trusted by the platform is where most defenses stop looking, so that is where the payload now hides. A signed and notarized macOS binary that steals wallets is that thread reaching Apple's gate.

Report the certificate, then hunt for keychain reads

If you run Macs, do three things this week. Block werkbit[.]io and the listed indicators, and pull any host that ran Werkbit.app for review. Alert on new LaunchAgents that borrow an Apple bundle identifier and on non-Apple processes touching the login keychain. Report the Emil Grigorov (WWB7JA7AQV) certificate to Apple so the notarization can be revoked. Then rotate every credential and wallet seed for any machine that opened the app, because by the time you are reading the logs, the data is already gone.