CrashStealer: When Gatekeeper Trust Becomes a Liability
Just reviewed the Jamf Threat Labs report on this new macOS infostealer, CrashStealer. What stands out isn't just the data harvesting capability, but the architecture. Unlike the typical AppleScript droppers or simple Obj-C wrappers we've been seeing in the ecosystem, this one is implemented in native C++. That usually implies better evasion capabilities and stability across different macOS versions.
The most concerning part is the use of a notarized dropper to bypass Gatekeeper. It serves as a stark reminder that "Apple Notarized" is a safety check, not a guarantee of benevolence. The malware validates the victim's login password locally before executing, likely to ensure it has the right context to decrypt the Keychain or escalate privileges.
For incident responders, spotting this requires looking past the initial "safe" badge. If you are triaging a potential infection, verify the signing status rigorously. Here is a quick workflow to verify a binary's signature and check its notarization status from the terminal:
codesign -dv --verbose=4 /path/to/suspicious/binary
spctl -a -v -t execute /path/to/suspicious/binary
If the second command returns a revoked status or identifies a developer ID not on your allow-list, treat it as a breach.
How is everyone else handling the notarization trust issue in their environments? Are we moving toward strict allow-listing of Team IDs via MDM, or is that too operationally heavy for most shops?
From a SOC perspective, the shift to C++ is frustrating. It creates much more noise in process creation logs compared to the AppleScript droppers which are easier to fingerprint. We are currently tuning our correlation rules to flag any process spawning from a non-standard parent that immediately calls security or dumpkeychain commands.
# Hunting for suspicious keychain access
ps aux | grep -i 'security' | grep -v grep
Strict Team ID allow-listing is the only way to go now. Gatekeeper 'default' settings are effectively dead for high-security environments.
I manage a fleet of Macs for a design studio, and this is a nightmare. Users constantly need to install random software. If we lock down Team IDs too hard, support tickets explode.
However, the local password validation mentioned in the report is interesting. If it's just checking validity, it might be using Authorization Services. Admins should check for unusual prompts or crashes in loginwindow processes, as the name 'CrashStealer' implies it might be triggering or leveraging crash logs.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access