Introduction
In early May, a suspicious macOS sample uploaded to VirusTotal surfaced through our sample-processing pipeline, and Jamf Threat Labs began tracking it. It impersonated Apple's crash reporting framework and, at that point, looked like an infostealer still in development. By early July we were seeing in-the-wild detections of the payload matching one of our in-house rules, indicating the project had matured from development into active use. We track this malware under the name CrashStealer.
Unlike much of the commodity stealer activity on macOS, which is built on AppleScript droppers or thin Objective-C wrappers, CrashStealer is implemented in native C++ around an internal class the authors named MacOSData. It validates the victim's login password locally before harvesting, collects broadly across browsers, cryptocurrency wallets, password managers and the keychain, encrypts what it collects with AES-GCM before exfiltrating over libcurl, and persists by copying and re-signing itself. Although its objectives overlap with families such as Atomic (AMOS), MacSync and Phexia, its native C++ implementation and client-side encryption set it apart, and we track it as a distinct family rather than a variant.
We have since identified the stage that precedes the payload: a signed and Apple-notarized dropper, distributed as a disk image named "Werkbit Setup," that retrieves the CrashStealer payload from attacker infrastructure and launches it. Because the dropper carries a valid Developer ID and a stapled notarization ticket, it clears Gatekeeper on first launch, in contrast to the ad-hoc-signed payload it installs.
Throughout this post, we examine CrashStealer as we observed it and highlight the behaviors most relevant from a defender's perspective.