Site navigation

Comment | Avoid These Critical Mistakes in a Ransomware Incident

David Neeson

,

ransomware recovery mistakes
In this contributed piece for DIGIT, David Neeson, deputy SOC team lead, Barrier Networks, explains how well-intentioned responses to ransomware attacks can make recovery far more difficult.

Every ransomware attack is a calamity, but errors made in those first few seconds by over-eager defenders can quickly turn the immediate misery into weeks of hard labour.

Picture this scenario: an employee’s computer has recently displayed an on-screen ransomware demand. With panic rising, what’s the worst thing the IT department could do? The answer still surprises some people: tell the employee to turn the infected system off.

For anyone hired to clean up after a ransomware attack, being told that infected machines have been powered down is close to the worst-case scenario. The official logic of this tactic is that ransomware traditionally involves data encryption so turning off a system as soon as possible interrupts that process while reducing the chances of an infection spreading to other systems. It just seems instinctively the right thing to do – limit the damage.

In fact, by the time an extortion message appears, today’s ransomware criminals have probably been inside the network for weeks so stopping what’s happening is a vain hope. What matters at this moment is making recovery as easy as possible. That requires forensics teams to uncover ‘patient zero’ – the system that gave attackers access – how far the compromise spread, and whether it achieved enough persistence to re-establish itself later on.

Hands off the device

Forensics, naturally, requires data. Some of this will be inside logs, hopefully backed by a centralised SIEM, but vital traces the attackers haven’t been able to erase will also be sitting in volatile memory. Powering off a device, including other possibly infected systems on the same network segment, deletes this evidence forever.

Lesson number one: if you’re worried about ransomware spreading, isolate infected systems from the network but leave as many devices as possible turned on so the remediation team has as much data to go on as possible. Recovery is never easy, but it will always be harder with less data.

Isolation isn’t always a friend

Think of ransomware recovery as a card game which starts with the attacker holding all the high-value cards. As time goes on, however, the ability to build a picture of the attackers using data lets the defenders grab back an ace or two. It’s a contest where every trace counts.

This is why even procedures such as isolation can be nuanced. For example, if it’s early in its spread, security platforms such as CrowdStrike Falcon will be deployed to block and quarantine suspected malicious processes. At this point, a live connection allows defenders to learn which command & control IPs the malware is communicating with.

However, later on when the network is already down and compromised devices are in isolated state, Falcon would be deployed without any prevention policies and use that to investigate detections or to interrogate the systems.

Nobody knows what’s normal

Ironically, the next mistake defenders have made is that they often know less about their network than the attackers do. This might sound counter-intuitive but it’s not unusual to find that the official list of network assets and applications is different in important ways from what’s actually running in that environment.

For recovery teams, having an accurate description of the applications, interfaces, connections, policies, and admin accounts is essential. Without this, distinguishing rogue access from legitimate use can become a long, slow process that extend the recovery process. Too often, what’s on the official list resembles a minor work of fiction, especially around the existence of privileged accounts everyone’s forgotten of that were created by admins years in the past.

No centralised log backup

Logs are critical but only if the ones that exist can be trusted – or even exist at all. Attackers will go to great lengths to cover their tracks to make recovery more difficult and one of the first things they try to delete or interfere with are logs. Countering that means having some form of centralised log backup.


Recommended reading


There are several ways to do this, but what matters as much is that the backup window goes far enough back in time and that it is stored in a place the attackers can’t access.

It should also be comprehensive, covering every network device or asset, including Windows or device event logs.

Data is your ally

For most of its history, cybersecurity has been about keeping bad people out of a clearly defined perimeter. This defensive mindset worked as long as everyone could assume that compromise was the exception.

Today, a breach is almost inevitable at some point. Simply defending the perimeter is no longer enough. What counts is having engineers and the experience on hand to rebuild the network, if necessary from scratch.

The message of this article is that this process isn’t something to worry about at some point in the future: the job of rebuilding a network begins the second an attack is detected. Internalising the rule that every scrap of data matters is still the surest way to make the bad experience of a ransomware attack as brief as it possibly can be.

David Neeson

Deputy SOC Team Lead, Barrier Networks

Latest News

AI

Nvidia Launches Open Secure AI Alliance for AI Safety and Security

AI Business Recruitment

Nearly a Quarter of Orgs Reducing Entry-level Hiring Due to AI Automation

Business

Scottish Businesses Turn to Self-funding as Growth Confidence Dips in H2

Data Finance

Payment Leaders are Struggling to Get Real-time Data