Back to Articles

Testing Ransomware Defense With Ransomwhere: A Controlled Chaos Approach

[ View on GitHub ]

Testing Ransomware Defense With Ransomwhere: A Controlled Chaos Approach

Hook

The best way to test if your security controls can stop ransomware is to run actual ransomware in your environment. The trick is making sure you can undo everything afterward.

Context

Security teams face a paradox when validating ransomware defenses: commercial breach simulation platforms are expensive and often overkill for basic testing, while real ransomware samples are dangerous to handle and difficult to reverse. You need something in between—a tool that behaves like ransomware but gives you control.

Ransomwhere fills this gap as a proof-of-concept ransomware simulator written in Go. It’s designed specifically for testing detection systems, backup recovery procedures, and incident response playbooks in controlled environments. Unlike full-featured attack simulation frameworks that simulate dozens of attack vectors, Ransomwhere does exactly one thing: it walks a directory tree and encrypts files, optionally deleting originals and wiping local snapshots. The simplicity is deliberate—it’s meant to be transparent and auditable, making it practical for repeated security drills without the overhead of enterprise simulation platforms.

Technical Insight

mode, path, delete, wipe flags

traverse directory

file paths

encrypt mode

decrypt mode

AES/crypto operations

reverse crypto operations

if delete=true

remove originals

if wipe=true

delete local backups

CLI Arguments Parser

Ransomwhere Core Engine

Directory Walker

Mode Decision

Encryption Module

Decryption Module

Target Files

File Deletion Handler

Snapshot Wiper

System Snapshots

System architecture — auto-generated

Ransomwhere’s architecture reflects a design philosophy of deliberate minimalism. The tool is built in Go, which typically produces standalone binaries. When you run it without arguments, it defaults to encrypt mode on a specific directory path without deleting original files—a safe-by-default approach that prevents immediate disaster if someone accidentally runs it.

The core operation is straightforward directory traversal with file encryption. Looking at the usage flags, the tool operates in two primary modes controlled by the -mode parameter: encrypt (default) and decrypt. Here’s what a typical testing workflow looks like:

# Start with a safe test: encrypt files but keep originals
./ransomwhere -log=warn -delete=false -mode=encrypt -path=/home/testuser/ransomtest/

# Attempt to restore files with decrypt mode
./ransomwhere -mode=decrypt -path=/home/testuser/ransomtest/

The -delete flag controls whether original files are removed after encryption, letting you escalate test realism progressively. Start with delete=false to validate that your EDR detects encryption behavior without risking data loss. Once you’re confident in detection, enable deletion to test whether your security controls block the removal operation itself.

The -wipe flag takes things further by attempting to delete local snapshots, mimicking behavior seen in real-world ransomware. This is where the tool transitions from “benign test” to “realistic threat simulation”:

# Full simulation mode - only run in isolated test environments
./ransomwhere -delete=true -wipe=true -path=/opt/isolated-test-data/

The Go implementation appears well-suited for security testing scenarios. Go programs typically compile to standalone executables with minimal external dependencies—useful for deploying into test VMs or containers. The logging system uses the -log parameter (with a default of “error”), letting you control verbosity during testing. In security drills, you might want verbose logging to understand exactly what the tool is doing, or minimal logging to more closely mimic real malware behavior.

One architectural detail worth noting: because the same binary appears to perform both encryption and decryption based on the -mode flag, this suggests the tool maintains some form of key accessibility for the operator. This design choice prioritizes operator control over simulating the key exfiltration behavior of actual ransomware.

Gotcha

The biggest limitation is that Ransomwhere lacks production safeguards based on the available documentation. There’s no indication of prompts, environment detection to prevent accidental execution on production systems, or kill switches. If you run ransomwhere -delete=true -wipe=true on an actual working directory, you’ll encrypt and delete your files. The tool appears to trust you to use it responsibly.

This simplicity also means Ransomwhere won’t help you test advanced ransomware behaviors. The tool focuses on file encryption and doesn’t claim to implement evasion techniques, persistence mechanisms, or multi-stage attack chains. If your security testing requires simulating lateral movement, credential theft, data exfiltration, or complex attack patterns, you’ll need to supplement Ransomwhere with other tools or look at comprehensive frameworks. The tool also offers limited configurability based on the documented flags—customization beyond the basic parameters would likely require modifying the source code.

Verdict

Use Ransomwhere if you need a lightweight, transparent tool for basic ransomware detection testing or security awareness training. It’s ideal for validating that your EDR/antivirus detects file encryption behavior, testing backup restoration procedures, or demonstrating ransomware impact to non-technical stakeholders in safe demo environments. The Go implementation suggests it could work across different platforms, though you should test in your specific environment first. Skip it if you need production-safe guardrails, sophisticated evasion technique simulation, or comprehensive attack chain testing—its deliberate simplicity means you’re trading safety controls and advanced features for transparency and ease of use. Absolutely skip it if you don’t have a completely isolated test environment with clear recovery procedures documented. This is a tool for security professionals who understand the risks; treat it with the same caution you’d apply to actual malware samples, because in the wrong environment, it can cause real damage.

// ADD TO YOUR README
[![Featured on Starlog](https://starlog.is/api/badge/developer-tools/hazcod-ransomwhere.svg)](https://starlog.is/api/badge-click/developer-tools/hazcod-ransomwhere)