Ransomware frequently asked questions

Three things, and the order matters more than the speed.

1. Isolate. Unplug the affected hosts or isolate their switch ports, and cut every connection to shared drives, virtualization platforms, backup servers and external disks. Isolate, but do not power off or shut down.
2. Stop. No reboot, no reinstall, no formatting, no disk check or repair utilities, and no immediate full-disk antivirus cleanup.
3. Preserve. Keep the original ransom note, keep encrypted samples, keep firewall and VPN logs, and pause every automated backup or sync job that could overwrite data.

Then make the call. A great deal of irreversible data loss is caused not by the malware but by the rescue attempts made in the hours after discovery.

Rebooting has several consequences that are hard to undo:

• Memory evidence disappears. Some families keep key material or decryption-related structures in memory; once the host is powered down that content is gone, and forensics loses a key source.
• Encryption may continue or accelerate. Some encryptors set themselves to run at startup, so a reboot triggers encryption of whatever is left.
• System writes overwrite remnants. Boot writes logs, temporary files and the page file, potentially overwriting unencrypted remnant data that was still extractable.
• Disk self-check rewrites structures. After an unclean shutdown the system may automatically run a disk check, rewriting filesystem structures and further reducing recoverability.

The right move is to keep the power on and pull the network, then wait for a professional judgement.

Not yet. The ransom note is one of the most direct inputs to family identification — the filename pattern, wording, contact format and ID encoding all feed into it, and identifying the family and version is what determines whether a decryption path exists at all.

A full antivirus cleanup should also wait. Cleanup can remove key files, configuration files, the note itself and samples of the attacker's tooling — which are both identification inputs and critical forensic evidence. In some cases what gets deleted is precisely the material recovery depended on.

The right order is: isolate, preserve evidence, then eradicate under professional guidance. If your antivirus has already quarantined files, keep the quarantine record and do not empty the quarantine.

We advise against making contact and we do not make it on your behalf. Deadlines, price increases and limited-time discounts are standard scripts designed to create time pressure and push victims past assessment straight into a transaction.

In practice:

• making contact confirms you are a staffed, funded target, which can raise the price and invite further pressure;
• payment does not guarantee a working decryptor, nor that stolen data is deleted;
• moving funds to overseas attackers carries its own compliance exposure.

A better use of that time is inventorying data sources: backups, storage snapshots, hypervisor snapshots, local copies on endpoints, historical exports. In a significant share of cases these overlooked sources are what recovery ultimately rests on.

A few signals help:

• New encrypted files. Watch a directory on an already-isolated host; if extensions keep appearing, a process is still running locally.
• Hosts falling one after another. Ransom notes appearing on different machines at different times usually means the actor is still moving through the network rather than having deployed once.
• Anomalous account activity: unfamiliar logons on domain controllers, bulk policy pushes, new scheduled tasks.
• Backup jobs terminating unexpectedly, shadow copies being deleted, antivirus being disabled.

While any of these persists, treat the incident as ongoing: widen isolation, disable suspicious accounts, rotate privileged credentials, and do not return restored systems to the production network until eradication is complete — being encrypted again after a restore is the most common and most avoidable second loss.

The initial conversation and a first read on the family are free. Send us the ransom note text and the appended extension, and we will tell you which family it is likely to be, whether a public decryptor exists, which recovery paths are worth checking, and what to do and avoid doing right now.

For a full recoverability assessment — which requires access to the environment, read-only imaging, and trial repairs and path validation on copies — whether and how it is charged depends on the scope of work. We state that clearly and get your confirmation before starting; we never do the work first and discuss it afterwards.

Whatever the assessment concludes, we explain what can be recovered, what cannot, and why. Where the conclusion is that data is unrecoverable, we do not continue with recovery work that has no substantive prospect of success.

A quote given before we understand the environment is meaningless, so we do not quote over the phone. Fees depend mainly on:

• Service type. Assessment only, data recovery, incident response, forensics and hardening differ widely in effort.
• Data volume and system count. One file server and an entire virtualization platform are not the same order of magnitude.
• Recovery difficulty. Whether backups and snapshots can be used, or whether file-by-file repair and remnant reassembly are required.
• Environment complexity and working mode. Remote or on-site, classified or not, whether physical media must be imaged locally.
• Time requirements. Whether overnight work and parallel staffing are needed.

The sequence is: recoverability assessment, then a written quotation covering scope, deliverables and expected timing, then implementation once both sides confirm. We do not accept settlement in cryptocurrency and provide no form of ransom payment.

Primarily remote. Intake runs 24/7, we respond quickly, and work proceeds through remote sessions and a controlled access channel — usually reaching substantive response faster than waiting for an engineer to travel — with coverage nationwide. Remote work is logged and your operations staff can supervise throughout.

We arrange on-site service when:

• physical media are damaged or RAID structures are inconsistent and hardware handling and imaging must be done locally;
• the environment is fully air-gapped or classified and external remote access is not permitted;
• evidence must be preserved on site, internal approval processes need someone present, or management wants an in-person briefing;
• the client specifically asks for on-site presence.

Whether an on-site visit is needed, and how it divides with remote work, is settled during assessment — not added later.

No. Family identification and the recoverability assessment are never withheld as leverage. We explain the assessment first, so you decide whether to engage us after you know what can be recovered, roughly how long it will take, and roughly what it will cost.

Payment milestones, methods and invoicing follow the contract or quotation, settled through corporate channels with invoices issued. We do not accept cryptocurrency and provide no ransom payment or purchase service.

Be cautious if you encounter any of the following in the market: a quote given without looking at the environment, claims of "100% decryption" or "guaranteed recovery", demands for full payment before the family identification is disclosed, or payment accepted only to a personal account or in cryptocurrency.

We complete technical verification before handover, and you accept against business criteria at handover — both layers.

What we verify

• Sampled bulk file-open checks, stratified by file type.
• Database mount and consistency checks, with row counts on key business tables.
• A recovered-data manifest annotated by system and point in time.
• An explicit list of what is confirmed unrecoverable.

What we suggest you check

• Business-side sampling against real scenarios: key queries, report generation, document cross-checks, opening attachments.
• Time boundaries: confirm the point in time data was restored to, and which increments need re-entry.
• Return systems to the production network only after acceptance, and complete credential rotation and the pre-go-live security check first.

The verification checklist is part of the deliverables, so it can be filed internally and used in later audits.

Ranked by return on effort, these five come first:

1. Rotate every credential: domain administrators, local administrators, service accounts, database accounts, VPN and remote access accounts, and third-party administrator accounts — and disable anything long dormant.
2. Close unnecessary internet exposure: remote desktop (3389), database ports (1433, 3306, 1521) and management consoles should not be open to the internet.
3. Enable MFA on remote access for the VPN and every administration channel — one of the highest-value single measures available.
4. Confirm backdoors are gone. Check for rogue accounts, scheduled tasks, services, startup entries and remote-management tools; do not return restored systems to production until the re-check passes.
5. Rebuild backups and test-restore. At least one offline or immutable copy, with credentials isolated from production, and a restore exercise actually performed.

Other hardening can follow a plan, but these five belong in the short window after recovery.

The core principle: assume the production domain is already lost, and the backup still has to survive.

• At least one offline or immutable copy: tape, removable media disconnected after each run, or object storage with a WORM policy. An always-online backup server does not meet this bar.
• Isolated credentials and privileges. The backup system should not join the production domain, should not run under a domain administrator account, and should not share passwords with production; deletion rights on backup storage are managed separately.
• Multiple restore points. A single latest backup is easily overwritten before the incident is even noticed; the chain must reach back to an earlier clean point.
• Snapshots are not backups, but they matter. Array and hypervisor snapshot permissions are often independent of the backup software, and in real cases they repeatedly turn out to be the lifeline — worth extending retention and restricting deletion rights.
• Test restores regularly. A backup never restored is not a backup. Run at least one full restore exercise a year and record how long it takes.

The test is simple: if an attacker obtained domain administrator rights, what would be left of your backups?

From actual response work, the overwhelming majority of incidents concentrate on these paths:

• Exposed remote desktop and database ports. Port 3389 open directly with weak or reused passwords has been the single most common path for years; exposed database ports (1433, 3306, 1521) are equally frequent, with attackers using the database's elevated privileges to run system commands after a successful brute-force.
• VPN and remote access without MFA. Credentials come from external leaks, infostealer logs and dark web markets — a password alone does not hold.
• Known vulnerabilities in edge devices and internet-facing applications. Unpatched firewalls, VPN gateways, middleware and public business systems get hit by mass scanning and automated deployment.
• Phishing and malicious attachments, typically used to gain an initial foothold before lateral movement.
• Third-party administration and supply chain channels: shared integrator accounts, remote maintenance tools, software update paths.

What they share is that none requires sophisticated technique — they exploit accumulated exposure and poor credential hygiene.

The good news is that the highest-return items mostly require no purchase:

Get those six genuinely done before considering a more elaborate detection and response programme. Our hardening plans are designed around your existing environment and budget, with no vendor lock-in.

Through verification, not through "it was configured". The most common failure mode is not skipping the work but doing it without it taking effect: policies bypassed by exception rules, patches installed but services never restarted, MFA covering only some channels, backup jobs reporting success while nothing has ever been restored.

Suggested verification:

• Check exposure from the outside. Confirm from the public internet that ports are genuinely closed, rather than reading the firewall config.
• Verify MFA channel by channel, including web entry points, clients, APIs and emergency access paths.
• Spot-check patch effectiveness against version numbers and service restart times, not just installation records.
• Run a real restore exercise. Pick a system at random, restore it fully from backup, and record how long it took.
• Test alert effectiveness. Trigger bulk renaming and shadow copy deletion in a test environment and confirm the alert fires and someone sees it.
• Review periodically. Re-check the exposure inventory and account list quarterly so nothing regresses.

Our hardening deliverables include item status, verification method and verification result precisely so this is checkable.