Files renamed with an unfamiliar extension and a ransom note
An active ransomware incident. The first decisions made are worth more than everything that comes after them.
What you see
Documents will not open, filenames have gained an extra extension, and a text or HTML note appears in every folder. Shares may be affected before the local machine is noticed.
What is actually wrong
An intrusion that has already reached the file server or the workstation with access to it. Encryption is the last stage of an attack that usually began days or weeks earlier.
Codes and articles
Fixes (2)
Contain it — network first, power last
Encryption is in progress. Minutes matter and the order of these steps matters.
Disconnect the affected machines from the network — unplug the cable, disable the Wi-Fi. Do this before anything else.
Isolating the machine stops it reaching more shares. It is the single most valuable action available and it costs seconds.
Do not power the machine off if it can be avoided. The encryption key is sometimes still in memory, and a memory capture is occasionally the difference between recovery and not.
This is the step most people get wrong. Pulling the power feels decisive and destroys volatile evidence — and sometimes the key itself — for no gain over disconnecting the network.
Disconnect backups and any external drive immediately, before checking whether they are affected.
On the file server, stop the shares to halt further damage while you assess.
Get-SmbSession | Format-Table ClientComputerName,ClientUserName,NumOpensGet-SmbShare | Where-Object Name -notin 'ADMIN$','IPC$','C$' | Set-SmbShare -Force -ErrorAction SilentlyContinue
Identify the account doing it — the SMB session list above usually names the machine and user within seconds.
Assess what is recoverable before touching anything
Encryption has finished. Resist the urge to start deleting and reinstalling.
Preserve a copy of the ransom note and a sample encrypted file. Identification services can sometimes name the family, and a few have public decryptors.
Check whether shadow copies survived — most families delete them, but not all succeed.
vssadmin list shadowsGet-CimInstance Win32_ShadowCopy | Format-Table InstallDate,VolumeName,DeviceObject
Check the backups from a machine that was never connected to the affected network, and verify a restore actually works before wiping anything.
Assume credentials are compromised. Every account that had access to the affected machines needs its password reset, and the domain KRBTGT account should be reset twice with the recommended interval between.
Rebuild affected machines from clean media rather than cleaning them. A machine that has been encrypted was fully compromised first, and removing the payload does not remove the access that delivered it.
This is the part that gets skipped under time pressure, and it is why so many organisations are hit a second time within weeks by the same intruder using the same access.
In the UK, report it to Action Fraud and, if personal data is involved, consider the ICO notification requirement — 72 hours from becoming aware.
Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.