Ransomware actors have one primary goal—bringing in money. But the way that they do it varies from attack to attack.
Before they actually trigger the ransomware payload, some threat actors might try to make it harder to root out their activity or kick them out. Others might take more of a “smash and grab” approach, going in armed with a solid understanding of the victim’s environment, what security tools they rely on, and more. Threat actors using that playbook move quickly, deploying the ransomware, and then pressuring the victim to make the payment.
In the Huntress 2025 Cyber Threat Report, we found that the average time-to-ransom across security incidents was almost 17 hours, with ransomware groups taking an average of 18 actions before they actually triggered the ransomware payload.
For businesses, time-to-ransom metrics show the urgency of ransomware attacks once threat actors get into their systems. Some of the attackers had a time-to-ransom average of just over four hours after gaining initial access, so every minute counts for businesses in how they strategize and prepare for these types of attacks.
Why is time-to-ransom important to track? Let’s take a step back and look at what this metric actually tells us.
Time-to-ransom is measured in the average number of hours it takes for attackers to move from initial access to the actual deployment of ransomware. We saw faster deployment times from some threat actors, including Play, Akira, and Dharma/Crysis, and longer times from others, including (ironically) Rapid, Sodinokibi, and Phobos.
"How Ransomware Groups Plan & Execute Attacks" featuring Huntress' Greg Linares
Another metric that we studied was linked to the actual malicious activities that threat actors carried out in a 48-hour window before triggering the ransomware, like commands that supported privilege escalation or lateral movement. Ransomware actors like Phobos and Maze carried out more than 30 actions on average before deploying ransomware. At the other end of the spectrum, Conti, Play, and Black Basta carried out fewer than 10 actions, on average.
Many times, these differences can be explained by threat actors’ motives and how they approach attacks. Actors like Play and RansomHub, for instance, go into an environment knowing exactly what they need to do to move as quickly as possible.
But there are other considerations. Attackers that perform a higher number of malicious activities might have goals aligned with data theft or espionage. Some might try to foil any mitigation and response efforts by security teams by targeting backups, clearing logs, and disabling security tools.
Regardless of the various actions they take after achieving initial access, we found that most threat actors exfiltrated data straight before triggering the ransomware payload. With the rise of double extortion methods and public data leak sites, ransomware actors are trying to get the most of the data on victims’ systems.
To determine time-to-ransom, we looked at cases where we had investigated ransomware incidents in customer environments. We used data going back to late 2023, where we hunted through activity logs to:
Identify events linked to ransomware and then find the point of initial access or first signs of observed malicious activity—whether that’s through unauthorized account access via stolen credentials or through brute force attacks on Remote Desktop (RDP)
Record the average time it took for threat actors to move from that point of initial access or first detected malicious activity to the eventual deployment of ransomware
Attribute the time-to-ransom to various ransomware groups based on the ransom note that threat actors delivered during the incident
It’s important to note that there are several variables that could impact time-to-ransom in any given incident.
One important variable here is Huntress’s visibility: for example, in some incidents, Huntress was installed in response to a suspected incident, or wasn’t installed on every endpoint, which could potentially limit what we could see. Other times, threat actors used defense evasion techniques, like disabling event logs, which can limit the scope of visibility into the inner workings of the attack.
Huntress also works with organizations that have smaller networks. That might impact the timeframe for ransomware incidents that we see: lateral movement, for example, looks different on a smaller network compared to how it might look on bigger enterprise networks.
No incident is alike, and differences within the attacks themselves can also impact the timing and number of malicious actions linked to an incident. The point of initial access for threat actors could impact how quickly it takes for them to accelerate the attack, for instance. Threat actors that gain initial access via compromised credentials for an account with lower-level privileges may need to take additional steps—say, targeting a heap-based buffer overflow that may be exploitable by local users—to elevate privileges. On the other hand, if threat actors gain access to an administrator account, they’ll be armed with these privileges from the start and ready to hit the ground running.
Let’s look at two separate incidents, and how time-to-ransom played out across those attacks.
Last year, we responded to an INC ransomware attack on an entity in the healthcare sector. Here, the first evidence that something was amiss was on December 22, when an attacker-controlled workstation had access to an account for over nine minutes. Six days later, on December 28, an admin account was seen moving fast, dumping credentials, and encrypting endpoints.
During the longer time-to-ransom journey in this incident, here are some of the things that the threat actor focused on between initial access and ransomware deploymen
Dumping credentials stored in the process memory of the Local Security Authority Subsystem Service (LSASS): Here, the threat actor sought to dump LSASS credentials via the ProcDump command-line utility (“C:\ Windows\Temp\Procdump\procdump.exe”)
Now, let’s look at another incident, which occurred in the same month (December 2024), but this time with a quicker time-to-ransom frame. In this incident, the threat actor targeted a technology company and deployed the Akira ransomware.
The first inklings of activity linked to the threat actor was from a legitimate account with stolen credentials, from a known, attacker-controlled workstation on December 12. The next day, the attacker performed a number of activities in rapid succession before deploying the ransomware, including:
As mentioned above, one important variable in measuring time-to-ransom is Huntress’ positioning around and insight into the incident. In both of these cases, Huntress was alerted by certain signals, like a triggered ransomware canary indicating that data has been encrypted on a machine, or suspicious arguments via WMI that could indicate lateral movement.
While these gave us an understanding of where the ransomware actor was at that point in time during the attack, a retrospective, closer look at security event logs gave us the breadcrumbs to the point of initial access. In cases like these, having security information and event management (SIEM) in place could give organizations a more proactive way to recognize threats before they cascade.
For businesses, looking at the actions that threat actors perform—and the time spent performing them—before triggering ransomware can give a rough idea of the opportunities they have for detection in an attack before ransomware is deployed, and how much time they may have to respond to ransomware attacks overall.
There's a stark discrepancy when comparing time-to-ransom averages to the timeline for businesses responding to an attack. A 2024 Statista report found that the average length of interruption after ransomware attacks at US businesses was 24 days. That means an hours-long attack could lead to a weeks-long disruption on a victim’s end.
As we’ve laid out above, many ransomware actors rely on tried-and-true methods for their attacks, and businesses need to be prepared. Here are some ways to be proactive:
Keep offline, encrypted backups for critical data, and test those backups in disaster recovery scenarios
Create an incident response playbook, which is reviewed and understood across the chain of command in your business, and that clearly lays out:
Who handles what across the immediate remediation, containment, and recovery phases
How data breach notification procedures and potential compliance issues will be handled
How details and updates will be communicated, both within the organization and with the public
Get insider access to Huntress tradecraft, killer events, and the freshest blog updates.
