Most ransomware defenses rest on a simple assumption: if files look encrypted, you’ve been hit, and if they look normal, you’re safe. New research suggests that assumption is outdated. After detonating 1,064 real ransomware strains in a controlled environment during the first half of 2026, Index Engines’ CyberSense Research Lab found that directory-entry destruction (47.8%) was far more common than full encryption (18.3%). Some strains even scrambled data while leaving filenames, file sizes, timestamps, and entropy untouched, so corrupted files looked perfectly healthy.
To mark Cybersecurity Awareness Month, we spoke with Jim McGann, CMO of Index Engines, about what these findings mean for detection, recovery, and the role of AI in modern attacks. He explains why signature-based detection is losing ground, how quickly damage can spread, and why leaders should move from asking “Do we have backups?” to “Can we prove our recovery data is clean?”
The full report is available at www.indexengines.com.
VMblog: What prompted this research, and what was the CyberSense Research Lab trying to understand?
Jim McGann: The goal of our Lab is to understand how ransomware is changing and what it’s doing to the data when an attack happens. We detonate real ransomware in a controlled environment and look closely at the damage it causes to file systems and databases. And we’re looking beyond the obvious signs of an attack, like full encryption, because ransomware is becoming much more subtle. We’re seeing things like partial encryption, directory-level destruction, preserved timestamps and file extensions, and other forms of corruption that can be much harder to spot.
In the first half of 2026 alone, we analyzed 1,064 ransomware strains. What we learn from that research feeds directly into CyberSense, helping us continually strengthen how we detect corruption, validate data integrity, and identify clean data for recovery. Ultimately, it’s about keeping CyberSense ahead of how ransomware is evolving and giving organizations greater confidence in the data they’re recovering.
VMblog: What was the most significant finding from the research?
McGann: One of the most significant findings is that full encryption is not the most common destructive behavior in the Lab’s sample set. Directory-entry destruction appeared in 47.8% of the strains studied, compared with full encryption in 18.3%. Instead of scrambling the contents of a file, this technique damages the filesystem information needed to locate and access it. The data may still exist on the disk, but the system can no longer find it.
This matters because a recovery check focused primarily on whether files look encrypted may miss damage at the directory or filesystem level. Organizations need to validate whether data is accessible, usable, and intact, not simply whether it appears unchanged.
VMblog: How is ransomware becoming more difficult for traditional detection methods to identify?
McGann: What we’re seeing is ransomware getting much better at hiding the signs of damage that security and data scanning tools have traditionally looked for. In fact, 64.7% of the samples changed their binary signature between builds, which means signature-based identification is largely futile. At the data level, we saw several different approaches. CryptoLocker preserved the original file extension, Satan produced low-entropy corruption, TimeTime deliberately encrypted files slowly, 2c3s6aax6x-enc preserved timestamps, and AbyssLocker encrypted only selected portions of files. Each one takes away a signal that defenders may traditionally rely on.
But Encoder brought the challenge into focus. Instead of encrypting a file, it rearranged the bytes inside it while preserving things like the filename, file size, timestamps, and entropy. So, on the surface, the file could look unchanged, even though the data inside was no longer usable. The Lab, and of course CyberSense, identified that corruption by looking directly at the structure and content of the file. That’s the takeaway from the research: you can’t assume data is clean just because it looks clean.
VMblog: What did the research reveal about the speed and potential blast radius of an attack?
McGann: One of the things that stood out in the research was how quickly ransomware can do damage. In our controlled Lab tests, ransomware was corrupting more than 97,000 files per hour. At that pace, 10,000 files could be impacted in about six minutes. These are Lab findings, so they’re not meant to represent what every real-world attack looks like, but they give us a sense of how quickly things can unfold.
And six minutes isn’t a lot of time. By the time an alert is investigated, escalated, and a response begins, significant damage may already have occurred. That’s why recovery readiness is so important. You need to know how you’re going to validate your data and, identify a clean recovery point before an attack happens.
VMblog: What role is AI playing in ransomware today?
McGann: There’s been a lot of fear around the idea of AI-powered ransomware making its own decisions about what data to attack and how to corrupt it. But that’s not what we saw— at least not yet. Across the strains we detonated, we didn’t see ransomware dynamically choosing high-value files or changing its attack based on the data it encountered.
Right now, its impact appears to be more about speed and scale earlier in the attack lifecycle, helping accelerate things like reconnaissance, vulnerability discovery, initial access, and lateral movement. By the time ransomware reaches the data and starts causing damage, the decisions have largely already been made.
So rather than getting caught up in the fear of some completely autonomous AI ransomware variant, the more immediate issue is that attackers may be getting to the data faster, giving organizations less time to respond.
VMblog: Why does this research matter to business and technology leaders?
McGann: This research matters because ransomware isn’t just a security issue. It’s a business resilience and recovery issue. When an attack happens, leaders need to know not only that they have backups, but that the data they’re relying on to restore the business can be trusted.
Our research shows why that’s becoming harder. A file can have the same name, size, timestamps, and even entropy and still be corrupted and unusable. If that damage goes undetected and you restore data that only looks clean, you risk prolonging the disruption and potentially starting the recovery process all over again.
For CISOs and business leaders, the takeaway is to change the question from “Do we have backups?” to “Can we prove our recovery data is clean?” Recovery confidence needs to be built and tested before an attack happens, because the middle of an incident is the worst time to discover that the data can’t be trusted.
The full report walks through each of these findings in detail, and it’s available now at www.indexengines.com.
