Incident Response & Ransomware Recovery
Ransomware Response and Recovery
During a ransomware event the organisation needs three things in order: stop it spreading, work out what is recoverable, and get the business running. Forensic completeness matters and it comes after those. This engagement is structured around that sequence, and the first call is answered by someone who has done it before rather than by a queue.
Methodology
- 01
Triage and scoping
What is encrypted, what is still running, which variant, whether the actor is still present, and what the business cannot function without. Established in the first hours because everything else depends on it.
- 02
Containment
Isolating affected segments, disabling compromised accounts, blocking command and control, and stopping lateral spread — without destroying the evidence needed later.
- 03
Evidence preservation
Memory and disk images from representative systems captured before rebuilding, because once a host is reimaged the answer to how it started is gone permanently.
- 04
Backup validation
Whether backups survived, whether they are clean, and how far back a known-good restore point sits. Frequently the single most consequential question in the incident.
- 05
Eradication
Removing persistence, closing the entry route, and resetting credentials — including the ones in scripts, service accounts and scheduled tasks that a password reset misses.
- 06
Recovery
Staged restoration in business priority order, into a network segment verified clean, with monitoring in place before systems return.
- 07
Forensic analysis
Initial access vector, dwell time, lateral movement path, and what was accessed or exfiltrated before encryption — which determines the notification obligation.
- 08
Post-incident review
Board-level readout, lessons, and a remediation plan that addresses the route in rather than only the encryption.
Approach to testing
- Containment before forensics, but not at the cost of all evidence. Representative images are taken before rebuild, so the question of how it started remains answerable.
- Backups are validated before any ransom conversation. Most decisions in the first 48 hours turn on whether a clean restore point exists, and that should be a measured answer.
- CSS does not negotiate with or pay threat actors. Where a client is considering it, CSS provides technical input on decryptor viability and data exfiltration evidence, and the commercial and legal decision stays with the client and their counsel.
- Exfiltration is assumed until disproven. Most current operators steal before encrypting, and the notification obligation depends on that answer rather than on the encryption.
- Recovery is staged by business priority, into a segment verified clean and monitored, because restoring into a compromised network re-encrypts within days and it happens regularly.
Types of assessment
Emergency response (default)
Live incident. Engagement begins within hours of the call, remotely first and on site as fast as travel allows.
Retainer response
Pre-agreed terms, contacts and access, so response begins immediately rather than after a procurement conversation. Materially faster.
Recovery support
Where the client has contained the incident themselves and needs help with clean rebuild and verification.
Post-incident forensics
After recovery, establishing initial access, dwell time and exfiltration for notification and insurance purposes.
Frameworks and standards
- NIST SP 800-61
- The computer security incident handling lifecycle the engagement is structured on.
- SANS incident handling process
- Practical handling structure, particularly for containment and eradication.
- MITRE ATT&CK
- Technique mapping for the attack narrative and for detection recommendations afterwards.
- CERT-In directions
- Indian incident reporting obligations, including the six-hour reporting requirement where applicable.
- DPDP Act / GDPR
- Breach notification assessment where personal data was accessed or exfiltrated.
Tools used
Tooling is where testing starts, not where it ends. Every automated result is reproduced by hand before it reaches a report.
Velociraptor
Rapid estate-wide triage, artefact collection and hunting for indicators across thousands of hosts.
KAPE
Targeted forensic artefact collection from individual systems.
Volatility
Memory analysis for running processes, injected code and credentials in memory.
Plaso / Timesketch
Timeline construction across multiple hosts and log sources.
YARA
Hunting for variant-specific indicators across the estate.
Client EDR and SIEM
Where present, the fastest route to scope and containment; CSS works within the client's tooling rather than deploying its own first.
Checklist approach
The checklist is the floor, not the ceiling. It guarantees coverage so nothing standard is missed; the findings that matter usually come from what a tester does after it is complete.
Immediate triage
- Variant identification and known behaviour
- Encryption scope: systems, shares, backups, cloud
- Whether the actor is still active
- Domain controller and backup platform status
- Business-critical systems and their state
- Whether a decryptor is publicly available
Containment
- Network segment isolation
- Compromised account disablement and credential reset scope
- Command and control blocking
- Scheduled task and service persistence removal
- Preventing reinfection during recovery
- Preserving evidence while containing
Backup and recovery
- Backup integrity and whether backups were targeted
- Last known-good restore point per system
- Restore into a clean segment, verified before reconnection
- Recovery order by business priority
- Data loss quantified between restore point and encryption
Forensics
- Initial access vector
- Dwell time from first access to encryption
- Lateral movement path and accounts used
- Evidence of data staging and exfiltration
- Volume and nature of data accessed
- Indicators of compromise for estate-wide hunting
Obligations
- CERT-In reporting within the required window
- Regulatory notification assessment for personal data
- Insurance notification and evidence requirements
- Customer and partner communication
- Law enforcement engagement where appropriate
How findings are scored
Every finding is scored on CVSS 3.1 and placed in one of five levels. The executive summary adds a sixth band — Compliant — so components that passed appear on the same chart as those that did not.
- Critical
- Immediate measures must be taken. These vulnerabilities can allow an attacker to take complete control of the application or server — stealing user data, tricking users into supplying sensitive information, or defacing the site.
- High
- Maximum risk associated with a specific vulnerability instance. May enable an attacker to compromise the application and its data, partially or completely, or to modify application behaviour beyond its intended purpose. To be handled with utmost priority.
- Medium
- Considerable risk. May enable an attacker to exploit the application to a particular level, gaining low-level information that can be used to craft more specific attacks.
- Low
- Lowest risk. May allow an attacker to gain some information about the application that was not intended to be known, without an exploitation technique currently available at that instance.
- Informational
- A functionality or component is missing best-practice implementation. Not a risk today, but may become one as the application changes or as exploitation techniques, policy or legal requirements evolve.
Scan types selected
- Safe Checks
- Standard / OWASP Top 10
- Destructive
- SANS Top 25
- Business Logic Vulnerability Testing
Standard toolset by stage
- OSINT
- Datasploit, Google Dorks, Shodan
- Enumeration & Scanning
- Nmap, Wfuzz, Unicornscan
- Domain Enumeration
- Nikto, DnsRecon, Knock
- Crawling & Fuzzing
- Burp Suite, Acunetix, Netsparker
- Vulnerability Analysis
- OpenSSL, sqlmap, CVE-Details
- Exploitation
- Metasploit, Netcat, Exploit-DB
How CSS tests
A unified swarm of agents, for blind spot detection
AI agents drive several testing tracks against the same target at once, then cross-check each other. A single tester works one hypothesis at a time; parallel agents cover the space a sequential pass leaves behind.
Estate-wide indicator hunting across thousands of hosts in the first hours is the difference between scoping an incident and guessing at it, and it is pure parallel search.
Timeline construction across many hosts and log sources is a correlation problem at a scale no analyst can hold during an incident.
Persistence hunting must cover every host, not a sample, because one missed scheduled task re-encrypts the estate after recovery.
Exfiltration evidence is found by correlating network volume, cloud storage access and archive creation across the whole dwell period.
During a live incident, every containment and eradication action is taken by a human responder with the client's authorisation. Agents accelerate collection, hunting and correlation. Nothing is isolated, disabled or deleted automatically — in an incident an automated action against the wrong system is a second outage.
Why this differs
What CSS does that most vendors do not
Every one of these is checkable. Ask any vendor for the same and compare the answers.
Recovery first, analysis second
The business needs to run. CSS sequences containment and recovery ahead of forensic completeness, while still capturing the evidence needed to answer how it started.
We do not negotiate or pay
CSS provides technical input on decryptor viability and exfiltration evidence. The commercial decision stays with the client and their counsel, and CSS does not have a commercial interest in either outcome.
Exfiltration assumed until disproven
Most current operators steal before encrypting. Treating encryption as the whole incident leads organisations to miss a notification obligation they were legally required to meet.
Recovery into a verified clean segment
Restoring into a network that is still compromised leads to re-encryption within days, and it happens often. Recovery is staged into a verified segment with monitoring in place first.
Reporting
Two documents, two audiences
Both are produced for every engagement. They are not the same document at two lengths — they answer different questions and are written separately. The structure below is the one CSS actually issues.
Technical assessment report
For the engineers who will fix it
- Disclaimer, and Limitations on Disclosure and Use
- Risk Level & Description — the five levels above, scored on CVSS 3.1
- Scan Type — which of the five assessment types were selected
- Assessment Scope — the control areas covered
- Assessment Date — the exact testing window
- Objective of the Assessment — objectives listed against completion status
- Tools Utilization — manual and automated tooling by stage
- Summary of the Assessment
- Overall Recommendations, split into Must Have and Should Have
- Vulnerability Overall Classifications as per Organization
- Security Issues Highlighted
- The Key Findings — each with evidence and detailed recommendation
- Summary of Findings & Conclusion
For this assessment specifically
- Incident timeline from initial access to containment, with confidence stated per event
- Initial access vector and the evidence supporting that conclusion
- Dwell time and lateral movement path with accounts and hosts
- Encryption scope and the systems affected
- Exfiltration assessment with supporting evidence, or the reason it could not be determined
- Containment and eradication actions taken, with timestamps
- Recovery record: what was restored, from when, and what data was lost
- Indicators of compromise for ongoing hunting
Executive summary
For the people who will fund the fix
- Objectives, each against a completion status
- Overall Finding of the Assessment — total threats identified, broken down by component and severity
- Summary of the Assessment
- Artefacts of the Assessment — the key findings as a numbered register with severity
- Observation of the Assessment — the major attacks the organisation should be prepared for, given what was found
- Overall Recommendation, including a Business Enabling Recommendation sequence
- Must Have and Should Have actions
For this assessment specifically
- What happened, in plain language, with dates
- How they got in and how long they were present
- Whether data was taken, and the notification position
- Current status and what remains outstanding
- The three changes that would most reduce the chance of recurrence
- One page, written for a board that may read it under pressure
Case studies
What this finds in practice
Representative engagement patterns. Sector and scale only — no client is named, and no detail is included that could identify one.
A manufacturing group, roughly 1,100 endpoints, encrypted across two sites overnight.
- Finding
- Initial access was a VPN appliance unpatched against a known exploited vulnerability, with a dwell time of 23 days. Backups were encrypted because the backup server was domain-joined and the service account held domain administrator. 340 GB had been exfiltrated to cloud storage over the preceding week.
- Recommendation
- Recover from the one offline tape set, rebuild domain controllers from clean media, separate backup identity from the production domain, and notify under the applicable obligations given the confirmed exfiltration.
- Outcome
- Production was running on critical systems within nine days and fully recovered in five weeks, with four days of data loss. The exfiltration evidence determined the notification position, which the client would otherwise have got wrong.
A hospital group, ransomware affecting administrative systems with clinical systems unaffected.
- Finding
- Containment stopped spread before clinical networks were reached — segmentation implemented two years earlier held. Initial access was a contractor account with no MFA. Backups were intact and immutable.
- Recommendation
- Recover from backup, enforce MFA on all third-party access, and review every contractor account for necessity and privilege.
- Outcome
- Full recovery in six days with no clinical impact. The segmentation that limited the blast radius had been a finding from a prior assessment, which the board noted when approving the next security budget.
A logistics company that had contained an incident itself before calling.
- Finding
- Containment had been effective but incomplete: a scheduled task on two non-obvious hosts survived and would have re-established access. Systems had also been restored into the original network segment without verification, and the initial access route remained open.
- Recommendation
- Complete eradication across the full estate rather than the affected hosts, close the entry route before reconnecting anything, and re-verify every restored system.
- Outcome
- The surviving persistence was removed before it activated. The client's own view was that self-containment had been the right first move and that stopping there would have cost them the recovery.
Next
Scope this assessment
Most scopes are settled in one call. Tell us what the application does and who uses it, and we will tell you what testing it properly involves.