Ransomware: what to do in the first hours, and why file names can lie

When ransomware hits, the first decisions often set how much can be recovered.

We have recovered data for four organisations after ransomware. One came to us four months after the attack, with its ERP system still down after several repair attempts. This is what that work taught us. Read the case study.

In the first hour

• Disconnect. Take the affected machines off the network, both cable and Wi-Fi, so it stops spreading. Do not wipe or reinstall anything.
• Do not attempt repairs on the originals. Every repair attempt writes to the disks. Copy first, then work on the copies.
• Check your backups before trusting them. In the case above the 1.09 TB backup disk had been encrypted along with everything else, because it was reachable from the same network.
• Write down what you see: the ransom note, the new file extensions, the times, and which machines are affected. It saves whoever recovers the data a lot of time.

Why file names can lie

Most people judge the damage by file names: files with a strange new extension are encrypted, the rest are fine. In that recovery some files kept their normal names while their contents had been replaced. A database file with its usual name was fully encrypted.

So we checked every file by its first bytes, not its name. A healthy SQL Server file starts with a known signature; the encrypted ones started with the attacker's marker. That check told a 23 GB database that looked fine, but was not, apart from a 15.4 GB copy that really was clean. Rebuilding on the wrong one would have cost days.

Rebuilding

• Rebuild on clean, isolated machines, never on the infected ones.
• Keep the originals read-only and record a checksum for everything you copy, so you can show later exactly what came from where.
• Check the business data, not just that the system starts. We counted records against the day of the attack: 268,921 ledger vouchers, 432 customers and 1,902 items. Then we created a test customer and a test item through the application, to show the system was usable and not only readable.
• Know where to stop. When recovering means changing the business data itself, that is a decision for the business, not the engineer.

Before it happens

• Keep at least one backup offline or unchangeable, where a stolen administrator account cannot reach it.
• Restore a backup on a schedule. A backup nobody has restored is only a hope.
• Use separate accounts for backups, and two-factor login for every administrator account.
• Update the systems that face the internet first: VPNs, remote desktop and email.

Dealing with encrypted files right now? Contact us or message us on WhatsApp. The earlier we see it, the more options there are.