Ransomware Defense in Practice: Hardening, Detection, and IR Config Guide

Ransomware defense in practice: disable SMBv1, SSH key auth, immutable backups, auditd/Sysmon behavior detection, and post-infection IR config.

Scope: This tutorial covers ransomware defense for Windows/Linux servers, endpoints, and backup systems. Prevent before encryption; contain and recover after. For enterprise IT ops and SOC teams.

Prerequisites

• Server/endpoint admin (Windows Administrator, Linux root)
• Independent backup storage (NAS, offsite disk, or cloud) that does not share credentials with production hosts
• Windows: PowerShell 5.1+; Linux: CentOS 7+/Ubuntu 20.04+ recommended
• Know the 3-2-1 backup rule (3 copies, 2 media types, 1 offsite)

How It Works

Ransomware kill chain: initial access (RDP brute force, phishing attachments, unpatched vulns) → lateral movement (SMB, WMI mass spread) → privilege escalation → encrypt-and-extort (encrypt local and share files, delete volume shadows) → ransom demand. Defense logic: defense-in-depth + immutable backups. Defense-in-depth shrinks attack surface and stretches detection time. Immutable backups guarantee cheap recovery even after encryption, which collapses the ransom negotiation.

Procedure

Step 1: Disable High-Risk Services and Protocols

Windows: disable SMBv1 (favorite ransomware lateral protocol):

`Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
dism /online /disable-feature /featurename:SMB1Protocol /norestart`

Linux: close unused remote-admin ports; replace password auth with SSH keys:

`sed -i 's/^#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshd`

Step 2: Build Immutable Backups

Linux: set immutable attribute on the backup dir (even root cannot delete/modify directly):

`chattr +i /backup/archive
lsattr /backup/archive`

Windows: versioned backups on a schedule (PowerShell scheduled task):

`robocopy D:\data E:\backup\data /MIR /R:2 /W:5
schtasks /create /tn BackupJob /tr "robocopy D:\data E:\backup\data /MIR" /sc daily /st 02:00`

Step 3: Deploy Behavior Detection

Linux: auditd on bulk writes to sensitive dirs:

`auditctl -w /data -p wa -k ransom_watch
auditctl -a always,exit -F dir=/data -F perm=w -k ransom_watch`

Windows: enable Sysmon (Event ID 11 file create, ID 1 process create). Watch `cmd.exe` bulk-calling `cipher`, `vssadmin`, and other ransomware-signature commands.

Step 4: Incident Response Procedure

Once infection is confirmed: (1) immediately unplug / firewall-isolate the infected host; (2) preserve the scene, do not reboot (avoid losing memory evidence); (3) inspect and stop the infection-source share; (4) restore from immutable backup; (5) if restore fails, try free decryptors (No More Ransom); do not pay the ransom.

Configuration Verification

Prove the defense: (1) SMBv1 disabled (`Get-SmbServerConfiguration | Select EnableSMB1Protocol` outputs False); (2) `rm /backup/archive` returns Operation not permitted — immutable bit holds; (3) a test script bulk-writing `/data` shows up in `ausearch -k ransom_watch`.

FAQ

FAQ1: Can data be recovered after encryption?

Depends on three things: independent backup off the infected host (immutable is safest); whether volume shadows were wiped (Windows: `vssadmin list shadows` for leftovers); whether a public decryptor exists. Most families have companion decryptors; check No More Ransom.

FAQ2: Why did backups get encrypted too?

Most common cause: backup volume mapped over SMB with excessive permissions; ransomware encrypts along the share. Fix: dedicated backup account, least privilege, no write from production hosts. Linux: `chattr +i` or object-storage immutable versioning so backups are write-once.

Summary

No silver bullet. Three levers: shrink attack surface + immutable backups + behavior detection. Disable SMBv1 and enable key auth to cut initial access. 3-2-1 immutable backups make data recoverable. auditd/Sysmon shortens time-to-detect. Run a restore drill every quarter. Keep patching and watching threat intel.