Ransom demand received: immediate response, evidence, and safe recovery

TL;DR — If you receive a ransom demand, do not pay, do not reply from the affected system, and do not start deleting files or "cleaning up." First preserve evidence, confirm what was actually affected, isolate the compromised account/system, and restore from known-good backups after rotating passwords, keys, and access. Reading time: ~6 min

The scenario

It is 2:17 PM on a Tuesday. You open your inbox and see an email with a subject like "Your network has been hacked" and a demand for cryptocurrency, or your website suddenly shows a note saying your files were encrypted. A client forwards a screenshot of the message, your team starts asking whether this is real, and someone suggests "just restore the server" before anyone has checked logs or backups. You need to know, fast, whether this is a bluff, a mailbox compromise, a website defacement (the site content was changed), or actual ransomware encryption.

Symptoms

• Email demand with common wording such as:

We have downloaded your data.
Pay 3 BTC within 72 hours or we publish it.
Do not contact law enforcement.

• Website homepage replaced with a ransom note such as:

Your files have been encrypted. Contact us at ...

• Files renamed with unusual extensions, for example:

invoice.pdf.locked
photo.jpg.encrypted

• Sudden inability to open documents; operating system shows messages like:

The file is corrupted or in an unknown format.

• Unexplained login alerts in email, cloud, or hosting accounts.
• New admin users, SSH keys (login keys), API tokens (app access secrets), or forwarding rules in email.
• Security tools or logs showing mass file changes, for example:

DELETE /index.php 200
PUT /index.php 200

or

Accepted publickey for deploy from 198.51.100.24

• Backups missing, disabled, or recently deleted.
• Attackers referencing real data samples, screenshots, or internal filenames.

Likely causes

Step-by-step diagnosis

1. Preserve the message and evidence before touching anything.

   • Email: in your mail app, use More actions → View source / Show original / Download .eml.
   • Website: save the page as PDF and take screenshots.
   • Hosting/cloud: export audit logs from your provider's dashboard.
   • This is your problem if the note disappears later or someone overwrites logs; preserving evidence now avoids that.
   • Then continue to Step 2.

2. Check whether the attacker shows proof of access.

   • Look for specific filenames, customer data, screenshots, recent invoices, or valid internal email threads in the demand.
   • If the demand is generic and includes no current evidence, jump to Fixes → Phishing or extortion email with no real compromise.
   • If it includes real current data, continue to Step 3.

3. Review account sign-ins and admin changes in the dashboard first.

   • In your provider's dashboard (e.g. Microsoft 365/Google Workspace/cloud host), open Security → Sign-in logs or Audit log.
   • This is your problem if you see unknown IPs, impossible travel, new admin users, new API tokens, mailbox forwarding rules, or recent backup deletions.
   • If yes, jump to Fixes → Compromised email or cloud admin account and Fixes → Backup system compromise or deletion by attacker.
   • If no, continue to Step 4.

4. Check whether this is a website-only defacement or full-system encryption.

   • In your hosting control panel, open File Manager and inspect the web root (public_html, www, or app directory).
   • If only website files like index.php, theme files, or CMS plugins changed, and documents/databases are otherwise normal, jump to Fixes → Website defacement through CMS/plugin/admin compromise.
   • If many unrelated files are renamed or unreadable, continue to Step 5.

5. Look for mass encryption signs on the affected machine or server.

   • File browser: sort by Date modified.
   • CLI, if you have it:

find /path/to/data -type f | sed 's/.*\.//' | sort | uniq -c | sort -nr | head

• This is your problem if many files changed in a short window, share a new extension, or cannot be opened.
• Jump to Fixes → Server or workstation ransomware encryption.

1. Check backup health before restoring anything.

   ⚠️ Restoring too early can overwrite evidence and can also restore attacker changes if the backup is already compromised.

   • In your backup provider or cloud dashboard, open Backups / Snapshots / Jobs.
   • Confirm there is at least one backup from before the incident and that it is still present.
   • If backups were deleted, disabled, or encrypted too, jump to Fixes → Backup system compromise or deletion by attacker.
   • If good backups exist, continue with the relevant fix section below.

[Demand Received] ---- 1. preserve evidence ----> [Check Proof]
                                              |
                                              v
                                      [Audit Logs]
                                              |
                     3a. unknown sign-ins ----> [Account Compromise]
                                              |
                     3b. no sign-ins           v
                                         [Check Files]
                                              |
               4a. only web files changed ----> [Defacement]
                                              |
               4b. many files encrypted       v
                                          [Ransomware]
                                              |
                                5. verify backups ----> [Recover]

Fixes

Phishing or extortion email with no real compromise

1. Do not reply, click links, or open attachments.
2. Report and remove the message in your mail system.
3. Change passwords only for accounts mentioned in the email, and enable MFA (multi-factor authentication) if not already enabled.
4. Check whether the password in the email is old by comparing it with your password manager history.
5. If the email came to multiple staff, warn them not to engage.

If you manage your own mail gateway, block the sender/domain and preserve the original message:

mkdir -p incident-evidence
cp ransom-message.eml incident-evidence/
sha256sum incident-evidence/ransom-message.eml

Verify it worked: the message is quarantined or deleted, and no suspicious sign-ins appear in your account logs.

Compromised email or cloud admin account

1. From a clean device, reset the affected account password in the provider dashboard.
2. Revoke active sessions: Security → Sessions / Devices → Sign out all.
3. Remove unknown MFA methods, mailbox forwarding rules, OAuth apps (connected apps), API tokens, SSH keys, and newly created admin users.
4. Rotate shared secrets the account could access: hosting passwords, database passwords, SMTP credentials, cloud keys.

If you have CLI access for a Linux host, rotate common secrets after changing dashboard access:

passwd deploy
sudo rm -f /home/deploy/.ssh/authorized_keys
sudo systemctl restart ssh

Verify it worked: unknown sessions disappear, forwarding rules are removed, and new sign-ins require your fresh credentials/MFA.

Website defacement through CMS/plugin/admin compromise

1. Put the site in maintenance mode if your platform supports it, or temporarily restrict access in your hosting panel.
2. Restore only the website files from a known-good backup from before the defacement.
3. Update the CMS, theme, plugins, and remove anything unused.
4. Reset all admin passwords and review admin users.
5. Check web server logs around the first file change for the entry point.

If you have file access and a clean backup archive:

mv public_html public_html-compromised-$(date +%F)
mkdir public_html
tar -xzf clean-site-backup.tar.gz -C public_html

Verify it worked: the ransom page is gone, the site loads normally, and no unknown admin users remain.

Server or workstation ransomware encryption

⚠️ Do not keep using the affected machine normally. Continued use can overwrite forensic evidence and may spread the attack to mounted shares.

1. Isolate the device: disconnect Wi-Fi/Ethernet or disable the instance/network port in your provider dashboard.
2. Do not delete encrypted files yet.
3. Capture what you can: screenshots, ransom note, list of changed files, running processes if available.
4. Rebuild from a known-good image or replacement server; do not trust the compromised system for production again.
5. Restore data from backups taken before the encryption time.
6. Rotate all credentials that were present on that machine.

If you have shell access, isolate networking carefully:

sudo ip link set eth0 down

Then inventory changed files:

find /path/to/data -type f -mtime -2 | head -200 > recent-file-changes.txt

Verify it worked: the affected system is offline, restored data opens normally on the rebuilt system, and no new encryption activity appears.

Backup system compromise or deletion by attacker

1. Check whether your backup provider has immutable snapshots (cannot be changed for a retention period) or deleted-item recovery.
2. Restore backup admin access from a clean account, then rotate backup credentials.
3. Re-enable schedules and create a fresh backup policy that uses a separate account from daily admin work.
4. Before restoring, confirm the backup date is before the first malicious activity.

If your backups are simple filesystem copies, preserve remaining copies before testing restores:

rsync -a --info=progress2 /backup/source/ /backup/preserved-copy/

Verify it worked: at least one pre-incident backup is readable, restorable, and protected by separate credentials/retention.

Fake demand triggered by leaked old password

1. Treat it as a password-reuse warning, not proof of a current breach.
2. Change that password anywhere it was reused.
3. Enable MFA on those accounts.
4. Search your password manager for the reused password and replace it everywhere.

If you maintain a local password inventory export for audit, search it carefully on a secure machine:

grep -R "old-password-fragment" ./password-audit-export

Verify it worked: all reused accounts have new unique passwords and MFA, and no current-system compromise evidence appears in logs.

Prevention

• Turn on MFA for email, cloud, hosting, and backup admin accounts. Prioritize the accounts that can reset other accounts.
• Separate backup access from daily admin access. Use a different admin account for backups, and enable immutable snapshots or retention lock where your provider supports it.
• Collect and retain audit logs. Export sign-in and admin-change logs to a central location daily. Example cron on a management host:

0 2 * * * /usr/local/bin/export-audit-logs >> /var/log/audit-export.log 2>&1

• Alert on dangerous changes. Add alerts for new admin users, disabled backups, deleted snapshots, mailbox forwarding rules, and new SSH keys.
• Test restores quarterly. Do one file restore and one full-environment restore to a non-production location, and record the exact backup timestamp used.
• Patch internet-facing software quickly. For CMSs and plugins, enable update notifications and remove unused components. Keep a simple inventory file such as:

{
  "cms": "WordPress 6.x",
  "plugins": ["seo-plugin", "forms-plugin"],
  "last_reviewed": "2026-10-30"
}

What not to do, even under pressure:

• Do not pay just to "buy time" without legal/insurance guidance.
• Do not reply from the affected mailbox or machine.
• Do not wipe or restore first and investigate later.
• Do not assume a website ransom note means only the website was touched.
• Do not trust the compromised system again until credentials are rotated and recovery is done from known-good sources.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.