Ransomware: What to Do in the First 24 Hours

A ransomware incident response checklist for Kenyan businesses — what to do in the first hour, the two mistakes that destroy evidence, whether to pay, and your Kenya Data Protection Act notification duties.

Someone calls you on a Sunday morning. Files across the shared drive have been renamed. There is a text file on every desktop demanding payment. Your finance manager cannot open anything.

What you do in the next hour shapes what the next six months cost you — legally, operationally and financially. Most of the damage we see in incident response is not caused by the attacker. It is caused by well-intentioned people destroying the evidence they will later need, in the first thirty minutes, before anyone who has done this before was called.

Here is the sequence.

Override two instincts first

Do not power the machines off. Every instinct says pull the plug. But a running machine holds evidence in memory that vanishes on shutdown: the encryption keys sometimes, the attacker's active connections, the processes actually doing the damage, credentials in use. Forensic teams recover things from memory that exist nowhere on disk. Powering down throws that away permanently.

Instead, disconnect from the network. Unplug the network cable, disable the wireless adapter, isolate the VLAN. This stops the spread without destroying the evidence. The machine stays on, but it can no longer reach anything else.

Do not start rebuilding. The second instinct is to restore from backup immediately and get everyone working again. Understandable, and it destroys the forensic trail that establishes what was taken. That matters because what was taken determines your legal notification obligations under the Kenya Data Protection Act. Rebuild first, and you may never be able to establish whether personal data was exfiltrated — which means you cannot demonstrate to the Data Commissioner that it was not.

The first hour, in order

Isolate affected systems from the network. Do not power them off.

Identify the blast radius. Which machines are affected? Which are merely suspected? Assume more than you can see, because ransomware is typically deployed at the end of an intrusion that has been quietly underway for days or weeks.

Protect the backups immediately. Modern ransomware operators target backups first, precisely because that is what makes you pay. If your backups are connected to the network right now, disconnect them. If they are in the same cloud tenant as the encrypted systems, assume they may be compromised too.

Preserve logs before they roll over. Firewall logs, domain controller logs, VPN logs, email logs. Many systems retain these for days, not months. This is the evidence that will establish how the attacker got in and what they touched.

Assemble the people. Somebody senior must own the decision-making. Somebody must own communications. Somebody technical must own containment. It should not be the same person, and none of them should be the person who is also trying to restore services.

Call for help. Incident response is a discipline. If your team has never done this under pressure, get someone who has. Neurobyte's incident response team can engage remotely within the hour.

The 24 hours that follow

Establish how they got in, because if you do not, they will use the same route again after you have rebuilt. In our experience the common initial access routes are an exposed remote desktop service, an unpatched VPN appliance, a phishing email that harvested credentials with no multi-factor authentication behind them, and a compromised third party with access to your network.

Establish what was taken. This is the question that determines your legal position. Modern ransomware operators exfiltrate data before they encrypt it, so that they can extort you a second time by threatening publication. That means a ransomware incident is very often also a personal data breach, whether or not you pay.

Determine your notification obligations. Under the Kenya Data Protection Act, notification to the Data Commissioner is required without undue delay where a breach poses a real risk to the rights and freedoms of data subjects, and affected individuals must be told where that risk is high. The clock runs from when you become aware of the breach, not from when your investigation concludes. This is why destroying the forensic trail is so expensive: you cannot argue that personal data was unaffected if you have made it impossible to know.

Should you pay?

We do not advise paying, and this is not a moral position — it is an operational one.

Paying does not resolve the breach. The attacker retains the data they exfiltrated. Organisations that pay are demonstrably more likely to be targeted again, sometimes by the same group, sometimes by another who learned they pay. Decryption tools supplied by attackers are frequently slow, incomplete, and corrupt some files outright. And restoring from a decryptor is often slower than restoring from a backup you should have had.

There are situations where an organisation genuinely has no viable alternative, and if you are in that position, take specialist advice before making contact rather than after. There are also legal considerations around sanctioned entities that are not obvious from the ransom note.

The decision should never be made in the first hour, by an exhausted person, alone.

What actually prevents this

Nothing in the response is as valuable as the things you do beforehand, and they are dull.

Multi-factor authentication everywhere, especially on remote access and email. It is usually free and it defeats the overwhelming majority of credential-based intrusions.

Offline or immutable backups, tested by actually restoring from them. An untested backup is a hypothesis, not a control.

Endpoint detection and response with someone watching it. Ransomware is deployed at 2am on a Sunday specifically because nobody is looking. Detection without response is a notification you read on Monday.

Patch the things facing the internet, quickly. The exposed VPN appliance with a known vulnerability is not a theoretical risk; it is how a large share of intrusions begin.

If you would like to know how your organisation would actually fare, our incident response simulator lets your team work a ransomware incident across the NIST lifecycle without the consequences. It is free, and it is a considerably cheaper way to discover the gaps in your plan.

Frequently asked questions

Should we pay the ransom?

We advise against it. Paying does not undo the breach — the attacker keeps any data they exfiltrated before encrypting, and organisations that pay are more likely to be targeted again. Supplied decryption tools are often slow, incomplete or corrupt files. Where an organisation genuinely has no alternative, take specialist advice before making any contact, including on the legal implications of paying entities that may be sanctioned. The decision should never be made in the first hour by one exhausted person.

Should we shut down the infected computers immediately?

No. Disconnect them from the network, but leave them running. Shutting down destroys memory-resident evidence — sometimes including encryption keys, and almost always the attacker's active processes and connections. Disconnecting from the network stops the spread while preserving what forensics needs. This single decision, made in the first ten minutes, frequently determines whether you can establish what was taken.

Is a ransomware attack a reportable data breach in Kenya?

Very often, yes. Modern ransomware groups exfiltrate data before encrypting it, so the incident is usually also a personal data breach. Under the Kenya Data Protection Act you must notify the Data Commissioner without undue delay where the breach poses a real risk to data subjects' rights and freedoms, and notify affected individuals where that risk is high. Because the obligation turns on what was actually taken, preserving forensic evidence is a legal necessity, not just good practice.

How did the attackers get in?

In most incidents we investigate, through one of four routes: an exposed remote desktop or management service, an unpatched internet-facing VPN or firewall appliance, phishing that harvested credentials not protected by multi-factor authentication, or a compromised supplier with access to your network. Establishing the specific route is essential, because rebuilding without closing it simply invites the same intrusion again — frequently within weeks.

How long does recovery take?

It depends far more on your backups than on the attacker. Organisations with tested, offline or immutable backups and a documented recovery plan often restore core operations within days. Organisations discovering that their backups were connected to the network, and therefore encrypted too, can take weeks or months, and some never fully recover their data. The variable you control is entirely in the preparation.