Ransomware Preparedness: Preventing and Recovering From Attacks

Ransomware is discussed as an event and experienced as a process. The encryption everybody pictures is the final step, executed after a crew has been inside the environment for days or weeks, has found the backups, has stolen what they intend to leverage, and has decided the moment of maximum disruption.

That window is the whole opportunity, and preparedness means being able to use it.

How the Attack Actually Runs

The sequence is consistent enough to plan against.

Initial access comes from one of three routes in the overwhelming majority of cases: phishing that yields credentials or a foothold, exploitation of an internet-facing system, particularly remote access and VPN appliances, or valid credentials purchased from an access broker who obtained them earlier and had no particular interest in you.

Establishing position follows: persistence, then credential harvesting and privilege escalation. This is where an intrusion becomes an incident, and it is where most organizations have the least visibility.

Reconnaissance from inside is the phase people underestimate. The crew maps the environment, identifies what matters, and specifically locates the backup infrastructure. Their objective is to reach a position where recovery is not an option.

Exfiltration happens before encryption, deliberately. Stealing data first means the leverage survives good backups, which is why double extortion became standard and why some crews now skip encryption entirely.

Deployment happens last, usually simultaneously across the estate from a privileged position, and usually timed for a weekend or a holiday.

The practical implication is that an organization with detection covering lateral movement, credential access and unusual outbound data transfer has multiple chances to intervene before anything is encrypted.

The Controls That Break the Chain

Prevention work should be weighted toward the routes actually used rather than distributed evenly.

Close the common entry points. Phishing-resistant multi-factor authentication on remote access and email removes the largest single route. Patch internet-facing systems on a compressed timeline, particularly VPN and remote access appliances, which have been the most exploited category for several years running. Know what you expose, because forgotten infrastructure is over-represented in real incidents.

Constrain movement. Tiered administration prevents privileged credentials being cached where an attacker can harvest them, which is how privilege travels. Segmentation limits what a foothold reaches. Removing local administrator rights from ordinary users closes a large proportion of escalation paths. These are the same controls that appear in every internal assessment, because they are what determines blast radius.

Protect the backups specifically. Assume the attacker will find them and will have domain privilege when they do. Immutable backups that cannot be deleted or altered within a retention window, at least one copy isolated from production identity, and restore credentials that do not exist in the production directory.

Watch for exfiltration. Large or unusual outbound transfers, particularly to cloud storage services, are among the most reliable late-stage signals and one of the last chances to intervene.

Testing Recovery Before You Need It

Most organizations have a recovery plan. Considerably fewer have tested it, and the gap between the two is where recovery times come from.

Test by restoring, to a clean environment, on a schedule. What that surfaces is consistent across organizations: the recovery time objective is longer than assumed, frequently by a multiple; some dependency nobody classified as critical blocks everything downstream; the runbook references systems that would themselves be encrypted; and the documentation needed to execute the restore is stored in the environment that is down.

Print the plan. Keep offline copies of the runbook, the contact list and the credentials needed to begin. An incident response plan accessible only through the systems under attack is not a plan.

Decide the Hard Questions in Advance

The ransom decision should not be made at three in the morning by whoever is awake.

Agree your position in advance, with counsel, your insurer and your executive team. Understand that payment does not guarantee usable decryption, does not prevent publication of stolen data, and may carry sanctions exposure depending on the actor. Know who authorizes the decision and who they consult.

Know your notification obligations before you need them. Every state has breach notification requirements with its own timelines, HIPAA imposes specific obligations on covered entities, public companies face SEC disclosure requirements for material incidents, and sector regulators add their own. Working out who must be told, and by when, during the first day of an incident is a poor use of the first day.

Establish the relationship with an incident response provider before you need one. Retainers exist because the worst time to procure a service is when you are the one having the emergency.

Rehearsing It

The exercise that changes outcomes most is a tabletop with the executive team, not the technical team, because the decisions that determine how an incident goes are made by people who will not be reading logs.

Run the scenario: production is encrypted on a Saturday morning, a crew claims to hold customer data, a journalist has called. Who decides what? Who talks to customers? What do you tell staff who cannot work? What is the threshold for notifying regulators?

Organizations that have had that conversation once handle the real thing markedly better than organizations that have not, and the exercise costs an afternoon.

To assess your ransomware readiness or test your recovery, get in touch.