{
	"id": "4a4fd558-3f4a-4421-9a08-77f1c4b9cda9",
	"created_at": "2026-04-06T00:08:36.105314Z",
	"updated_at": "2026-04-10T03:21:49.128292Z",
	"deleted_at": null,
	"sha1_hash": "c2b4db76d8ab7198720f71bd2e77553ce3e5acec",
	"title": "Gone in 52 Seconds…and 42 Minutes: A Comparative Analysis of Ransomware Encryption Speed | Splunk",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1472914,
	"plain_text": "Gone in 52 Seconds…and 42 Minutes: A Comparative Analysis of\r\nRansomware Encryption Speed | Splunk\r\nBy Shannon Davis\r\nPublished: 2022-03-23 · Archived: 2026-04-05 13:54:10 UTC\r\nDo you feel like every other cybersecurity news story mentioned ransomware in 2021? We feel the same way, and\r\nas a cybersecurity vendor, we felt that we should also contribute to the noise. :-)\r\nhttps://www.splunk.com/en_us/blog/security/gone-in-52-seconds-and-42-minutes-a-comparative-analysis-of-ransomware-encryption-speed.html\r\nPage 1 of 7\n\nBut we did want to try and do something different.\r\nOn top of Splunk’s numerous ransomware detections from our threat research team, we wanted to use Splunk to\r\nsee if we could add some refinement and knowledge to the ransomware clamor. We decided to measure how fast\r\nransomware encrypts files; not just one or two ransomware binaries, but dozens of them — all using Splunk.\r\nhttps://www.splunk.com/en_us/blog/security/gone-in-52-seconds-and-42-minutes-a-comparative-analysis-of-ransomware-encryption-speed.html\r\nPage 2 of 7\n\nWhy? Well, partly because we have an unlimited Splunk license, but also because we couldn’t find the answer to\r\nthe question: “How long do you have until ransomware encrypts your systems?” This seems like knowledge that\r\norganizations could use to organize their defenses. If organizations have more than 20 hours before ransomware\r\nfinishes encrypting, they might choose to focus on detecting and mitigating ransomware after infection. If\r\nransomware encrypts an entire system in 52 seconds, organizations should probably respond earlier in the\r\nransomware lifecycle.\r\nIn our initial hypothesis, we asserted that if ransomware executes on a system, then it’s too late for an organization\r\nto respond effectively. We conducted a literature review of ransomware encryption speed and only uncovered\r\nwork that was encyclopedic in scope from one of the ransomware groups themselves.\r\nThe LockBit group posted a table on their Tor site (Fig. 1) listing encryption speeds for more than 30 ransomware\r\nfamilies, showing — perhaps not surprisingly — that LockBit was the fastest. To be fair, I guess that makes sense;\r\nyou typically don’t release PR pieces that highlight how bad you are. We then looked at dwell time for\r\nransomware intrusions and found that the three-day dwell time cited by Mandiant in their 2021 M-Trends report\r\nwas fairly representative. This gave us a “how long till people realize they are infected with ransomware”\r\ntimeframe.\r\nhttps://www.splunk.com/en_us/blog/security/gone-in-52-seconds-and-42-minutes-a-comparative-analysis-of-ransomware-encryption-speed.html\r\nPage 3 of 7\n\nFigure 1. LockBit analysis of ransomware encryption speeds among competing ransomware groups.\r\nPrep Work\r\nWe couldn’t leave it to LockBit’s marketing team to only release content like this, so we rolled up our sleeves and\r\ngot busy building an environment that would allow us to conduct our own ransomware speed tests. We took the\r\ngreat Splunk Attack Range project, created by Splunk’s Threat Research Team, and modified it to fit our needs.\r\nhttps://www.splunk.com/en_us/blog/security/gone-in-52-seconds-and-42-minutes-a-comparative-analysis-of-ransomware-encryption-speed.html\r\nPage 4 of 7\n\nFigure 2. Diagram outlining the ransomware environment created using a modified version of Splunk Attack Range.\r\nWe created four different “victim” profiles consisting of Windows 10 and Windows Server 2019 operating\r\nsystems, each with two different performance specifications benchmarked from customer environments. We then\r\nchose 10 different ransomware families and 10 samples from each of those families to test. Figure 3 outlines the\r\nfamilies that we tested, along with the Microsoft Defender detection identifiers from VirusTotal.\r\nhttps://www.splunk.com/en_us/blog/security/gone-in-52-seconds-and-42-minutes-a-comparative-analysis-of-ransomware-encryption-speed.html\r\nPage 5 of 7\n\nFigure 3. Ransomware families and corresponding Microsoft Defender detection identifiers from VirusTotal.\r\nWe tested every sample across all four host profiles, which amounted to 400 different ransomware runs (10\r\nfamilies x 10 samples per family x 4 profiles). In order to measure the encryption speed, we gathered 98,561 test\r\nfiles (pdf, doc, xls, etc.) from a public file corpus, totaling 53GB. To collect the necessary data, we used a\r\ncombination of native Windows logging, Windows Perfmon statistics, Microsoft Sysmon, along with Zeek and\r\nstoQ for further analysis (that’s content for future blogs, so be patient).\r\nIn order to capture the required encryption events, we enabled Object Level Auditing on the 100 directories where\r\nour test files lived. This provided us with EventCode 4663 logs that we could use to calculate the Total Time to\r\nEncryption (TTE) for each sample. The samples we tested had an Accesses value of DELETE at the end of\r\nencrypting each file, which is how we measured encryption speed. Not all ransomware behaves this way, so a\r\nsearch for EventCode=4663 Accesses=DELETE in Splunk may not always return the same results.\r\nThe Heist\r\nhttps://www.splunk.com/en_us/blog/security/gone-in-52-seconds-and-42-minutes-a-comparative-analysis-of-ransomware-encryption-speed.html\r\nPage 6 of 7\n\nJust like watching Gone in 60 Seconds (the Nicholas Cage version, of course), you’re on the edge of your seat\r\nwaiting for the results. Well, here you go.\r\nFigure 4. Median ransomware speed measured across 10 ransomware families.\r\nAs you can see, LockBit lived up to its own hype and was the quickest to encrypt of all the ransomware families\r\nwe tested. We listed the median duration, as some families had one or two samples that would skew the average\r\nduration. For example, LockBit had the fastest sample coming in at four minutes and nine seconds (fig. 5). Babuk\r\nwas a close second but had one sample that was the slowest of all samples tested, which took more than three and\r\na half hours (fig. 6).\r\nFigure 5. LockBit had the fastest ransomware sample to encrypt files with a duration of four minutes and nine seconds.\r\nFigure 6. Babuk had the second fastest median encryption speed but the slowest individual sample, which took more than three and a half\r\nhours to encrypt the files.\r\nThe Getaway\r\nThis research is available in a comprehensive whitepaper with more details than what is outlined here (I get in\r\nbig trouble for going over 800-1,200 words). As I mentioned earlier, there is more research to come out of our data\r\nset. We plan to publish the data to the Splunk BOTS Portal in time for .conf22 (June 14-17, 2022). This way, you\r\ncan investigate the data yourself and possibly uncover details that we may not have noticed during our tests.\r\nFinally, you might ask what this means if you’re a network defender. Well, if we go back to our original\r\nhypothesis of ransomware being too fast to defend against once it executes on the victim system, that should give\r\nyou a hint. Start looking “left of boom,” where boom is the malware detonation, and assess your capabilities to\r\nprevent or detect the ransomware group’s behavior. Multi-factor authentication, network segmentation, patching,\r\nand centralized logging (couldn’t help myself there) are all very good strategies to bolster your defenses against\r\nransomware or any other malicious actors for that matter (I’m looking at you, Nicholas Cage). And of course, this\r\nsort of work is what you can expect from SURGe over the next couple of months and well into the summer. I\r\nmean, someone has to talk about ransomware, right?\r\nHappy Hunting!\r\nAuthors and Contributors: As always, security at Splunk is a family business. Credit to authors and\r\ncollaborators: Shannon Davis, Ryan Kovar\r\nSource: https://www.splunk.com/en_us/blog/security/gone-in-52-seconds-and-42-minutes-a-comparative-analysis-of-ransomware-encryption-s\r\npeed.html\r\nhttps://www.splunk.com/en_us/blog/security/gone-in-52-seconds-and-42-minutes-a-comparative-analysis-of-ransomware-encryption-speed.html\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.splunk.com/en_us/blog/security/gone-in-52-seconds-and-42-minutes-a-comparative-analysis-of-ransomware-encryption-speed.html"
	],
	"report_names": [
		"gone-in-52-seconds-and-42-minutes-a-comparative-analysis-of-ransomware-encryption-speed.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434116,
	"ts_updated_at": 1775791309,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c2b4db76d8ab7198720f71bd2e77553ce3e5acec.pdf",
		"text": "https://archive.orkl.eu/c2b4db76d8ab7198720f71bd2e77553ce3e5acec.txt",
		"img": "https://archive.orkl.eu/c2b4db76d8ab7198720f71bd2e77553ce3e5acec.jpg"
	}
}