mandiant/flare-vm is a PowerShell-driven collection of installation scripts that turns a bare Windows VM into a fully curated reverse engineering and malware analysis workstation for authorized analysts.
| Tool | mandiant/flare-vm — scripted installer that builds and maintains a reverse engineering environment on a Windows VM |
| Category | Environment provisioning / analysis workstation tooling (PowerShell over Chocolatey and Boxstarter) |
| Primary Use | Standing up a repeatable, curated malware analysis and reverse engineering lab VM with hundreds of tool packages installed via Chocolatey |
| Safe Use | For cyber security analysts building malware analysis environments in isolated VMs for authorized defensive research, incident response, and reverse engineering work |
| Telemetry Note | The installer is intentionally noisy by design: it requires disabling Windows Defender, Tamper Protection, and Windows Updates, and pulls many offensive-analysis binaries that EDR will flag — on any managed corporate host this pattern is a strong indicator of a lab build or policy violation |
mandiant/flare-vm is one of the most widely recognized projects in the malware analysis space, sitting at over nine thousand stars and written almost entirely in PowerShell. At its core it is not a single tool but a provisioning framework: a set of installation scripts that transform a plain Windows virtual machine into a fully stocked reverse engineering workstation. The project explicitly frames itself as solving the problem of reverse engineering tool curation — the tedious, error-prone work of hunting down disassemblers, decompilers, debuggers, and utilities every time an analyst builds a new lab. It comes from mandiant, the incident response and threat intelligence firm, and carries an Apache-2.0 license, which matters because the legal notice passes through license responsibility for each installed package to the end user.
The architecture is deliberately boring in the best sense of the word. FLARE-VM builds on two established technologies: Chocolatey, a Windows-based NuGet package management system, and Boxstarter, which leverages Chocolatey packages to automate installation and create repeatable scripted environments. A Chocolatey package here is essentially a ZIP file containing PowerShell installation scripts that download and configure a specific tool. That design choice means every tool in the environment is versioned, individually replaceable, and scripted rather than hand-installed — the difference between a lab you can rebuild in an afternoon and one that only exists as an aging snapshot nobody wants to touch.
The requirements section of the README is unusually candid and worth reading closely, because it encodes the operational assumptions of the whole project. FLARE-VM should only be installed on a virtual machine, full stop, with that word ONLY emphasized in the source. The VM needs Windows 10 or newer, PowerShell 5 or higher, at least 60 GB of disk and 2 GB of memory, usernames without spaces or special characters, and an internet connection. More significantly, the installer expects Tamper Protection and any anti-malware solution such as Windows Defender to be disabled — preferably via Group Policy — and Windows Updates turned off at least during installation. These are not incidental settings; an environment full of disassemblers, debuggers, and unpackers is inherently hostile territory for endpoint protection.
The installation flow itself is a clean example of Microsoft-signed-tooling-first provisioning. The analyst opens an elevated PowerShell prompt, downloads install.ps1 from the repository, runs Unblock-File on it to clear the mark-of-the-web, and sets Set-ExecutionPolicy Unrestricted -Force (with a documented fallback of -Scope CurrentUser if a more specific group policy overrides it). Then .\install.ps1 takes over: it runs validation checks, installs Boxstarter and Chocolatey if they are missing, and either launches a customization GUI or proceeds headlessly depending on the flags passed. A snapshot before installation is explicitly recommended, as is switching the finished VM to host-only networking — a sensible containment measure for a machine that will routinely execute hostile code.
The installer's parameter surface reveals how the project balances interactivity and automation. -password <password> supplies the current user's credentials so Boxstarter can survive reboots mid-installation, which is essential when dozens of packages require restarts. -noWait skips the confirmation message, -noGui disables the customization GUI for fully scripted builds, and -noReboots and -noChecks exist but are explicitly marked as not recommended. The two configuration-oriented flags are more interesting: -customConfig <config.xml> points at a configuration XML that defines the package list and environment variable paths, and -customLayout feeds in a custom taskbar layout XML. Both accept either local paths or URLs, which makes it trivial to version your lab definition in your own repository and rebuild identically later.
The installer GUI, shown after validation and bootstrap, lets the analyst customize package selection — drawing from both FLARE-VM's own package set and the broader Chocolatey community — and adjust environment variable paths. The default configuration lives in config.xml in the repository root, and it is more than a package list. It supports post-installation steps across several XML tags: apps, services, path-items, registry-items, and custom-items. The README's worked example shows a registry-items entry that sets HideFileExt to 0 under HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced to display known file extensions — a small quality-of-life tweak, but one that hints at how far the framework reaches into system state beyond simple software installation.
The taskbar layout mechanism is a nice piece of polish that most provisioning systems skip. CustomStartLayout.xml defines which tools get pinned where, but with pragmatic safeguards: entries for packages that failed to install simply do not appear, so no broken shortcuts litter the taskbar. Only .exe applications or shortcuts can be pinned, and the README documents workarounds for non-application items — create a shortcut pointing at cmd.exe or powershell with arguments, or use VM-Install-Shortcut with the -runAsAdmin flag for tools needing elevation. These details suggest a project maintained by people who actually use the environment daily rather than checking a box on a feature list.
The troubleshooting section is one of the more honest pieces of documentation you will read in this space. Installation failures funnel into three logs: %VM_COMMON_DIR%\log.txt, %PROGRAMDATA%\chocolatey\logs\chocolatey.log, and %LOCALAPPDATA%\Boxstarter\boxstarter.log. The project explicitly states that install.ps1 itself is rarely the failure point and that individual packages are usually to blame, then enumerates seven root causes: Chocolatey or MyGet download timeouts on .nupkg files, remote-host download timeouts, IDS or AV blocking tool downloads, host-specific issues, dependency build failures, dead tool URLs returning HTTP STATUS 404, and — most tellingly — tool SHA256 hashes drifting from what is hardcoded in the package script. The maintainers candidly note they cannot fix causes one through four since they do not control those upstream factors, while five through seven belong in the companion mandiant/VM-Packages repository where the actual package definitions live.
A few operational caveats deserve emphasis for anyone planning to adopt this. Package updates are described as best effort and untested; the recommended remedy for a broken update cycle is simply a fresh FLARE-VM install — practical advice given how cheap a scripted rebuild is. The commercial-tool integration is also thought through: if you install IDA Pro via the idapro.vm package, you must place your installer and optionally your license file on the Desktop before running the FLARE-VM installer, since the framework cannot distribute licensed software. The project also points to an official walkthrough video, a CONTRIBUTING guide, and the FLARE mailing list at flare-external@google.com for community announcements.
From a defensive perspective, it is worth understanding what a FLARE-VM build looks like from the outside, because defenders will encounter it. The installation pattern — Set-ExecutionPolicy Unrestricted, Group-Policy-disabled Defender, disabled Windows Updates, mass downloads of debugger and packer binaries — is a signature that any EDR or SIEM will flag on a managed host. That is precisely why the project insists on VM-only deployment and host-only networking post-install: this is lab infrastructure, not a workstation toolchain. Security teams should treat detection of this pattern on production endpoints as either a policy violation by a well-meaning analyst or, in adversarial hands, an actor attempting to build analysis capability in place — either way it warrants investigation.
For the authorized professional, flare-vm remains the reference answer to a real problem: reverse engineering environments rot, drift, and die with the analysts who built them. By expressing the entire lab as declarative XML configuration and idempotent PowerShell over Chocolatey and Boxstarter, mandiant has made lab reproducibility a solved problem — snapshot before, install, snapshot after, and rebuild from the config whenever the environment degrades. The nine-thousand-plus star count reflects that utility. It is not an attack tool; it is the workbench on which analysis of hostile code happens, and it belongs in every malware analysis and incident response team's standard kit.
mandiant/flare-vm.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.