Most security incidents reach a company through the most ordinary door available. Not an alert on a dashboard, not a briefing from a threat intelligence feed, but a help desk ticket from someone in marketing who cannot open their files and is starting to sound worried.
That is the part people underestimate about tier 1 work. On the day it happens, the first responder is whoever picked up the phone, and the next ten minutes of their decisions matter more than any tool the company bought.
Recognizing it before the ransom note
The obvious version announces itself: a black desktop, red text, a file on the desktop explaining how to pay. By then nobody needs help identifying it.
The version worth recognizing is the one before that. Files that will not open. Documents renamed with an extension nobody has seen. A shared drive where the same thing is starting to happen to folders the user has not touched. Something opened this morning, usually an attachment on an invoice from a supplier who turns out not to exist, and the machine has felt busy ever since.
That last detail is the one to catch, because encryption takes time and it works outward. A user calling about their own files at nine in the morning is often calling in the middle of the process, not after it, and the shared drive is on the same list.
Containment first, and nothing before it
The instinct on a help desk is to diagnose. Every good tech has been trained to find out what is happening before they change anything, and that instinct is correct on almost every ticket and wrong on this one.
Ransomware is the case where the priority inverts. Get the machine off the network before anything else: unplug the cable, turn off wireless, disconnect it in whatever way is fastest with a nervous user on the other end of the phone. Every second it stays connected is a second more of mapped drives and file shares getting rewritten. The diagnosis will keep. The shared marketing folder will not.
That means talking a user through unplugging their own machine, calmly, while they are frightened, which is a skill more like handling an upset caller than anything technical. Short sentences, one instruction at a time, no explanation of what ransomware is until the cable is out.
Whether the machine then gets powered off depends on your organization’s plan. Responders who want memory preserved for investigation will tell you to leave it running and isolated. Others want it off. The point is that this is a decision your incident plan should already have made, and if nobody knows the answer on the day, the argument itself is a finding worth writing up afterwards.
The helpful actions that hurt
Well meant technical instincts cause real damage during the first hour, and they are worth naming because they all feel productive.
Running a full antivirus scan is the most common. It occupies the machine for twenty minutes, it does not decrypt anything, and it delays the one action that matters. Scanners are for finding what is installed, not for stopping what is running.
Rebooting is the second. It changes nothing about the encryption, and it may cost investigators anything held in memory, including material that would have identified the strain and the entry point.
Deleting the ransom note tidies the desktop and removes a piece of evidence. Restoring from backup onto a machine still connected to the network reinfects the restore. Paying, or discussing paying, is a business decision that involves legal counsel and insurance, and it is not a conversation the help desk should be having with the user.
There is one more, subtler than the rest: quietly fixing what you can and closing the ticket. Ransomware never travels alone. Something arrived, something ran, and something may still hold credentials. A ticket closed as resolved because the user’s files were restored from backup hides all of that from the people whose job it is to find it.
Documenting while it is fresh
Escalation is only as good as what goes with it. The details that vanish within the hour are exactly the ones responders need: what the user opened and when, which drives were mapped, what the note said, which shares showed the same file names, when the machine went offline, whether anyone else nearby is reporting anything similar.
Write it on the ticket while the user is still on the phone, not afterwards from memory. Incident timelines get reconstructed from help desk notes far more often than anyone expects, and the note that says “user opened an invoice attachment around 8:40, marketing share affected, isolated 9:05” is worth more to the investigation than any tool output produced later.
Knowing which tickets stop being yours is not passing the buck, it is where the tier boundary actually is, and this is the clearest example of it on the whole desk.
Practicing a call you hope never comes
There is no good way to rehearse this at work. Nobody stages a ransomware incident for training, and the first real one is a terrible classroom.
ServiceDesk Simulator runs it as a ticket: files renamed, a note on the desktop, a shared drive starting to go the same way, and a user who needs talking through unplugging a cable. Scanning gets you a scanner politely explaining it cannot help. Escalating before the machine is isolated and documented gets refused. The only path through is containment, then notes, then handover, in that order, which is exactly the muscle memory worth owning before a Tuesday morning ever needs it.