
When ransomware strikes, common advice like “just restore from backup” is dangerously simplistic and often leads to reinfection.
- Attackers now systematically target and encrypt backup repositories before launching the main attack.
- Paying the ransom offers no guarantee; a significant percentage of victims who pay never fully recover their data.
Recommendation: Isolate infected systems BUT DO NOT power them down. Your first priority is evidence preservation to enable a true, clean recovery.
The screen displays a message that makes your blood run cold. A timer is counting down. Your files are inaccessible, appended with a strange extension. You are the victim of a ransomware attack. In this moment of pure panic, every decision you make is critical. The impulse is to act—to pull plugs, to call your IT provider in a frenzy, maybe even to consider paying the criminals. This is where most businesses make their first, and often most catastrophic, mistake.
The standard advice you find online—isolate systems, don’t pay the ransom, restore from backups—is not wrong, but it’s dangerously incomplete. It misses the nuances that separate a managed incident from a total business-ending disaster. What if your backups are also encrypted? What if paying the ransom doesn’t get you a key? What if, in your haste to restore, you re-introduce the same malware back into your network?
This is not another generic checklist. As a crisis incident responder, my role is to guide you through the first hour of an attack with a focus on what truly matters: evidence preservation and strategic containment. The goal is not just to get your data back, but to ensure you do so without compounding the damage. We will move beyond the platitudes and into the professional-grade actions that lay the groundwork for a successful recovery, not just a temporary fix.
This guide will walk you through the precise, ordered steps of a professional incident response. We will cover how to trace the attack’s origin without destroying evidence, the grim reality of ransom payments, why your backups are at risk, and the critical sanitisation process required before any restoration attempt. By understanding the attacker’s playbook, you can effectively counter it.
Contents: Responding to a Ransomware Attack
- Did It Come From an Email or a USB Stick? Tracing the Patient Zero
- To Pay or Not to Pay: Why 40% of Payers Never Get Their Data Back?
- Why Your Cloud Backups Might Be Encrypted Too?
- The Remote Desktop Port That Hackers Scan for 24/7
- How to Sanitise Systems Before Restoring From Clean Backups?
- Why Your “Plan B” Must Include a Paper List of Emergency Contacts?
- The .gitignore Mistake That Leaks Your API Keys to the Public
- Implementing Robust Cybersecurity Protocols for UK SMEs Without a Dedicated IT Team?
Did It Come From an Email or a USB Stick? Tracing the Patient Zero
Your first question should not be “How do we fix this?” but “How did this happen?” Identifying the initial point of entry, or “Patient Zero,” is not an academic exercise; it is the most critical first step in containment. Without knowing the entry vector, you cannot be certain you have plugged the hole, and any recovery effort is simply resetting the stage for a repeat attack. The most common culprit remains the inbox, as 30-40% of ransomware breaches originate from phishing emails, where a user clicks a malicious link or opens a compromised attachment.
However, the immediate priority is not remediation but evidence preservation. Your computer systems, particularly the memory (RAM) of infected devices, contain volatile evidence that is crucial for forensic analysis. Powering down a machine will wipe this data forever. Your actions in the first 30 minutes will determine if a proper investigation is even possible. Do not delete files, do not run antivirus scans randomly, and do not power anything off until you have a clear plan. The goal is to freeze the crime scene, not to clean it up.
Action Plan: Forensic Standstill Protocol
- Immediately isolate impacted systems from the network (unplug the Ethernet cable) but do not power them down to preserve crucial RAM evidence.
- Examine existing detection systems (antivirus, EDR, IDS) and collect all relevant logs before they are overwritten or tampered with.
- Look for evidence of initial access “dropper” malware, such as Bumblebee, Dridex, Emotet, or QakBot, which may have been active for days or weeks.
- Document every action taken meticulously. This log will be essential for any subsequent insurance claims and law enforcement reporting.
- Do not attempt any remediation or restoration until all forensic evidence has been properly captured and preserved by professionals.
By following this protocol, you shift from a state of panic to one of control. You are gathering the intelligence needed to understand the full scope, or blast radius, of the attack. This information is non-negotiable for ensuring the threat is fully eradicated before you begin the process of recovery.
To Pay or Not to Pay: Why 40% of Payers Never Get Their Data Back?
The ransom note presents a devil’s bargain: pay a fee, often in cryptocurrency, and receive a key to decrypt your files. For a business facing total paralysis, this can seem like the fastest, or only, way out. However, the decision to pay is fraught with peril and is strongly advised against by law enforcement and cybersecurity professionals. The reality is that paying the ransom is not a business transaction; it is a deal with criminals who have no incentive to act honorably.
The statistics on payment outcomes are grim. Recent data shows a historic low in payment success rates, with one report revealing that 84% of victims who paid failed to fully recover their data in Q4 2024. This failure can occur for many reasons: the decryption key may be faulty, the decryption process itself may corrupt the data, or the attackers may simply take the money and disappear. In some cases, a second, different ransomware group will extort the victim after seeing they are willing to pay.
Case Study: Change Healthcare’s $22M Ransom Payment Failure
In February 2024, Change Healthcare, a massive US healthcare technology company, reportedly paid a $22 million ransom to the BlackCat/ALPHV ransomware group to prevent the release of stolen data. Despite the payment, the incident spiralled out of control. The affiliate who conducted the initial attack claimed they weren’t paid their share by the main group, then provided the 100 million stolen patient records to another ransomware gang, RansomHub. This second group then attempted to extort Change Healthcare again. As this case shows, payment offers zero guarantee against data leaks or re-extortion, turning a single crisis into a multi-front disaster that cost the parent company nearly $2.9 billion.
Furthermore, paying the ransom funds the ransomware ecosystem, enabling attackers to refine their tools and target more victims. It also marks your organization as a willing payer, increasing the likelihood of being targeted again in the future. The short-term hope offered by payment is a mirage that often leads to greater long-term pain. The only viable path is a robust recovery strategy based on clean backups and fortified systems.
Why Your Cloud Backups Might Be Encrypted Too?
The common refrain in any disaster recovery plan is “restore from backups.” This assumes, however, that your backups are safe and untouched. Modern ransomware gangs are acutely aware of this and have adapted their tactics accordingly. Their primary objective before triggering the main encryption routine is to find and eliminate your ability to recover. This means your backup repositories—whether on-premises or in the cloud—are a prime target.
According to Veeam’s 2024 Data Protection Trends Report, this is not a hypothetical threat; it’s the standard operating procedure. A staggering 96% of ransomware attacks specifically target backup repositories, and they are successful in compromising them 76% of the time. Attackers use stolen administrative credentials to log into your backup solutions, delete existing backup files, disable backup jobs, and then encrypt the backup storage itself. If your cloud backup uses the same credentials as your production environment, it offers no protection.
The only effective defense against this tactic is to create an “air gap” or, more practically in a cloud environment, to use immutable storage. Immutability ensures that once a backup is written, it cannot be altered or deleted for a specific period, even by an account with administrative privileges. This creates a locked, read-only copy of your data that is resistant to tampering. Implementing this requires a strategic approach to your cloud storage configuration.
To defend your last line of defense, you must treat your backups with the highest level of security. This includes:
- Enable delete protection or object lock features on storage resources (like AWS S3 Object Lock or Azure Blob immutable storage).
- Configure Write-Once-Read-Many (WORM) policies with a retention period (e.g., 90+ days) that cannot be altered.
- Enable versioning on cloud storage to retain multiple variants of objects, allowing you to roll back from malicious changes.
- Use completely separate administrative accounts and credentials for your backup environment, distinct from your production network.
- Regularly test your ability to restore from these immutable backups in an isolated sandbox environment.
The Remote Desktop Port That Hackers Scan for 24/7
One of the most common, yet easily preventable, entry points for ransomware is the exposure of remote management services directly to the internet. Chief among these is Microsoft’s Remote Desktop Protocol (RDP), which typically runs on port 3389. For convenience, many businesses open this port on their firewall to allow employees or IT providers to access systems remotely. To attackers, this is an open invitation. Automated scanners operated by criminal groups are constantly sweeping the entire internet, 24/7, looking for open RDP ports.
Once an open port is discovered, they can launch several types of attacks. The most common is a brute-force attack, where automated tools try thousands of common usernames and passwords per minute until they find a combination that works. If your organization has weak or default passwords, it’s a matter of when, not if, they will get in. Even more dangerous are vulnerabilities in the RDP service itself, like the infamous BlueKeep (CVE-2019-0708), which can allow an attacker to gain complete control of a system without even needing a password.
Exposing RDP to the internet is the digital equivalent of leaving your office front door wide open with the key in the lock. There is no legitimate reason in the modern security landscape to do this. Secure remote access requires a layered defense that hides these management ports from public view and enforces strict authentication.
To properly secure your network’s entry points, you must go beyond simply closing one port. A holistic approach is required:
- Never expose RDP (port 3389), WinRM (5985/5986), SSH (22), or VNC (5900) directly to the internet. All these ports should be blocked at your network firewall.
- Implement a Zero Trust Network Access (ZTNA) solution or a Virtual Private Network (VPN) with mandatory multi-factor authentication (MFA) for all remote connections.
- Apply critical security patches for remote access services immediately. Vulnerabilities like BlueKeep and DejaBlue are “wormable,” meaning an attack can spread automatically across your network.
- Consider advanced defenses like Single Packet Authorization (SPA), which keeps ports completely invisible to scanners until a specific, secret “knock” sequence is sent by an authorized user.
- Actively monitor Windows Event Logs for failed login attempts (Event ID 4625) and successful logins (Event ID 4624) at unusual times or from unknown locations, and set up automated alerts for suspicious patterns.
How to Sanitise Systems Before Restoring From Clean Backups?
After a ransomware attack, the temptation is to find a clean backup and restore it as quickly as possible to get back to business. This is a critical error. Restoring data onto a system that has not been properly sanitised is like rebuilding a house on a toxic waste dump. The malware, or the persistence mechanisms it leaves behind, may still be lurking on the system. Reconnecting a compromised but “restored” machine to the network can trigger the attack all over again, sometimes within minutes.
Ransomware is often just the final payload. The initial breach may have occurred weeks or months prior, during which time attackers may have installed backdoors, keyloggers, or other malicious tools to maintain access. Simply deleting the ransomware files is not enough. A proper system sanitisation is required. This means you must assume the operating system and all software on the compromised machine cannot be trusted. The only safe approach is to wipe it completely and start from scratch.
Before any data is reintroduced to your production environment, it must be tested. This is done by restoring the backup to an isolated virtual environment, or “sandbox,” that has no connection to your internal network or the internet. In this safe space, you can boot the restored systems, analyse them for any signs of dormant malware, and validate the integrity of the data. Only when you have 100% confidence that the backup is clean can you proceed with a full-scale restoration.
The sanitisation and restoration process must follow a strict protocol to avoid reinfection:
- Perform a full secure-erase and re-imaging of all compromised hard drives. Do not simply run “removal tools” on suspected systems.
- Before restoration, actively check for persistence mechanisms left by attackers in registry keys, scheduled tasks, and startup services.
- Always restore backups first to a completely isolated virtual environment (sandbox) to test for any dormant malware or data corruption.
- Validate that the backups you are restoring are verifiably clean and that you are not simply reintroducing the original infection into your network.
- Patch all known vulnerabilities and enhance security protections (e.g., email filtering, endpoint detection and response) before bringing the newly restored systems back online.
Why Your “Plan B” Must Include a Paper List of Emergency Contacts?
In a full-blown ransomware attack, you must assume that all your digital systems are compromised, inaccessible, or untrustworthy. This includes your email, your VoIP phone system, your contact lists, and your access to company files. How do you execute your incident response plan when the plan itself is an encrypted file on the server? How do you contact your cyber insurance provider when their phone number is in your locked Outlook contacts? This is why a physical, offline “Plan B” is not paranoia; it’s a professional necessity.
Your team will need to communicate and access critical information when all standard channels are down. This requires an out-of-band communication channel—a method that doesn’t rely on your compromised corporate network. This could be a pre-agreed Signal group, a set of dedicated burner phones, or simply a group text message chain. The tool doesn’t matter as much as the fact that it is established and tested *before* the crisis hits.
The core of this offline plan is a physical “Blackout Box” or “Crisis Kit.” This is a secure, physically accessible container that holds all the information and tools you would need if your entire digital infrastructure vanished. It’s the fire extinguisher for your digital life, and every business needs one. It should be stored in a secure but easily accessible location, with copies potentially held by key executives off-site.
Your physical Blackout Box should be assembled and checked quarterly, and contain at a minimum:
- Laminated paper copies of all emergency contacts: your incident response team leader, your external IT provider, your legal counsel, your cyber insurance provider’s 24/7 hotline, and your local FBI field office’s cyber task force.
- USB drives loaded with critical offline software, such as bootable operating system images, portable antivirus tools, and network diagnostic utilities.
- Printed and laminated network diagrams showing your infrastructure topology, critical asset locations, and the physical location of backup repositories.
- A hard copy of your cyber insurance policy, including the policy number and the specific URL for the incident reporting portal.
- The established out-of-band communication channel (e.g., “In a crisis, we will form a Signal group named ‘Project Phoenix'”) and decision-making flowcharts from your incident response plan.
- A full, printed copy of the incident response plan itself.
The .gitignore Mistake That Leaks Your API Keys to the Public
While many ransomware attacks originate from a classic phishing email, an increasingly common vector, especially for tech-savvy companies and cloud-based businesses, is the exploitation of leaked credentials. Attackers don’t always have to “hack” their way in through a firewall; sometimes they can just walk in the front door using keys that have been accidentally left lying around in public. One of the most common places to find these keys is in public code repositories like GitHub.
Developers use API keys, access tokens, and other “secrets” to allow their applications to communicate with cloud services like Amazon Web Services (AWS), Azure, or Google Cloud. These keys are powerful—they are essentially passwords for applications. If an attacker gets your AWS secret key, they can access your cloud infrastructure, spin up servers, steal data, and, of course, deploy ransomware. A frequent mistake is that a developer will accidentally commit a file containing these secrets into a Git repository, which is then pushed to a public GitHub page. Even if the mistake is noticed and the file is “deleted” in a later commit, the secret remains in the repository’s history, forever accessible to anyone who knows how to look.
Attackers run automated tools that do nothing but scan public GitHub commits for the tell-tale format of API keys. As a result, credential theft is now considered the number one cloud ransomware attack vector. The moment a key is exposed, you must assume it is compromised. You are in a race against the bots.
If you suspect a credential leak, immediate action is required to invalidate the keys before they can be used:
- Immediately scan your entire repository history (not just the current code) with tools like `git-secrets` or `TruffleHog` to detect any accidentally committed credentials.
- As soon as a key is identified, revoke and rotate it immediately on the corresponding cloud platform (e.g., AWS IAM, Azure Active Directory). This is your highest priority.
- Implement a proper Secrets Management System (like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault) as the only robust long-term solution. Code should retrieve credentials from the vault at runtime, never store them in files.
- Enforce phishing-resistant Multi-Factor Authentication (MFA) on all cloud accounts, especially for developers and administrators.
- Regularly audit all non-human identities, such as service accounts and API keys, and remove any that are unused or have overly permissive access.
Key Takeaways
- Isolate, but do not power off. Your first priority in a ransomware attack is to preserve the volatile evidence in RAM for forensic analysis.
- Assume your backups are a primary target. The only reliable backup is an immutable, offline, or air-gapped copy that attackers cannot delete or encrypt.
- Paying the ransom is not a recovery strategy. It funds criminals, marks you as a target, and offers no guarantee you will get your data back intact.
Implementing Robust Cybersecurity Protocols for UK SMEs Without a Dedicated IT Team?
For Small and Medium-sized Enterprises (SMEs) in the UK, especially those without a dedicated internal IT department, the threat of ransomware can feel overwhelming. The resources and advice can seem geared towards large corporations. However, the UK government, through the National Cyber Security Centre (NCSC), has developed frameworks and resources specifically to help SMEs build a strong, cost-effective defense against the most common cyber threats.
The cornerstone of this is the Cyber Essentials scheme. It’s a government-backed framework that, when implemented, will protect your organisation against the vast majority of common cyber attacks. It is not a complex, multi-year project; it is a clear, achievable standard based on five key technical controls: firewalls, secure configuration, user access control, malware protection, and patch management. Achieving Cyber Essentials certification is a powerful statement that you are taking security seriously, and is increasingly a requirement for government contracts.
In the event of an attack, UK-based organizations also have specific legal obligations. Under GDPR, you must report any breach that compromises personal data to the Information Commissioner’s Office (ICO). As the NCSC confirms, UK-based organizations must report ransomware incidents to the ICO within 72 hours if personal data is affected. This is not optional. The NCSC itself also provides technical assistance and can direct you to NCSC-assured Cyber Incident Response providers for professional support.
SMEs should not feel they are alone. A wealth of resources is available, but they must be leveraged proactively.
- Achieve Cyber Essentials certification. This UK government-backed five-control framework is the most cost-effective way to defend against common threats.
- Know your reporting obligations. Report any ransomware attack involving personal data to the UK Information Commissioner’s Office (ICO) within 72 hours.
- Contact the National Cyber Security Centre (NCSC) for technical guidance and use NCSC-assured Cyber Incident Response (CIR) providers for professional crisis support.
- Leverage free, UK-specific resources provided by the NCSC, such as the Early Warning service and regional Cyber Resilience Centres (CRCs).
- Implement the NCSC’s core ransomware guidance: enforce multi-factor authentication, maintain offline backups, segment your network, and ensure regular security updates are applied.
The time to build your defences and create your response plan is now, not during a crisis. Start by implementing these foundational protocols today to protect your business’s future.