Responding to ransomware and extortion

Why this matters

Ransomware is the incident most organisations are actually planning for, and it is where every part of this domain gets exercised at once under the worst possible conditions: systems unavailable, executives in the room, a countdown on a screen, and decisions that are not the analyst's to make.

It is also the scenario that punishes weak preparation most visibly. Everything lesson 29 listed — tested restores, isolated backups, out-of-band comms, named authority — is decided months earlier and settled by the time the ransom note appears.

The lesson

Early indicators before encryption starts

The most valuable thing in this lesson: encryption is the last step, and the activity before it is detectable.

A typical intrusion runs for days or weeks before anything is encrypted, and that window is where the incident can still be won. What runs in it:

• Initial access — phishing, an exposed remote service, a vulnerable perimeter appliance, or purchased access from a broker.
• Discovery — enumeration of hosts, shares, accounts and the directory. Often noisy, and detectable if anyone is watching for it.
• Credential theft, and escalation toward domain administrator.
• Lateral movement, commonly via remote administration tooling, remote desktop, or remote service creation.
• Defence tampering — disabling EDR and antivirus, clearing logs, stopping services, modifying group policy to push their own settings.
• Backup destruction, which is deliberate and early: deleting shadow copies, attacking the backup server, deleting cloud snapshots, revoking retention locks. If your backups fail during a ransomware incident, this is usually why.
• Exfiltration of data in bulk, often through legitimate file-sharing services or a cloud-storage client so it blends in.
• Deployment, finally, typically pushed estate-wide through group policy or a management tool.

So the detections that matter most are not the encryption itself:

• Shadow copy deletion and backup catalogue tampering. A near-perfect signal — almost nothing legitimate does this — and it fires before encryption.
• Security tooling being disabled or uninstalled, en masse.
• Mass file reads by one account, or large outbound transfers out of hours.
• Administrative tooling appearing where it has no business being.
• Directory enumeration at a volume no human performs.
• New service creation across many hosts in a short window.

The point to carry into an exam scenario and into a job: an organisation that detects ransomware when the files change has missed every opportunity it had. The alerts above are cheap to write and are the ones worth having.

Containment when the clock is visible

If encryption is running, the calculus from lesson 30 shifts hard toward speed — this is the case where evidence loses to damage.

Immediate priorities, roughly in order:

1. Stop the spread. Isolate at the network level, disable the account and the mechanism doing the pushing, block the deployment path. Segment-level containment is justified here even at high business cost, because the alternative compounds by the minute.
2. Protect what is not yet encrypted — and above all the backups. Disconnect or lock the backup infrastructure before it is reached.
3. Powering off encrypting hosts is one of the rare cases where it is correct. It destroys memory evidence and it stops the encryption of that host's remaining files, and stopping the damage wins.
4. Preserve what you can cheaply. A memory image from one representative host, before it goes down, is worth a great deal later — the key material is occasionally recoverable from it, and more reliably it tells you which variant you have.
5. Do not delete the ransom note or the encrypted samples. They identify the variant, which determines whether a free decryptor exists.
6. Move communications out of band immediately, per lesson 29, on the assumption the attacker is reading email.

What not to do, each of which happens under pressure:

• Do not pay or negotiate from the analyst's chair. Not your decision, and contacting them at all is a decision in itself.
• Do not restore into a compromised environment. Restored systems are re-encrypted, sometimes within hours, because the access is still there.
• Do not wipe everything immediately. Once the spread is stopped, evidence still matters — for the scope of data theft, for notification obligations, and for finding the entry point you must close before recovery.
• Do not rely on the decryptor if you pay. They are often slow, partial and buggy; recovery from a decryptor is not a fast path.

Backups: tested, isolated, and actually restorable

The single factor that most determines the outcome, and it is entirely decided before the incident.

Three properties, all required:

• Isolated. Backups must be unreachable from the compromised environment — offline, on separate credentials in a separate identity system, or immutable with a retention lock the domain administrator cannot remove. A backup server joined to the domain, reachable with domain credentials, is not a backup against this threat. It is the attacker's first target and they know it.
• Tested. A restore actually performed, of the systems that matter, with the date and the duration recorded. Untested backups fail at restore time for ordinary reasons — missing application state, broken dependencies, an incomplete selection, expired credentials — and the discovery is expensive.
• Complete and current enough. Covering what the business needs, at a recovery point it can tolerate.

Two more questions rarely asked until they are urgent:

• How long does a full restore take? Not the backup window — the restore. Organisations regularly find the answer is weeks for a full estate, which is a business continuity fact that should have been known in advance.
• Are the backups clean? A backup taken after the intrusion began may contain the attacker's persistence. Check the restore point against the timeline from lesson 30, and restore data rather than system state where you can.

The classic guidance — three copies, two media, one off-site — is worth knowing by name, and for this threat the operative addition is one offline or immutable, because online and reachable is the property that gets them destroyed.

Data theft as the real leverage

The shift worth understanding, because it changes what a good backup buys you.

Modern ransomware operations steal data before encrypting, and then extort on both: pay to decrypt, and pay again not to publish. Some skip encryption entirely and extort on the stolen data alone. The reason is straightforward — organisations got better at restoring, so encryption alone stopped paying.

The consequence: restoring from backups solves the availability problem and does nothing about the disclosure one. An organisation that recovers flawlessly in a day may still face a data breach with every notification obligation that carries.

What follows for the response:

• Establishing what was taken becomes central, not a secondary question. It drives regulatory notification, customer communication and legal exposure.
• Look for the exfiltration explicitly in outbound volume, cloud storage clients, archive creation, and access to file shares at a scale no person reaches. The staging step — building a large archive somewhere unusual — is often the most findable trace.
• The attacker's claim is not evidence. They will say they have taken more than they did, and occasionally less. Your own telemetry decides what you can state, and "we cannot rule it out" is an honest and sometimes necessary position.
• "They promised to delete it" is worth nothing. Payment buys a promise from a criminal, and stolen data has been published after payment often enough that this should not be presented to an executive as a risk that payment removes.
• Notification obligations may already be running from the moment of awareness, per lesson 26, and awareness is a determination made from your evidence.

Decisions that belong to the business, not the analyst

The closing point of the domain, and a reliable exam theme.

Not the analyst's decisions:

• Whether to pay. A business, legal and executive decision, with sanctions implications in some jurisdictions and insurance implications in most. An analyst who negotiates or pays has gone far outside their role.
• Whether to notify regulators, customers or the public, and what to say. Legal and privacy decide; you supply facts.
• Whether to involve law enforcement.
• Accepting the business impact of a containment action that stops operations. You recommend and explain; the owner decides — though the plan may pre-authorise the analyst to act first in defined circumstances, which is exactly why lesson 29 insists on settling authority in advance.
• Whether to rebuild the estate or restore it, where the cost is large.

The analyst's job, and it is a demanding one:

• Establish and communicate the facts: what happened, what is affected, what was taken, what is still at risk, and how confident you are in each.
• State what is not known, and what it would take to find out.
• Give options with consequences, not a single recommendation dressed as the only choice. "Isolating the segment stops the spread and stops order processing for an estimated four hours" is the shape that lets someone decide.
• Execute the decision competently, whichever way it goes.
• Keep the record, contemporaneously, in the form lesson 38 sets out.

The distinction is not modesty. It is that these decisions require information an analyst does not have — contractual exposure, cash position, regulatory posture, reputational strategy — and made from the wrong chair they are made badly.

It is also the point this course opened with, at its sharpest: the analyst's authority comes from the quality of the facts they produce, and it is spent the moment they start producing conclusions the facts do not support.

Topics this lesson owns

• [x] Early indicators before encryption starts
• [x] Containment when the clock is visible
• [x] Backups: tested, isolated, and actually restorable
• [x] Data theft as the real leverage
• [x] Decisions that belong to the business, not the analyst