← Field Notes
Threat model · Deep dive

It never needed admin: detecting the CrashStealer macOS infostealer

R Rob Flanagan · · 4 min read

A signed, notarized infostealer that ran a full credential-theft chain without ever asking for root. If the plan was to stop it at the door, the door was open. You catch this one inside, by the noise it leaves.

Jamf Threat Labs documented a macOS infostealer that ran a full credential-theft chain without ever asking for root. That fact reorders how you defend against it. If your plan was to stop it at the door, the door was open. You catch this one inside, by the noise it leaves.

CrashStealer is a native C++ stealer disguised as a crash reporter. At the time Jamf analyzed it, the dropper was signed, notarized, and passed Gatekeeper, which is Gatekeeper working as designed. In the trace Jamf documented, every stage ran in the signed-in user's session, and no step invoked sudo. It copies the login keychain, lifts browser passwords and crypto wallets, then drops a LaunchAgent named com.apple.crashreporter.helper that relaunches at login.

The chain, stage by stage

Reading the extraction chain is what makes the defensive layers obvious.

  • The signed, notarized dropper clears Gatekeeper on first launch.
  • It runs a curl command supplied by a file on GitHub, decoding base64 blobs piped to bash.
  • Cleartext HTTP pulls a payload disk image, saved to /tmp.
  • xattr -cr clears extended attributes, then codesign -s - re-signs the modified bundle ad-hoc, which keeps it runnable.
  • A fake password box appears, and dscl -authonly validates the entered login password before the login keychain is copied.
  • The LaunchAgent lands in a user folder for persistence at login.

No step in that chain asked for administrator rights.

Notarized is not the same as safe

The dropper carried a real Developer ID and a stapled notarization ticket, so default policy let it run. Apple's documented post-discovery mechanisms can revoke that Developer ID, issue a notarization revocation ticket to block later launches, and add XProtect blocking or remediation, and Jamf reported the signer to Apple. None of that reverses data already stolen. Default Gatekeeper admits software that passes Developer ID, notarization, and current malware checks, so before a sample is classified, a malicious dropper can still pass. Treat Gatekeeper as a floor, not an allowlist.

What should catch it

With behavioral EDR. Security products can use Apple's Endpoint Security framework to collect process-execution, file, extended-attribute, authentication, and background-item events. Those can expose the executions of codesign, xattr, dscl, and security, the access to login.keychain-db, the creation of the LaunchAgent plist, and the launch of its target. Recording, retention, correlation, and alerting stay product- and configuration-specific, so having the tool and the tool firing are two different things. One caution worth acting on: the observed dscl and security command lines carry the captured password, so confirm your product's argument redaction and access controls before relying on full command-line capture.

Without EDR. Inventory scripts can hunt the artifacts left behind. An Apple-prefixed LaunchAgent sitting in a user folder you didn't put it in, the temp and cache paths, and leftover loot archives are all findable, and you can inspect the Program and ProgramArguments keys and validate the referenced executable. Event collection can catch it live; inventory is delayed hunting. The chain maps cleanly to MITRE ATT&CK: Gatekeeper bypass (T1553.001), curl to bash (T1059.004), credentials from keychain (T1555.001), Launch Agent persistence (T1543.001), and masquerading with CrashReporter names (T1036.005).

Removing admin was still right

Taking local admin away from users limits some system changes, and it was a correct decision. It does not contain stolen credentials, because this chain never needed admin to begin with. So if it ran, treat the event as credential theft, not malware cleanup: isolate the Mac, reset the captured login password from a clean system, revoke active sessions and tokens, and rotate the secrets it could reach. Containment and evidence come before eradication, which is the order the CISA and NIST incident-response playbooks put them in.

Five checks are worth running tonight. Are you flagging unexpected com.apple.* LaunchAgents in user folders and validating the executable they reference? Alerting on ad-hoc re-signs and extended-attribute clearing? Is keychain and dscl -authonly telemetry landing where you would see it? Are you treating the published domains and C2 IP as point-in-time indicators rather than trusting a feed? And is "Install system data files and security updates" enabled, with Macs able to reach Apple's notarization endpoints? Open your endpoint console and ask which of these would have fired last night.

Sources

The kill chain is from Jamf Threat Labs' own analysis; the control and response references are Apple, MITRE, CISA, and NIST primary sources:

← Back to Field Notes