The Tradecraft Behind 2026's Least-Prevented Ransomware Families

Key Takeaways

• Ten ransomware families with the lowest 2026 prevention scores share evasion tradecraft built to stay hidden.
• Play recorded the lowest prevention score at 13%, followed by BlackByte at 25%.
• Obfuscated files or information is the most common technique, hiding payloads and strings from static inspection.
• Common evasion methods include process injection, indicator removal, masquerading, registry modification, and reflective code loading.
• Picus Breach and Attack Simulation safely tests prevention and detection controls against these ransomware techniques.

Most organizations own more security tools than ever, yet breaches keep landing, because there is a quiet gap between the controls teams believe protect them and the ones that actually stop an attack. Closing that gap is the motivation behind the Picus Blue Report, our annual, data-driven look at whether real attack techniques run against production controls are actually prevented, logged, and detected, using aggregated, anonymized results from the Picus Platform.

In this year's Blue Report data, we analyzed the ten least prevented ransomware families and pulled apart the tradecraft that keeps them hidden. This post focuses on the two MITRE ATT&CK tactics, Stealth and Defense Impairment, that ransomware leans on to stay quiet and to knock defenses down.

Below, we rank the ten most common techniques across these families, show how real strains implement each one, give defenders a focused way to shut each technique down, and close with how Picus helps you validate that your prevention controls are actually effective against them.

Methodology

Before mentioning the results, we need to explain our methodology for this analysis.

Why These Ten Ransomware Families

The families in this post are the ten with the lowest 2026 prevention scores in the Blue Report dataset:

When a family is prevented this rarely, its evasion tradecraft is doing exactly what it was built to do, which is why the Stealth and Defense Impairment layer is worth studying on its own.

For each of the ten families, we analyzed its behavior and mapped every Stealth and Defense Impairment technique it uses. We then looked at how common each technique is across the ten families and ordered them by prevalence, from the technique the most families share down to the one the fewest share.

Top 10 Stealth and Defense Impairment Techniques

1. T1027 Obfuscated Files or Information

The most common technique seen in ransomware families is this one. This technique stores payloads, strings, or configuration in an unreadable form so that static inspection and signature engines find nothing useful.

For example, Sodinokibi keeps its embedded portable executables XOR-encrypted on disk and decrypts them in memory with a single-byte key just before execution, so the real code never sits in the clear where a scanner can read it:

As a second example, Black Kingdom hides its delivery logic as a long list of decimal character values that only becomes a script after runtime reconstruction:

2. T1685 Disable or Modify Tools

This technique covers actively killing, uninstalling, or degrading security software and the telemetry it depends on, including clearing the Windows event logs that would record the attack.

BabLock ransomware uses this technique really densely. It abuses a legitimate vendor uninstaller to remove endpoint protection, kills a long list of AV, EDR, backup, and database services, and then wipes the Windows event logs. The sequence is:

A second example that uses this technique is the LockBit 5.0 ransomware. It stops telemetry data flow for security software by patching Event Tracing for Windows (ETW) to overwrite the first byte of EtwEventWrite with 0xC3 (a ret), which silently turns the function into a no-op and blinds any tooling that relies on ETW telemetry. In practice, this action looks like this:

3. T1055 Process Injection

This technique runs malicious code inside another, legitimate process, so the activity is attributed to a trusted image rather than an unknown binary.

For instance, Magniber injects with thread execution hijacking. It enumerates processes, selects a suitable target, suspends one of its threads, writes shellcode, and redirects the thread's instruction pointer to the injected code. The injection sequence is below:

4. T1070 Indicator Removal

This technique deletes or alters the traces an intrusion leaves behind, such as the malware's own files, file timestamps, and command history.

The ransomware that uses this technique clearly is BlackByte 2.0. It uses the well-known ping-delay-then-delete trick so both its collector and its encryptor remove themselves after finishing, with the ping providing a short delay so the file handle is released first. It also timestomps the encrypted files and the ransom note, backdating them to 2000-01-01 to frustrate timeline forensics. The self-delete command is:

For command-history removal, Black Kingdom can be seen as an example. It deletes the PowerShell PSReadLine history file before encrypting so responders cannot replay the operator's commands. The wipe is a one-liner:

5. T1036 Masquerading

This technique makes malicious files, services, and traffic look like trusted resources by matching legitimate names, locations, or file types.

For example, Play stages its tooling and the ransom note in a legitimate-looking path and ships a service binary named to mimic the genuine Sysinternals PsExec service, so it blends in with expected admin tooling. In practice:

BlackByte also adds file-type masquerading, pulling its AES key material from the command-and-control server as a file with a .png extension, disguising key delivery as a benign download.

6. T1112 Modify Registry

This technique changes Windows registry values to weaken defenses, loosen security settings, or stash malicious state where fewer files exist.

As an example, Sodinokibi uses the registry to store its own operational state (session keys, the random file extension, encrypted host metadata) under a custom subkey so that less of its footprint lives in ordinary files. The stored values look like this:

7. T1620 Reflective Code Loading

This technique maps and executes a payload directly from memory instead of calling LoadLibrary, so nothing is written to disk or registered with the Windows loader.

For example, Magniber uses its script-based stages (JS, JSE, WSF) to load a .NET executable directly in memory, which avoids the on-disk artifacts and image-load telemetry that a normal process launch would generate. Here is the command example:

8. T1564 Hide Artifacts

This technique keeps malicious activity out of sight of the tools and people watching a host, for example through hidden windows or spoofed process arguments.

BabLock uses this technique. It spoofs process arguments to run its cleanup commands quietly. It starts a system binary suspended, writes the real command line directly into the process environment block, then resumes it, so any tool reading the command line sees benign or empty arguments. The pattern is:

9. T1218 System Binary Proxy Execution

This technique runs malicious code through trusted, signed Windows binaries (LOLBins), so it blends with normal system activity and slips past allowlists.

For instance, Magniber runs its code through more than one trusted binary. It uses the signed regsvr32.exe to launch a small dropped script file without installing anything, and it runs its encrypted ransomware DLL through a fake .msi installer using the signed msiexec.exe. The invocations are:

10. T1480 Execution Guardrails

This technique gates execution behind an environment check, so the ransomware only runs where the operators intend and quietly exits in sandboxes or off-limits regions.

For example, LockBit 5.0 terminates on Russian-language or Russian-geolocated systems, a common way to avoid running inside the operators' own region and to dodge automated analysis. The checks are below:

Another example that uses this technique is BabLock. It gates execution behind a hardcoded launch code (--run=3306), so a sample detonated without it simply exits and defeats automated sandboxes.

Validating Your Controls with Picus Platform

You almost certainly have security controls in place against ransomware. The harder question is whether they actually stop the techniques in this post. The only way to know whether your defenses stop the tradecraft used by Play, LockBit, Hive, and the rest is to run those techniques against your own controls and measure what happens.

Breach and Attack Simulation (BAS) is the most direct way to do this. Picus Breach and Attack Simulation safely emulates real adversary techniques against your production prevention and detection controls and returns a clear, per-technique verdict on what was blocked, what was logged, and what slipped through.

It draws on the Picus Threat Library, a large and continuously updated collection of real-world threats, so you can test your controls against current ransomware behavior, including the Stealth and Defense Impairment techniques in this post and many other threats, and see a prevention and detection score for each one rather than assuming your controls work.

Figure 1. Picus Threat Library, Network Infiltration Attacks Module

When a gap appears, the Picus Mitigation Library turns it into action with vendor-specific and vendor-neutral prevention signatures and detection rules for your existing security stack, so you can close it quickly.

Figure 2. Picus Mitigation Library, Vendor-specific Prevention Signatures

Start validating your security controls against these threats and get actionable mitigation insights with a 14-day free trial of the Picus Platform.