CrashStealer the new information thief in macOS who signs his installer to evade Gatekeeper and steal credentials

Security investigators have identified a new information thief for macOS baptized as CrashStealer, which stands out for its implementation in native C + + and for techniques that seek to evade traditional system controls. Unlike most stealer who resort to droppers in AppleScript or wrappers in Objective-C, this project prioritizes performance and ofuscation, and incorporates local encryption of stolen data before sending them to the attacker.

What makes CrashStealer particularly concerned is not only what it takes away, but how it does it: the campaign uses a distributed installer as a disk image ("Werkbit.app") signed and notarized with a valid developer identifier, allowing it to draw Gatekeeper. The dropper is also protected after a PIN access system linked to the distribution web, which reduces public exposure of bait and facilitates more selective targeting. After execution, the binary downloads a second payload from operator-controlled repositories and servers, reinstates and re-signs components and persists as LaunchAgent to survive rebeginnings.

Technically, malware shows two distinctive features: first, Local value of login password to unlock the key chain (keychain) and thus access credentials; second, pack the stolen and figure it with AES-GCM on the customer before exfiltration by HTTP (S) using libcurl. It also incorporates multiple layers of resistance to the analysis, such as control flow ofuscation, encrypted chains and anti-debugging mechanisms, which complicates response work and detection by traditional tools.

The scope of the theft is wide: credentials and cookies of Chromium browsers, extensions of more than seventy popular cryptomoneda portfolios (including MetaMask and Phantom), password managers data (1Password, Bitwarden, LastPass and others) and user folder files. After collecting the information, the packaging and sending it to external servers controlled by the attackers, thus completing an intrusion cycle designed to maximize impact on financial accounts and persistent access.

The implications are clear: signature and notarization are no longer an absolute guarantee of safety, and institutional and private users must assume that confidence in an installer must be complemented by additional controls. For organizations this means reviewing application input flows, white list policies and telemetry that detect changes in LaunchAgens and key calls. For domestic users, the lesson is not to lower your guard to "verified application" notices and to distrust installers from unverified sources or protected by access mechanisms such as PINS that are shared outside official channels.

Immediate practical recommendations include avoiding opening disk images or running applications whose origin you cannot independently verify, not entering the session password or key key in unexpected dialog tables, and in case of suspicion, rotate credentials and keys from a clean device before restoring the committed equipment. Organizations should deploy detection solutions with the ability to monitor persistence (LaunchAgens), verify system-level signatures and block malicious developer signatures when identified. It is also recommended to activate multifactor authentication in all critical services and to keep the system and security solutions up to date.

For those who want to deepen the context and the original research, see the pages of the JAMF laboratories and specialized media coverage that have documented the campaign: Jamf Threat Labs and The Hacker News. Apple's documentation about Gatekeeper and notarization helps to understand why signing and notarizing is no longer sufficient as the only criterion of trust: Apple - Gatekeeper.