Thijs Xhaflaire (via Ric Ford):

Jamf Threat Labs discovers and investigates CrashStealer, a C++ macOS infostealer that impersonates Apple's crash-reporting framework to harvest browser credentials, cryptocurrency wallets and keychain data, encrypting stolen files with AES-GCM before exfiltrating them to a remote command-and-control server.

[…]

Unlike the payload it eventually installs, the dropper is properly code signed and notarized: it is a universal (arm64 and x86_64) binary signed with the Developer ID Emil Grigorov (WWB7JA7AQV), has hardened runtime enabled, and carries a stapled notarization ticket. Notably, the disk image itself is signed as well, not just the application inside it, which is uncommon in malicious DMG delivery where the container is typically left unsigned.

[…]

That file supplies the curl command the dropper runs next. Staging the first hop on a trusted developer domain keeps the initial network activity inconspicuous.

[…]

[The script] clears extended attributes on the staged bundle with xattr -cr, makes the inner binary executable, strips the payload's existing signature and re-signs it ad-hoc (codesign --remove-signature followed by codesign -s - --force --deep --no-strict), registers it with Launch Services via lsregister -f, and finally launches it in the background with open -g -n.

Previously:

• Notarized Mac App That Downloads Malware
• Fake Mac Apps on GitHub
• Notarized Atomic Stealer (AMOS)
• More Notarized Mac Malware
• App Transport Security

CrashReportExtension:

The Crash Report Extension framework allows you to perform analysis and produce a report when your app crashes. Your crash-handling code executes out-of-process, rather than from a signal handler or other in-process techniques.

You implement your handler by writing an app extension that conforms to the CrashReporterExtension protocol. The system calls your processCrashReport(process:) method when the app crashes. Use the CrashedProcess parameter to inspect the state of the crashed app by retrieving a crash reason, symbolicating relevant addresses, and communicating with the process over a read-only Mach port. After collecting the crash data, you can send a report back to your own server.

[…]

Crash Report Extension is available on iOS 27 and later. It isn’t available to Catalyst-based macOS apps, or on iOS apps running on Mac computers with Apple silicon.

The top of the page says “macOS 27.0+,” so I guess this means it does work for regular AppKit and SwiftUI Mac apps. It’s great to finally have a supported way to do this.

I don’t know why they can’t just give you the crash report text or .ips JSON directly, though. It looks like you have to use Mach IPC with the corpsePort to get the backtrace for each thread and then use the extension API to symbolicate the addresses. Even then, I’m not sure you can get all the information that’s in a standard crash report, such as the Application Specific Backtrace. Maybe you can find the address for gCRAnnotations/__crashreporter_info__ and load it with mach_vm_read?

Previously:

• WWDC 2026 Links
• Visual Studio App Center Retirement
• What Happened to __crashreporter_info__?
• Restarting macOS Apps Automatically on Crash
• Crash Reporting for Sandboxed Mac Apps
• Reliable Crash Reporting