The Company Received a Ransomware Threat: How to Investigate the Attack, Preserve Evidence and Assess Data Theft

The Company Received a Ransomware Threat: How to Investigate the Attack, Preserve Evidence and Assess Data Theft

It begins with an unexpected message.

Employees cannot open important files. Business applications stop responding. A ransom note appears on a workstation, server or shared folder. The message claims that company data has been encrypted and demands payment in exchange for a decryption key.

Then comes a second threat: the attackers claim they have copied confidential company information and will publish it unless the organisation pays.

For business owners and management teams, this creates two separate but connected problems. The company may have lost access to its systems, and sensitive information may have been taken.

Restoring operations is important, but it does not necessarily explain how the incident happened or whether information was stolen. A ransomware investigation must consider the initial access, the systems affected, the activity before encryption and any evidence of data theft.

The response also needs to be handled carefully. Poorly planned actions can destroy useful evidence, allow an attacker to retain access or make it harder to establish what happened.

This guide explains how to investigate a suspected ransomware attack, preserve digital evidence, assess possible data theft and organise the next steps.

What Happens During a Ransomware Attack?

Ransomware is malicious software or an attack technique used to disrupt access to data or systems, commonly by encrypting files. Attackers may demand payment in exchange for a decryption tool or make additional threats involving information they claim to have stolen.

Not every ransomware incident follows the same pattern. Some attacks affect a single computer, while others disrupt servers, shared storage, business applications and connected systems.

A typical incident may involve several stages:

  1. Initial access to a device, account or network.
  2. Establishing a foothold in the environment.
  3. Attempting to obtain additional access or privileges.
  4. Identifying important systems and information.
  5. Copying or preparing data for removal in some incidents.
  6. Deploying ransomware or otherwise disrupting systems.
  7. Sending ransom demands or threatening to publish information.

This sequence is not universal. Some attacks are automated, some involve human operators and others use stolen credentials or compromised remote access services.

The investigation should establish which stages are supported by evidence rather than assume that every incident followed the same pattern.

Why a Ransomware Investigation Must Examine More Than Encryption

When files become inaccessible, the immediate priority is to contain the incident and restore essential operations safely.

However, encryption is only one part of the potential damage.

A company may also need to determine:

  • Whether attackers accessed employee accounts.
  • Whether confidential documents were viewed or copied.
  • Whether customer or supplier information was exposed.
  • Whether administrative credentials were compromised.
  • Whether attackers created additional accounts or access methods.
  • Whether cloud services were affected.
  • Whether the attacker still has access to any part of the environment.

A ransom note claiming that information has been stolen is not proof that the claim is genuine. Equally, the absence of a data-theft claim does not establish that no information was accessed.

The organisation needs to examine available evidence and distinguish confirmed findings from claims made by the attacker.

Warning Signs That a Business May Be Experiencing a Ransomware Incident

Some indicators are obvious, while others appear before files are encrypted.

Potential warning signs include:

  • Files suddenly becoming inaccessible or displaying unfamiliar extensions.
  • Ransom notes appearing on computers or shared folders.
  • Unusual changes to server or endpoint activity.
  • Security tools reporting suspicious processes.
  • Unexpected administrator account activity.
  • Unfamiliar remote access sessions.
  • Large or unusual data transfers.
  • Security settings being disabled or altered.
  • Employees reporting suspicious attachments or login requests.
  • Attackers contacting the company with information about its internal systems.

A single alert does not necessarily confirm ransomware. It should be assessed alongside other technical and operational evidence.

What to Do Immediately After Receiving a Ransomware Threat

The first response should focus on safety, containment, business continuity and evidence preservation.

1. Activate the Incident Response Process

Notify the people responsible for cybersecurity, IT operations, management and legal or privacy matters.

Establish a clear incident lead and a secure communication channel. Avoid relying on potentially compromised company email or collaboration accounts for sensitive response discussions.

If the organisation has an established incident response plan, follow it and document decisions as they are made.

2. Contain Affected Systems Safely

The security team may need to isolate affected devices or network segments to reduce the risk of further spread.

The appropriate action depends on the environment and the incident. Do not make broad changes without considering operational impact and evidence requirements.

If there is active encryption or a continuing compromise, containment may take priority over preserving a particular device in its current state. Where possible, coordinate with qualified incident responders so that evidence is retained while the threat is controlled.

3. Preserve the Ransom Note and Related Communications

Keep copies of the ransom note, messages, email addresses, contact instructions, payment demands and any links or identifiers provided by the attackers.

Record where the message appeared and when it was discovered.

Do not visit suspicious links or download files supplied by the attacker using an ordinary company workstation. Preserve relevant information through a safe, controlled process.

4. Avoid Premature Restoration or Reinstallation

Rebuilding systems may be necessary, but wiping or reinstalling affected devices too early can remove useful evidence.

Where practical, obtain advice from incident responders about preserving relevant system images, logs and files before rebuilding.

Restoration should use trusted backups and validated systems. Reconnecting an infected or insufficiently checked device may allow the incident to continue.

5. Do Not Assume Paying the Ransom Will Resolve the Incident

Payment does not guarantee that attackers will provide a working decryption tool, delete stolen information or stop contacting the organisation.

It may also create legal, regulatory, sanctions and other risks depending on the parties and jurisdiction involved.

The decision should be made by authorised management with appropriate legal, security and specialist advice. Do not allow the attacker to dictate the investigation or response process.

How to Investigate a Ransomware Attack

Once immediate containment is underway, a structured investigation can help establish the incident’s scope and identify what happened.

1. Identify the Systems and Accounts Affected

Begin by establishing which devices, servers, applications and accounts show signs of compromise.

Create an inventory of affected and potentially affected assets, including:

  • Employee workstations.
  • File servers.
  • Domain controllers and identity services.
  • Cloud applications.
  • Remote access systems.
  • Business databases.
  • Backup infrastructure.
  • Network storage.
  • Administrator accounts.

Record the system owner, business function, relevant identifiers and known symptoms.

Do not assume that systems displaying no visible damage are unaffected. The attacker may have accessed accounts or information without encrypting the associated devices.

2. Establish How the Attack May Have Started

Investigators should examine possible initial access routes.

These may include:

  • Phishing emails.
  • Stolen or reused passwords.
  • Compromised remote access accounts.
  • Unpatched or exposed services.
  • Malicious downloads.
  • Compromised third-party access.
  • Unauthorised remote access software.
  • Previously compromised devices.

Relevant evidence may include email records, authentication logs, endpoint alerts, firewall records and available system activity.

For incidents involving suspicious email communications, Cyb3rsect’s email forensics information provides related context.

The presence of a phishing email does not automatically prove that it caused the ransomware incident. Investigators should look for evidence connecting the message, account activity and subsequent events.

3. Build a Timeline of Attacker Activity

A timeline helps establish the sequence of events and identify gaps in the available evidence.

Depending on the systems involved, relevant timestamps may relate to:

  • Suspicious email delivery.
  • Account logins.
  • Password resets.
  • New user creation.
  • Changes to security settings.
  • Unusual remote access.
  • File access and downloads.
  • Security alerts.
  • Encryption activity.
  • Ransom note creation.
  • Discovery and containment.

Use timestamps from original records where possible, and record the time zone. Different systems may store time differently, so normalisation may be needed before comparing events.

The timeline should distinguish when an event occurred from when it was discovered.

4. Examine Whether Data Was Accessed or Copied

This is one of the most important parts of a ransomware investigation.

Attackers may claim to have stolen customer records, employee files, contracts or other confidential information. The organisation needs to assess whether available evidence supports that claim.

Investigators may examine:

  • Unusual file access.
  • Large or unexpected downloads.
  • Cloud storage activity.
  • Outbound network connections.
  • File transfer records.
  • Archive creation.
  • Access to sensitive databases.
  • Unusual account activity.
  • Security alerts relating to data movement.

Not every large transfer is malicious, and not every suspicious connection proves data theft. The activity needs to be examined in context.

If the organisation cannot establish whether information was copied, the report should state that limitation rather than make an unsupported conclusion.

5. Check Whether Backups and Recovery Systems Were Affected

Ransomware incidents sometimes target backup infrastructure in an attempt to make recovery more difficult.

The organisation should establish:

  • Which backups remain available.
  • Whether backup systems were accessed.
  • Whether backup credentials may have been exposed.
  • Whether recovery copies are isolated.
  • Whether restoration points pre-date the suspected compromise.
  • Whether restored systems can be validated safely.

Do not assume that a backup is clean simply because it completed successfully. Validate the source, integrity and security of recovery data before restoring it to production.

6. Investigate Persistence and Additional Access

Even after encrypted systems have been isolated, the attacker may retain access through compromised accounts, remote access services or other mechanisms.

The security team should examine relevant account activity, access permissions, remote connections and system changes.

This may include reviewing:

  • Unfamiliar user accounts.
  • Unexpected administrator privileges.
  • New remote access configurations.
  • Changes to authentication settings.
  • Suspicious scheduled activity.
  • Unknown applications or services.
  • Unusual cloud sessions.

The objective is to determine whether unauthorised access may remain and what steps are needed to remove it safely.

7. Preserve and Document Digital Evidence

Ransomware investigations can involve large volumes of evidence from different systems.

Preserve relevant material using appropriate procedures, including:

  • System and security logs.
  • Ransom notes.
  • Relevant email messages.
  • Endpoint alerts.
  • File and directory records.
  • Network information.
  • Account activity.
  • Cloud service records.
  • Backup information.
  • Incident response notes.

Maintain an evidence log that records the source, collection date, person responsible and any handling performed.

Where appropriate, preserve forensic images or other suitable copies for later examination. Access to sensitive evidence should be restricted.

For a practical overview, see Cyb3rsect’s digital evidence preservation guide.

What If the Attackers Threaten to Publish Company Data?

Some ransomware incidents involve a second form of pressure: the attackers claim that confidential information has been copied and will be released.

This may be described as double extortion, although the details vary between incidents.

The company should establish what information may be involved and whether there is evidence that it left the organisation’s systems.

Consider the potential exposure of:

  • Customer records.
  • Employee personal information.
  • Financial documents.
  • Commercial contracts.
  • Intellectual property.
  • Supplier information.
  • Internal correspondence.
  • Authentication credentials.

Do not treat an attacker’s sample files or claims as complete proof of the data held. They may be genuine, manipulated, outdated or taken from another source.

The organisation should involve its legal, privacy and security advisers to assess notification obligations and appropriate communications. Requirements vary by jurisdiction and by the type of information involved.

How to Prepare a Ransomware Investigation Report

A useful report should explain what was examined, what the evidence supports and which questions remain unresolved.

Depending on the scope, it may contain:

Incident summary: A concise description of the suspected ransomware event.

Systems affected: The devices, accounts, applications and services examined.

Evidence reviewed: The logs, files, communications and records available for analysis.

Timeline: A chronological account of relevant events.

Initial access assessment: The evidence supporting possible entry routes.

Data exposure assessment: What is known about access to or possible copying of information.

Containment and recovery actions: The measures taken by the organisation.

Limitations: Missing records, unavailable systems or conclusions that cannot be established.

Further actions: Issues requiring additional technical, legal or security review.

The report should clearly separate confirmed findings, technical observations and hypotheses. It should not identify an attacker or claim a specific volume of stolen data without adequate supporting evidence.

How Cyb3rsect Can Support a Ransomware Investigation

A ransomware incident can leave an organisation with difficult questions about access, data exposure and the reliability of its recovery process.

Depending on the circumstances and the evidence lawfully available, a digital investigation may involve examining relevant system records, reviewing suspicious communications, documenting affected accounts, analysing available files and building a timeline of activity.

Cyb3rsect focuses on digital forensics, cyber investigations and online fraud intelligence. The appropriate scope depends on the organisation’s environment, the evidence available and the questions that need to be answered.

An investigation can help organise findings and identify areas requiring further action. It should not promise guaranteed decryption, recovery, attacker identification or the return of stolen data.

If your organisation has received a ransomware demand, discovered encrypted files or suspects that confidential information has been accessed, visit Cyb3rsect to submit an enquiry.

Final Thoughts: Recovering Systems Is Only One Part of the Investigation

A ransomware incident should not be treated as resolved simply because files have been restored.

The organisation also needs to understand how the attack may have started, which systems and accounts were affected, whether information was accessed or copied and whether unauthorised access may remain.

Preserve relevant evidence, coordinate containment and recovery carefully, and involve appropriate technical and legal specialists.

Most importantly, distinguish what the attackers claim from what the evidence actually establishes.

Contain the threat. Preserve the evidence. Investigate the impact.

Leave a Reply

Your email address will not be published. Required fields are marked *