Ransomware Response

Ransomware encrypts files and demands payment for decryption keys. This playbook directs your response from initial detection through containment, scope assessment, and recovery. The encryption-specific procedures here differ from general malware response: ransomware requires immediate network isolation to prevent lateral encryption spread, backup integrity verification before any recovery attempt, and careful sequencing of system restoration to avoid re-infection.

Activation criteria

Invoke this playbook when any of the following conditions are confirmed or strongly suspected:

Roles

For organisations without dedicated security staff, the incident commander and technical lead roles are typically combined. The evidence custodian role remains distinct to maintain chain of custody integrity.

Response overview

                              +------------------+
                              |    DETECTION     |
                              |  Ransomware      |
                              |  indicators      |
                              +--------+---------+
                                       |
                                       v
                        +--------------+---------------+
                        |         PHASE 1              |
                        |    IMMEDIATE ISOLATION       |
                        |    (0-30 minutes)            |
                        +--------------+---------------+
                                       |
                        +--------------+---------------+
                        |                              |
                        v                              v
              +---------+----------+        +----------+---------+
              |  Contained to      |        |  Spreading or      |
              |  single endpoint   |        |  scope unknown     |
              +---------+----------+        +----------+---------+
                        |                              |
                        |                   +----------+---------+
                        |                   |  Network segment   |
                        |                   |  isolation         |
                        |                   +----------+---------+
                        |                              |
                        +--------------+---------------+
                                       |
                                       v
                        +--------------+---------------+
                        |         PHASE 2              |
                        |    SCOPE ASSESSMENT          |
                        |    (30 min - 4 hours)        |
                        +--------------+---------------+
                                       |
                                       v
                        +--------------+---------------+
                        |         PHASE 3              |
                        |    BACKUP VERIFICATION       |
                        |    (2-8 hours)               |
                        +--------------+---------------+
                                       |
                                       v
                        +--------------+---------------+
                        |         PHASE 4              |
                        |    RECOVERY                  |
                        |    (8-72 hours)              |
                        +--------------+---------------+
                                       |
                                       v
                        +--------------+---------------+
                        |         PHASE 5              |
                        |    POST-INCIDENT             |
                        |    (72+ hours)               |
                        +------------------------------+

Figure 1: Ransomware response phases with timing expectations

Phase 1: Immediate isolation

Objective: Stop ransomware spread by isolating affected systems from the network.

Timeframe: Complete within 30 minutes of detection.

1. Isolate confirmed infected endpoints immediately. Do not shut down infected machines as this destroys volatile memory evidence. Instead, disconnect network connectivity while maintaining power:

   For wired connections, physically disconnect the ethernet cable. For wireless, disable the wireless adapter through the operating system or, if available, via MDM remote command:

   # Windows: Disable all network adapters
   Get-NetAdapter | Disable-NetAdapter -Confirm:$false

   # Linux: Bring down network interfaces
   for iface in $(ip -o link show | awk -F': ' '{print $2}'); do
     sudo ip link set "$iface" down
   done

If remote command execution is unavailable and physical access is not immediate, instruct the user by phone to disconnect the network cable or enable airplane mode.

2. Assess immediate spread indicators. Query your SIEM or EDR for the last 60 minutes of activity from the infected host:

   Search parameters:
   - Source IP/hostname: [infected system]
   - Destination: Any internal IP
   - Ports: 445 (SMB), 139 (NetBIOS), 3389 (RDP), 5985/5986 (WinRM)
   - Time range: 60 minutes before detection to now

Any successful connections to these ports indicate potential lateral movement targets requiring immediate isolation.

3. Isolate network segments if spread is confirmed or suspected. When the infected endpoint communicated with file servers, domain controllers, or multiple endpoints, isolate the entire network segment:

   +------------------------------------------------------------------+
   |                         NETWORK ISOLATION                        |
   +------------------------------------------------------------------+
   |                                                                  |
   |  QUARANTINE SEGMENT                    PROTECTED SEGMENTS        |
   |  +------------------------+            +----------------------+  |
   |  |                        |     X      |                      |  |
   |  |  Infected endpoint     +----/-/-----+  Domain controllers  |  |
   |  |  Potentially infected  |   Block    |                      |  |
   |  |  endpoints             |            +----------------------+  |
   |  |                        |     X      +----------------------+  |
   |  |  Contacted file        +----/-/-----+                      |  |
   |  |  servers               |   Block    |  File servers        |  |
   |  |                        |            |  (unaffected)        |  |
   |  +------------------------+            +----------------------+  |
   |           |                            +----------------------+  |
   |           |                     X      |                      |  |
   |           +--------------------/-/-----+  Backup systems      |  |
   |                               Block    |  (CRITICAL)          |  |
   |                                        +----------------------+  |
   +------------------------------------------------------------------+

Figure 2: Network segment isolation to contain ransomware spread

Implement segment isolation through firewall rules or switch ACLs:

   # Cisco IOS example: Block infected VLAN from reaching critical systems
   access-list 150 deny ip 10.1.50.0 0.0.0.255 10.1.10.0 0.0.0.255
   access-list 150 deny ip 10.1.50.0 0.0.0.255 10.1.20.0 0.0.0.255
   access-list 150 permit ip any any

   interface Vlan50
    ip access-group 150 in

4. Disable compromised accounts. If the ransomware executed under a specific user context, disable that account immediately:

   # Disable user account in Active Directory
   Disable-ADAccount -Identity "compromised_user"

   # Force sign-out from all sessions
   Get-ADUser -Identity "compromised_user" |
     Set-ADUser -Replace @{adminCount=1}

If the ransomware used a service account or administrative credentials, disable those accounts and rotate credentials for all accounts with similar privilege levels.

5. Preserve volatile evidence before any system changes. Capture memory from at least one infected system before reimaging:

   # Using WinPMEM (run from USB or network share, not infected disk)
   winpmem_mini_x64.exe infected_host_memory.raw

Store memory captures on a separate, isolated system. Do not write evidence files to the infected system’s disk.

Decision point: If ransomware is confirmed contained to a single endpoint with no evidence of lateral movement, you may proceed directly to Phase 2 with that endpoint isolated. If spread is confirmed or cannot be ruled out within 30 minutes, complete segment isolation before proceeding.

Checkpoint: Before proceeding to Phase 2, confirm:

• All confirmed infected endpoints isolated from network
• Network segments isolated if spread detected
• Compromised accounts disabled
• Volatile evidence preserved from at least one infected system
• Backup systems confirmed unreachable from infected segments

Phase 2: Scope assessment

Objective: Determine the extent of encryption, identify the ransomware variant, and assess impact to operations.

Timeframe: 30 minutes to 4 hours.

1. Identify the ransomware variant. Examine ransom notes and encrypted file characteristics:

   Ransom note filenames follow predictable patterns: README.txt, DECRYPT_INSTRUCTIONS.html, HOW_TO_RECOVER.txt, or variant-specific names. The note content typically identifies the ransomware family and provides payment instructions.

   Upload a ransom note and sample encrypted file (not containing sensitive data) to identification services:

   • ID Ransomware: https://id-ransomware.malwarehunterteam.com/
   • No More Ransom: https://www.nomoreransom.org/

   Check for known decryptors. Some ransomware variants have been broken and free decryption tools exist. No More Ransom maintains a repository of available decryptors.

2. Map encryption scope across systems. For each potentially affected system, determine encryption status:

   # PowerShell: Check for encrypted files by extension on remote system
   # Run from management workstation against isolated but powered systems
   $targetComputers = @("server01", "server02", "workstation15")
   $ransomwareExtensions = @("*.encrypted", "*.locked", "*.crypted", "*.cry", "*.crypto")

   foreach ($computer in $targetComputers) {
       Write-Host "Checking $computer..."
       Invoke-Command -ComputerName $computer -ScriptBlock {
           param($extensions)
           foreach ($ext in $extensions) {
               $files = Get-ChildItem -Path C:\ -Filter $ext -Recurse -ErrorAction SilentlyContinue
               if ($files) {
                   Write-Output "$env:COMPUTERNAME : Found $($files.Count) files matching $ext"
               }
           }
       } -ArgumentList (,$ransomwareExtensions)
   }

Document findings in a scope matrix:

3. Determine initial infection vector. Understanding how ransomware entered guides remediation and prevents reinfection. Common vectors and investigation approaches:

   Phishing email: Search email logs for messages delivered to the infected user in the 24 hours before detection. Look for attachments (.zip, .doc with macros, .js, .exe) or links to unusual domains.

   Exposed RDP: Check firewall logs for external RDP connections (port 3389) to infected systems. Query authentication logs for unusual RDP logon patterns.

   Exploited vulnerability: Review patch status of infected systems. Check for recent exploitation attempts in IDS/IPS logs.

   Compromised credentials: Review authentication logs for impossible travel, unusual times, or unfamiliar source IPs for accounts on infected systems.

4. Assess operational impact. Determine which business functions are affected and their tolerance for downtime:

   Function	Systems affected	Current status	Maximum tolerable downtime
   Programme delivery	Grants management encrypted	Unavailable	48 hours
   Financial operations	Finance system unaffected	Operational	N/A
   Communications	Email servers unaffected	Operational	N/A
   Field operations	File server encrypted	Degraded	24 hours

Checkpoint: Before proceeding to Phase 3, confirm:

• Ransomware variant identified (or confirmed unidentifiable)
• Encryption scope documented for all systems
• Initial infection vector identified or investigation ongoing
• Operational impact assessed with priority ranking
• Free decryptor checked and status documented

Phase 3: Backup verification

Objective: Confirm backup integrity and identify clean restore points before beginning recovery.

Timeframe: 2 to 8 hours.

1. Verify backup system integrity. Confirm the backup infrastructure itself was not compromised:

   Check backup server for indicators of compromise:

   • Ransomware file extensions or ransom notes
   • Unexpected processes or services
   • Modified backup schedules or retention policies
   • Deleted or modified backup jobs
   • Unusual authentication events

   # Check for recently modified backup configurations
   find /etc/backup -type f -mtime -7 -ls

   # Review backup job history for unexpected changes
   grep -i "delete\|modify\|cancel" /var/log/backup/audit.log | tail -100

2. Identify clean restore points. Determine the last backup taken before ransomware execution. The ransomware execution timestamp from Phase 2 defines your recovery point objective:

   Timeline example:

   Day 1, 09:00  - Daily backup completed (CLEAN)
   Day 1, 14:30  - Ransomware executed (INFECTION POINT)
   Day 1, 15:00  - Detection and isolation
   Day 2, 09:00  - Daily backup (if reached) would be COMPROMISED

   Clean restore point: Day 1, 09:00 backup
   Maximum data loss: 5.5 hours of work

For immutable or air-gapped backups, verify the immutability window extends past the ransomware execution time.

3. Test restore capability. Perform test restores to an isolated environment before committing to full recovery:

   +------------------------------------------------------------------+
   |                    RESTORE TEST ENVIRONMENT                      |
   +------------------------------------------------------------------+
   |                                                                  |
   |   ISOLATED TEST NETWORK                  BACKUP STORAGE          |
   |   +------------------------+            +--------------------+   |
   |   |                        |            |                    |   |
   |   |  Test VM               |<-----------+  Backup repository |   |
   |   |  (restored from        |  Restore   |                    |   |
   |   |   backup)              |            +--------------------+   |
   |   |                        |                                     |
   |   +------------------------+                                     |
   |            |                                                     |
   |            v                                                     |
   |   +------------------------+                                     |
   |   |  Verification:         |                                     |
   |   |  - Files readable?     |                                     |
   |   |  - No ransomware?      |                                     |
   |   |  - Data integrity?     |                                     |
   |   +------------------------+                                     |
   |                                                                  |
   +------------------------------------------------------------------+

Figure 3: Isolated restore test environment

Test restore verification checks:

• Files open correctly and contain expected data
• No ransomware extensions or ransom notes present
• System boots and operates normally (for full system restores)
• Database integrity checks pass (for database restores)
• Application functionality verified

4. Calculate recovery time and data loss. Based on backup verification, determine realistic recovery parameters:

   Recovery metric	Value	Implication
   Last clean backup	2024-03-15 09:00	Reference point for all restores
   Data loss window	5.5 hours	Work since last backup is lost
   Estimated restore time (file server)	4 hours	500GB at ~35MB/s
   Estimated restore time (database)	2 hours	Full + transaction log replay
   Total estimated recovery	12-18 hours	Sequential recovery, validation included

Checkpoint: Before proceeding to Phase 4, confirm:

• Backup infrastructure verified uncompromised
• Clean restore points identified for all affected systems
• Test restores completed successfully
• Recovery time and data loss calculated and communicated to leadership
• Decision on ransom payment documented (see Ransom payment framework below)

Ransom payment decision framework

The decision to pay ransom involves technical, legal, financial, and ethical considerations. This framework supports decision-making but does not prescribe an outcome.

Technical factors:

• Decryptor availability: Free decryptor available? Paying is unnecessary.
• Backup status: Clean backups verified? Recovery without payment is viable.
• Decryptor reliability: Even when paid, decryptors fail 20-30% of the time or decrypt slowly.

Legal factors:

• Sanctions compliance: Payment to sanctioned entities (OFAC, UK sanctions lists) may be illegal regardless of circumstance.
• Regulatory requirements: Some jurisdictions require reporting ransomware incidents to authorities before payment decisions.
• Insurance: Cyber insurance policies may cover ransom payments but require specific procedures.

Organisational factors:

• Mission impact: How does extended downtime affect beneficiaries and programme delivery?
• Financial capacity: Can the organisation absorb the payment and still operate?
• Precedent: Payment funds criminal operations and may increase targeting of similar organisations.

Decision authority: The decision to pay ransom is an executive and board-level decision, not a technical decision. IT provides the technical assessment; leadership decides based on full organisational context.

Document the decision and rationale regardless of outcome.

Phase 4: Recovery

Objective: Restore systems to operational status in priority order while preventing reinfection.

Timeframe: 8 to 72 hours depending on scope.

1. Establish clean recovery environment. Before restoring any systems, prepare a verified clean network segment:

   +------------------------------------------------------------------+
   |                    RECOVERY ARCHITECTURE                         |
   +------------------------------------------------------------------+
   |                                                                  |
   |  QUARANTINE (infected)        RECOVERY (clean)                   |
   |  +--------------------+       +--------------------+             |
   |  |                    |       |                    |             |
   |  |  Infected systems  |   X   |  Restored systems  |             |
   |  |  (evidence only)   +---/---+  (validated clean) |             |
   |  |                    |       |                    |             |
   |  +--------------------+       +---------+----------+             |
   |                                         |                        |
   |                                         | Controlled             |
   |                                         | reconnection           |
   |                                         v                        |
   |                               +---------+----------+             |
   |                               |                    |             |
   |                               |  Production        |             |
   |                               |  (after validation)|             |
   |                               |                    |             |
   |                               +--------------------+             |
   |                                                                  |
   +------------------------------------------------------------------+

Figure 4: Recovery architecture with quarantine separation

2. Remediate infection vector. Before restoring systems, close the entry point identified in Phase 2:

   Vector	Remediation
   Phishing	Block sender domain, update mail filtering rules, notify users
   Exposed RDP	Disable external RDP, implement VPN or ZTNA requirement
   Unpatched vulnerability	Apply patches to backup images before restore, or patch immediately after restore before network connection
   Compromised credentials	Reset all potentially affected passwords, enforce MFA

3. Restore systems in priority order. Recovery sequence prevents dependency failures and prioritises critical services:

   Priority 1: Infrastructure (hours 0-4)

   • Domain controllers (if affected)
   • DNS servers
   • Authentication systems

   Priority 2: Critical applications (hours 4-12)

   • Finance systems
   • Programme management systems
   • Communication systems (if affected)

   Priority 3: File services (hours 12-24)

   • File servers
   • SharePoint/document management
   • Collaboration platforms

   Priority 4: User systems (hours 24-72)

   • Workstations (reimage rather than restore where possible)
   • Non-critical applications

   For each system restoration:

   Restore procedure per system:

   1. Restore to isolated recovery network
   2. Boot and verify basic functionality
   3. Scan with updated antivirus/EDR
   4. Verify no ransomware indicators present
   5. Apply any patches released since backup date
   6. Validate application functionality
   7. Move to production network segment
   8. Verify connectivity and access
   9. Document completion

4. Restore user data with validation. File server and user data restoration requires additional verification:

   # Scan restored files for ransomware indicators
   # Run on restored but isolated file server

   # Check for known ransomware extensions
   find /data -type f \( -name "*.encrypted" -o -name "*.locked" -o -name "*.crypted" \) > /tmp/suspicious_files.txt

   # Check for ransom notes
   find /data -type f \( -name "README*.txt" -o -name "*DECRYPT*" -o -name "*RANSOM*" \) >> /tmp/suspicious_files.txt

   # Report findings
   if [ -s /tmp/suspicious_files.txt ]; then
       echo "WARNING: Suspicious files found in restore"
       cat /tmp/suspicious_files.txt
   else
       echo "No ransomware indicators found in restored data"
   fi

5. Reconnect users progressively. Do not enable all user access simultaneously. Staged reconnection allows monitoring for reinfection:

   • Hour 0-2: IT staff only, verify functionality
   • Hour 2-4: Critical function users (finance, programme leads)
   • Hour 4-8: Department heads and managers
   • Hour 8+: All staff in batches of 20-30

   Monitor security tools closely during reconnection for any indicators of persistent infection or reinfection.

Checkpoint: Before proceeding to Phase 5, confirm:

• All priority systems restored and validated
• User access restored progressively with monitoring
• No ransomware indicators detected in restored systems
• Infection vector remediated
• Normal operations resumed

Phase 5: Post-incident

Objective: Document the incident, implement improvements, and complete required notifications.

Timeframe: 72 hours onwards.

1. Complete evidence preservation handoff. Transfer preserved evidence to long-term secure storage. Evidence retention requirements vary by jurisdiction and whether law enforcement involvement is planned:

   Evidence type	Retention period	Storage requirement
   Memory captures	12 months minimum	Encrypted offline storage
   Disk images	12 months minimum	Encrypted offline storage
   Log exports	7 years (if financial data involved)	Secure archive
   Ransom notes	Indefinite	Secure archive
   Communication records	7 years	Secure archive

   Follow chain of custody procedures documented in Evidence Collection.

2. Complete regulatory notifications. Ransomware incidents involving personal data may trigger notification requirements:

   UK GDPR/Data Protection Act 2018: If personal data was affected (encrypted or potentially accessed), assess whether notification to the ICO is required. The 72-hour notification window begins when you become aware of the breach, not when recovery completes.

   Donor requirements: Review grant agreements for incident notification requirements. USAID, FCDO, and UN agencies have specific notification procedures.

   Cyber insurance: Notify your insurer according to policy terms, typically within 24-72 hours of discovery.

3. Conduct post-incident review. Schedule a review meeting within 2 weeks of recovery completion. Participants should include incident responders, affected department heads, and leadership.

   Review agenda:

   • Timeline reconstruction: What happened and when?
   • Detection effectiveness: How was ransomware detected? How long before detection?
   • Response effectiveness: What worked? What caused delays?
   • Recovery effectiveness: Did backups work as expected?
   • Root cause: How did ransomware enter? Why did controls fail?
   • Improvements: What changes prevent recurrence?

4. Implement improvements. Common post-ransomware improvements:

   • Backup isolation: Implement air-gapped or immutable backups if not already in place
   • Network segmentation: Reduce lateral movement capability
   • Endpoint detection: Deploy or enhance EDR capability
   • User training: Targeted phishing awareness based on infection vector
   • Patch management: Address any gaps identified in vulnerability management

   Document improvements with owners and timelines. Track to completion.

5. Update response procedures. Revise this playbook and related procedures based on lessons learned. Document:

   • What steps were unclear or missing?
   • What tools or access were unavailable when needed?
   • What communication templates needed revision?

Communications

Communication templates

Initial notification (Executive leadership, 1 hour):

Subject: [SECURITY INCIDENT] Ransomware - Initial notification

We are responding to a ransomware incident affecting [number] systems.

Current status: Phase 1 - Containment (isolation in progress/complete)

Known impact:
- [X] systems confirmed encrypted
- [Departments/functions] affected
- Backup systems: [Status]

Immediate actions taken:
- Affected systems isolated from network
- Incident response team activated
- Backup verification in progress

Next update: [Time, within 4 hours]

Incident commander: [Name]
Contact: [Phone/secure channel]

This information is confidential. Do not forward.

Staff notification (All staff, 4 hours):

Subject: IT Service Disruption - Action Required

We are experiencing a security incident affecting some IT systems.

Impact:
- [List affected systems/services]
- [List unaffected systems if helpful]

What you should do:
1. Do not attempt to access affected systems
2. Save any work in progress to [unaffected location] if possible
3. Report any unusual activity to IT immediately at [contact]
4. Do not discuss incident details externally

What we are doing:
- Our IT team is working to restore affected services
- We expect [service] to be restored by [realistic time]
- Updates will be provided every [X] hours

If you have questions, contact [helpdesk contact].

Thank you for your patience.

Board notification (24 hours):

Subject: Security Incident Report - Ransomware

Summary:
On [date] at [time], we detected a ransomware infection affecting [scope].
The incident is currently in [phase] of response.

Impact:
- Systems affected: [number and types]
- Data affected: [classification and volume]
- Operational impact: [description]
- Financial impact: [estimate if known]

Response:
- Containment: [status]
- Recovery: [status and timeline]
- Root cause: [identified/under investigation]

Regulatory:
- ICO notification: [required/not required/submitted]
- Donor notifications: [status]

Ransom:
- Demand: [amount if known]
- Payment decision: [decision and rationale]

Next steps:
[Key milestones and timeline]

Full incident report will be provided upon completion of post-incident review.

Law enforcement notification

Consider reporting ransomware incidents to law enforcement. In the UK, report to:

• Action Fraud: https://www.actionfraud.police.uk/ (for all cyber crimes)
• National Cyber Security Centre: https://www.ncsc.gov.uk/section/about-this-website/report-a-cyber-incident (for significant incidents)

Benefits of reporting include access to intelligence on the ransomware variant, potential identification of decryptors, and contribution to broader threat intelligence. Law enforcement does not typically disrupt recovery operations.

For international organisations, consider reporting to national cyber security agencies in relevant operating countries.

See also

• Evidence Collection -forensic evidence preservation procedures
• Malware Containment -general malware response procedures
• Backup Recovery -detailed restore procedures
• Incident Triage Matrix -severity classification criteria
• Data Breach Response -if personal data was affected
• Incident Response Framework -framework and concepts