The State of Nevada experienced a ransomware incident that began on May 14, 2025, when a state employee downloaded and ran a trojanized administrative tool on an internal workstation. The tool installed a backdoor that gave the threat actor ongoing access for more than three months. The threat actor escalated privileges during this period and deployed ransomware on August 24, 2025. The attack disrupted more than 60 agencies, and the State restored statewide operations over 28 days.
In this newsletter, we summarize the incident based solely on the state’s After-Action Report, focusing on the technical controls that would have prevented or limited the impact.
Initial Compromise
The State’s Version
The State’s report describes the initial compromise as the result of a “Search Engine Optimization poisoning campaign” where the attacker “embedded malicious code into a trusted online resource frequently accessed by state IT personnel.” The report also notes that the spoofed site appeared in Google search results through SEO manipulation and Google Ads placement. Elsewhere in the incident timeline, the report characterizes the initial compromise as “social engineering.”
Was it Really SEO Poisoning?
While the report frames the compromise as an outcome of SEO poisoning, the described behavior does not align with how SEO poisoning works. SEO poisoning is a technique attackers use to increase the visibility of malicious websites by making them appear credible in search results. It relies on tactics such as typosquatting, cloned content, and paid ads to boost a spoofed site’s ranking. These methods influence what users see, but they do not compromise legitimate sites or install or execute malware on workstations. Malware execution still requires the user to download and run a file.
Was it Really Social Engineering?
The report’s reference to “social engineering” as the initial compromise also does not match the technical events it describes. There is no mention of phishing, impersonation, pretexting, or user manipulation. Instead, the report states that the user visited a spoofed website, downloaded a tool, and executed it. This is consistent with user-controlled software installation, not social engineering.
What We Suspect Actually Happened
Based on the technical details in the report, the sequence appears more straightforward than the terms “SEO poisoning” or “social engineering” suggest: A state employee found the spoofed site through a search result, downloaded the trojanized tool, and ran it on an internal workstation. Executing the file installed a backdoor that activated at each user logon and maintained a persistent connection to the threat actor’s infrastructure.
The Unexplained Six-Week Gap in the Timeline
The report notes that the State used Symantec Endpoint Protection (SEP), a signature-based antivirus product. According to the timeline, the earliest evidence of threat-actor activity occurred on May 14, 2025, when a state employee downloaded and executed the trojanized tool. The report later states that SEP quarantined and deleted the malicious file on June 26, 2025.
This creates a six-week gap that the report does not account for. The report states that the tool was downloaded twice on May 14, but it does not explain why it was downloaded a second time or how the June 26 quarantine event relates to those earlier downloads. It is not clear whether the file remained on the system for six weeks and was only detected during a later scan on June 26, or whether the quarantine event involved a different instance of the file.
Was the Quarantine Alert Investigated?
Although SEP quarantined and deleted the file on June 26, the report does not describe any investigation or follow-up action. It also does not state whether SEP generated an alert in response to the quarantine event, whether anyone reviewed the event, or whether the quarantine was treated as a routine antivirus event that required no further analysis. What is clear is that the backdoor installed by the tool remained active after June 26, and the threat actor continued to use this access until August 24, 2025. During this period, the threat actor harvested credentials, escalated privileges, and moved through the State’s environment without detection.
3+ Months of Uninterrupted Access
Over the three months following initial access, the threat actor operated within the State’s environment without interruption. During this period:
They installed commercial remote-monitoring tools on multiple workstations, giving them keylogging, screen capture, and full remote access.
They collected credentials for 26 user accounts and accessed the password vault server to obtain additional privileged credentials.
They created an encrypted tunnel to bypass internal security controls and used RDP to move across servers.
They cleared event logs on the systems they accessed.
They modified settings on the virtualization management platform in preparation for deploying ransomware.
They accessed the backup server and deleted backup volumes.
By the end of this period, the threat actor had persistent access, remote monitoring tools across systems, privileged credentials, unrestricted lateral movement, vault access, and the ability to delete backups, the full set of conditions needed to deploy ransomware.
Data Access and Exfiltration Attempts
According to the report, the threat actor accessed 26,408 files across multiple systems, including files containing personal information. The threat actor packaged a subset of this data into a six-part ZIP archive, a common tactic ransomware threat actors use to stage data for exfiltration.
The report states that there is no evidence at this time that the packaged data was exfiltrated, but it does not describe any controls or telemetry that would have detected data leaving the network. Without that visibility, the absence of evidence does not confirm that exfiltration did not occur.
Ransomware Deployment and Service Disruption
The threat actor deployed ransomware on August 24, disrupting services across more than 60 State agencies. Virtual machines were encrypted, core systems went offline, and widespread outages were reported by the Governor’s Technology Office within minutes. Public safety systems, DMV services, court platforms, health and human services systems, payroll, and other internal agency applications became unavailable, with some agencies closing offices as a result.
The deployment required a full rebuild of the State’s Active Directory environment. Credentials were reset, identity services were re-established, and systems were brought back online in phases. Restoration took 28 days, reflecting the scope of the disruption and the effort required to rebuild core systems.
Deleting backup volumes removed the State’s primary restoration path. The report does not describe offline backups, immutability, or other safeguards that would have protected backup data. Recovery efforts relied heavily on vendor assistance: one vendor recovered data from a device used by the threat actor, though the report does not explain how.
Although the report describes the event as something that “could have escalated” into a full-scale ransomware incident, the scope of outages, the loss of identity services, the backup deletion, and the month-long restoration period reflect the conditions of a full-scale ransomware incident.
Gaps in Foundational Security Practices
The report outlines attacker activity that should have been limited or detected by basic security controls. The following controls are foundational in most environments and are designed to prevent or detect the types of actions described in the report:
Software Execution and Acquisition Controls
Application whitelisting, which blocks the execution of unapproved software, would have prevented the trojanized file from running.
Web content filtering, which restricts access to malicious or spoofed websites, would have blocked access to the fake download site.
Approved software repositories, which define where software may be obtained, remove the need to download tools from search results.
Scanning user-controlled software, such as hash verification, VirusTotal scanning, or sandbox testing, would have identified the trojanized file before it was used in production.
Privilege and Access Controls
Privileged access management, which limits the use of administrative rights, would have reduced the ability to install software on State computers.
MFA for critical systems such as Active Directory, the password vault server, virtualization platforms, and backup infrastructure, which would have made it significantly harder for the threat actor to use harvested credentials to access these systems.
Endpoint Security and Monitoring
Properly configured antivirus software, including alerting, real-time scanning of downloaded files, and scheduled scans, would have identified the trojanized file at the time it was downloaded or executed, rather than six weeks later.
Endpoint Detection and Response (EDR) would have provided behavioral visibility into workstations, detecting the backdoor and other activity that occurred after the initial compromise.
Network Security and Detection
Network intrusion detection could have detected the encrypted tunnel, RDP-based lateral movement, and command-and-control traffic.
Network segmentation, which reduces the paths available for lateral movement, would have limited the threat actor’s ability to move between systems after obtaining credentials.
Backup and Recovery Controls
Immutable or write-protected backups, which cannot be altered or deleted by a compromised account, would have prevented the removal of backup volumes.
Offline or air-gapped backups, which remain accessible even if production systems are compromised, would have provided a quick recovery path after the backup volumes were deleted.
Deletion controls and approval workflows, which prevent mass backup removal and would have blocked or challenged the attacker’s attempt to delete backup volumes.
Alerting on backup modifications or deletions, which would have detected the attacker’s actions as soon as the backup volumes were removed.
Audit and Logging
Centralized log forwarding and retention, which preserve security-relevant logs even when they are cleared on local systems, would have maintained visibility into the attacker’s activity.
SIEM monitoring and alerting would have correlated events across systems and identified unusual authentication activity, access to the password vault server, installation of unapproved software, and repeated log file deletion.
Final Thoughts
The incident involved three months of undetected threat-actor activity, including the installation of unauthorized software, credential theft, lateral movement, backup deletion, and ransomware deployment. Each step reflects actions that foundational controls are designed to prevent or detect.
At the same time, the report describes the State’s security program as mature and emphasizes strategic initiatives, exercises, and planning efforts. However, the document does not address the discrepancies between that characterization and the control gaps evident in the incident timeline. Without a clear accounting of which controls were in place, how they were configured, and why they did not prevent or detect the activity described, it is difficult to determine how similar incidents will be mitigated in the future.
The report outlines the recovery process in detail but does not provide the same level of clarity on preventive and detective controls. A clear understanding of control performance is necessary to assess the effectiveness of the security program and identify where adjustments are required.
