Ransomware

On Monday, October 26, a cyberattack knocked the University of New Mexico Health Sciences Center's computers offline. UNM Hospital is the state's only Level I trauma center, and for two hours, from 12:30 to 2:30 p.m., it diverted ambulances to other hospitals in Albuquerque and Santa Fe and limited new admissions. Outpatient surgeries and appointments at more than 30 clinics were cancelled for the rest of the day, and classes at the four health sciences colleges were cancelled into Tuesday.

A group calling itself BYOD (also written Byod) claimed the attack on its Tor leak site the same day. A day later it partly backtracked: saying it had not known the hospital ran machines used for real-time patient care, it offered free decryption keys for the hospital side only and promised to pay patients up to $2,500 each, while saying it would keep the stolen data. UNM has confirmed none of the group's claims. For anyone who runs clinical services on ordinary Windows endpoints, this incident is a useful test of two things: whether losing the endpoints stops patient care, and how to respond when an attacker starts talking to your patients.

What is confirmed and what is only claimed

UNM's security team identified the threat late Monday morning, around 11 a.m. according to most reports (Help Net Security puts detection at about 11:30). Shortly after noon, staff got alerts telling them to shut down and unplug desktops and to take mobile devices off hospital Wi-Fi. Employees also reported a message on their screens, delivered as an automated audio recording, claiming the attackers had student, employee and patient data, including Social Security numbers (SSNs), and telling administrators to make contact.

Systems came back in phases from 2:30 p.m. Monday. By Tuesday afternoon UNM said its critical electronic systems were back online, all hospitals were fully open and ambulance traffic was normal. Its own finding is that the event "affected some end-user devices but did not penetrate core systems or servers." UNM's spokesperson later told the Albuquerque Journal that both personal and workplace devices were affected and that some staff were still told not to turn on their computers on Wednesday.

The FBI says it is assisting. UNM says it cannot yet tell whether patient data was taken and is waiting on the forensic analysis, and that it has made no concessions to the attackers.

BYOD's version is much bigger: about 36,000 machines across the main campus and hospital, both Active Directory forests, Group Policy, the entire Microsoft Entra tenant and two Oracle databases, with HR and payroll data, Banner student records, internal email, research data and Cerner electronic health record rosters. None of that has been verified, and UNM's statement contradicts the claim of server access. It is not even confirmed that a ransomware payload ran, although BYOD's own post talks about "locked devices".

The group is new. The Record says it appeared in September; ransomware.live first logged it in early October. Counts of its victims differ: BleepingComputer saw six on its leak site, with data published for three, while ransomware.live has listed about ten.

How an endpoint-only attack still stops a hospital

If UNM's account is right, the attackers never reached the electronic health record servers. Care still stopped, because clinicians reach those servers through workstations, and once the workstations are suspect the safe move is to turn them off. That is what UNM did within about an hour of detection, and it is the reason ambulances were diverted.

BYOD's claim of Group Policy control matters here, even unproven. Group Policy is the Active Directory feature that pushes settings, scripts and scheduled tasks to every domain-joined machine. An attacker with rights to edit a Group Policy Object can schedule a payload on thousands of endpoints at once without touching a single server. That pattern, mass encryption through a domain policy, has been common in ransomware intrusions for years, and it fits an outcome where endpoints are hit and core systems are not.

What to do

Separate clinical access from general endpoints. Put the workstations that run the electronic health record, pharmacy and imaging viewers in their own organisational unit with their own Group Policy, and limit who can edit it to a small tiered admin group. Keep personal and bring-your-own devices on a guest or segmented network that cannot reach clinical servers, so the network already enforces on a normal day what UNM had to ask staff to do by phone alert.

Practise downtime. Downtime procedures mean paper orders, printed medication administration records and a read-only copy of the day's schedule and active patient lists that someone can open on an isolated machine. Run a drill where every workstation is assumed compromised for four hours and measure what fails. If diversion is the only option, decide in advance who calls it and when.

Do not engage with the "compensation" offer. BYOD wants patients to send it proof of their identity and treatment, which hands a data thief more data. Nothing makes its promise to pay enforceable, its pledge to remove the leak post once UNM makes contact is an opening for negotiation, and the "pentesting" label on its FAQ page is the group describing itself, which proves nothing. Tell patients and staff plainly not to reply, as UNM did, and route contact attempts to law enforcement (the FBI's IC3 portal) and your incident lead.

Run the notification clock from discovery. Under the HIPAA Breach Notification Rule, patients must be told without unreasonable delay and no later than 60 days after a breach is discovered, and breaches of 500 or more people go to the Department of Health and Human Services (HHS) in the same window. HHS guidance treats ransomware encryption of patient data as a presumed breach unless a documented risk assessment shows a low probability of compromise. Student and employee records fall under state breach laws instead; New Mexico's gives 45 days.

Check for theft yourself. Do not wait for the leak site. Pull firewall and proxy logs for large outbound transfers in the weeks before detection, look for archiving tools such as 7-Zip or WinRAR run on servers, and check cloud storage and file sync uploads by account.

Checking your own logs for mass endpoint encryption

Three places show a policy-driven or scripted rollout quickly:

• On domain controllers, Security event 5136 (a directory object was modified) for changes to Group Policy objects or their gPLink attribute. It only appears with "Audit Directory Service Changes" enabled, so check that today.
• In SYSVOL, new or recently changed ScheduledTasks.xml or startup scripts under Policies\{GUID}\Machine\Preferences and Machine\Scripts.
• On endpoints, event 4698 (scheduled task created) and 7045 (service installed) appearing on hundreds of hosts within minutes, and vssadmin delete shadows or wmic shadowcopy delete in process creation logs.

If you run Microsoft Defender for Endpoint, an advanced hunting query that counts renamed files per device and process in five-minute bins shows encryption as a sharp spike:

DeviceFileEvents
| where Timestamp > ago(7d) and ActionType == "FileRenamed"
| summarize Renamed = count() by DeviceName, InitiatingProcessFileName, bin(Timestamp, 5m)
| where Renamed > 500
| order by Renamed desc

The same process name across many devices in the same window is the signature to look for. Tune the threshold to your estate.

Our on-demand risk reduction work reviews who can edit Group Policy and how far a compromised workstation can reach, and our security operations team watches for the mass changes above. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: BleepingComputer, Infosecurity Magazine, Help Net Security, The Record, The Register, PCrisk, Albuquerque Journal, Associated Press via KSAT, Medical Daily, DataBreach.com, HHS ransomware fact sheet, Perkins Coie on New Mexico's breach law.