How one fake browser update turned into three incidents, and what it takes to shut each one down
It’s 4:47 on a Friday afternoon when an alert fires in Microsoft Defender. Dana, the office manager at a 40-person dental practice, ran what she thought was a browser update, and the program has been reaching into the passwords her browser saved. Someone on the IT side opens the alert, clicks Isolate device, and a minute later Dana’s computer is cut off from the rest of the network. Everyone breathes a little easier.
The program Dana unknowingly ran was an infostealer, a type of malware built to collect saved passwords and active logins from a computer and send them to an attacker. It usually finishes in seconds and has no reason to stick around, so by the time an alert reaches a person, whatever got collected is already gone.
That’s the trouble with treating isolation as the final response step. Cutting the computer off stops it from doing more harm, but it can’t recall the logins that already left. An infostealer response starts with that click, and it isn’t finished until every stolen login has been found and shut off.
Dana and her practice are fictional. I’ve spent the last few weeks building them into a lab for a session I’m presenting at Galactic’s Incident Response Seminar, and the “update” she ran is a harmless stand-in that mimics a real infostealer without stealing anything.
What follows is the response from that first click to the moment Dana gets her computer back.
What Dana’s Computer Was Holding
Dana’s browser had saved her passwords for payroll, the imaging vendor’s portal, and the bank. She was also signed in to Outlook and Teams, and those sign-ins are kept alive by tokens, small digital passes that let a website remember you’re already logged in. Whoever steals a token can step into Dana’s session without her password and without the code or phone prompt that MFA usually adds.
The demo draws on Galactic’s IR Playbook Binder, a set of step-by-step guides for handling specific kinds of incidents, from malware to account compromise to business email compromise. Following that approach, the response treats the alert as a breach of every account the computer could reach. That’s also why the first phone call to Dana comes with an instruction that surprises people: leave the computer on, stop using your accounts, and don’t change any passwords yet. A new password typed on the infected computer could be stolen the same way the old one was, and changing a password doesn’t sign out an attacker who’s already holding her tokens.
Making a List of Everything That Was Exposed
With the computer contained, the next job is a list. Call it a credential exposure inventory. It’s simpler than the name suggests. Each saved password and each signed-in account on Dana’s computer gets its own line, marked as presumed stolen until someone deals with it.
The list shows how far the damage could spread, and it doubles as the to-do list for the rest of the response, since containment isn’t finished until each line has been handled. It also gives the technical staff and the business owners the same thing to look at.
How One Alert Turns Into Three Incidents
The list rarely stays the same size for long, because an incident keeps moving while you work it. In the demo, the email trace shows the same fake update reached six other people at the practice, and one of them ran it too. That opens a second case with its own computer and its own Credential Exposure Inventory.
Then Dana’s sign-in history shows something more serious. Hours after the theft, someone logged in as Dana from another country and created an inbox rule, an automatic filter that forwards any message mentioning “invoice” or “payment” to an outside address. Her computer had been isolated the whole time, and it didn’t matter, because the stolen logins opened her mailbox from anywhere. A malware alert has now become an account takeover and the start of business email compromise, a scam where attackers use a real mailbox to redirect payments. The response has to cover all three.
Shutting Off the Stolen Logins in the Right Order
Containing an infostealer comes down to shutting off what was stolen, in a particular order. The work happens from a separate, clean computer used only for admin work, so nothing typed during the cleanup can be captured.
The first step is revoking Dana’s sessions, which signs her out everywhere and makes the stolen tokens useless. That has to happen before or alongside the password reset, because a stolen session keeps working after a password change. After that, the team sets a new password, removes any MFA method nobody recognizes, and deletes the forwarding rule. Then they change the vendor and portal passwords on the list and block the server the infostealer was sending data to. The last check is Dana’s sign-in history, to confirm nobody has used the old logins since.
One scenario in the session tests that order. Halfway through, someone mentions that a helpful coworker reset Dana’s password an hour earlier, from Dana’s own computer, to get her back to work. It has to be done again from the clean computer, because the new password may have been captured as well.
Proving the Computer Is Clean Before It Goes Back
While the accounts are locked down, someone else preserves the evidence. The infostealer file gets pulled from quarantine and logged, which only works if the security software keeps those files instead of deleting them. That log starts before any cleanup, so nothing important gets erased by accident.
By default, Dana’s computer is wiped and reinstalled, and it goes back to her only after a formal sign-off, sometimes called an endpoint clearance. She sets up MFA again from a clean device with a phishing-resistant method, such as a security key or passkey that a fake website can’t trick. Three checks have to pass before the person leading the response signs off personally: a clean scan, a fresh login required on old sessions, and the infostealer’s server blocked.
The written record includes a timeline, and in this scenario it shows the fake update reached seven inboxes 20 minutes before anyone clicked. That becomes the first question for the review afterward: what could have caught it in those 20 minutes?
Where Dana’s Response Could Have Gone Wrong
Each step in Dana’s response had a shortcut that would have felt reasonable in the moment and made things worse. The coworker who reset her password from the infected computer took one of them, and the others tend to start the same way, with someone trying to help. These are the six to watch for.
-
Treating the quarantine as the finish line. Isolating the computer starts the investigation, and the stolen logins are still out there.
-
Letting the user reset their password from the infected computer. The new password can be stolen the same way the old one was.
-
Resetting the password without revoking sessions. The stolen tokens keep working until those sessions are shut off.
-
Rebooting or powering off the computer to “fix” it. That erases evidence that only existed in its memory, and the stolen logins stay active either way.
-
Coordinating the response over the same email and chat accounts that were stolen. Move the conversation to a phone call or a separate channel the attacker can’t see.
-
Giving the computer back without a formal clearance. Without a signed clearance, there’s no record that anyone confirmed it’s clean.
Each of these is easier to avoid when the response stays organized around the list of what was exposed, because that list keeps everyone focused on what the attacker already has. It also brings the response back to where it started, with the click that isolated Dana’s computer.
The Question to Ask on Friday at 4:47
Isolating the computer is the right first move, and it means someone saw the alert and acted on it. It tells you the machine can’t do more harm, but the bigger questions are still open: what left, who has it, and where they’re using it.
So after you click isolate, the next step is asking what that computer held and starting the list.
I’ll work through the whole response live, from the first Defender alert to the signed clearance, at Galactic’s Incident Response Seminar on November 11. It’s a free, virtual event, and every attendee gets the full 2000+ page Galactic IR Playbook Binder, including the playbooks this demo draws on. Register here.
