Build a Ransomware Sandbox with FLARE-VM and CAPE: Automated Config Extraction and IOC Dumping

Ransomware analysis demands two things most labs lack: a fully loaded analyst workstation and an automated detonation engine that never gets bored. This guide gives you both. You’ll build a FLARE-VM Windows analysis machine for hands-on static and dynamic work, pair it with a CAPE sandbox on Ubuntu for automated detonation, and wire the whole thing to extract C2 configurations and dump IOCs—safely, repeatably, and without a single packet leaking to the internet.

TL;DR: What This Sandbox Setup Gets You

FLARE-VM gives you a fully instrumented Windows analysis environment—PEstudio, FLOSS, CAPA, and dozens of other Mandiant tools—in minutes instead of days. CAPE (Config And Payload Extraction), the open-source descendant of Cuckoo Sandbox, gives you automated detonation with one killer feature: it pulls C2 configurations out of malware families automatically. Together, they form a complete ransomware triage pipeline: submit a sample, get a JSON report with C2 URLs, BTC wallets, file extensions, ransom note paths, dropped artifacts, mutexes, and network signatures—then convert that output directly into YARA and Sigma detection rules.

Prerequisites and Lab Architecture

Malware analysis is a hostile workload. The sample you’re detonating is actively trying to encrypt filesystems, scan networks, and detect your environment. Under-spec the lab and you’ll chase phantom failures for weeks.

Recommended host specifications:

• CPU: 8+ cores with Intel VT-x/AMD-V enabled (16 threads preferred for parallel CAPE tasks)
• RAM: 32 GB minimum—Windows 10 guest for analysis plus Ubuntu host services plus a second Windows guest for CAPE detonation
• Storage: 500 GB SSD; malware detonation generates significant disk churn and you’ll snapshot constantly
• Hypervisor: VMware Workstation Pro (now free for personal use as of 2024) or VirtualBox 7.x. KVM works for CAPE on dedicated Linux hosts.

Architecture: Ubuntu host runs the CAPE controller, the Windows CAPE guest, and optionally INetSim or FakeNet-NG for network spoofing. A separate VMware/VirtualBox-hosted Windows VM runs FLARE-VM for manual analysis. All virtual networks are host-only. No NAT. No bridged adapters. Ever.

Isolation matters more than any other design decision here. CISA’s #StopRansomware advisories repeatedly document ransomware operators pivoting from analysis infrastructure or leaked samples to live attacks—your lab is a target. A misconfigured bridged adapter turns your lab into a liability. Take a clean snapshot of every guest before detonation and treat reversion as mandatory, not optional.

Installing FLARE-VM on a Windows Analysis VM

FLARE-VM, maintained by Mandiant (now part of Google Cloud), installs a curated malware analysis toolset onto a clean Windows machine. Start with a fresh Windows 10 or 11 VM—never install it on your daily driver, and never skip the snapshot.

1. Create a Windows 10 VM (4 GB RAM minimum, 80 GB disk), disable Windows Defender real-time protection, and exclude the analysis directories.
2. Take a clean snapshot named pre-flare.
3. Open PowerShell as Administrator and run the official installer:

Invoke-WebRequest -Uri https://raw.githubusercontent.com/mandiant/flare-vm/main/install.ps1 -OutFile install.ps1
Unblock-File .install.ps1
.install.ps1

The installer runs 30–60 minutes and drops in the tools that matter for ransomware triage:

• PEstudio — static inspection of imports, sections, and entropy (high entropy in .text sections screams packed ransomware)
• FLOSS — FireEye Labs Obfuscated String Solver; automatically deobfuscates stack strings, a staple of ransomware loaders
• CAPA — Mandiant’s capability detector; maps binary behaviors to MITRE ATT&CK techniques like T1486 (Data Encrypted for Impact)
• DIE (Detect It Easy), x64dbg, PEview, Procmon, and TitanHide for anti-anti-debug work

Snapshot again post-install as flare-clean. This is your rollback point before every detonation.

Deploying the CAPE Sandbox

CAPE is actively developed on GitHub (github.com/kevoreilly/CAPEv2) and extends the Cuckoo architecture with configuration extraction—the reason you’re deploying it for ransomware work.

The fastest path on Ubuntu 22.04 is the community installer script, which handles dependencies, virtualization libraries, and web API setup:

git clone https://github.com/kevoreilly/CAPEv2
cd CAPEv2/installer
sudo ./install.sh

For the Windows detonation guest, you have two options. VMcloak automates guest creation entirely from the Linux host—preferred for repeatability. Manual setup works fine for a first lab:

1. Create a Windows 10 VM on the same host-only network as CAPE.
2. Install the Python agent from agent/agent.py in the CAPE repository and set it to run at startup.
3. Disable Windows Update, Defender, and the firewall inside the guest.
4. Install common software (PDF readers, Office viewers) so the detonation environment resembles a real endpoint.
5. Take a snapshot named exactly what you’ll configure in conf/virtualbox.conf or conf/vmware.conf.

In the CAPE config, set the guest’s snapshot name, IP, and platform. CAPE reverts to this snapshot before and after every single analysis task—that reversion is your contamination backstop.

Configuring Network Isolation and Safe Detonation

Two modes dominate safe detonation. internet:none cuts all guest networking so you observe what malware attempts without letting it succeed. Alternatively, route traffic to INetSim or FakeNet-NG, which emulate DNS, HTTP, HTTPS, SMTP, and dozens of other protocols—ransomware’s C2 beacon gets a believable response, so it proceeds further into its execution chain and reveals more behavior.

Key settings in CAPE’s conf/cuckoo.conf and routing config:

• internet = none as the default route for all analysis tasks
• route = inetsim when you want simulated services; point the guest’s gateway at the INetSim host
• reboot = true enabled so CAPE can capture post-reboot persistence behavior—critical for ransomware that stages via scheduled tasks
• Snapshot revert forced before every task (machinery section)

Pre-detonation safety checklist:

• All virtual networks confirmed host-only (check hypervisor settings physically, not from memory)
• Host’s physical network adapters excluded from guest network sharing
• Shared folders between host and guest disabled or read-only and empty
• Clean snapshot exists and revert is tested
• Clipboard and drag-and-drop disabled in hypervisor settings

OWASP’s guidance on isolation principles applies here as much as it does to web infrastructure: assume the workload is hostile and architect so compromise of the workload cannot reach anything you care about.

Detonating a Ransomware Sample

Obtain your sample from a reputable source—MalwareBazaar (abuse.ch), VirusTotal Intelligence, or your incident response pipeline. Samples almost always arrive password-protected in ZIP archives (MalwareBazaar uses infected as the standard password) to prevent accidental detonation by antivirus on intermediate systems.

Submit via the web UI at http://localhost:8000 or the CLI:

python3 cuckoo.py submit --timeout 240 --package exe ransomware_sample.exe

Choose the analysis package deliberately: exe for standard payloads, zip with password for archive-wrapped samples, dll with export function specified for library payloads. Set a 240–300 second timeout—ransomware needs time to complete encryption, and a 60-second default truncates the most valuable behavior.

Expected console output: VM acquisition, snapshot restore, agent contact, injection of the analysis packages (capemon, CAPE’s monitoring DLL), then behavioral logging. After the timeout, CAPE reverts the snapshot and processes the collected data into the report. Total cycle time for a well-tuned lab: 5–8 minutes per sample.

Extracting C2 Configuration Automatically

This is CAPE’s headline feature and the reason it beats vanilla Cuckoo for ransomware work. CAPE ships with dozens of family-specific config extractors—written as Python modules—that run against the collected behavioral and memory data after detonation. For ransomware families including LockBit, Conti, BlackCat/ALPHV, and dozens more, CAPE pulls out the embedded configuration the sample carries.

The extracted config appears in the report under the CAPE.configs key. A typical extraction looks like this:

"Configs": {
  "family": "lockbit3",
  "rsa_public_key": "MIIBI...",
  "extension": "aaaaab",
  "ransom_note": "Restore-My-Files.txt",
  "c2_urls": ["http://185.x.x.x/gateway.php"],
  "wallet": "bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh"
}

Every field is operationally valuable: C2 URLs feed network-blocking rules, the BTC wallet becomes a threat-intel pivot across campaigns, extension lists and ransom note filenames go straight into EDR content, and the embedded RSA public key uniquely fingerprints the affiliate build. Note that ransomware is now heavily RaaS-driven—the config often identifies the affiliate campaign, not just the family, which matters for attribution and CISA advisory correlation.

Dumping and Analyzing IOCs

CAPE’s JSON report is a structured IOC goldmine. Beyond the config, expect:

• Dropped files — every artifact written to disk, with hashes, ready for static follow-up in FLARE-VM
• Mutexes — ransomware’s single-instance guards are high-fidelity host-based signatures with near-zero false-positive rates
• Registry keys — Run-key persistence, wallpaper changes, shadow-copy deletion via vssadmin delete shadows /all /quiet
• Network signatures — DNS queries, HTTP requests, and Suricata/Snort alerts (CAPE integrates suricata natively)
• Behavioral signatures — CAPE’s signature engine flags known techniques: mass file modification, encryption API patterns (CryptEncrypt, BCryptEncrypt), anti-VM checks

Export options: the full JSON report via the API (/apiv2/tasks/get/report/<task_id>/), a MISP export for threat intel sharing (CAPE supports pushing IOCs and signatures directly to a MISP instance), and PDF/HTML reports for stakeholders. Malformed samples—corrupted PE headers, invalid ZIP structures—get flagged in the report’s errors section rather than crashing the pipeline.

Turning Results into Detection Rules

The pipeline’s endpoint is detection content. Three practical conversions:

• YARA rules from config data: The embedded RSA public key, extension strings, and ransom note text are stable strings. FLOSS extracts them statically from the sample in FLARE-VM; combine two or three into a YARA rule. Vendor false-positive rates stay low when you anchor on config content rather than generic packer artifacts.
• Sigma rules from behavior: CAPE’s process behavior logs translate directly into Sigma—shadow-copy deletion, defense evasion via vssadmin, and suspicious parent-child process chains (e.g., WINWORD.EXE spawning a signed binary creating .encrypted files). Feed Sigma into your SIEM via converters like sigma-cli.
• Suricata rules from network traffic: C2 URLs and HTTP patterns from the config extractor become network IDS signatures.

Troubleshooting Common Sandbox Failures

• VM agent timeouts: Almost always networking—guest can’t reach the CAPE host on port 8000, or the agent isn’t starting. Verify host-only connectivity with a ping before blaming CAPE, and confirm the agent runs at boot.
• Anti-VM evasion: Ransomware increasingly checks hypervisor artifacts (CPUID leaves, registry keys, MAC prefixes). TitanHide in FLARE-VM, Pafish-hardened guests, and vmcloak’s artifacts-removal steps help. CAPE’s config also supports cover-flaws and anti-evasion options. Reality check: some heavily protected samples simply require manual analysis in a debugger—know when to switch tools.
• Snapshot restore errors: Name mismatches between the config file and actual snapshot names are the #1 cause. VBoxManage/VirtualBox version mismatches come second.
• Encrypted sample not executing: Packed payloads may require the correct package (try zip with password), a longer timeout, or failing anti-evasion checks that silently terminate execution. Check the behavioral log’s tail for process exit before encryption begins.

Safety, Legality, and Sample Handling

Detonating ransomware in an isolated lab for defensive research is legal in most jurisdictions and is standard practice across the industry—you are not operating the malware against systems you lack authorization to test. What is never acceptable: detonating on production networks, exposing the sandbox to the internet, or analyzing samples on a machine with access to real data. CISA’s #StopRansomware program and OWASP’s guidance on testing environments both underscore the same principle—containment architecture is your legal and operational defense.

Handle samples the way they arrive: password-protected archives (infected is the community standard), transferred over isolated networks, stored on dedicated encrypted volumes. Snapshot before detonation. Revert after. Every time, no exceptions.

Build this lab once, snapshot it properly, and you have a ransomware triage pipeline that turns a raw sample into C2 infrastructure, IOCs, and deployable detection rules in under ten minutes.

Frequently Asked Questions

Is it legal to detonate ransomware in a sandbox?

Yes—analyzing malware in an isolated lab for defensive research and incident response is legal in most jurisdictions and is standard industry practice. What’s never legal is running it against systems you lack authorization to test. Keep the lab host-only, never expose it to the internet, and never detonate on production networks.

Why use both FLARE-VM and CAPE?

They solve complementary problems. FLARE-VM gives you deep static and dynamic analysis tooling on Windows—PEstudio, FLOSS, CAPA, x64dbg—for hands-on analyst work. CAPE automates detonation from a Linux host and, critically, extracts C2 configurations automatically. Use CAPE for volume triage and IOC generation; use FLARE-VM for the samples that resist automation.

Does CAPE work against ransomware with anti-VM checks?

Partly. CAPE’s monitoring supports cover-flaws, hardened guests reduce hypervisor artifacts, and vmcloak strips many tells—but sophisticated samples with hypervisor-detection logic may refuse to execute or behave artificially. Plan on falling back to manual analysis with anti-anti-debug tooling for the hardest targets.

Can CAPE reports be exported to MISP?

Yes. CAPE supports exporting IOCs and signatures directly to a MISP instance for threat intelligence sharing, alongside JSON and HTML report formats via its API.

Related reading

• Hunting Ransomware Pre-Encryption Behavior with Sysmon and Velociraptor: Shadow Copy Deletion, Batch Encryption, Ransom Notes
• Weekly Threat Intel: LockBit Successor Shuffles, September 2026 Edge Device CVEs and Loader Chains

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy