Preservation, chronology and incident scope
Ransomware Forensic Investigation
Independent post-containment examination of endpoints, servers, identities and retained logs to test initial access, spread, encryption impact and evidence relevant to possible data theft.
Direct access to Alistair Ewing · Free initial consultation · Written estimate before work
Reconstruct the incident after immediate risks are under control
Ransomware investigation begins with the evidence that survived the incident and response. The business may need to understand when suspicious activity began, which accounts and systems were involved, how access or privilege changed, how the activity spread, what was encrypted or disrupted and whether the retained records bear on data staging or removal.
The useful answer rarely comes from the ransom note alone. Endpoint and server artefacts may need to be reconciled with identity, remote-access, security-tool, firewall, proxy, DNS, VPN, cloud, backup and administrative records. Incident notes and containment times are part of that chronology because isolation, rebuild and restoration can change the evidence available.
Compute Forensics can take a defined role as forensic investigator, technical lead or independent reviewer, working alongside the organisation’s live-response team where necessary.
Questions the investigation may test
- When the earliest suspicious activity supported by the records occurred and how far that predates encryption or disruption.
- Which identity, remote-access route, exposed service, vulnerability or endpoint is supported as a possible entry route, and which alternatives remain.
- What evidence exists of persistence, credential access, privilege change, discovery, lateral movement or remote administration.
- Which endpoints, servers, accounts, applications, backups or cloud resources show relevant activity.
- How encryption, deletion, service stopping, attempts to inhibit recovery or other impact unfolded across the environment.
- Whether available evidence supports data access, collection, archive creation, attempted transfer or observed transfer before encryption.
- How containment, rebuild and restoration affected the chronology and the material still available for examination.
- Which gaps prevent a confident root-cause, attribution, impact or exfiltration conclusion.
Potential evidence sources
- Preserved endpoint and server images, targeted collections and memory where proportionate and safely acquired.
- Identity-provider, authentication, administrator, MFA and remote-access records.
- Endpoint detection and response (EDR), antivirus, security information and event management (SIEM), operating-system, application and scheduled-task records.
- Firewall, proxy, DNS, VPN, network-flow and secure web gateway logs within their retention periods.
- Cloud-platform, email, collaboration, storage and service-provider audit records.
- Ransom notes, suspicious executables, scripts, archives or configuration files handled through an agreed safe route.
- Backup, hypervisor, asset, vulnerability, patch, change and recovery records.
- Alert exports, incident tickets, analyst notes, isolation times and a record of every material response action.
Chronology before narrative
Test each stage against retained evidence
Entry and foothold
Authentication, remote access, vulnerable services, email, endpoint execution and persistence are examined as competing routes. An exposure or alert is not automatically the route used.
Privilege and spread
Accounts, administrator tools, remote sessions, service creation, task execution and network records may help map lateral movement and privilege change.
Staging and possible theft
File access, archive creation, cloud or transfer tools and network records are assessed by separating access, staging, attempted transfer and observed transfer. A volume or connection may not reveal content.
Encryption and recovery
Impact, isolation, shutdown, rebuild, restore and return-to-service events are aligned so that later changes are not mistaken for attacker activity.
Reporting for decision-makers
Useful deliverables after a disruptive event
- A source-referenced chronology with time zones, clock issues and confidence stated.
- Affected-account and affected-system schedules tied to observed evidence.
- An initial-access and activity assessment that records alternatives and gaps.
- A separate exfiltration findings matrix where data theft is alleged.
- A technical report or independent review for directors, lawyers, insurers or an incident-response partner.
Recovery and payment
Keep forensic findings separate from recovery and payment decisions
Forensic work may help validate technical claims and document what was captured or lost, but it does not promise a decryptor, successful restoration or deletion of data held by an attacker. Ransom payment, negotiation, sanctions, insurance and notification decisions require the appropriate legal, financial, insurer and incident-response advice.
Any statement attributed to an attacker is recorded as a claim unless independently supported. Payment is not technical proof that data will be returned, deleted or withheld from publication.
What may remain unresolved
- Log rotation, disabled auditing, damaged systems, encryption and rapid remediation can leave substantial gaps.
- The earliest retained event may post-date the attacker’s entry.
- Use of credentials, infrastructure or a tool does not by itself identify the human operator or group.
- Network connections, transfer volumes or archive files may support an inference without proving the exact content received elsewhere.
- Absence of retained evidence is not proof that persistence, access or transfer did not occur.
- No forensic examiner can guarantee attribution, decryption, restoration, data recovery or removal of copies held by another party.
- The report informs, but does not replace, legal, regulatory, insurer, sanctions or business-continuity decisions.
Information needed for an incident estimate
- Organisation, insurer, legal adviser, response provider and relevant third-party names for conflict checking.
- Whether the incident is active, contained or in recovery, and who has live-response authority.
- The known start, encryption, discovery, containment and restoration dates.
- An overview of affected systems, including identity, cloud, endpoints, servers and backups.
- Available evidence, retention deadlines, existing incident reports and actions already taken.
- The questions about root cause, chronology, affected systems, exfiltration or independent review to be answered.
- The intended recipients, reporting deadline and required output.
Please do not attach evidence, passwords or confidential case papers to the public enquiry. A secure route is agreed only after the conflict check.
Current response guidance
Independent official references
See the NCSC ransomware response collection and its technical response capabilities guidance. UK organisations can report a cyber incident through report.ncsc.gov.uk.
If payment is under consideration, obtain appropriate advice and consult the current NCSC payment guidance and UK financial sanctions guidance for ransomware.
Frequently asked questions
Can you respond while the ransomware incident is still active?
A suitable live-response lead should direct immediate containment, safety, recovery and communications. Compute Forensics can discuss a defined preservation, analysis, technical-lead or independent-review role when responsibilities and access are clear.
Should we turn off affected systems?
There is no safe universal answer because operational risk and volatile evidence differ. Follow the authorised response lead’s plan. Record isolation, shutdown and other changes precisely so they can be interpreted later.
Can you identify the initial access route?
Sometimes several sources converge on a likely route. In other cases the necessary logs have expired or only a vulnerability, suspicious account or possible route remains. The report states what supports each possible route and the level of confidence rather than forcing certainty.
Can a ransomware investigation prove that data was stolen?
It may identify file access, staging, archive creation, transfer tools, network activity or publication. Each supports a different proposition. A separate exfiltration analysis should state whether observed transfer and exact content can actually be established.
Can you decrypt the files or guarantee recovery?
No. Recovery prospects depend on the ransomware, damage, keys, backups and system state. Forensic investigation and recovery are different workstreams, and neither a decryptor nor successful restoration can be promised.
Will a report name the ransomware group?
Malware, infrastructure and behaviour may resemble a known operation, but those indicators can be reused or imitated. Group naming should be qualified and is not proof of the individual operator.
Can you independently review another incident-response report?
Yes. A focused review can test source coverage, chronology, root-cause reasoning, exfiltration statements, assumptions and limitations without unnecessarily repeating the whole investigation.
Read all questions about fees, timing, evidence and instructing Alistair
Initial enquiry
Need a focused ransomware evidence review?
Provide the parties, incident state, key dates, an overview of affected systems, retained evidence and the decision the investigation must inform. If the incident remains active, use the live-response route first and identify the responsible provider in the enquiry.