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

Wade Tregaskis:

In short: if you have any file in your app (or whatever it is you’re trying to get Apple to sign) that is over 4 GiB, you must use a disk image (DMG) to package it for notarytool, not a zip file.

This is because support for files larger than 4 GiB requires using the “Zip64” zip file format, which would be fine except Apple’s notary servers can’t handle them.

Previously:

• altool Update and notarytool

Update (2026-07-22): Rosyna Keller:

It’s recommended to notarized exactly what you’re going to ship to users and shipping zips is extremely risky because you never know what tool the user will use to decompress the file.

Multiple unzipping tools will strip necessary extended attributes that could cause the code signature to fail to validate. This is especially true if you put non-code files in “code places” and they have to be signed with an extended attribute.