Ransomware Simulation in Red Team Engagements: Walking the Line

NOTE: Some of the topics in this article are probably going to be a bit contentious, but part of the hope in publishing this article is to drive some additional discussion within the offensive security community.

Ransomware has become one of the most prevalent threats that companies face today. It seems that not a week goes by where we aren’t hearing about another major ransomware attack, and it’s not just a feeling. It truly is big business, with Chainanalysis reporting that ransomware payments reached $1.1 billion last year.

And that’s just the payments. IBM has estimated that the average recovery cost of a ransomware data breach is $4.45 million. These are devastating numbers for many businesses.

So is it any wonder that ransomware protection has become a major concern for the defensive cybersecurity community? EDR and MSP advertisements are full of stats about thwarting ransomware, and it seems like every other booth at security conferences specializes in it.

Clearly, the defensive side of the industry has pivoted to address this exploding threat — but where does that leave the offensive security community? How should we be addressing this threat in our engagements?

If you’re familiar with BC Security, you know that our focus is threat emulation — and ransomware is undeniably a major component of modern threat campaigns.

For a long time, however, we were against running full ransomware simulations (i.e., encrypting actual client files or targeting backups). There are simply too many risks involved. Anytime you encrypt something, there’s a chance you can’t recover it — and that could have catastrophic consequences, especially for smaller customers with limited backups and IT support.

Instead, we’ve historically dropped files to demonstrate access and write capabilities. Sometimes, we would encrypt those files to give EDR/AV systems a chance to detect encryption activity.

Even with that limited approach, customer interest in “full” ransomware simulation continued to grow, forcing us to reevaluate. There are indeed a lot of shortcomings with the drop-file-and-encrypt method. Palo Alto summarized many of these issues:

• Encrypting files you’ve dropped mimics legitimate tool behavior more than it mimics ransomware (e.g., compression utilities).
• Testing known extensions only validates detection of known IOCs, not ransomware behavior.
• Not targeting backups — real ransomware disables backups to increase leverage.
• No targeting of remote shares — most simulators only encrypt locally.
• Dropping dormant “real” ransomware samples only tests IOC detection, not behavioral analysis.

Some of these are easier to address than others — but these issues only cover tooling limitations, not the added complexity of conducting ransomware simulations during live Red Team engagements.

Given how common ransomware is, you’d expect this to be a major topic of discussion — yet there are almost no public guides, blogs, or open-source frameworks for how to do this safely.

There are good reasons for that. There’s essentially no way to build a ransomware simulator that can’t also be misused as a real ransomware tool.

The open-source community has largely drawn a red line here — one that’s understandable, though worth debating, especially given that most well-known open-source C2 frameworks are the very tools used to deploy ransomware in the first place.

That’s a discussion for another day — or maybe a roundtable webcast.

Example of a Ransomware Deployment Chain — Microsoft.

The result is a gap for small companies and small Red Teams: very few resources exist for how they should approach ransomware simulation or what tools to use.

This was one of the motivations behind integrating PSRansom into Empire. The move was controversial at first, but it also revealed something important — every detractor admitted it was a common client request, and most had their own private ransomware simulators to handle those engagements anyway.

Should You Perform Full Ransomware Simulations?

In short: No — not in production environments, and not all at once.

Some large, mature organizations can set up isolated networks to safely test full encryption behavior, but for most customers, this isn’t realistic. Instead, we can test in phases, addressing specific aspects of ransomware behavior more safely.

Safer Approaches

1. Controlled File Encryption

One safer approach is having customers pre-place target files themselves. This provides legitimate user context without risking business-critical data.

Alternatively, shared drives can be suitable targets since version control can facilitate recovery.

You can also clone a real user’s workstation and deploy it on the network — a low-risk option for organizations already using cloud endpoints.

In all cases, encryption testing on legitimate systems should only be done with trusted customers and under clear coordination between teams.

2. Backup Targeting (or Not)

Targeting backups remains too risky.

If you must, create dummy backups specifically for testing — and isolate this test entirely from active engagements.

At BC Security, we conduct ransomware-specific tests as separate events. While this breaks our typical threat-emulation methodology, the elevated risk justifies the change.

Traditional Red Teaming still addresses many ransomware precursors.

Command-and-Control (C2) infrastructure is a key enabler of ransomware attacks. A single endpoint encryption event isn’t catastrophic — attackers need lateral movement and environment prep to cause true impact.

Mandiant reported that, on average, there are three days between the initial detection of malicious activity and ransomware deployment.

Modern ransomware operations also involve data theft for extortion, a TTP long included in Red Team operations. Detecting and mitigating initial lateral movement and C2 behaviors remains the strongest defense against ransomware.

Balancing Risk and Realism

While encryption attacks are worth incorporating into Red Team engagements, there’s no reason to abandon traditional TTPs.

Executing these tests requires close coordination with the customer and extensive tool validation beforehand. Ideally, teams should build their own simulators to ensure transparency and control, but a few vetted tools — such as Empire — now include limited encryption capabilities for these purposes.