The Ransom Note Is Often Not the Beginning of the Incident
Commonly noticed after a Ransomware Attack:
— > A user turns on a computer and sees a ransom note.
— > Files are inaccessible.
— > Shared drives begin failing.
— > Someone calls IT.
— > Executives start asking whether backups are available.
The immediate instinct is understandable:
Get everything running again.
But ransomware response requires two objectives at the same time:
Stop the damage.
and
Understand what happened.
Moving too quickly toward restoration can unintentionally destroy evidence, reconnect compromised systems or leave the attacker’s original access path untouched.
The first 24 hours should therefore be structured around containment, preservation, investigation and carefully controlled recovery.
Hour 0–1: Activate the Incident Response Process
Once ransomware is suspected, treat the situation as a security incident rather than a routine IT outage.
Activate the organization’s incident-response process.
Establish a small decision-making group that may include:
- IT
- cybersecurity
- executive leadership
- legal counsel
- privacy/compliance
- cyber insurance
- communications
- external DFIR support
Avoid having large groups independently making changes to affected systems.
Someone should be assigned responsibility for documenting:
- when the incident was discovered
- who discovered it
- affected systems
- actions taken
- people contacted
- major decisions
- timestamps
- evidence collected
A simple incident chronology created from the beginning can become extremely valuable later.
Hour 1–3: Contain the Attack
The immediate technical objective is preventing further spread.
CISA’s ransomware guidance recommends determining which systems are affected and isolating them as an early response priority.
Depending on the environment, containment might involve:
- disconnecting affected hosts from the network
- disabling Wi-Fi on compromised endpoints
- isolating network segments
- restricting compromised accounts
- disabling malicious remote-access mechanisms
- blocking known malicious infrastructure
- restricting suspicious cloud sessions
- revoking compromised tokens
But containment should be coordinated.
Attackers may still have active access and may react when they realize defenders have discovered them.
This is also why organizations should consider using out-of-band communications for sensitive incident-response discussions when the integrity of normal corporate communications is uncertain.
Don’t Immediately Wipe Everything
One of the most damaging reactions during an incident is rebuilding compromised systems before forensic evidence is preserved.
A compromised system may contain evidence showing:
- how the attacker entered
- which credentials were used
- which commands were executed
- what persistence was installed
- which systems were contacted
- whether data was staged
- whether information was exfiltrated
- when encryption began
Some evidence is volatile.
Information stored in memory can disappear when a system is shut down.
Logs may roll over.
Cloud-session information may expire.
Malware can delete itself.
That doesn’t mean an infected machine should remain connected to the network.
It means containment and evidence preservation need to be coordinated.
Hour 2–6: Determine the Scope
The ransom note tells you ransomware exists.
It does not tell you the scope of the incident.
Investigators should begin determining:
— Which endpoints are affected?
— Which servers are affected?
— Are domain controllers compromised?
— Are cloud systems involved?
— Are backups accessible to the attacker?
— Were privileged accounts compromised?
— Did the attacker access email?
— Did they use remote-management tools?
— Is the attacker still present?
Security telemetry becomes extremely important.
Useful evidence may exist across:
- EDR
- SIEM
- identity-provider logs
- Active Directory
- Microsoft 365
- VPN logs
- firewalls
- DNS
- web proxies
- cloud audit logs
- email security
- vulnerability-management platforms
- network telemetry
This is where centralized visibility becomes valuable.
A ransomware attack is rarely represented by one alert.
It is usually a sequence of events.
Understand the Attack Timeline
Modern ransomware incidents frequently involve more than encryption.
The attacker may have been inside the environment before the ransomware payload was deployed.
Investigators should attempt to reconstruct:
Initial access → execution → privilege escalation → persistence → credential access → discovery → lateral movement → data staging → exfiltration → encryption
Not every incident will contain every step.
But the sequence matters.
If defenders simply restore encrypted servers without identifying the original access method, the attacker may retain the ability to return.
The ransomware is the visible impact.
The compromise that enabled it may be the larger security problem.
Hour 4–8: Preserve Evidence
Depending on the nature of the incident, evidence preservation may include:
- forensic disk images
- memory captures
- EDR telemetry
- authentication logs
- Windows event logs
- firewall logs
- VPN records
- cloud audit trails
- email logs
- malware samples
- ransom notes
- suspicious scripts
- persistence artifacts
- IP addresses
- domains
- file hashes
- registry artifacts
- timestamps
For cloud systems, snapshots can sometimes provide a point-in-time copy for investigation.
Maintain documentation about how evidence was obtained, when it was collected and who handled it.
This becomes especially important when the incident may involve:
- litigation
- law enforcement
- cyber-insurance claims
- regulatory investigation
- contractual disputes
- employee misconduct
Evidence should support conclusions rather than assumptions.
Hour 4–12: Protect Identity
Ransomware response is often an identity-security problem.
If the attacker obtained credentials, simply removing malware may not remove access.
Investigators should determine whether there is evidence of:
- compromised administrator accounts
- newly created users
- unexpected MFA registrations
- malicious OAuth applications
- new API credentials
- service-account misuse
- suspicious mailbox rules
- persistence through cloud identities
- token theft
- privilege escalation
Credential resets may be required.
But they should be executed in a planned sequence.
Resetting passwords while the attacker still controls a privileged system could allow those new credentials to be captured again.
Identity remediation therefore needs to align with containment.
Hour 6–12: Determine Whether Data Was Stolen
Many ransomware operations combine encryption with data extortion.
Before encrypting systems, attackers may steal information and threaten to publish it.
Organizations should therefore investigate potential exfiltration.
Useful questions include:
- Did unusual outbound data transfers occur?
- Were archive utilities used?
- Were large files staged?
- Did unusual cloud-storage activity occur?
- Were sensitive file repositories accessed?
- Which compromised identities had access to regulated information?
This determination can affect:
- breach-notification obligations
- legal strategy
- insurance
- executive communications
- customer notification
- regulatory response
Do not assume that an incident involved only encryption.
Hour 8–16: Evaluate Recovery Options
Recovery should begin from systems that are understood to be clean.
Before restoration, determine:
- which services are most critical
- whether backups are intact
- whether backups were accessible to the attacker
- whether recovery credentials are secure
- whether restoration infrastructure is trustworthy
- whether vulnerabilities that enabled the incident have been remediated
CISA recommends maintaining offline, encrypted backups and regularly testing their integrity.
Backups that exist but cannot be restored are not a recovery strategy.
Neither are backups that the ransomware operator was able to encrypt along with production systems.
Recovery priorities should be defined according to business criticality, not simply which server is easiest to restore.
Hour 12–24: Move From Emergency Response to Controlled Recovery
By this stage, leadership should be receiving a clearer operational picture.
A useful executive update should answer:
What do we know?
Affected systems, known indicators and confirmed business impact.
What do we not know?
Open investigative questions.
Is the threat contained?
Explain the evidence supporting that assessment.
Was data potentially accessed or exfiltrated?
State confirmed evidence separately from assumptions.
Are backups viable?
Explain restoration status and risks.
What is the business priority?
Identify systems or services that should be restored first.
What happens next?
Provide the next investigation and recovery milestones.
Avoid overstating certainty.
During the first 24 hours, information will evolve quickly.
A disciplined investigation distinguishes between:
Confirmed
Likely
Possible
Unknown
That makes technical findings more useful to executives, attorneys, insurers and regulators.
What Not to Do
During the first 24 hours, avoid several common mistakes.
Don’t immediately restore everything.
Understand the compromise before reconnecting systems.
Don’t destroy evidence unnecessarily.
Coordinate system shutdown and rebuilding with the forensic investigation.
Don’t assume encryption is the entire incident.
Look for credential theft, persistence and data exfiltration.
Don’t negotiate impulsively.
Ransom and extortion decisions should involve leadership, legal counsel, insurance and appropriate specialists.
Don’t communicate sensitive response activity through potentially compromised channels.
Consider alternative communications where appropriate.
Don’t make unsupported claims.
Statements such as “no data was stolen” should be based on evidence.
Preparation Determines How the First 24 Hours Go
The best ransomware response begins before a ransomware attack occurs.
Organizations should already have:
- an incident-response plan
- a ransomware playbook
- critical-asset inventory
- network diagrams
- centralized logging
- EDR coverage
- tested offline or resilient backups
- defined escalation contacts
- cyber-insurance information
- external DFIR contacts
- executive communication procedures
Tabletop exercises can reveal weaknesses in these procedures before an actual crisis.
One particularly useful question is:
If a ransomware attack began at 2:00 a.m. tomorrow, who would make the first five decisions?
If the answer is unclear, the incident-response plan needs work.
Incident Response Should Produce Answers
A successful ransomware response should do more than restore systems.
Leadership should ultimately understand:
How did the attacker get in?
What did they access?
How long were they present?
Did they steal data?
What systems were affected?
What security controls failed?
What needs to change to prevent recurrence?
Those answers are where incident response and digital forensics intersect.
When Every Hour Matters, Evidence Matters Too
Velocis Technologies provides Digital Forensics and Incident Response (DFIR) services to help organizations contain incidents, preserve evidence, reconstruct attack timelines and move toward controlled recovery.
Our approach connects technical response with investigative discipline so organizations can make decisions based on evidence rather than assumptions.
Experiencing an Active Cyber Incident?
Do not submit sensitive incident details through a public form if you believe communications may be compromised.
Contact Velocis for immediate DFIR assistance. Let the experts handle the incident response after a ransomware attack.
Call: 903-436-4044 | email: info@velocistech.com