Ransomware and the practice server: what actually stops it

A practice runs on one machine more than owners realize. The schedule, the charts, the imaging, the billing: if the practice server is encrypted at 7 AM, there is no 8 AM. That's why it's the target, and why the attackers do their homework before they pull the trigger.

How it usually gets in

• Email. A staff member opens an attachment or a link that looks like it came from a supplier, a lab, or the practice itself. Email security is the first wall for a reason.
• Remote access. A remote desktop or support tool left reachable from the internet with a password that's been in a breach. This is the most common way into a practice server specifically.
• A vendor's connection. The imaging or software vendor's remote tool, with shared credentials nobody rotates.
• An old machine on the network. A front-desk PC or a recorder that hasn't been updated in years.

What they do once they're in

Wait, usually for days. Map the network, find the server, find the backups. Disable or wipe the backups first, because a practice that can restore won't pay. Then encrypt the server, often at night or before a weekend, and leave the note. If they also copied the charts out first, there's a second demand: pay or the records get published, which is a reportable breach either way.

What actually stops it

• No remote access from the open internet. The server is reachable from home or a second office only through a private connection with its own login. The open remote-desktop port, the single most exploited thing in practices, doesn't exist.
• Access by role, no shared passwords. The front desk can't reach the imaging share; the vendor's account is its own and gets turned off between visits.
• Updates applied and noted. The security update that closes the hole gets installed the week it's released, and someone can show you that it was.
• An off-site backup the attacker can't touch. Nightly, encrypted, kept for 30 days with a lock that no password in the practice can shorten. This is the single thing that turns a disaster into a long afternoon.
• A restore you've tested. Every month, something comes back from the off-site copy and the result is written down. When it matters, you already know how long a full rebuild takes.
• Someone watching. Monitoring that notices the server at 3 AM doing something it never does.

The day it happens anyway

With the setup above: the practice calls us, we confirm what's encrypted, isolate the server, rebuild it from the locked off-site copy, and you lose a night's work at most. Without it: the practice is closed for a week, pays or doesn't, notifies patients either way, and starts over. The difference is the plan you bought before, not the response after. Our practice server is built this way by default.