Ransomware Response Is More Than Malware Removal

Removing the ransomware binary is the smallest part of a ransomware response. The encryptor is what the business sees. The intrusion behind it, the access path, the stolen data and the damaged recovery assets are what decide whether the incident ends or comes back.

Teams that treat ransomware as a malware problem tend to do the same thing: isolate the infected machines, delete the payload, restore from backup. Each step is reasonable. Together they leave the attacker’s access, and possibly the attacker’s copy of your data, exactly where they were.

Why the payload is the wrong place to start

Ransomware is common enough that the question is no longer whether a response plan is needed. Verizon’s latest Data Breach Investigations Report finds ransomware involved in 48% of the breaches in its dataset. The same report puts software vulnerabilities at the start of 31% of breaches, ahead of stolen passwords as the top way in. Neither figure describes a malware infection. Both describe someone getting access and using it.

Mandiant’s latest M-Trends points the same way. In ransomware-related incidents, prior compromise was the most frequently observed initial infection vector, at 30%. In those cases the access was already in place before the ransomware operator arrived. M-Trends also reports that the median time between initial access and hand-off to a second threat group fell to 22 seconds in cases where a hand-off occurred. In some intrusions, the group that gains access is not the group that encrypts.

That changes the first question. The useful question is not “where is the malware?” It is “how did this group get here, what else did they reach, and what do they still hold?”

Six workstreams, not one

A ransomware response runs several streams at once. CISA’s response checklist covers most of them: detection and analysis, reporting and notification, containment and eradication, and recovery. Cleaning malware sits inside one of those.

Four ways the malware-first approach fails

It misses the way in

If the entry point is a vulnerable internet-facing system or a compromised account, the encryptor’s removal does not touch it. Rebuilding the file servers does nothing for the VPN account the attacker is still using. CISA’s checklist asks teams to identify the systems and accounts involved in the initial breach, including email accounts, and to reset credentials only after the environment is cleaned and rebuilt.

It ignores the second extortion

Ransomware incidents can involve theft as well as encryption. The NIST ransomware profile describes attackers who steal data and demand a second payment to keep it private. Restoring files from backup answers the first demand and leaves the second untouched. Whether data left the network has to be established from evidence, which is one reason evidence preservation belongs in the first hours.

It restores into an unsafe environment

CISA warns about reinfection during recovery. Its example is a new VLAN for recovery: add only verified clean systems. A fast restore that skips verification can bring back the persistence the attacker planted. How to structure recovery so it does not depend on a compromised environment is a design problem in its own right, covered in the related architecture guide.

It leaves decisions without owners

Ransomware forces decisions that technical staff cannot make alone: whether to take whole business units offline, how to handle contact from the extortion group, when to notify, what to tell customers. If those owners are not named in advance, the technical team makes them by default, under pressure, with partial information.

A hypothetical case

This is a constructed example, not a documented incident. A manufacturer finds its file servers encrypted on a Friday. The IT team isolates the servers, removes the payload and restores from backup over the weekend. Business resumes on Monday. The ransom note also referred to stolen data, which nobody investigated. The VPN account used to enter was never identified, so it was never reset. The following week, the same account is used again. A few days after that, a sample of the company’s files appears on the group’s leak site. Every action the team took was sensible. The response was scoped to the malware, and the incident was not.

What a ransomware response plan needs beyond a malware playbook

• A scoping stream led by identity. Newly created accounts, privilege changes, unusual VPN logins and credential-dumping tools are on CISA’s hunting list for a reason. Identity is where persistence usually sits.

• Data-theft assessment as a standing task. Assume theft is possible until the evidence says otherwise, and decide who answers the question.

• Closure criteria written before the incident. Name the authority that can declare the incident over, and the conditions they must see.

• Named decision owners. Containment scope, business shutdown, contact with the attacker, notification and external communications each need an owner and a deputy.

• Out-of-band coordination. CISA advises phone calls or channels the attacker cannot see.

• Pre-arranged outside relationships. Counsel, insurer, incident response provider and the relevant authorities in your jurisdiction. Confirm notification obligations with counsel before an incident, since they vary by country and sector.

NIST IR 8374 Rev. 1 maps these outcomes to the NIST Cybersecurity Framework 2.0 across governance, identification, protection, detection, response and recovery. Organizations can use it to assess their readiness and build a ransomware playbook. It is a useful way to check whether a plan covers more than the payload.

Sources

1. CISA and partners, #StopRansomware Guide. https://www.cisa.gov/stopransomware/ransomware-guide

2. Verizon, Data Breach Investigations Report (latest edition). https://www.verizon.com/business/resources/reports/dbir/

3. Google Cloud, Mandiant M-Trends (latest edition, executive edition). https://cloud.google.com/security/resources/m-trends-executive-edition

4. NIST, IR 8374 Rev. 1: Ransomware Risk Management, A Cybersecurity Framework 2.0 Community Profile. https://csrc.nist.gov/pubs/ir/8374/r1/final