Fake Mac Crash Report Asking for Your Password? Do Not Type It

Your Mac throws up a window that looks exactly like a system crash report, and it wants your login password before it will go away. Do not type it. In July 2026, Jamf Threat Labs published an analysis of a macOS infostealer it named CrashStealer, which does exactly this: it impersonates a normal macOS system tool and harvests the password you hand it. If you already typed yours, skip ahead to the runbook further down this page and start working through it.

This is not a story about an exotic zero-day. Nothing was hacked, no security flaw was exploited, and no update would have prevented it. The whole attack rests on one thing: most Mac users have been trained, over years of legitimate use, to type their password into any window that looks like it came from macOS. CrashStealer draws a convincing window, and the user does the rest.

That makes this a problem you can actually solve with knowledge rather than software. Below, two things you will not find in most of the coverage: a practical method for telling a genuine macOS authorization prompt from an app-drawn imitation, and a calm, ordered runbook for the moment you realize you already typed your password into one. The first section is about prevention. The second is about damage control at 2am, which is usually when people figure this out.

Key Takeaways

• The real macOS crash reporter never asks for your password. If a window claiming to be a crash report, a diagnostic tool, or a system updater wants your login password, that window was drawn by an application, not by macOS.
• Context beats pixels. A determined attacker can produce a screenshot-perfect fake. What they cannot fake is the reason a real prompt appears: genuine macOS authorization dialogs follow an action you just took. A prompt that arrives out of nowhere is the single strongest warning sign you have.
• Notarization is not a security audit. Jamf Threat Labs reported that the application distributing CrashStealer was signed and notarized with a valid Apple Developer ID, which is why it passed Gatekeeper. Apple has since revoked the certificate, but revocation is cleanup, not prevention.
• If you typed your password, assume the login Keychain is gone too. Jamf reported that the malware verifies the entered password locally and, if it is correct, can use it to unlock the login Keychain and reach far more than what you typed.
• The recovery order matters. From a different, trusted device: Apple Account password first, then your password manager's master password, then email, then money, then everything else. Treat crypto seed phrases as burned.

What Jamf Threat Labs Actually Reported

Jamf Threat Labs published its analysis of CrashStealer in mid-July 2026, and it was picked up over the following days by 9to5Mac, MacRumors, Help Net Security, Malwarebytes, Infosecurity Magazine, and SecureMac. It is worth separating what was actually reported from what has since been paraphrased into vaguer warnings.

The delivery: a disk image that is not what you asked for

According to Jamf's writeup, the malware arrives inside a disk image named Werkbit Setup. The victim mounts the DMG and installs what they believe is the software they went looking for. Nothing at this stage looks alarming, because at this stage nothing is asking for anything unusual.

The important detail here is the mismatch. You searched for one thing; the disk image that landed in your Downloads folder is named something else. That gap is one of the few reliable signals available before anything runs, and it is worth building a habit around: read the name of the disk image in the Finder sidebar before you drag anything out of it.

The lure: an app that calls itself CrashReporter

Once installed, Jamf reported, the malicious application presents itself as CrashReporter.app, borrowing both the name and the general look of a normal macOS system component. It then displays a password prompt styled to resemble a legitimate macOS system dialog.

This is a good disguise for a specific reason. Crash reports are one of the few things macOS genuinely does surface unprompted. Apps do crash, macOS does offer to report it, and most users have dismissed that dialog dozens of times without reading it closely. The malware borrows that familiarity. It shows up at a moment when an unexpected system window would not feel strange, and it asks for the one thing the real dialog never asks for.

What happens when you type

This is the part that makes CrashStealer worse than a plain phishing window. Jamf reported that the malware verifies the entered password locally, and if the password is correct, it can use it to unlock the login Keychain.

Think about what that means in practice. The password you typed is not the prize on its own. It is the key to the container that holds everything else. Your login Keychain is where macOS stores Wi-Fi passwords, app credentials, certificates, secure notes, and for many people a long tail of saved website logins. Unlocking it converts one stolen string into a full credential dump.

The reported targets line up with that: browser-stored credentials, password manager data, cryptocurrency wallet data including browser wallet extensions, and login Keychain contents. If you have ever wondered why we keep writing that your Mac password is not just a screen lock, this is why. It sits at the root of the credential tree. Our guide to why macOS keeps prompting for your login Keychain password explains how tightly that keychain is bound to your account password in normal, non-malicious circumstances.

Two technical notes worth knowing

Jamf highlighted two characteristics that are relevant to defenders even if you never touch a disassembler.

First, CrashStealer is written in native C++. Many Mac stealers over the past few years have leaned heavily on AppleScript, which is comparatively easy to inspect, easy for security tools to pattern-match, and easy for macOS itself to gate behind automation permissions. A native binary sidesteps a category of detection that the ecosystem had grown comfortable relying on. The practical takeaway for a normal user: heuristics like "malicious apps ask for Automation permissions" are not a rule you can lean on.

Second, and more consequential, the distributing application was signed and notarized with a valid Apple Developer ID. That is why Gatekeeper let it through without the friction most people associate with untrusted software. We will come back to this, because "but it was notarized" is doing a lot of unearned work in a lot of people's threat models.

The timeline

Per Jamf, earlier samples that appeared to be incomplete or still in development surfaced around May 2026. Working, in-the-wild versions were detected in early July 2026, and the public analysis followed around July 13 to 15.

That two-month gap between half-built samples and working deployment is normal, and it is a reason not to treat any single published analysis as the end of the story. Stealers get iterated on. The disk image name, the app name, and the exact wording of the prompt are the most disposable parts of this operation. The technique is the durable part, and the technique is the thing worth learning.

The Core Idea: A Password Prompt Is a Claim, Not Proof

Before the checklists, one idea that makes all of them easier to remember.

When a window appears on your screen asking for your password, that window is making a claim about who it is. It is claiming to be macOS. Nothing about a window's appearance can substantiate that claim, because any application with permission to draw on your screen can draw anything, including a perfect replica of a system dialog. Fonts, spacing, the padlock icon, the exact shade of the background material, the button placement, the little app icon in the corner: all of it is just pixels, and all of it is copyable.

So the question is never "does this look real?" The question is "is there a reason a real one would be here?"

That reframing is what the rest of this article builds on. Visual inspection still has value, and there are specific checks below that genuinely catch sloppy fakes. But visual inspection is a filter, not a verdict. Context is the verdict.

Visual Forensics: Real macOS Prompt vs. App-Drawn Fake

Here is what you can actually check, roughly in order of how much weight each check deserves.

1. Did you do something that would require authorization?

This is the highest-value check by a wide margin, and it costs nothing.

Genuine macOS authorization prompts are consequences. You installed something. You changed a setting in System Settings that has a padlock on it. You approved a system extension. You ran a command that needed elevated privileges. You unlocked a Keychain item. You changed a network configuration. In every one of those cases, you performed a deliberate action a second or two earlier, and the prompt names that action.

macOS does not, in normal operation, decide on its own to ask for your login password while you are reading a web page or watching a video. If a password prompt appears and you cannot point to the thing you just did that caused it, treat it as hostile until proven otherwise. Not "probably fine." Hostile.

The corollary is uncomfortable but true: an attacker who knows this will try to time the fake prompt to something you did, most often the moment right after you install their app. A prompt appearing immediately after you open freshly downloaded software is not reassuring context. That is the exact moment CrashStealer's prompt appears.

2. Does the thing asking have any business asking?

Some system components ask for your password routinely. Some never do.

The macOS crash reporter is firmly in the "never" category. When an app crashes, the real dialog tells you the app quit unexpectedly and offers to reopen it, ignore it, or send a report to Apple. It does not need your password, because sending a crash log to Apple does not require administrator rights. There is no configuration in which the genuine crash reporter asks you to authenticate.

The same applies to most things that just show you information. A window telling you an app crashed, a notification about an available update, a dialog about a document that failed to save, a message about a disconnected drive: none of these have a legitimate reason to demand your login password. If an informational message suddenly turns into an authentication request, something is wrong with that window, not with your Mac.

The categories that genuinely do prompt: installing software that writes outside your home folder, unlocking padlocked panes in System Settings, approving kernel or system extensions, changing FileVault or Startup Security settings, and Keychain access for specific stored items. If the window in front of you is not doing one of those things, it should not be asking.

3. Find out which app is actually asking

A fake prompt belongs to a process. You can go find that process while the prompt is still on screen.

Check the menu bar. Move your pointer to the top of the screen. The application name next to the Apple menu tells you which app is currently frontmost. If a window claiming to be a system dialog is up and the menu bar says the name of some app you just downloaded, you have your answer.

Try Command-Tab. If you can switch away from the prompt and it goes behind another window like any ordinary app window, it belongs to an app. Some genuine system dialogs float above everything; an app-drawn fake often does not, and the ones that do reveal themselves other ways.

Open Force Quit. Press Command-Option-Escape. The Force Quit window lists your running applications by name. Look for anything you do not recognize, anything that appeared in the list at the same time the prompt did, or anything whose name is suspiciously close to a system component. Quitting the offending app usually makes the prompt disappear, which is itself the confirmation you were looking for.

Open Activity Monitor. Applications > Utilities > Activity Monitor gives you a longer list, including background processes. Sort by CPU or by process name and look for recent arrivals. This is more work than Force Quit and more prone to false alarms, since macOS legitimately runs a lot of oddly named background processes, but it is where you look when Force Quit shows nothing.

The honest limitation: a well-built fake can name its process something innocuous, and you will not necessarily recognize a malicious name among the hundred legitimate ones. This check catches lazy fakes reliably and sophisticated ones sometimes.

4. The drag test

This one is genuinely useful, and it works in one direction.

Try to drag the prompt window across the screen. Push it toward the far edge, or onto a second display if you have one. A real system dialog is its own window and can be moved anywhere on the desktop. A fake that has been drawn inside another window, which is common when the fake lives in a web page, an Electron app, or a full-screen view, cannot leave the boundaries of its parent window. If the prompt clips, snaps back, or refuses to cross out of a rectangle that corresponds to some other app's window, it is fake. Full stop.

The one-way part: if the prompt does drag freely anywhere on screen, that proves nothing. A native app can create a borderless floating window that moves exactly like a system dialog. Passing the drag test is not a clean bill of health. Failing it is a conviction.

A related variant: try resizing the window, or look for a window that is subtly the wrong size for the content in it. Fakes built from a web view sometimes scale strangely when you change display resolution or move between displays with different scaling.

5. Use Touch ID instead of typing

If your Mac has Touch ID and you are being asked to authenticate for something you actually initiated, use the fingerprint sensor rather than the keyboard.

This is not because Touch ID is impossible to imitate visually. An app can display a Touch ID-styled prompt. The reason it helps is more direct: a fingerprint authentication does not hand your password to the app. Real Touch ID authentication happens through the Secure Enclave and returns a yes-or-no answer to the requesting process. Nothing types your password, so nothing captures it. If the window is fake, you have given it a fingerprint scan it cannot convert into a credential.

There is a second signal in it too. If you are performing an action that normally offers you Touch ID on your Mac, and this particular prompt insists on a typed password with no Touch ID option, ask yourself why. Some genuine prompts do require a typed password, so this is a yellow flag rather than a red one, but combined with the other checks it adds up.

6. Escape, then see what happens

Press Escape, or click Cancel. Then watch.

A genuine authorization prompt cancels cleanly and the action you were performing fails in a way that makes sense. You tried to unlock a settings pane; the pane stays locked. You tried to install something; the installer reports that it could not continue.

A fake typically nags. It reappears after a few seconds, or it reappears every time you click on the desktop, or it comes back on the next login, or it never quite goes away. Persistence in the face of a cancel is a strong tell, because the malware's entire value depends on eventually getting your password. It is built to keep asking. Real system dialogs are not.

This check has a cost: you have to wait around to see whether it comes back, and in the meantime you are sitting in front of a Mac that may be actively running something you do not want. Use it, but do not use it instead of disconnecting.

7. Read the text, but weight it lightly

Sloppy fakes get things wrong. Generic wording where macOS would name a specific app or a specific action. Slightly off capitalization. A version number or product name that does not match what you are running. Grammar that reads like it was translated. Button labels in the wrong order for macOS conventions. An icon that is a slightly stale version of the current system icon.

All of these are worth noticing, and none of them are worth relying on. The typography of a system dialog is a solved problem for an attacker with a screenshot and an afternoon. Treat textual oddities as a reason to escalate to the other checks, never as the last line of defense.

Be honest about the ceiling of visual inspection

Every check above can be defeated by a sufficiently careful attacker. A native, well-built fake that appears at a plausible moment, drags freely, uses correct wording, and disappears when you cancel would pass every visual test in this article.

That is not a reason to skip the checks. It is a reason to understand what they are for. They catch the majority of real-world fakes, which are not built with unlimited care. But the layer underneath them, the one that does not depend on the attacker's craftsmanship, is behavioral.

The Behavioral Rules That Do Not Depend on Craftsmanship

These are the rules that hold even when the fake is perfect.

Rule 1: Never type your password into a prompt you did not summon. If you cannot name the action that caused it, the answer is no. Not "let me look at it more closely." No.

Rule 2: When in doubt, cancel and re-initiate deliberately. If you genuinely do need to authorize something, dismiss the prompt, quit the app, and start the action yourself from a place you trust. Open System Settings yourself and click the padlock. Run the installer yourself from the Finder. If a prompt then appears as a direct result of the thing you just clicked, it is far more likely to be real, because you created the context rather than accepting a context handed to you.

Rule 3: A prompt that appears immediately after you install something is the highest-risk prompt there is. That is where CrashStealer lives. New software asking for your admin password can be legitimate, but it is also the exact shape of the attack. If the software is something you just downloaded from a site you have not used before, stop and reconsider what you are installing before you authenticate.

Rule 4: Prefer Touch ID whenever it is offered. It converts "I gave them my password" into "I gave them nothing."

Rule 5: If anything feels wrong, disconnect first and think second. Turning off Wi-Fi costs you nothing and takes two seconds. It is the cheapest possible action, and it is the one that stops data leaving.

If You Already Typed It: The Post-Exposure Runbook

This section assumes the worst case: you typed your login password into a prompt you now believe was fake. You are probably somewhere between annoyed and genuinely frightened. Work through this in order. It is designed so that the highest-leverage moves come first, and so that nothing here requires you to make a judgment call while stressed.

Two framing points before the steps.

First, assume exfiltration already happened. Infostealers are built for speed; they collect and send. Do not spend your first ten minutes trying to determine whether data left. Spend them on the assumption that it did.

Second, assume the login Keychain is compromised. Jamf reported that a correct password lets CrashStealer unlock it. That means the scope of this incident is not "one password." It is "every credential that password protected."

Step 1: Disconnect the Mac from the network. Right now.

Turn off Wi-Fi from the menu bar. If you are on Ethernet, unplug the cable. If you want to be thorough, turn on Airplane-style isolation by disabling Wi-Fi and Bluetooth both.

This does two things: it stops any further upload of data the malware has collected but not yet sent, and it cuts off any remote instruction channel. It does not undo what already left, and it is not a substitute for the credential rotation below, but it is free and instantaneous and it bounds the damage.

Do not shut the Mac down yet. You will want to inspect it shortly, and a running system is easier to inspect than one you have to boot back into. If you have no intention of inspecting it and plan to go straight to a full erase, shutting down is fine.

Step 2: Stop typing credentials on that machine

This is a rule for the next several hours, and it is the one people break without noticing.

Do not log into your email on that Mac to check for suspicious activity. Do not open your password manager on it to change passwords. Do not sign in to your bank on it to look at transactions. Every credential you enter on a machine you believe is compromised is a credential you are handing over a second time. The instinct to immediately go check things is strong and it is exactly wrong.

Treat that Mac as a read-only crime scene until you have decided what to do with it.

Step 3: Get to a different, trusted device

Use your phone, a tablet, another computer, or a family member's machine. What you need is a device that was not involved in this incident.

One caution: if your phone is signed into the same accounts and you keep a synced password manager on it, the phone is still a usable device for recovery, because the compromise was of credentials rather than of the phone itself. But if you have any reason to think the same malicious installer touched more than one machine, use something else.

Step 4: Change your Apple Account password first

Do this before anything else, from the trusted device.

Your Apple Account is the root of the tree. It gates iCloud Keychain, Find My, iCloud backups, device authorization, purchases, and in many cases the recovery path for other accounts. If an attacker gets it, they can use it to reach things you never stored on the compromised Mac at all.

On an iPhone or iPad: Settings > your name > Sign-In & Security > Change Password. On the web: appleid.apple.com. While you are there, review the list of trusted devices and remove anything you do not recognize or no longer use.

Choose a password you have never used anywhere else, and do not reuse a pattern of an old one.

Step 5: Change your password manager's master password second

If you use 1Password, Bitwarden, Dashlane, KeePass, or anything similar, its master password is the second root. Jamf reported password manager data among CrashStealer's targets, so treat the vault as exposed.

From the trusted device, change the master password, then look for a "sign out of all devices" or "deauthorize all sessions" control and use it. Many password managers also offer a secret key or account key concept; if yours supports rotating it, do that too.

If your password manager was unlocked on that Mac at the time, or if its data was cached locally, assume the vault contents are known to the attacker. That is a bad feeling, and it also gives you a precise to-do list: everything in the vault needs to rotate. Prioritize by the next steps.

Step 6: Rotate email, then money, then everything else

The order is not arbitrary. It follows the blast radius.

Email first. Whoever controls your email can reset most of your other accounts. Change the password on every email account you own, starting with the one that receives password reset messages. Then, in each account's security settings, look for a list of active sessions or authorized devices and revoke everything you do not recognize. Also check for forwarding rules and filters you did not create; a common post-compromise move is to quietly forward or auto-archive security notifications so you never see the alerts.

Money second. Banks, brokerages, payment apps, anything with a stored card. Change passwords, then check recent activity, then call the institution if anything looks off. Many banks will note the incident on your account and increase scrutiny for a period if you tell them.

Then everything else. Work accounts, cloud storage, social media, shopping sites, developer platforms, domain registrars, VPS providers, anything with an API key. Domain registrars and cloud consoles deserve to be higher on this list than most people put them, because control of a domain or a cloud account is a long-lever attack on everything downstream.

Do not try to do all of this in one sitting. Do email and money now, tonight. Do the long tail over the next few days, working from your password manager's list.

Step 7: Revoke sessions and devices everywhere

Changing a password does not always kill an existing session. Many services will happily keep an already-authenticated session alive after a password change unless you explicitly terminate it.

For every important account, find the security page that lists active sessions, logged-in devices, or connected applications, and clear it out. Google, Microsoft, Apple, GitHub, Slack, Discord, and most major services all offer this. Also revoke third-party app authorizations you do not recognize, because OAuth tokens are a persistence mechanism that survives password changes.

While you are in there, check your browser sync sessions. If your browser profile was synced to a compromised machine, signing out all sync sessions and re-establishing sync from a clean device is worth the inconvenience.

Step 8: Treat crypto seed phrases as compromised

If you held cryptocurrency in a software wallet or a browser wallet extension on that Mac, this is the part that has a deadline measured in minutes, not days.

Jamf reported cryptocurrency wallet data among CrashStealer's targets, including browser wallet extensions. Assume any seed phrase, private key, or wallet file that existed on that machine is now known.

The action is not "change the wallet password." Wallet passwords protect a local file; the seed phrase is the account. If the seed is out, the funds are reachable from anywhere in the world regardless of what you do on your Mac.

From a clean device, generate a new wallet with a new seed phrase, and move funds to it. A hardware wallet with the seed generated on the device itself is the right destination if you have one or can get one. Do not re-enter the old seed phrase on any device to "secure" it; there is nothing to secure. Do not enter it into any tool or website that offers to check whether it has been compromised, which is itself a common scam.

If you ever stored a seed phrase in a note, a screenshot, a text file, or your password manager on that Mac, the same applies. That is a good moment to reconsider that storage choice going forward.

Step 9: Enable two-factor authentication on everything that supports it

If you were already using 2FA on your email and financial accounts, this incident is significantly less bad than it could have been, because a stolen password alone does not open those doors.

If you were not, turn it on now as you rotate each password. Prefer an authenticator app or a hardware security key over SMS. SMS 2FA is meaningfully better than nothing and meaningfully worse than the alternatives, because SIM-swap attacks are a mature industry.

One caveat specific to this scenario: if your authenticator app's backup was stored in a cloud account whose password was in the compromised keychain, re-enroll your 2FA rather than assuming the existing setup is safe.

Step 10: Now inspect the Mac itself

With credentials rotating from a clean device, come back to the machine. Keep it off the network while you look.

Login Items and background items. Open System Settings > General > Login Items & Extensions. There are two lists worth reading: apps that open at login, and background items permitted to run. The second list is the interesting one, because it names the developer responsible for each background agent. Anything you cannot account for is worth investigating. Be aware that legitimate software puts entries here too, so do not delete everything reflexively; search the developer name before acting.

Configuration profiles. Open System Settings > General > Device Management. On a personal Mac that is not enrolled with an employer or school, this pane usually does not appear at all. If it does appear and lists a profile you did not install, that is a serious finding. Configuration profiles can change DNS settings, install certificates, and enforce policy, and they are a favorite persistence mechanism precisely because most users never look here.

The Applications folder, sorted by date. In the Finder, open Applications and switch to list view sorted by Date Added or Date Modified. Anything that arrived around the time of the incident deserves scrutiny. Do the same for your user-level Applications folder if you have one.

Browser extensions. Open each browser's extensions page and remove anything you did not deliberately install. Pay particular attention to wallet extensions, which are directly relevant here, and to anything with broad permissions to read data on all sites.

Recent downloads. Look through your Downloads folder for the disk image or installer that started this. Do not open it again. Knowing the filename helps you recognize the same lure if it shows up again.

If you find something and remove it, do not conclude you are clean. Removing the piece you found tells you nothing about the pieces you did not.

Step 11: Decide whether to erase and reinstall

Here is the honest answer, without hedging: if you typed your login password into a fake system prompt, erase and reinstall is the correct call.

The reasoning is not that removal is impossible. It is that verification is impossible. You cannot prove a negative on a machine that has run an unknown native binary with your admin password in hand. Manual cleanup gets you to "I did not find anything else," which is not the same as "there is nothing else." For a machine that holds your work, your email, and your money, that gap matters.

Cases where you can reasonably skip the erase: you saw the prompt, you did not type anything, you quit the app and removed it, and nothing since has behaved oddly. Cases where you should definitely erase: you typed the password; or you cannot reconstruct what you installed; or you have found persistence items you do not understand; or the machine has access to anything you are responsible for on behalf of other people.

How to do it properly on a modern Mac:

1. Finish rotating credentials first, from the clean device. Do not erase before you have your accounts under control, because the erase does not fix your accounts.
2. Back up your documents, not your applications and not a full system image. Copy the files you need to an external drive. Photos, documents, projects, source code, anything you generated.
3. Use Erase All Content and Settings (System Settings > General > Transfer or Reset) on Apple silicon and T2 Macs, or reinstall from macOS Recovery.
4. Set the Mac up as new. Do not restore from a Time Machine backup made after the infection, and do not use Migration Assistant to pull applications and system settings across from the compromised state. That is how people reinfect themselves and conclude the malware was undetectable.
5. Reinstall applications from the Mac App Store or from each developer's official site, fresh.
6. Copy your documents back from the external drive.
7. Sign back in and re-enroll two-factor authentication.

Yes, it is a lost evening. It is a lost evening that ends with a machine you can actually trust, which is worth more than the evening.

Why Notarization Did Not Save Anyone Here

The most instructive part of this case is that everything worked as designed, and the user still got hit.

What notarization actually is

When a developer distributes a Mac app outside the App Store, they submit it to Apple's notary service. Apple runs an automated check: it scans for known malicious content, verifies the code signature, checks that the app is signed with a valid Developer ID, and confirms a set of hardening requirements. If it passes, Apple issues a ticket that gets stapled to the app.

Read that list again and notice what is not on it. There is no human reviewer. There is no behavioral analysis of what the app does when a user runs it. There is no judgment about whether the app's purpose is honest. Notarization answers a narrow question: does this binary contain anything we already recognize as malicious, and is it properly signed by an identifiable developer?

An app that draws a convincing password box and sends what it captures does not contain "known malicious content" in the sense the scanner is looking for, particularly if it is a novel native binary. It sails through.

What Gatekeeper does and does not promise

Gatekeeper is the enforcement layer on your Mac. When you open a downloaded app, Gatekeeper checks whether it is signed and notarized, and whether the notarization ticket is valid. If it is, the app opens with minimal friction. If it is not, you get the warnings and blocks that Mac users know well, including the "app is damaged and can't be opened" message that we cover in our Gatekeeper and quarantine troubleshooting guide.

What Gatekeeper is promising is accountability, not safety. It is telling you: this software comes from a developer who registered with Apple, paid for a Developer ID, and had their binary scanned. That means if it turns out to be malicious, Apple knows whose certificate to revoke. It does not mean Apple has evaluated whether the app deserves your trust.

The gap between those two things is where this entire category of attack lives. And it is not new: we wrote about the same pattern in December 2025 when MacSync Stealer used a valid Apple notarization to bypass Gatekeeper. The lesson did not take, because "notarized" still reads to most people as "approved."

Revocation is cleanup, not protection

Apple has revoked the certificate involved in CrashStealer. That is the right response and it does real work: on Macs that check revocation, the app will no longer launch, and the same certificate cannot be used to sign the next build.

But revocation happens after the analysis, which happens after the infections. Everyone hit during the window between deployment in early July and the revocation got no benefit from it. Certificate revocation is the immune system's memory, not its barrier. Meanwhile, obtaining a fresh Developer ID is a solvable problem for a motivated operator, which is why this same pattern keeps recurring with different certificates attached.

The practical conclusion for you: use Gatekeeper, keep it enabled, never disable it to run something you were told to disable it for. And do not let it be the reason you trust an app. The question "is it signed?" is much less important than "did I get this from the developer, or from a search result?"

Where Installers Like This Come From

In practice, malicious disk images reach users through a small number of channels, and all of them exploit the same moment: you have decided you want a piece of software and you are looking for where to download it.

Search advertising. Someone searches for a well-known app and clicks the first result, which is a paid ad pointing at a look-alike site. The ad copy is right, the landing page is a good clone, and the download button works. This is the highest-volume channel by a distance, and it works because the top of a search results page feels authoritative.

Look-alike download sites. Domains that are one character off, or that add a plausible word, or that use a different TLD. Also the whole ecosystem of "download portals" that wrap real software in their own installers. Even when those sites are not distributing malware, they are distributing modified installers, which is a habit you do not want.

Links pushed in chat and forums. A Discord server, a Telegram group, a Reddit thread, a comment on a support forum. Someone helpfully posts a mirror. Sometimes it is a real person being helpful and sometimes it is not, and you cannot tell from the message.

Cracked and "free" versions of paid software. This one is self-explanatory and it remains one of the most reliable ways to end up with a stealer.

The defense is the same across all four: decide where you are going to download from before you search. Go to the developer's actual domain, which you can usually verify through the app itself, an existing installation, a bookmark, the developer's App Store listing, or their verified social account. Then download from there. Never let the search results page choose the source for you.

Practical Prevention That Actually Moves the Needle

A short list, in rough order of impact.

Install from the Mac App Store when the app is there. App Store apps are sandboxed and reviewed, which is a genuinely different bar from notarization. It is not perfect, but it is a much narrower attack surface.

When the app is not in the App Store, go to the developer's own verified site. Type the domain, use a bookmark, or navigate from the developer's App Store listing. Do not click an ad.

Read the disk image name before you install. If you searched for one product and mounted a DMG called something unrelated, stop. That single habit would have caught CrashStealer at the door.

Keep macOS updated. XProtect signatures and revocation data ship through the update mechanism, and they arrive whether or not you install the full OS update, but staying current keeps every layer in a supported state. Our macOS Tahoe 26.6 update guide covers what the current release includes and how to install it cleanly.

Use a password manager with a master password that exists nowhere else. Distinct from your Mac login password, distinct from your Apple Account password, not a variation of either. This is what limits the blast radius when one credential falls.

Keep the login Keychain locked behind a real password. Do not weaken your account password because typing it is annoying, and do not disable the keychain's protections. Touch ID exists precisely so that a strong password is not a daily tax.

Enable FileVault, and back up. FileVault protects data at rest if the machine is lost. Backups are what make "erase and reinstall" a two-hour inconvenience rather than a catastrophe. Both are covered in more depth in our Mac security and privacy guide.

Turn on two-factor authentication before you need it. It is the control that makes a stolen password survivable.

Does Antivirus Actually Help on a Mac?

An honest answer, without pointing you at a product.

Malware scanners on macOS are useful for a specific job: recognizing things that have already been analyzed and catalogued. If a known stealer family lands on your machine, a maintained scanner will very likely catch it, and that is not nothing, because most infections are not novel. Scanners are also genuinely helpful after an incident, as a second opinion when you are trying to work out what is on a machine.

What they are less good at is the case in this article. CrashStealer was a native binary from a developer account with a valid certificate, and its core malicious act was showing a window and reading what the user typed. There is a window of time between a new family appearing and detection catching up, and during that window signature-based tools have nothing to match on. Behavioral detection helps and is not magic.

There is also the honest counterpoint that macOS ships with layered protections already: Gatekeeper, XProtect, XProtect Remediator, notarization checks, System Integrity Protection, and app sandboxing for App Store software. For a careful user with good download habits, third-party antivirus adds less than it does on other platforms.

Where it makes clear sense: if you share the Mac with people who are less careful, if you handle other people's data, if you work in an environment with compliance requirements, or if you have already had one incident and want a second set of eyes. Where it makes less sense: as a substitute for the habits in the previous section. No scanner protects you from deciding to type your password into a window.

If you want the longer comparison, our Mac antivirus guide for 2026 goes through the trade-offs in detail.

Troubleshooting Common Issues

Problem: A password prompt appeared, I clicked Cancel, and I did not type anything. Am I fine? Solution: Almost certainly yes, on the password itself. Clicking Cancel discloses nothing. But the app that drew the prompt is still on your Mac, and it is still running. Quit it from Force Quit, then find and delete it, then check Login Items & Extensions and Device Management for anything it left behind. Watch for the prompt returning, which means something is still persisting. If you cannot find the source, or the prompt reappears after a restart, treat it as an active infection and work through the runbook from Step 10.

Problem: I genuinely cannot tell whether a prompt is real, and I need to authorize something legitimate. Solution: Dismiss the prompt entirely, then create the context yourself. Quit the app. Open System Settings or the Finder directly and initiate the action you wanted from there. If a prompt appears as an immediate result of a click you made in a place you trust, it is far more likely to be genuine. When you do authenticate, use Touch ID if it is offered, so no password is typed regardless. If the prompt keeps appearing without you initiating anything, that ambiguity is itself the answer: it is fake.

Problem: I already typed my password. What do I do in the first sixty seconds? Solution: Turn off Wi-Fi or unplug Ethernet. Stop using that Mac for anything involving credentials. Pick up your phone or another computer and change your Apple Account password, then your password manager master password. Then email, then financial accounts. If you held cryptocurrency on that Mac, move the funds from a clean device before anything else, because seed phrase exposure has no undo. The full ordered sequence is in the runbook section above; work through it rather than improvising.

Problem: I found an app in Force Quit or my Applications folder that I do not recognize. Solution: Do not open it. Search the exact name from a different device before you act, because plenty of legitimate helper apps have odd names. If it is unfamiliar and appeared around the time of the incident, quit it, move it to the Trash, empty the Trash, then check Login Items & Extensions for a matching background item and remove that too. Finding one component does not mean you found all of them, so continue with the inspection steps and consider the erase decision.

Problem: System Settings shows a configuration profile I never installed. Solution: On a personal Mac that is not managed by an employer or school, the Device Management pane usually does not exist at all. If it exists and lists an unfamiliar profile, that is a strong indicator of compromise, and profiles can redirect DNS or install certificates that let traffic be intercepted. Remove it from System Settings > General > Device Management, then check your network settings for changed DNS servers. Given what a profile can do, this finding pushes strongly toward a full erase and reinstall.

Problem: My Mac now asks for the login Keychain password constantly and nothing I type works. Solution: This can happen for entirely innocent reasons, usually when your account password and keychain password have fallen out of sync after a reset. It can also follow a security incident. If you have any reason to suspect malware, rotate your credentials from a clean device first, then troubleshoot. If you are confident it is unrelated to any incident, our guide on Mac repeatedly asking for the login Keychain password walks through resyncing or resetting the keychain safely.

FAQ

Does the real macOS crash reporter ever ask for my password?

No. When an app crashes, macOS offers to reopen it, ignore it, or send a report to Apple. Sending a crash log does not require administrator privileges, so there is no configuration in which the genuine crash reporter asks you to authenticate. A crash-report window requesting your login password is fake, without exception.

How did malware get past Gatekeeper if my Mac is up to date?

Jamf Threat Labs reported that the distributing app was signed and notarized with a valid Apple Developer ID. Notarization is an automated scan for known malicious content and signing problems, not a human security review, so a novel native binary can pass. Gatekeeper honored a valid ticket. Apple has since revoked the certificate.

If I typed my password, is only that password compromised?

No, and this is the key point. Jamf reported that CrashStealer verifies the password locally and, if correct, can unlock the login Keychain. Your keychain holds Wi-Fi passwords, app credentials, certificates, and saved logins. Treat every credential stored on that Mac as exposed, not just the one you typed.

Will erasing my Mac fix the problem on its own?

No. Erasing removes the malware from the machine but does nothing about credentials that already left it. Rotate your passwords from a clean device first, starting with your Apple Account and password manager, then erase. Also avoid restoring from a post-infection backup or migrating applications across, since that can reintroduce the problem.

Can I tell a fake prompt by how it looks?

Sometimes, not always. Try dragging it: a prompt that cannot leave another app's window is definitely fake. Check the menu bar and Force Quit to see which app is asking. But a well-built native fake can pass every visual test, which is why the reliable rule is context, not appearance. Unsummoned prompts are hostile.

Should I install antivirus on my Mac after this?

It can help, mainly for catching known malware families and as a second opinion after an incident. It is weakest against exactly this scenario, a novel signed binary whose attack is a convincing window. Good download habits, a distinct password manager master password, and two-factor authentication protect you more than any scanner does.

Conclusion

CrashStealer is a well-executed version of an old idea. Jamf Threat Labs reported a native C++ infostealer, delivered in a disk image named Werkbit Setup, that installs an app calling itself CrashReporter.app, shows a password prompt dressed as a system dialog, verifies what you type, and uses a correct password to unlock your login Keychain and reach browser credentials, password manager data, and cryptocurrency wallets. It was signed and notarized with a valid Apple Developer ID, so Gatekeeper let it through, and Apple revoked the certificate after the fact.

Strip away the specifics and what remains is a single decision point: a window asked for your password, and you decided whether to give it. That decision is not a technical one. It is a habit, and habits can be built. The one worth building is small enough to remember at 1am: if you did not do something that would require a password, do not type one. Cancel, find out which app is asking, and re-initiate the action yourself from somewhere you trust. Use Touch ID when it is offered, because a fingerprint cannot be stolen the way a typed string can.

If you are reading this after already typing your password, the situation is recoverable and the order is what matters. Disconnect the Mac. Move to a different device. Apple Account first, password manager second, email third, money fourth. Move crypto immediately from a clean device and treat the seed phrase as burned. Revoke sessions, check Login Items and configuration profiles, then erase and set up as new rather than restoring the compromised state. Work down the list rather than trying to solve everything at once.

Take fifteen minutes this week to do the preventive part while nothing is on fire: confirm two-factor authentication is on for your email and financial accounts, make sure your password manager's master password exists nowhere else, verify you have a working backup, and check that macOS is current. Then bookmark this page. The next fake prompt will look different, and the rules will be the same.