Ransomware attack: what to do in the first hours

Your accountant logs in first thing in the morning and the accounting database is gone. In its place: files with an extension nobody recognizes and a text note asking for money. That is what a ransomware attack looks like at a 10 to 200-person company with no security team and no written plan for this exact day.

The short version, if you're reading this mid-incident: pull the infected machines off the network, but leave them powered on. Disconnect anything that holds your backups. Call whoever will handle the response from a mobile phone, not over company email. Don't reinstall anything and don't pay anything in the first hour. The details follow, in order.

The first 15 minutes: cut the network, not the power

Ransomware lands on one machine and spreads from there to shared folders and neighboring servers. Every minute the infected computer stays connected, more files on the shared drive get encrypted. So the first move is low-tech: unplug the network cable and turn off Wi-Fi. Not sure which machines are hit? Switch off the whole network switch or the internet uplink. An hour of the office being offline costs less than an encrypted file server.

Leave the power on, with one exception. A running computer holds processes, network connections and sometimes encryption keys in memory, and whoever investigates will want all of it. But if you can see a data server being encrypted right now and you can't isolate it, shut it down. The data matters more than the evidence.

Where are your backups right now?

Everything else depends on this answer. Attackers go looking for backups on purpose, and a copy sitting on a network share or on the same server usually goes down with the data. Got an external drive with a backup on it? Don't plug it into any machine on this network until you know the infection is gone. One connection, and your last clean copy is encrypted too.

If your backups lived in immutable storage (where a copy can't be overwritten or deleted until its retention period ends) or offsite with no standing network access, you're in good shape. Ransomware recovery for a small business in that position is a technical job. Nobody has to negotiate with anyone.

The first hour: one decision-maker, and talk off the network

Pick one person who makes the calls. The director, the IT lead or your outside provider, it doesn't matter which, as long as it's one person. When five people are rebooting servers, "trying to restore" and phoning a friend who knows computers, evidence gets wiped and the infection sometimes spreads further.

Assume company email and anything tied to your domain is compromised until proven otherwise. If the attacker has been inside for a few days, they may well be reading your emails about how you're fighting them. Switch to mobile phones. Keep the list of numbers (IT provider, director, chief accountant, bank, lawyer) on paper. A contacts file on an encrypted server won't do you much good.

The bank gets its own call. If online banking software or e-signature keys were on the infected machines, treat them as stolen and ask the bank to hold outgoing payments until things are clear.

Write it down while it's fresh

Keeping an incident log feels like paperwork, and later everyone asks for it: the investigators, your lawyer, the regulator, and you at the post-mortem. Note the time of every event and every action. Who noticed first, what the file extension is, what the ransom note is called, which machines were unplugged and when. Photograph the note with your phone and don't delete it. The note and the extension let specialists identify the ransomware family, and for some older families free decryptors exist through the No More Ransom project.

What not to do

• Don't reinstall everything right away. A fresh copy of Windows gets people back to work, but it wipes the traces that show how the attacker got in. If you never find the way in, expect them back through the same door.
• Don't run "decryptors" from forums. Some are malware themselves. Others damage files so badly that even the right key won't open them.
• Don't restore backups onto the same network until the entry point is closed and passwords are changed. Whatever you restore will just get encrypted again.
• Don't write to the attackers yourself. Your first message tells them you've read the note and you're in a hurry.
• Don't hunt for someone to blame in front of the team. The person who opened a strange attachment yesterday needs to feel safe saying so today. That one admission can save hours.

Change passwords from a clean machine

Inside a company network, ransomware almost always runs under a real user account, often an admin one. So once things are isolated, you change the passwords for domain admins, VPN, remote access, the backup server, email and cloud services. Doing it from an infected machine is pointless: the new password goes wherever the old one went. Use a computer you know is clean, ideally one that isn't on the affected network. Wherever MFA isn't on yet, turn it on now, starting with email, VPN and backups.

Pay the ransom or not?

Our advice is don't pay, and morality has little to do with it. Paying guarantees nothing. The decryptor may never arrive, may take days to run, or may break some of your files. If the data was copied out, the attackers keep it either way. A company that paid once becomes known as a company that pays. There's legal exposure too: if the group is under sanctions, sending it money can itself be a sanctions violation.

The owner still makes the call. Just make it once you know the state of your backups, not in the first hour. If you have a clean copy, the question usually answers itself.

Personal data and the CNPDCP

The encrypted servers almost certainly held personal data about customers or employees. Accounting always has it. Some current ransomware strains copy the data out first and encrypt it afterwards, so "they encrypted it but didn't take it" is something you have to prove, not assume.

Under Moldova's Law No. 195/2024 on personal data protection, just as under GDPR, a breach has to be reported to the CNPDCP within 72 hours of you becoming aware of it. If you don't have the full picture yet, you file with what you know and add details later. Bring in a lawyer on day one, not day three.

How it went for one of our clients

A bakery and confectionery plant in Moldova came to us in the middle of the crisis. The entry point turned up fairly quickly: a phishing email to a corporate mailbox. Workstations and part of the Windows servers were encrypted, operations had stopped, and several departments were down.

The accounting system survived. UNA ran on Oracle under Linux in a separate network segment, and the ransomware, which was spreading through the Windows segment, never reached it. That wasn't luck. It was how the architecture had been designed, and on that day it paid off.

From there the work followed the same steps described above. Infected workstations were cleaned, and some were reinstalled from gold images. Encrypted data was recovered from the existing backups as far as possible. We took inventory of which accounts were compromised, which passwords had to be rotated and which services needed reconfiguring. Then we closed the way in: a rebuilt network split into VLANs with a FortiGate at the perimeter, XDR on every workstation and server, and a new mail server with sandboxed attachment checks and SPF/DKIM/DMARC. The full story is in the case study.

What to do before an attack

At a prepared company, recovery follows a plan. At an unprepared one it turns into a search for whatever can still be saved. Getting prepared takes less than people expect:

• Backups on the 3-2-1 rule: three copies, on two different types of media, one of them offsite. At least one copy immutable or with no standing network access.
• Scheduled test restores. Until you've restored from a backup at least once, you don't really know you have one.
• MFA on email, VPN and above all on the backup server.
• A segmented network: accounting, production, servers and guest Wi-Fi kept apart. The case above shows why.
• A one-page plan on paper: who decides, who to call, where the copies are and how to check them.

This is the work we do. Our backup and disaster recovery service runs on Veeam and Proxmox Backup Server, with immutable storage, offsite copies and a monthly test restore of critical systems with a written report. Information security covers FortiGate, EDR on endpoints, MFA and incident response with a report and recommendations.

If everything is already encrypted, isolate the machines as described in the first section and call or message us. If things are still running, let's check whether your backups would survive an attack like this. The first meeting takes 30 minutes and commits you to nothing.