The First 24 Hours After a Ransomware Detection: A Step-by-Step Playbook

Three principles before you touch anything

When the first ransom note appears on a screen, the strongest pressure is to do something immediately. That is also the moment when irreversible damage is easiest to cause. Agree these three principles before an incident happens.

Isolate rather than power off. The instinctive response is to pull power to stop the encryption. But memory holds things that exist nowhere else: running processes, open connections, and sometimes encryption keys or malware that lives only in RAM, and powering off erases all of it. Prefer isolation at the network layer: shut the switch port, remove security group rules, quarantine the VLAN, drop site-to-site VPN tunnels, disable the accounts being abused. This is a trade-off rather than an absolute rule: if encryption is spreading fast and network-layer isolation is not available, powering off may be right, provided it is a conscious decision by someone with the authority to make it, recorded with a timestamp.

Do not destroy evidence. In the first hours, every cleanup action is a data destruction action. Do not reimage, do not delete suspicious files, do not run antimalware cleanup, do not format disks, do not delete snapshots. That evidence answers the most important question of the incident: how did the attacker get in. Without an answer, you will restore straight back into the same opening.

This is not a purely technical incident. Ransomware brings legal obligations, insurance implications, customer and partner relationships, and decisions that belong to executive management. Bring them in early, not after the technical work is finished.

Hours 0 to 1: confirm and isolate

Start by confirming this really is an encryption incident rather than a storage fault, an application bug, or a false alarm. Typical signs: many files with changed extensions, ransom notes across multiple directories, unfamiliar processes writing continuously to disk, and services stopping unexpectedly.

Once confirmed, work through this order:

• Isolate affected systems from the network, but leave them powered on.
• Cut the spread paths: disconnect network segments, pause replication between sites, drop connections to partner systems.
• Protect the backup system immediately: take it off the shared network and change its administrative credentials. In many incidents the backup infrastructure is targeted first.
• Disable privileged accounts you suspect are compromised, and pause automation that could distribute the payload further, such as centralised deployment tooling.
• Move internal communication out of band. If corporate email or chat may be compromised, everything you write about the incident there is being read by the attacker.

In parallel, start the incident log from the first line: time of detection, who detected it, the indicators, and what actions were taken and when. That record serves both the technical investigation and the requests legal and insurance make later.

Hours 1 to 3: mobilise the right people

During this window the most important work is not at a keyboard.

• Executive management. A decision maker senior enough to authorise halting production, notifying customers, or spending on external responders, plus someone owning internal communication, because if the organisation says nothing, rumour fills the space.
• Legal. Counsel should be informed within the first hours, not days later. They determine what obligations arise, what may be shared externally, and how documentation is handled.
• Insurance. If you carry cyber insurance, read the policy on day one. Many policies contain requirements about when the insurer must be notified and about using responders from an approved panel, and engaging an outside firm first can affect what is covered.
• Digital forensics specialists. With no internal forensic capability, engage externally early, because lead times are measured in days.
• Authorities. Whether and how to report is a decision for legal and management.

Hours 3 to 6: scope the incident and preserve evidence

Alongside mobilisation, establish scope: which systems are encrypted, which were accessed but not encrypted, and which appear untouched. Do not assume unencrypted systems are safe, since attackers are usually present for some time before triggering encryption.

Evidence preservation belongs in this window because logs have a finite life:

• Extend log retention immediately at the operating system, application, network and cloud layers. Size-based rotation can lose the relevant window within hours.
• Export logs to separate storage that the suspected accounts cannot reach.
• Snapshot affected volumes before you operate on them.

aws ec2 create-snapshot --volume-id vol-0123456789abcdef0 \
  --description ir-evidence-2026-08-10-web01

• If you have the capability, capture memory images from hosts that are still running, before full isolation or before any forced shutdown.
• Record chain of custody: who collected what, when, where it is stored, and who has accessed it.

Also look for signs of data exfiltration: unusual outbound volumes, transfers to unfamiliar cloud storage, connections to file sharing services. Whether data left the environment changes the incident from an availability problem to a data protection problem, and directly affects the obligations counsel has to assess.

Hours 6 to 12: backups are the critical asset now

Before thinking about restoring, answer three questions about your backups.

Are they intact? Check whether backup sets have been deleted, encrypted, or had their retention policy altered. Review the backup system’s own audit log for unusual administrative activity in recent weeks.

Are they clean? The harder question. If the attacker was present for weeks before triggering encryption, recent backups very likely already contain their remote access tooling, and restoring from one brings the attacker back with the data. Establish the initial intrusion date as precisely as you can, choose a restore point earlier than that, and scan restored data in an isolated environment before it rejoins production.

How long does a restore take? Measure it with an actual test rather than the number in a document. Restoring several terabytes from cold storage can take days, and that number drives your interim operating plan.

Hours 12 to 24: entry point first, restoration second

This step is most often skipped under pressure to bring services back, and it decides whether you get encrypted a second time. Plenty of organisations recover quickly, run for a few days, and are hit again through the same path because the attacker never lost access.

Before anything goes back into production, have a defensible answer to four questions, even if incomplete: how the attacker got in, how long they were present, which accounts they compromised, and what persistence they installed. Common entry paths include remote access exposed to the internet, unpatched edge devices, leaked or guessed credentials, and access through a service provider’s account.

A sensible restoration sequence:

1. Build a clean environment separated from the infected one, rebuilding from trusted sources rather than cleaning existing machines.
2. Patch the entry point and close equivalent paths elsewhere.
3. Rotate all credentials: user passwords, service keys, certificates and CI/CD secrets. If a domain controller may have been compromised, treat every credential in the domain as exposed and follow your operating system vendor’s guidance.
4. Restore data into the isolated environment, scan it, verify integrity, and only then connect it to the network.
5. Bring services back in waves, prioritising business-critical systems, with heightened monitoring afterwards.

The ransom question

Sooner or later the question comes up, and the technical team needs to understand its own position in it. Whether to pay is a business and legal decision that belongs to executive management, advised by counsel and by the insurer. This article does not recommend either way, and the technical team should not be the party making that recommendation.

What the technical team owes is accurate input for the people who do decide: the condition and trustworthiness of backups, estimated restoration time, the scope of affected systems, and the evidence about whether data was exfiltrated. A few technical facts belong in that briefing too. Obtaining a decryptor is not the same as a fast or complete recovery, since decryption can be slow and can leave corrupted files behind. It does not remove the need to find and close the entry point, and it does not change the fact that data was copied out if that happened. Transactions of this kind may also carry legal constraints only counsel can assess.

Notification obligations

A ransomware incident may trigger obligations to notify regulators, customers, contractual counterparties, or sector-specific bodies. Determining which obligations apply, to what scope, and in what sequence is work for counsel, based on the type of data affected, whose data it is, the sector you operate in, and your contractual commitments. If the organisation has customers or data outside Vietnam, additional regimes may need to be considered.

What the technical team provides is an accurate, current picture: which systems were affected, what data resided on them, what evidence exists that data was accessed or removed, and the time window of the incident. Avoid definitive external statements before the data supports them.

Common day-one mistakes

• Powering off servers in bulk before any evidence is captured.
• Reimaging infected hosts, then realising there is nothing left to investigate.
• Restoring as soon as a backup exists, before the entry point is known.
• Discussing the incident over corporate email that may itself be compromised.
• Failing to record timestamps, making the timeline impossible to reconstruct.
• Rotating user passwords while forgetting service keys, tokens and certificates.

Beyond 24 hours

By the end of day one, a reasonable position is: spread contained, evidence preserved, scope broadly understood, backup status verified, and the right stakeholders engaged. Full recovery typically takes days to weeks and should follow business priority rather than ease of restoration. Keep heightened monitoring for several weeks, then hold a post-incident review aimed at systemic causes rather than individual blame. The most valuable findings are usually procedural: an alert nobody read, a backup that had never been restore-tested, an out-of-date emergency contact list.

How HiTechCloud can help

HiTechCloud helps businesses in Vietnam prepare before this happens: backup architecture with separated and immutable copies, periodic restore tests so recovery times are known rather than assumed, network segmentation to limit lateral movement, log retention and centralisation so an investigation is possible, and response runbooks with maintained contact lists. We operate in-country infrastructure for systems that need data to stay in Vietnam, and we are an AWS partner and a Google Premier Partner. For specialist digital forensics and legal advice, work with dedicated providers and counsel.