Ransomware

The encryption is the last hour of an operation that took days or weeks. Describing ransomware as malware that encrypts files puts the attention on the loudest and least reversible step, and away from every step where it could have been stopped.

The real sequence starts with access, and access is usually bought. Initial access brokers compromise organisations at scale and sell the foothold to whoever wants it: valid credentials for a remote access portal with no second factor, a session token from an infostealer log, or an exposed service. The buyer is an affiliate: the ransomware itself is a service, with the operators providing the encryptor, the negotiation infrastructure and the leak site, and the affiliate doing the intrusion for a share. That division of labour is the single most important structural fact about the current threat, because it means the person in your network is not the person whose name is on the malware.

Once inside, the work is ordinary intrusion. Find the domain, escalate, move to the systems that matter. Then, before anything is encrypted, three things happen: the backups are located and destroyed or encrypted, the security tooling is disabled from a privileged account, and the data is exfiltrated. Only then does the encryption run, usually at night or over a holiday, pushed out through the same management channel the organisation uses to deploy software.

The extortion is layered. Pay to decrypt, pay to prevent publication, and in some cases pressure applied through customers, regulators or the press. Where an operation calculates that the second layer is enough, it skips the first: no encryption, no outage, no forensic mess, just the data and a deadline.

The failure that decides the outcome is almost always the backups, and it is a design failure rather than an operational one. Backups exist. They are reachable from the production domain with credentials the attacker has by that point, or the backup appliance is joined to the same directory, or the copies are online for convenience of restore. The attacker deletes them first, because a client who can restore does not pay. On engagements, reaching the backup infrastructure is a specific objective for exactly this reason, and we reach it more often than not.

The second failure is that the initial access is boring. A remote access portal without a second factor, an account whose credentials appeared in an infostealer log two months earlier, a supplier connection with standing access. There is rarely anything sophisticated at the entry point, and the organisation could usually name the gap if asked before the incident.

The third is that the dwell time is not used. The intruder is inside for days, running discovery, touching hundreds of hosts, disabling protection, and copying data out. All of that is visible in telemetry that most victims were already collecting. What was missing was somebody looking, and authority to act at three in the morning.

The fourth is the decision nobody rehearsed. Whether to pay, who decides, who talks to the regulator, what the notification obligation is and when the clock started, whether the cyber insurance requires something specific in the first hours. Making those decisions during the incident, with systems down, is how a technical problem becomes a corporate one.

The two models are run by the same kind of crew and demand very different responses.

The row that changes planning is the second. An encryption event announces itself; an exfiltration-only event is found when the attacker chooses to tell you, which may be weeks after the data left. An organisation whose whole plan is built around restoring from backup has no plan for the second column, and that column is growing.

Treating it as an endpoint problem. By the time the encryptor runs, the attacker holds privileged credentials and has disabled the agent. The controls that matter are earlier: identity, remote access and segmentation.

Believing backups are enough. They address downtime and do nothing about publication. They also have to survive an attacker with domain privileges, which most do not.

Testing restores by testing the backup job. A successful job is not a successful restore. The question is whether the business can be running again, and how long that takes, measured by doing it.

Assuming payment ends it. It buys a decryptor of variable quality and a promise about data you cannot verify. It also does not restore the systems: decryption of a large estate takes days.

Planning for the incident without legal and communications. Notification duties, insurance terms and customer communication are decided under time pressure. That is a rehearsal problem, not a technical one.

Close the entrance. Every remote access path with an origin-bound second factor, no exceptions for service accounts and no legacy protocol enabled. Monitor for your own credentials appearing in infostealer logs and breach corpora, and force a reset when they do. Those two measures address where the great majority of these intrusions begin.

Make the backups survivable. At least one copy immutable and outside the production identity boundary, so that domain privileges do not imply backup privileges. Then test a restore of a system the business actually needs, end to end, and record how long it took. That number is your recovery capability; anything else is an assumption.

Reduce the blast radius with network segmentation and by removing shared local administrator credentials, because the encryptor is deployed using the same paths a lateral movement exercise uses. If an attacker cannot reach every host from one, they cannot encrypt every host from one.

Then rehearse the decision. Who declares an incident, who can isolate a site without a change request, who speaks to the regulator, what the notification clock is, and what the position on payment is, agreed in advance and in writing. Run it as an exercise with the executive team present, because that is the group whose absence causes the delays.

For detection, the highest-value signals in the days before encryption are: mass deletion of backups or shadow copies, security agents being uninstalled or put into passive mode from a privileged account, large outbound transfers to file-sharing services, and discovery tooling touching hundreds of hosts. Each of these is loud and each precedes the encryption by long enough to matter.

We do not deploy ransomware. What an engagement establishes is whether the preconditions exist: can we reach the backup infrastructure, can we obtain the privileges the encryptor would need, can we disable or evade endpoint protection from that position, and could we move data out without anything being raised.

The report answers those four questions with evidence and with times, and the finding is written as an attack path with the specific step that would break it identified. Where we reached the backup environment we describe how, because that is usually the single most consequential paragraph in the document.

Severity here is not a score on a technique. It is a statement about whether the organisation would survive the operation, and it is written so that a board can read it without a translation.

Whether your credentials are already for sale, and whether your organisation appears on a leak site or in an access broker’s listing, is what continuous monitoring of criminal marketplaces is for. It is observation rather than protection, and it is often the earliest warning available.

Should we pay a ransom? That is a business and legal decision rather than a technical one, and it should be made before an incident rather than during it. What is worth knowing technically is that a decryptor works imperfectly, that recovery still takes days, and that paying gives no verifiable assurance about copies of your data.

Do backups protect us from ransomware? They protect against the downtime, provided at least one copy is immutable, outside the production identity boundary, and tested by an actual restore. They give no protection at all against publication of data that was taken before the encryption.

Why is ransomware described as a service? Because that is how the market is organised. One group builds and maintains the encryptor and the leak infrastructure, affiliates carry out the intrusions, and access brokers sell the initial foothold. The name on the malware tells you very little about who is in your network.

What is double extortion? Charging twice for the same intrusion: once for the decryption key and once for not publishing the data that was stolen first. It became standard because backups made the first demand negotiable, and it is the reason a good restore process no longer ends the incident.