Posted on

Emergency Ransomware Help: What to Do in the First 24 Hours

Emergency Ransomware Help What to Do in the First 24 Hours

If ransomware is active in your environment right now, this article is written for you.

The decisions made in the first 24 hours determine whether this incident is contained and recovered in days or whether it becomes an extended crisis measured in weeks. The sequence matters. Actions taken out of order consistently produce worse outcomes than following the correct sequence even under time pressure.

This is not a general overview. It is a specific, sequenced guide to what your team should do right now, in what order, and why each action matters.

Before Anything Else: Confirm It Is Ransomware

Do not initiate a full emergency response based on a single user complaint about inaccessible files. Confirm that what you are seeing is ransomware before executing actions that will disrupt operations.

Confirmation signals that distinguish ransomware from other file access problems include ransom notes appearing on screens or in affected directories, files with altered extensions appearing across multiple systems simultaneously, multiple users reporting inaccessible files in different departments at the same time, and security tool alerts indicating encryption activity or known ransomware process signatures.

A single user with a corrupted local drive is not a ransomware event. Multiple systems showing the same pattern within minutes of each other is ransomware until proven otherwise. When in doubt, treat it as ransomware and begin containment. The cost of unnecessary containment is operational disruption. The cost of delayed containment is additional encryption across your environment.

The First 30 Minutes

Stop the Spread Immediately

Disconnect infected systems from the network. This is the single most important action in the first 30 minutes. Every minute a connected infected system remains on the network is additional encryption on additional systems.

For wired connections, physically pull the network cable. This is faster and more reliable than software-based disconnection and does not depend on the infected system’s operating system being responsive.

For wireless systems, disable the wireless access point serving the affected area if you cannot disable the adapter on the device. Disabling the AP removes network connectivity from all devices in that area simultaneously, which is faster than device-by-device wireless disconnection when multiple systems are affected.

For virtual machines, disconnect network interfaces through the hypervisor management console. Do this from the hypervisor level, not from within the VM, because a ransomware-affected VM cannot be trusted to execute isolation commands reliably.

Do not shut down infected systems. Volatile memory contains forensic evidence including potential encryption key material, attacker tools, and authentication tokens that are destroyed permanently on shutdown. Isolate infected systems from the network while keeping them powered on.

Disable Remote Access Infrastructure

Disable VPN, Remote Desktop Gateway, and any remote monitoring and management tools that provide connectivity into your environment from outside. Do this immediately after isolating infected endpoints.

Ransomware operators frequently maintain access to environments through remote access infrastructure. Disabling that infrastructure closes the external pathway and prevents the attacker from establishing new sessions during your containment phase. It does not remove an attacker who has already established internal persistence through other means, but it closes the external door.

Remote access infrastructure that is disabled for containment must be fully reviewed, reconfigured, and confirmed clean before it is re-enabled. Re-enabling compromised remote access infrastructure during recovery has produced reinfection in multiple documented ransomware incidents.

Notify Your Core Response Team

Alert the people who need to be involved in this response immediately. Do not wait until you have a complete picture of the scope before making notifications. Notify now and update as you learn more.

The minimum notification list is your IT lead, your executive decision-maker, and your legal counsel. All three need to be engaged from the first 30 minutes because the decisions that will be required in the next several hours require their authority and their expertise simultaneously.

Use out-of-band communication for this notification. If your email system may be affected, use personal mobile phones. Do not coordinate the response through systems that may be compromised.

Call Your Cyber Insurance Provider

Call your cyber insurance carrier’s emergency line now, not after you have assessed the scope. Most cyber insurance policies require prompt notification and many require insurer involvement in vendor engagement decisions. Costs incurred before you notify your insurer may not be covered under policies that condition coverage on prompt notification.

The insurer’s emergency line contact, policy number, and account manager name must be accessible outside your production environment. If that information is in your email system and your email system is affected, you may not have it when you need it. After this incident, store it in your incident response plan in printed form.

Hours One Through Three

Assess the Scope

With initial containment actions in place, your next priority is understanding what you are dealing with before additional recovery or remediation work begins. Beginning restoration before the full infection scope is understood consistently extends recovery timelines because systems missed during initial assessment continue encrypting during restoration of other systems.

Scope assessment requires:

  • Active directory authentication log review to identify systems that authenticated with credentials that may have been compromised during the dwell period. Systems that the attacker accessed through compromised credentials may not show encryption activity yet but are potentially compromised and must be included in the scope assessment.
  • Network flow analysis to identify systems that communicated with known-infected systems during the spread window, which may indicate lateral movement to those systems before containment was complete.
  • Endpoint detection alert correlation to identify all systems where ransomware-associated process activity was detected across your managed endpoint population.
  • User and help desk ticket review to identify systems reported as inaccessible or showing unusual behavior that may not have generated automated alerts.

The scope assessment output is a definitive inventory of confirmed-infected, potentially-infected, and confirmed-clean systems. That inventory drives all subsequent recovery prioritization.

Preserve Forensic Evidence

Before any remediation work begins, forensic evidence must be preserved from infected systems. This evidence is required for the forensic investigation that identifies the entry point and determines what data was accessed, and it is destroyed permanently if remediation begins before capture.

Evidence that must be preserved includes:

  • Memory captures from infected systems containing the ransomware executable, any encryption key material still resident in memory, attacker tools and scripts, and authentication tokens documenting which accounts the attacker used. Memory is destroyed on shutdown or reimage.
  • System logs from affected endpoints, servers, and domain controllers covering the 72-hour window before the encryption event was detected. Windows Event Logs have limited retention and may be overwritten if not captured quickly.
  • Network logs from firewalls, VPN concentrators, and network monitoring systems covering the same period. These document attacker movement and any data transferred out of the environment before encryption.
  • Photographs and screenshots of ransom notes, affected file directories, and any attacker communication displayed on systems. This basic evidence requires no specialized tools and takes minutes to collect.

Do not wipe or reimage any system until forensic evidence has been captured and your incident response team has confirmed remediation can proceed.

Identify the Ransomware Variant

Identifying the specific ransomware variant that encrypted your systems determines whether free decryption tools are available, informs your legal team about potential OFAC sanctions exposure before any payment decision, and supports the forensic investigation by providing context about the attacker group’s typical techniques.

Submit an encrypted file sample and the ransom note to the No More Ransom project’s Crypto Sheriff tool at nomoreransom.org, or to the ID Ransomware tool at id-ransomware.malwarehunterteam.com. These tools will identify the variant and indicate whether a free decryption key is available.

If a free decryption tool exists for your variant, do not run it yet. Threat elimination must be completed before any decryption or restoration work begins. Document the tool availability and return to it after the environment is confirmed clean.

Assess Backup Availability

Locate your most recent backup set and determine immediately whether backup systems were connected to the infected environment during the attack window, because connected backups may themselves be compromised or encrypted.

The questions your assessment must answer:

  • Is the backup recent enough to be operationally acceptable? A backup from six months ago may recover your systems but will lose months of data your business cannot afford to recreate.
  • Is the backup in an isolated location that the ransomware could not reach? Backups on network-attached drives connected to the infected environment are frequently encrypted alongside everything else.
  • Has the backup been tested? An untested backup is not confirmed to be recoverable until you attempt restoration. If your backups have not been tested recently, treat them as potentially unrecoverable until you confirm otherwise.

The backup assessment determines your primary recovery path. Organizations with clean, recent, isolated backups move to a defined recovery process. Organizations without viable backups face harder decisions about alternative recovery paths.

Make Key Decisions With Complete Information

Hours Three Through Eight

Make Key Decisions With Complete Information

The decisions required in this window should be made after initial containment is in place, scope assessment is underway, and backup availability is assessed. Making these decisions before that information is available produces decisions made with incomplete context.

The payment decision should not be made until backup availability is confirmed, the ransomware variant is identified and screened against the OFAC sanctions list, legal counsel has reviewed the payment implications, and your cyber insurance provider has been engaged. If clean backups are available, payment is rarely necessary. If backups are unavailable or compromised, the payment assessment requires the full legal and financial analysis that the first three hours of response have been building toward.

The regulatory notification decision must be assessed in parallel with technical response. If personal information was on affected systems, breach notification obligations under applicable frameworks have already begun running from the moment of discovery. Legal counsel must advise on which frameworks apply, what the notification timelines are, and what information must be included. In regulated industries, notification timelines as short as 36 hours from discovery mean that the notification process must begin in the first hours of the response, not after recovery is complete.

The law enforcement engagement decision should be made in this window. Filing a report with the FBI Internet Crime Complaint Center is recommended for all ransomware incidents and is required in some regulated industries. Law enforcement engagement does not slow your recovery and may provide threat intelligence about the attacker group that is relevant to your response decisions.

Notify Required Parties

Ransomware events trigger notification obligations to multiple parties simultaneously, and those obligations begin running from the moment of discovery regardless of where technical recovery stands.

Regulatory bodies in your applicable frameworks require notification within timelines that begin at discovery. Healthcare organizations must assess HIPAA breach notification obligations. Financial services organizations must assess FFIEC, SEC, and applicable state regulatory notification requirements. Defense contractors must notify DoD within 72 hours of discovery under DFARS 252.204-7012. These timelines cannot wait for recovery to be complete.

Contracting officers for defense contractors and for any organization with government contracts that require security incident notification must be notified promptly. Review contract terms for notification requirements and timelines.

Business associates and partners whose operations depend on your systems or who hold data affected by the incident require notification that allows them to take protective action for their own environments and obligations.

Your board or executive leadership requires a factual briefing covering confirmed scope, recovery path, estimated timeline, and legal obligations. This briefing enables the organizational decision-making authority that recovery decisions require.

Activate Business Continuity

Activate manual and offline alternatives for critical business functions that depend on affected systems. Operations cannot wait for technical recovery to complete, and the business continuity procedures that allow partial operations during recovery must be activated now if they have not already been.

If your business continuity procedures have not been documented and practiced before this incident, you are building them under pressure. Document what you implement so that the improvised procedures can be formalized after the incident is resolved.

Communicate clearly with staff about what systems are available, what manual procedures are in effect, and what staff should say to customers who ask about service disruptions. The last point requires legal review before staff receive guidance, because what employees say to customers during an active incident has legal implications that unreviewed guidance can create.

Hours Eight Through Twenty-Four

Eliminate the Threat Before Restoring Anything

Restoration of systems before the attacker has been fully removed from the environment produces reinfection. This is one of the most consistent patterns in poorly managed ransomware recoveries: systems are restored, the attacker uses maintained access to re-encrypt them, and recovery work must be repeated.

Threat elimination must be confirmed complete before any restoration begins. This requires professional incident response support if you do not have the internal forensic capability to confirm that all attacker persistence mechanisms, backdoors, and access points have been identified and removed.

Threat elimination includes removing all ransomware payloads and persistence mechanisms identified on infected systems, resetting all credentials in the environment including service accounts and domain administrator accounts, patching the specific vulnerability or misconfiguration that served as the entry point, and validating that no attacker access points remain in the environment before restoration begins.

Begin Prioritized Restoration

With threat elimination confirmed, restoration can begin. The restoration sequence should prioritize systems in the order that most rapidly enables critical operations, not in alphabetical order or by convenience.

Infrastructure dependencies must restore first. Domain controllers and DNS must be online before dependent systems can function. Authentication infrastructure failures cascade to every system that depends on it.

Production-critical systems restore second, in the sequence determined by your operational dependencies. The order matters: restoring a dependent system before the system it depends on creates additional problems that extend the restoration timeline.

End-user systems restore last, after the infrastructure and critical business systems that support them are confirmed operational.

Validate each restored system before connecting it to the production network. Confirmed-clean systems connecting to a still-recovering environment must be monitored for reinfection indicators in the hours following reconnection.

Monitor for Reinfection

Deploy enhanced monitoring across the environment as systems are restored. Attackers who maintained access through persistence mechanisms that were not fully identified during threat elimination will reactivate that access as systems come back online. Enhanced monitoring during the restoration phase detects that reactivation before it reaches critical systems.

Halt restoration immediately if indicators of active attacker presence are detected during the restoration phase. Resume only after additional remediation has confirmed the environment is clean.

After 24 Hours

The first 24 hours stabilize the incident. The work that follows determines whether your organization comes back stronger or remains vulnerable to a repeat event.

Mandatory post-incident work includes a complete forensic investigation that identifies the entry point, maps the full lateral movement path, determines what data was accessed or exfiltrated, and documents every attacker persistence mechanism. That investigation is the foundation of the post-incident hardening program that closes the specific gaps this attack exploited.

Post-incident hardening must address every security gap the investigation identified, not a general list of security improvements. The entry point vulnerability must be specifically closed. The lateral movement enablers must be specifically addressed. The logging gaps that prevented earlier detection must be specifically filled.

Your incident response plan must be updated based on what actually happened, because live incidents reveal gaps that document review does not. Every gap discovered during this response is a gap that will not slow the response to the next one.

Meet Our CEO, Matt Rosenthal

With more than 30 years of experience in business and technology leadership, Matt Rosenthal has guided organizations across healthcare, finance, legal, manufacturing, and defense through active ransomware events and the preparation investments that determine how those events resolve. As President and CEO of Mindcore Technologies, Matt leads a team that provides emergency ransomware response support, incident response planning, and the ongoing managed IT and cybersecurity services that reduce ransomware risk before an incident requires emergency response.

If your organization is in an active ransomware incident right now, contact Mindcore immediately. The response support your organization needs is available.

Frequently Asked Questions

Should we shut down all systems immediately when ransomware is detected?

No. Shutting down infected systems destroys volatile memory containing forensic evidence and potentially encryption key material that is critical to the investigation and recovery. The correct immediate action is network isolation, which stops spread while preserving the evidence on powered-on systems. Shut down infected systems only after forensic memory capture is complete and your incident response team has confirmed shutdown is appropriate.

What if we do not have an incident response team or plan?

Call your cyber insurance carrier immediately. Most policies provide access to approved incident response vendors who can be engaged within hours. If you do not have cyber insurance, contact a managed security services provider or incident response firm directly. The contact information for an incident response firm should be in your emergency contacts before an incident. If you do not have that contact established, search for established incident response firms and engage one as your first action after notifying your insurance carrier.

How do we know if our backups are safe to use?

Backups stored on network-attached systems connected to the infected environment during the attack may be encrypted or compromised. Backups stored in isolated locations, immutable cloud storage, or air-gapped media that was not connected to the environment during the attack are more likely to be clean. Verify backup integrity by checking hash values and attempting a test restoration to an isolated environment before committing to full restoration. Do not assume backups are clean because they appear intact in backup job logs.

When can we tell customers what happened?

Customer communication during an active ransomware incident requires legal review before any external statement is made. What you say, when you say it, and how you say it have legal implications that unreviewed communication can create or worsen. Legal counsel must review all external communications before release. For customers who are experiencing service disruption and contacting your organization, staff should acknowledge the disruption, confirm the organization is working to restore service, and avoid characterizing the cause of the disruption before legal review of that characterization has been completed.

How long will recovery take?

Recovery timelines depend on environment size, backup availability, and infection scope. Organizations with clean, recent, tested backups and good environment documentation recover in days. Organizations without viable backups or with extensive infection scope face recovery timelines of weeks to months. The most reliable estimate for your specific situation requires the scope assessment output from the first three hours of response and the backup availability assessment. Do not commit to a recovery timeline before those assessments are complete.

Get Help Now

If your organization is in an active ransomware incident, contact Mindcore immediately. Response time matters. Every hour of delay in expert engagement extends the timeline and cost of recovery.

Mindcore’s cybersecurity services and managed IT services include emergency ransomware response support for organizations across healthcare, finance, legal, manufacturing, and defense. If you are not in an active incident but want to ensure your organization never faces this situation without a plan, contact Mindcore to build the incident response capability, backup infrastructure, and security controls that determine how ransomware events resolve before one requires you to find out.

Related Posts

Matt Rosenthal