Ransomware Recovery — Backups, Negotiation, and Re-infection Prevention

Ransomware recovery is where IR meets business continuity. Technical decisions have direct business consequences — a wrong decision here is measured in days of downtime, not hours.

Backup Assessment Framework

BACKUP VIABILITY CHECKLIST
────────────────────────────────────────────────────────────────────
Question                              | Why It Matters
────────────────────────────────────────────────────────────────────
1. Does the backup exist?             | Basic existence check
   wbadmin get versions               |
                                      |
2. When was the last successful       | Determines data loss window
   backup? (date and time)            | (RPO — Recovery Point Objective)
                                      |
3. Is the backup BEFORE initial       | Attacker had access for weeks before
   attacker access? (not just before  | encryption — backup must predate
   encryption)                        | their initial foothold
                                      |
4. Is the backup itself encrypted?    | Ransomware targets backup servers
   (restore 10 test files)            | Test before committing to full restore
                                      |
5. Is the backup accessible from a   | If backup is on the same domain,
   clean environment?                 | attacker may still have access
                                      |
6. How long does restoration take?    | Business continuity: if 72 hours
   (full restore estimate)            | to restore, is business viable for 72h?
                                      |
7. Is there a free decryptor?        | No More Ransom → check before paying
   nomoreransom.org                   |
────────────────────────────────────────────────────────────────────

Identifying Free Decryptors

Resources for free ransomware decryptors:
1. nomoreransom.org — largest collection, law enforcement partnerships
   Search by: ransom note contents, encrypted file extension, or sample upload

2. ID Ransomware — identifies family from ransom note/sample
   id-ransomware.malwarehunterteam.com
   Once identified → check if decryptor exists

3. VirusTotal → upload ransom note → comments may mention decryptor
4. GitHub → search "[family name] decryptor"
5. Ransomware family's own leak site (dark web) — some groups provide
   decryptors after arrests or business decisions

Families with historical free decryptors (check current availability):
  Dharma/Crysis, REvil (some variants), Maze (retired, keys released),
  Avaddon (keys released), DarkSide (some variants), STOP/DJVU,
  TeslaCrypt (master key released), GandCrab (retired, keys released)

Families with no known decryptor (as of training cutoff):
  LockBit 3.0, BlackCat/ALPHV, BlackMatter, Conti (successor groups),
  Hive (law enforcement seized keys — check FBI resources)

Credential Rotation After Ransomware

# MANDATORY: Reset ALL privileged credentials before reconnecting

# 1. Domain Admin accounts (all of them)
$domain_admins = Get-ADGroupMember "Domain Admins" | 
  Where-Object {$_.objectClass -eq "user"}
$domain_admins | ForEach-Object {
  Set-ADAccountPassword -Identity $_.SamAccountName `
    -NewPassword (ConvertTo-SecureString "$(New-Guid)" -AsPlainText -Force)
    -Reset
}

# 2. Double-reset the KRBTGT account (invalidates ALL Kerberos tickets including Golden Tickets)
# First reset:
Set-ADAccountPassword -Identity krbtgt `
  -NewPassword (ConvertTo-SecureString "$(New-Guid)" -AsPlainText -Force) -Reset
# Wait 10 hours (max Kerberos ticket lifetime) — or force on all DCs immediately:
# Replicate the change to all DCs: repadmin /syncall /AdeP
# Second reset (required — each DC has the previous key cached):
Set-ADAccountPassword -Identity krbtgt `
  -NewPassword (ConvertTo-SecureString "$(New-Guid)" -AsPlainText -Force) -Reset

# 3. Service accounts (anything running as a domain account)
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} |
  ForEach-Object {
    Write-Host "Service account: $($_.SamAccountName)"
    # Reset each service account password
    # Update the service configuration on affected systems
  }

# 4. Local administrator accounts (LAPS if deployed)
# If LAPS not deployed: manually reset on all systems
# If LAPS deployed: rotate LAPS passwords now

# 5. Application credentials stored in config files
# Search for plaintext passwords in config files on affected systems

Clean Environment Recovery Procedure

RECOVERY ORDER:
────────────────────────────────────────────────────────────────────
Phase 1: Infrastructure (Days 1-2)
  ├── Build new Domain Controllers from scratch (not restore)
  ├── Verify AD replication is clean
  ├── Deploy new DNS with clean forwarders
  └── Rotate krbtgt (both resets)

Phase 2: Critical Business Systems (Days 2-3)
  ├── Identify MINIMUM systems needed to operate
  ├── Build from golden image (NOT restore of system state)
  ├── Restore DATA only from verified pre-compromise backup
  ├── Deploy EDR with maximum telemetry before network connection
  └── Connect ONE system at a time, verify clean before next

Phase 3: Secondary Systems (Days 3-7)
  ├── Build remaining servers from golden images
  ├── Restore user data from backup
  └── Verify no re-infection indicators before each batch

Phase 4: Post-Recovery Hardening
  ├── Enforce MFA on all remote access (VPN, RDP, web apps)
  ├── Review and close unnecessary network paths (RDP exposure, SMB)
  ├── Deploy Privileged Access Workstations for admin tasks
  ├── Test backup restoration monthly (don't assume — verify)
  └── Document lessons learned and update IR playbook

Negotiation Basics

⚠️  CRITICAL: Never negotiate without legal counsel present. ⚠️

When negotiation may be necessary:
- No viable backup
- Decryptor not available
- Business impact of downtime exceeds ransom demand
- Double extortion with regulated data

NEVER negotiate if:
- The decryptor is publicly available for free
- Law enforcement has seized decryption keys for this family
- The ransom demand is for a sanctioned entity (OFAC check REQUIRED before payment)

Pre-negotiation checklist:
1. OFAC check: verify ransomware group is not on OFAC SDN list
   (paying a sanctioned group violates US federal law)
   Reference: treasury.gov/resource-center/sanctions/SDN-List
   
2. Cyber insurance: notify immediately — policy may cover negotiator fees,
   ransom payment, and restoration costs
   
3. Law enforcement notification: FBI, CISA — may have decryption keys
   (Hive ransomware keys obtained by FBI, Ragnar Locker, others)
   
4. Payment methodology: ransom typically demanded in Monero (XMR) or Bitcoin (BTC)
   Cryptocurrency purchase requires identity verification (KYC) — document the
   purchase chain for legal and tax purposes

5. Test decryption: NEVER pay full ransom before testing decryptor on a small
   sample of files — verify the decryptor works before completing payment

Retrieval Practice

An organization was hit with LockBit 3.0 ransomware. The backup server was also encrypted. The only backup is a cloud-based offsite tape backup from 72 hours ago. The ransom is $500,000. The CEO wants to know: should we pay? Walk through the decision framework.

Reveal answer

The decision requires answering several questions before making a recommendation: (1) Is LockBit 3.0 on the OFAC sanctions list? As of the training cutoff, LockBit itself was not designated, but always check the current SDN list before payment — paying a sanctioned group violates federal law regardless of business need. (2) Is there a free decryptor? Check nomoreransom.org and the NCA/FBI resources for LockBit keys. Law enforcement operations against LockBit (2024) resulted in some decryption keys. (3) What is the recovery time objective? If restoring 72-hour-old tape takes 5 days and the business can tolerate 5 days of downtime, restoration is viable despite the data loss. If the business cannot survive 5 days (hospital, financial clearing), payment becomes a business continuity decision. (4) Is this double extortion? If LockBit exfiltrated data before encrypting, payment to prevent leak publication must be evaluated separately — even full restoration from backup does not address the exfiltration threat. (5) What data was in the 72-hour window? Files modified or created in the past 72 hours are permanently lost regardless of payment or restoration — assess the business impact of that specific data loss. Recommendation framework: if restoration from 72-hour-old backup is operationally acceptable AND no sanctioned entity issue AND business can operate for the restoration period → restore from backup without paying. If any of those conditions fail → engage legal counsel and cyber insurer before deciding on payment.