Ransomware Three Days Before a Filing Deadline

Failures and controls.

1. Backups were reachable from the compromised host. The mapped drive and domain-admin credential meant the ransomware had write access to its own backups. Control: immutable cloud backup (180,000 setup + 15,000/month) so deletion requires an out-of-band action. This is the control that directly addresses total loss.
2. No network separation between production and backup. Control: backup VLAN and firewall rules (120,000). Cheap and effective, but on its own it fails if credentials are reused, which is why it is second, not first.
3. RPO of 4 hours against a nightly full backup. Even a perfect restore from the surviving copy loses three days, so the design cannot meet its own stated objective. Control: the cloud option with hourly incrementals; the VLAN alone does nothing for RPO.
4. No detection. EDR at 90,000/year would have shortened dwell time, but it is preventive/detective, not recoverable, and the firm's immediate problem is recovery.

Portfolio within 500,000. Immutable cloud backup (180,000) plus backup VLAN and firewall (120,000) = 300,000, leaving 200,000. Note the recurring 15,000/month is 180,000/year, so the first-year total is 480,000 and the annual run rate must be budgeted, not treated as a one-off. Add the tabletop exercise (30,000), because the 20-hour restore revealed that nobody had ever tested the procedure, and hold the remaining 170,000 against the 20,000 restore test and immediate incident costs.

Deliberately left out. EDR and tape rotation. EDR is valuable but does not restore data, and tape is superseded by cloud immutability for this firm. Both belong in the next budget cycle with a written justification, not in a 500,000 emergency spend.

Criteria to weigh. Recovery certainty, time to recovery against the deadline, legal and insurance consequences, and the precedent set for future attacks.

Against paying. A decryption key is unverifiable before payment, and in a meaningful share of cases it is incomplete or corrupt, particularly for large file sets, so payment does not guarantee the 8-hour RTO. Paying puts PHP 400,000 into criminal hands and marks the firm as a payer, which invites repeat targeting; the same actors often return. Insurance may exclude ransom payment or require prior approval, and paying without checking can void cover. There may also be sanctions exposure if the recipient is a designated entity, which is a serious matter for an accounting firm whose own clients are audited.

For paying, honestly stated. It is fast if it works, it is cheaper than a missed filing deadline in direct cost terms, and the firm has a three-day deadline it cannot move. That is the real pressure and it should be named rather than ignored.

Decision. Do not pay as the primary plan. Restore from the surviving copy, accepting that the 20-hour restore breaches the 8-hour RTO, and negotiate the deadline exposure with clients and the revenue authority on the basis of a documented incident. In parallel, engage the insurer and counsel before any payment decision, because the insurance and legal position is what actually constrains the choice. If restoration fails and no other copy exists, payment becomes a last-resort decision for the partners and insurer jointly, documented in writing, not a unilateral IT call.

The decisive point is that the firm should never again be in a position where a ransom demand is the fastest route to its own data; the funding request in the previous task exists to remove that position permanently.

First four hours.

1. Isolate, do not power off. Disconnect the file server and NAS from the network, disable the switch ports, and suspend the affected domain account. Powering down can destroy volatile evidence such as running processes and encryption keys; isolation stops spread while preserving it.
2. Preserve evidence. Photograph screens, capture the ransom note and any file extension, and export relevant logs before anything is rebuilt. The insurer and any law-enforcement report will require this, and the timeline matters.
3. Scope the blast radius. Check domain controllers, mail, and every host that mounted the file server share. Reused domain-admin credentials mean the attacker may hold more than the file server; assume the credential is compromised and plan a password reset for privileged accounts, done from a clean machine.
4. Notify and convene. Inform the insurer, engage counsel, and set up a client-communication channel with one named spokesperson. Do not let individual partners improvise messages about client data.
5. Restore to clean infrastructure. Build a fresh server, apply patches, restore data from the offsite copy, validate integrity with the client-matter index, and only then reconnect.

Why rebuild rather than clean. Ransomware operators routinely leave persistence: scheduled tasks, services, additional accounts, or a second-stage payload that re-encrypts after recovery. Cleaning removes visible artefacts but cannot prove their absence on a machine that ran with domain-admin context. A rebuild from known-good media is the only way to make a defensible statement that the system is trustworthy - and for an accounting firm, that statement is what the client and the auditor are actually buying.

The sequencing rationale: every action above either stops spread, preserves the ability to prove what happened, or restores service. Anything that does none of those three things is a distraction during the first four hours.