The 2025 ransomware attack on the state of Nevada’s systems is a great lesson in incident response: they recovered quickly, lost nothing, and ended up with better security in the end. At the same time, they acknowledge there’s room for improvement.
Let’s take a journey through the attack to look at what Nevada did right (and wrong), and see what we can learn from it.
The attack: nutshell version
In August 2025, the state of Nevada was hit with a ransomware attack that affected more than 60 state agencies including Health and Human Services and the DMV. No ransom was paid. Operations were restored in just 28 days at a cost of around $1.6 million, most of which was covered by insurance.
May: Attackers sneak in
The attack started in May when an employee downloaded what they thought was a legitimate software tool, but in fact was malware from a spoofed website. The attackers even leveraged legitimate Google ads as a vector to deliver the malware.
What went wrong: The malware download was part of a sophisticated social engineering effort. Spoofed websites are rampant these days, with AI making it possible to mount a carbon copy of a legitimate website in under 20 minutes. With these threats, traditional phishing tests just aren’t going to cut it anymore. It might even become necessary for IT departments to resort to the old restriction that all downloads have to go through them.
The malware itself went undetected by Symantec Endpoint Detection until June, when it was deleted from the system. However, by then the attackers already had a backdoor established, and they installed remote monitoring software on another user’s system to log keystrokes.
What went wrong: It’s unclear whether Symantec didn’t detect the malware because the user hadn’t kept his detection software up to date, or if it was a Zero Day in May and Symantec just didn’t have its detection implemented until June. The remedy depends on which scenario occurred.
The attackers established encrypted tunnels and moved laterally through the system, eventually accessing sensitive directories and even a password vault. All the while, the attackers deleted log entries that would have exposed their presence in the system.
What went wrong: Ideally, lateral movement isn’t that easy due to access restrictions. We’ll hear more about this later.
August: Ransomware strikes
In August, the attackers made their move. They deleted online backups and encrypted VMs, which took critical services offline, and posted a ransom note inside the system.
The state of Nevada never disclosed the amount of the ransom, only that they did not pay it. Instead, they took quick action and restored operations to some departments within a few days, and the entire system within 28 days.
September: Recovery
The response started with siloing infected VMs. Then they rescued deleted backups using backup keys, and restored access to critical systems in a sequence established by their pre-made recovery plan: payroll, emergency and social services, police and court records, and DMV systems, followed by various other services managed by the state.
What went right: Pretty much everything in the above paragraph. Having a well-thought-out Recovery Plan, with priorities agreed upon during calmer times, laid out a clear path and avoided wasting post-attack time on frantic decisions, knee-jerk reactions, and squabbles among departments.
Coming back from the attack cost around $260,000 in staff overtime and $1.3 million for contractors, which was paid for by the state’s cyber insurance.
What went right: These are impressive metrics for a ransomware recovery.
Even if the backups weren’t air-gapped, they were recoverable.
What went right/wrong: The wording in the report leads me to believe that the backups were in the cloud, well-separated from the operational system. I’m not going to delve into the cloud vs. air-gapped backups debate here, but I’ve always been partial to air-gapped solutions, especially for crucial infrastructure.
What can we learn from Nevada?
The state already had plans in the works for hardening their system, which they are going forward with in the aftermath of the breach:
More restrictive access – To prevent lateral movement through the system, the state began adopting zero-trust methodologies, strengthening ACLs to restrict access between domains and adding more separation between admin accounts and user accounts.
Controlled privilege – Some user accounts were found to have more privileges than needed, such as access to sensitive data or settings, so those were adjusted accordingly.
Dead wood cleanup – Long-unused user accounts, expired certificates, and out-of-date privilege rules were removed or updated.
One of the best things about government cybersecurity stories is that they’re often well-documented in an after-report, where we get a lot of juicy details that private corporations just won’t give up. This attack is no exception, with a 30-page report from the Governor’s Technology Office for the state of Nevada giving us all the details.
