The Mac Login Box That Won't Close Is Stealing Your Session.

The Mac login box that won't close is hijacking your logged-in sessions.

You did everything you were told to do. You turned on multi-factor authentication. You use a password manager. And an attacker still walked straight into your account — without your password, and without your second factor. Here is the uncomfortable truth behind that scenario, and why it is showing up in real incidents at small firms.

The real thing you should know about

The anchor is straightforward: a macOS stealer can grab your live session cookies by way of a password dialog that refuses to close, and use those cookies to slip past MFA by hijacking a session you have already logged into. This is the AMOS family of AppleScript infostealers — the same lineage behind the fake-prompt Mac attacks — turned toward a sharper goal: stealing the proof that you are already signed in.

A quick, plain explanation of why that matters. When you log into your email or a cloud app and clear MFA, the service hands your browser a small token — a session cookie — that says "this person already proved who they are." For convenience, that token keeps you logged in so you are not re-entering codes all day. An attacker who copies that live token can paste it into their own browser and the service treats them as you, already authenticated. They never see your password and never trigger your MFA prompt, because from the service's point of view, the login already happened.

The macOS version of this attack uses a nasty bit of theater. A password dialog appears and will not go away — you cannot dismiss it, it keeps coming back, it nags until you give in. People eventually type their password just to make it stop. That unlocks what the malware needs, and while it is at it, the stealer scoops up the active session cookies sitting on the machine. We are not detailing the mechanics beyond that, because the point here is awareness, not a recipe. This often pairs with "adversary-in-the-middle" phishing, where a fake login page relays your real login and harvests the session in transit — two roads to the same destination: your live, already-authenticated session in someone else's hands.

Why a small firm should actually care

For years the advice has been "just turn on MFA," and that advice is still good — MFA stops a huge share of attacks. But it has quietly created a false sense of total safety. MFA verifies the moment you log in. It does nothing about what happens to the session after that moment. If an attacker steals the already-logged-in session, the MFA you are so proud of never even gets a chance to fire.

For a small business, this reframes the whole risk. You can have every box checked — strong passwords, MFA on everything — and still get taken if a single Mac in the office runs a stealer and gives up its session tokens. The accounts most worth hijacking are exactly the ones a small firm leans on: the email that everything else resets through, the cloud storage with client files, the accounting or practice-management system. For a healthcare or dental office, a hijacked session into a system holding patient data is not just an IT problem; it is a potential reportable breach, with all the cost and disclosure that follows.

And because the attacker rides in on a valid session, the intrusion can look completely normal. There is no failed-login alarm, no MFA denial, no obvious red flag — just "you," doing things, from somewhere you have never been. That is what makes stolen-session attacks so dangerous for firms that assume MFA is the finish line.

What protection actually looks like

The fix is to stop treating login as a single yes/no gate and start watching the session itself. That is the job of ITDR — identity threat detection and response — paired with session monitoring.

In plain terms, this layer pays attention to what a logged-in account actually does, not just whether it logged in. It looks for the tells of a hijacked session: the same account suddenly active from a new country, two locations at once, a token showing up on a device or network that has never been seen before, or a sign-in that skipped the normal MFA step because it reused an existing session. When something looks like a borrowed identity rather than the real person, it can flag it, force a fresh login, or kill the session before much harm is done. This is the protection MFA alone cannot provide, because MFA's job ends the instant you are let in.

Underneath that, the basics still earn their place. Real endpoint detection on every Mac can catch the stealer before it ever harvests a cookie. And a simple human rule helps too: a password box that will not close is not normal — that persistence is a warning sign, not a glitch, and the right move is to stop, not to give in and type your password to make it go away.

The bottom line

MFA is necessary, but it is not the whole story. Attackers adapted, and the new prize is your live session — the proof that you already logged in. A Mac login box that refuses to close can be the moment that proof gets stolen, handing someone access that sails right past your second factor.

That is the gap we close for the firms we protect: ITDR and session monitoring that watch the logged-in account, not just the front door, so a stolen token gets caught instead of cashed in. If your security plan stops at "we have MFA," there is a real blind spot worth closing — and doing it is enterprise-grade protection made simple. Let's talk about what that looks like for your business.