Furkan İkkan Türkçe
Back to posts

Ransomware Incident Response: First 60 Minutes Checklist

What to do in the first hour after a ransomware attack. A practical incident response checklist for sysadmins: isolate, preserve evidence, assess scope, and contain the threat.

Siber GüvenlikRansomwareIncident ResponseDisaster RecoveryActive DirectoryDigital ForensicsWindows Server

When ransomware hits your environment, the first 60 minutes decide how bad the next 60 days will be. Your ransomware incident response in the first hour isn't about cleaning up — it's about stopping the spread, preserving evidence, and buying yourself time to think. I've been through incident response scenarios where panic turned a 5-server problem into a 50-server disaster. Here's the checklist I follow when the alert fires and screens start showing ransom notes.

Confirm It's Actually Ransomware Before You Touch Anything

First step: verify. Not every encrypted file means ransomware. I've seen failed disk controllers, corrupt RAID arrays, and broken backup jobs that looked exactly like an attack. Before you start pulling network cables, confirm the indicators.

Check for:

  • Ransom note files (usually .txt or .html with names like README_RESTORE.txt, HOW_TO_DECRYPT.html)
  • Mass file extension changes (.locked, .encrypted, .crypt)
  • Shadow copies deleted (vssadmin list shadows returns nothing)
  • Suspicious processes consuming high CPU on multiple hosts
vssadmin list shadows
dir C:\*.txt /s /b | findstr /i "README RESTORE DECRYPT"
Get-Process | Sort-Object CPU -Descending | Select-Object -First 10

If you see ransom notes on multiple servers and shadow copies are gone, you're in an active incident. Time to move fast.

Isolate Infected Systems From the Network Immediately

This is the single most important step. Every minute an infected host stays on the network, the attacker is lateral-moving to your other servers. Don't shut the machines down — you'll lose volatile evidence in RAM. Just disconnect them.

Physically pull the network cable or disable the NIC:

Disable-NetAdapter -Name "Ethernet0" -Confirm:$false

On Linux hosts:

ip link set eth0 down

Don't forget to isolate at the switch level too. If you have access to your switch or firewall, shut down the VLAN or port group for the affected segment. I once watched an infection spread through a shared storage LUN because nobody thought to isolate the vSwitch — the ransomware jumped from one VM to three others via the iSCSI network.

Warning: Do not power off infected VMs yet. Live memory may contain encryption keys, process artifacts, and network connections that are critical for forensics and potential decryption.

Disable Compromised Accounts and Kill the Attackers' Access

Ransomware operators almost always have hands-on-keyboard access. They don't just deploy the encryptor and leave — they maintain persistence. If you only isolate the infected server but leave their backdoor account active, they'll come back through another path.

Immediately:

  1. Disable the suspected compromised user accounts in Active Directory
  2. Force password resets on all admin accounts — not just the obvious ones
  3. Check for newly created local admin accounts on affected hosts
  4. Review recent changes to AD group memberships, especially Domain Admins and Enterprise Admins
  5. Kill active RDP sessions and disable RDP access to non-essential systems
Disable-ADAccount -Identity "suspicious_user"
Get-ADGroupMember -Identity "Domain Admins" | Select-Object Name, whenChanged
quser /server:DC01

On Linux, check for unauthorized SSH keys and new users:

cat /home/*/.ssh/authorized_keys
grep x:0: /etc/passwd
last -20

Preserve Evidence Before You Start Cleaning Up

Everyone wants to start reimaging servers immediately. Don't. You need evidence for forensics, for law enforcement, and for your own post-mortem. Once you wipe a machine, that data is gone forever.

Capture the following before any remediation:

  • Memory dump from infected hosts (use tools like WinPMEM or LiME for Linux)
  • Network logs from your firewall, switch, and SIEM covering the last 72 hours
  • Copies of the ransom note files and any encrypted file samples
  • Event logs: Security, System, Application, and PowerShell operational logs
  • Backup system logs to check if the attackers tried to delete backups
wevtutil epl Security C:\evidence\security.evtx
wevtutil epl "Microsoft-Windows-PowerShell/Operational" C:\evidence\powershell.evtx

On Linux:

cp /var/log/syslog /evidence/
cp /var/log/auth.log /evidence/
journalctl --since "72 hours ago" > /evidence/journal.txt

Store all evidence on a write-once medium or an isolated share that nobody else can access. I keep a dedicated external drive locked in my office specifically for incident response — no network connectivity, no cloud sync, no risk of contamination.

Assess the Scope and Identify Patient Zero

You need to figure out how far this has spread and where it started. Patient zero tells you the attack vector, and the attack vector tells you what to fix so it doesn't happen again.

Check your monitoring tools, SIEM, and endpoint detection for:

  • Alerts from the last 24–48 hours that were dismissed or missed
  • Unusual authentication patterns (logins at 2 AM from unfamiliar IPs)
  • Bulk file access or modification events across file servers
  • New scheduled tasks or startup entries on multiple hosts
Get-ScheduledTask | Where-Object {$_.State -eq "Ready" -and $_.Date -gt (Get-Date).AddDays(-2)}

On Linux, check crontab and systemd timers:

crontab -l
ls -la /etc/cron.*
systemctl list-timers --all

Most ransomware enters through one of three paths: phishing, exposed RDP, or a compromised VPN credential. Identifying which one happened to you determines your entire recovery strategy.

Do Not Pay the Ransom — Call for Help First

I'm not going to tell you what to decide about paying. That's a business decision. But do not pay in the first hour. You don't even know if your backups are intact yet. I've seen organizations pay 6-figure ransoms only to discover their offline backups were fine the whole time.

Before any payment discussion:

  • Verify your backup status (are offline/immutable backups available?)
  • Check if a free decryptor exists at nomoreransom.org
  • Contact your incident response firm or cybersecurity vendor
  • Notify legal and compliance teams — data breach notification timelines may apply
  • Document everything with timestamps

As I covered in my previous post about backup failures (https://furkanikkan.com/urun/geri-yuklemede-basarisiz-olan-yedekler-sessiz-veri-kaybi-senaryosu-27), the backup you think is working might not restore when you need it. Now is the time to find out.

The First Hour Sets the Tone for Everything

Ransomware response is chaos management. You will never follow this checklist perfectly — every incident has its own ugly surprises. But having a structured plan means you're making decisions instead of reacting blindly. Isolate, preserve evidence, kill access, assess scope, then get help. In that order.

Print this checklist. Tape it to the wall next to your monitoring station. When the alert fires at 3 AM and your phone is ringing, you won't have time to look it up.

Cover image: CNE CNA C6F · PDM (Openverse / kamu malı) · https://www.flickr.com/photos/94966166@N02/52401145106