The First 24 Hours After a Ransomware Attack: What to Do and What Not to Do

An employee arrives in the morning and notices that their file extensions have changed and there is a text file on the desktop titled "your data has been encrypted". Within minutes the accounting software will not open and the folders on the file server cannot be read. Every manager hopes never to live through this moment, but every manager should be ready for it.

Much has been written about preventing ransomware, including why immutable backups are the last line of defence. This article is about response rather than prevention: once the attack has happened, what should you do in the first 24 hours, and what should you absolutely avoid?

The steps below are a general framework. Every incident is different, and in a serious attack working with an experienced incident response team is always the right call.

The First Hour: Manage the Panic, Stop the Spread

Ransomware rarely stays on one computer. It tries to spread to network shares, servers and any backups it can reach. Your first goal is to stop the damage from growing.

Disconnect affected devices from the network

Unplug the network cable and turn off Wi-Fi on computers and servers showing signs of encryption. For virtual servers, disconnecting the virtual network adapter or isolating the relevant VLAN on the firewall does the same job. If necessary, temporarily cut internet access and the VPN tunnels between branches.

Do not power devices off blindly

The first instinct is usually to shut the computer down. But information held in memory, such as running processes, open connections and sometimes encryption keys, is lost when a device powers off. That information is valuable for understanding how the attack happened and, in some cases, for recovering data. Disconnecting from the network is usually enough to stop the spread. Make the shutdown decision together with an incident response specialist if you can.

Appoint an incident lead

When everyone is trying something, evidence gets destroyed and decisions collide. Appoint a single coordinator. The technical team, management, legal and communications should all work through this person. Assume the attackers may also have access to email, and use the phone or a separate messaging channel to communicate.

Preserve the Evidence

The pressure to bring systems back quickly is enormous. But wiping evidence as you go may mean you never learn how the attacker got in. A restore performed without closing the entry point can lead to the same attack repeating within days.

• Photograph the ransom note and any on-screen messages.
• Export firewall, VPN, email and server logs; some devices rotate logs quickly.
• Take a snapshot or copy of affected virtual servers before anything is deleted.
• Do not overwrite or format encrypted disks.
• Keep an incident timeline: who noticed what and when, and when each step was taken.

These records are needed for technical analysis and for later official notifications and insurance claims.

Determine the Scope

You cannot build a recovery plan without knowing which systems are affected. In the first few hours, look for answers to these questions:

• Which servers, computers and shares have been encrypted?
• Are the domain controller and identity systems affected?
• Are the backup server and backup repositories reachable and intact?
• Could data have been exfiltrated? Has there been unusually high outbound traffic in recent days?
• Where might the attack have started: a phishing email, an exposed remote desktop port, an unpatched VPN appliance?

Many ransomware groups today copy data before encrypting it and then use double extortion: "pay, or we publish". So the scoping exercise must cover not only "what was encrypted" but also "what might have been stolen".

Do Not Pay the Ransom on Reflex

Attackers use countdown timers and rising ransom amounts to build pressure. Under that pressure, paying can look tempting. But a few facts are worth knowing:

• Paying does not guarantee a working decryptor. The tools provided can be slow, buggy or incomplete.
• Paying does not mean stolen data will be deleted.
• Organisations that pay can become repeat targets.
• Payment has legal and tax implications, so the decision must be assessed with legal counsel.

If you have intact, reachable backups, the question of payment often never comes up. So before any payment discussion, establish the state of your backups.

Verify Backup Integrity

Backups are the heart of recovery. Attackers know this and try to delete or corrupt backups before encrypting. Before you start restoring, check the following:

• Are the backups untouched? Copies kept in immutable repositories or in S3 buckets protected by object lock cannot be deleted even if an administrator password is compromised. These copies are usually the most reliable starting point.
• Which backup date is clean? Attackers may have been inside for days or even weeks before encrypting. The latest backup may contain malware too. Open and scan the backup in an isolated environment.
• Is the backup server safe? If the backup server is domain-joined and has been compromised, it is safer to restore from a freshly built backup server.

Keeping one copy of your backups independent of the main network, in a different location and in immutable form, makes a huge difference at this point. This is the essence of the 3-2-1 backup rule.

Plan the Restore Order

Trying to restore everything at once chokes both the network and the team. A predefined priority order speeds up recovery. A typical order looks like this:

1. Infrastructure and identity: a clean network segment, firewall rules, domain controller and DNS.
2. Business-critical applications: ERP, accounting, sales and order systems, databases.
3. Communication: email and internal messaging tools.
4. File shares: active projects and recent folders first, then archives.
5. User computers: ideally reinstalled from a clean image.

Do not connect restored systems straight back to the old network. Validate them in an isolated environment, apply security patches and only then move them into production. Defining in advance how quickly each system must be back, your RTO, and how much data loss is acceptable, your RPO, makes these decisions much easier under pressure.

Reset Credentials

Most ransomware attacks progress through compromised user accounts. Restoring systems is not enough; you also need to invalidate the keys the attacker holds.

• Change the passwords of all administrator and service accounts.
• If you use Active Directory, reset the Kerberos account (krbtgt) password in a controlled way with expert support.
• Enforce multi-factor authentication on VPN, remote access, cloud portals and email.
• Look for new user accounts and scheduled tasks that may have been created during the attack.
• Do not forget the management passwords of infrastructure such as firewalls and the virtualisation platform.

Do Not Skip Notification Duties

A ransomware attack is often also a personal data breach. If the encrypted or exfiltrated systems hold customer, employee or supplier data, obligations arise under KVKK, Turkey's personal data protection law.

As a general rule, the data controller must notify the Personal Data Protection Board without delay and at the latest within 72 hours of becoming aware of the breach. Affected individuals must also be informed within a reasonable time. We recommend working with your legal counsel on the content and timing of the notification.

Also consider the following:

• If you have a cyber insurance policy, inform the insurer early; many policies set specific deadlines and procedures.
• Contact law enforcement to file a criminal complaint.
• Prepare a clear statement for customers and partners based on verified facts.

What to Avoid: A Short List

• Formatting encrypted disks or restoring over them.
• Running random "decryptor" tools found online on production systems.
• Reconnecting systems to the internet before the entry point is found.
• Letting unauthorised people contact the attackers.
• Discussing the incident over email accounts that may be compromised.
• Moving forward without recording what happened.

Afterwards: Lessons Learned

The job is not over when systems are back up. Within a few weeks, hold a review meeting with the whole team. Where did the attacker get in, why was it not detected, which steps worked and which wasted time? The answers should turn into concrete actions: patch processes, multi-factor authentication, network segmentation, immutable backups and regular restore tests.

Adapting the steps in this article to your own environment and turning them into a written incident response plan, before the next incident, will save hours when a real attack hits.

Frequently Asked Questions

Should I shut down an infected computer immediately?

Usually not. Disconnect it from the network first. Shutting down can destroy valuable evidence in memory. Make the shutdown decision with an incident response specialist if possible.

Is restoring the latest backup enough?

Not always. Attackers may have been inside for days and the latest backup may contain malware. Validate the backup in an isolated environment and, if needed, choose an older clean one.

Is KVKK notification required for every ransomware incident?

If the affected systems contain personal data and its confidentiality, integrity or availability was affected, a notification duty very likely arises. Assess the situation with legal counsel and do not miss the 72-hour window.

Can ransomware affect cloud backups?

If an attacker takes over the backup software's administrator account, ordinary cloud backups can be deleted too. Copies marked as immutable, however, cannot be deleted or changed for the defined retention period.

Be Ready to Recover with CloudRUX

Anyone can buy infrastructure; the difference in a crisis is having a Turkish-speaking engineer on the other end who actually runs the systems. CloudRUX keeps your backups in data centres in Turkey, with immutable copies and fixed monthly billing. Explore our Backup as a Service (BaaS) and S3 object storage options, or get in touch to review your backup and recovery plan together.