What should we do when a server is hit by ransomware?

Internet-facing servers are usually entered through a handful of doors that are always left open:

• Remote desktop exposed to the internet. Port 3389 forwarded directly, or a cloud security group open to any source, combined with a weak password or an administrator password shared across servers. Families such as Phobos, Makop and BeijingCrypt mainly get in this way, brute-forcing a logon and deploying the encryptor by hand.
• SQL Server exposed to the internet. Port 1433 plus a weak sa password, followed by system commands through features such as xp_cmdshell. Mallox and its successor Weaxor are built around this route.
• Unpatched internet-facing applications. Critical flaws in ERP, OA, finance software and middleware are scanned for and exploited in bulk; TellYouThePass is the best-known family on this route.
• The cloud account itself. With a leaked AccessKey or console password, an attacker can manage instances and delete snapshots straight from the console - Alibaba Cloud's own guidance on AccessKey leaks lists extortion among the consequences.

Finding the entry point is not paperwork. If it stays open and passwords stay the same, being encrypted again by the same crew after the restore is far from rare; see why ransomware keeps coming back.

Ransomware operations rarely stop at one server. Once the first host falls, the spread is usually unsophisticated: the same local administrator password opens the next server, saved remote-desktop connections and credentials on the first machine point to others, or domain administrator rights let the attacker deploy everywhere at once.

So establish the scope first:

• Which servers show ransom notes, changed extensions or new accounts? Were they encrypted at different times? Staggered timestamps usually mean the attacker is still moving through the network.
• Which servers share an administrator password with the encrypted host, can reach it inside the same security group or VPC, or belong to the same domain?
• Has anyone logged in to the hypervisor hosts, the backup server or the NAS?

If domain controllers show unfamiliar logons, mass-deployed scheduled tasks or pushed group policies, handle it as domain-wide encryption. If the encrypted data is virtual disks on ESXi or Hyper-V hosts, the work centres on the datastore; see virtualization platforms encrypted. Linux servers and BT Panel hosts on the same network need checking too - see Linux server ransomware.

Yes, but work out where each one stands before deciding how to use it.

Shadow copies (VSS) are usually gone, but check every server. Deleting shadow copies and disabling system recovery is routine for ransomware - MITRE ATT&CK files it under Inhibit System Recovery (T1490), with vssadmin, wmic and wbadmin among the commonly abused built-in tools. Deletion does not always succeed, so check every volume on every server. A read-only query such as vssadmin list shadows is enough. If a copy survived, copy the files you need to a different disk rather than restoring the whole volume in place.

Cloud snapshots live in the provider's control plane, normally out of reach of an encryptor running inside the server. That is a real advantage of cloud servers, with two conditions. First, the console account and AccessKeys must not have leaked - otherwise the attacker can simply delete snapshots, and deleted snapshots cannot be recovered. Second, you must not delete them yourself by accident: Alibaba Cloud's documentation states that automatic snapshots set to be released with the disk are deleted when the instance or disk is released.

An old snapshot is not automatically a clean one. Days or longer often pass between intrusion and encryption, so the snapshot from the day before encryption may already hold new accounts, remote-control tools and scheduled tasks. Rolling back in place has three further problems: rollback is irreversible and wipes data written after the snapshot, the evidence on the original disk is overwritten, and Tencent Cloud requires the instance to be shut down before rolling back an attached disk. The safer sequence:

1. Snapshot the current state first (see the steps above).
2. Create a new disk from the candidate snapshot and attach it as a data disk to a new instance in an isolated security group.
3. Inspect accounts, scheduled tasks, services and remote-access tools on that disk, and check against the intrusion timeline whether the snapshot predates the intrusion.
4. Once it is confirmed clean, extract only the business data and move it onto a newly built or reinstalled server.

If the backup server and backup files were deleted or encrypted too, work through the other data sources listed in backups destroyed.

Restore order follows business dependencies, not whichever server happens to be fixed first. CISA's ransomware response guide makes the same point: prioritise restoration against a predefined list of critical assets, and restore onto a clean network. A typical order:

A few working rules:

• Recover the data, not the server. Compromised servers should be rebuilt rather than cleaned and kept; data is extracted from snapshots, backups or repair output and moved onto new instances.
• Restored systems go to an isolated segment first. Move them back into production only after confirming no back doors remain, patches are applied and credentials are changed.
• Databases are a separate workstream. Page-level repair and log replay for encrypted SQL Server, MySQL and Oracle data files are covered in database encrypted by ransomware; file servers and NAS are covered in servers and NAS encrypted.

The most common question is whether the business can be brought back first. It can run in parallel with the investigation, provided the original servers stay isolated and untouched and the restore happens on a different, clean host.

The consoles of Alibaba Cloud ECS, Tencent Cloud CVM and Huawei Cloud ECS differ only in detail. A few tasks can only be done there, and they decide how much usable material is left for everything that follows:

• Isolate with security groups, not by shutting down. Restrict inbound and outbound rules to the responders' fixed IPs, close every port that is not needed, and then check whether remote sessions established earlier are still alive. When you need to get into the OS, use the console's own management terminal - on Alibaba Cloud, for example, VNC connections are not restricted by security group settings.
• Snapshot before anything else. CISA's guide recommends snapshotting cloud volumes to keep a point-in-time copy for forensic review, and Alibaba Cloud's anti-ransomware guide lists snapshotting the system and data disks of an affected instance as a response step.
• Protect the instance from being released. Pay-as-you-go instances on Alibaba Cloud support release protection, which rejects manual release requests from the console, API or CLI. It covers manual release only and does not apply in cases such as overdue payment.
• Change the keys and review the audit trail. From a clean computer, change the root and sub-account passwords, enable multi-factor authentication and rotate every AccessKey that was stored on the servers. Then review the audit trail: new sub-accounts, new AccessKeys and newly attached permission policies usually mean the attacker is planting a back door, and deleted snapshots or images and newly created instances need checking too.
• Confirm whether anti-ransomware backups survived. If Alibaba Cloud Security Center's anti-ransomware backup, Huawei Cloud host security ransomware backup or Cloud Backup and Recovery (CBR) was enabled, check the available backup points in the console, and restore to a new instance rather than the original.

None of this replaces forensics and recovery inside the servers, but it keeps a way back open for every later step.