«5:42 p.m.» The Loud Attack

It’s Friday, 5:42 p.m., and the IT manager has already half-closed her laptop. The parking lot outside is emptying out; the early shift has long since gone home, and the late shift is now on the job. Then comes the first alert: The ERP server isn’t responding. She opens her laptop again. Just routine, she thinks—a service that’s frozen. By 5:51 p.m., the ERP system is down. By 5:55 p.m., the file server is down. At 5:58 p.m., a ransom demand with a payment deadline is discovered.

She does what any good IT manager would do: she opens the backup console. And at that moment, a bad evening turns into a nightmare: the backups from the past few weeks are also encrypted. The backups were on the same network. It had always been planned to change this, but it had never been urgent.
Five minutes later, the CEO is sitting in the conference room, his mind still half on the previous client meeting. Parts have to be shipped to a client on Monday; there’s a contractual penalty for late delivery. His questions come quickly and are all legitimate: Who decides now what goes offline? Do we call the police? The insurance company? Who first? And—he lowers his voice—do we pay? No one in the room has a prepared answer to any of these questions. There’s an emergency folder, somewhere. It was created four years ago and hasn’t been touched since.

At 6:20 p.m., the IT director makes the most important decision of the evening. A colleague had given her a phone number a year ago, saying, “Save it, hopefully you’ll never need it.” She dials +41 62 288 14 14. The call lasts twelve minutes and consists of five questions: What happened? Who is affected? Since when? Where? What steps have already been taken? This is followed by a brief scoping call: the scope, criticality, and initial emergency measures are determined jointly.
 
At 6:47 p.m., the CSIRT begins assisting with the investigation of the incident, and the first recommendation surprises everyone in the room: Don’t reinstall anything. Don’t delete anything. Not even the ransom note.

Because two things matter right now, and they’re in conflict with each other: containment (isolating network segments, blocking compromised accounts, stopping the spread) and securing evidence. Anyone who destroys the evidence in a panic will never find out how the attacker got in. And if you don’t know that, the risk that the attacker will break in again increases. By midnight, the environment has been isolated and initial findings are available. At 11:40 p.m., the CEO asks the question again: “Should we pay?” The incident responder’s answer: “We strongly recommend not paying. However, only you can and are allowed to make that decision. And it’s too early for that decision anyway: First, we need to know what the attacker actually has and whether they’re still here.”

Whether the attacker is still active becomes clear during the night leading into Sunday. While operations are on hold, the forensics team sifts through the logs: logins, process chains, timestamps. At 3:17 a.m., the point of entry is identified: an email containing malware, sent three days before the encryption, disguised as a job application, and opened in the HR department. No one is to blame, the email was well crafted. The attacker was on the network for two to three days: he collected login credentials, gained administrator privileges, scouted the network, disabled the antivirus software, and calmly prepared the encryption, including the backups. And then came the discovery that turned the night around: a second, still-active backdoor. The attacker had taken precautions in case they were kicked out. If the company had simply “reinstalled everything” on Saturday, the backdoor would have remained, and everything would have started all over again.

The rest is technical work, and technical work is unspectacular: removing backdoors, resetting passwords in the correct order, then performing a phased recovery from the one backup the attacker couldn’t access, the monthly offsite copy stored outside the network.

A list now hangs in the conference room: first, identities and directory services; then ERP and production control; then the rest. Every system is checked before it goes back online. Security comes before speed. At the same time, a second front is active—one not found in any IT manual: The customer isn’t fobbed off, but is kept informed with facts and a realistic timeline. The response is understanding. Incidents happen; what matters is how you handle them.

On Wednesday morning at 6:00 a.m., the early shift starts up the machines. A five-day outage, no ransom paid, damage that stings, but a managed process rather than chaos. A week later, the final report is on the CEO’s desk. On the last page is the sentence that hurts him more than the contractual penalty: The attack was visible for several days. The suspicious logins at odd hours, the new administrator accounts, the disabled antivirus protection, it was all there in the logs. It’s just that no one looked. At 3:00 a.m., in a company with 180 employees, no one checks the login logs. This kind of negligence is often a reality, which is precisely why the company now has 24/7 monitoring by a SOC provider, a retainer agreement with defined response times, well-rehearsed playbooks, and offline backups. The emergency number is now laminated and hanging in the conference room.