# Building A Malware Lab

> Use before analysing any malware — building an isolated environment where a sample can run and be observed without escaping to your network or the internet.

- Skill: `jihedbfr-art/building-a-malware-lab` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add jihedbfr-art/building-a-malware-lab`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jihedbfr-art/building-a-malware-lab/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: jihedbfr-art (https://skillmd.com/u/jihedbfr-art)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/jihedbfr-art/building-a-malware-lab

---




## Prerequisites
- Target system, dependencies and environment configured.

## Usage
### Purpose

Analysing malware means running hostile code on purpose. Do it wrong and the sample spreads to your network, phones home and tips off the attacker, or encrypts the machine you're working on. This skill covers building a lab that contains all of that — the prerequisite for every other skill in this domain. Never analyse a live sample outside one.

### When to use it

Once, before you start doing malware analysis, and then maintained over time. Set it up properly and you reuse it for every sample; cut corners and the first ransomware sample teaches you why isolation matters.

### Procedure

1. **Use virtual machines you can snapshot and roll back.** A VM lets you detonate a sample, observe, then revert to a clean state in seconds. Build at least two: a **victim** VM (where the sample runs) and an **analysis/services** VM (where you watch it).
2. **Isolate the network — this is the critical control.** Put the lab VMs on a **host-only or internal network** with no route to your real LAN or the internet. The sample must not be able to reach anything you care about.
3. **Simulate the internet** so the malware behaves realistically without actually reaching out. Point the victim's DNS/gateway at the services VM running a tool that fakes internet responses:
   ```
   # on the services VM (e.g. REMnux)
   inetsim        # fakes DNS, HTTP, SMTP, etc. so the sample "connects"
   ```
   This lets you capture C2 attempts and behaviour while nothing leaves the lab.
4. **Harden the host boundary.** Keep the hypervisor and host patched, disable shared folders and shared clipboard during detonation, and don't rely on a VM alone for a sophisticated sample — some malware detects or escapes VMs. For high-risk work, use dedicated hardware.
5. **Tool the VMs.** On the victim, install analysis tooling (a FLARE-VM style Windows build); on the services VM, network capture and fake-services (a REMnux-style Linux build). Snapshot both **clean** before any sample touches them.
6. **Establish a workflow**: snapshot → transfer sample in (one-way, e.g. read-only share disabled after copy) → detonate → observe → collect artifacts → **revert to clean snapshot**. Never reuse a detonated VM without reverting.
7. **Handle samples safely outside the lab too**: store them encrypted/password-protected (the convention is a zip with password `infected`), never double-click them on your host, and don't email them around unprotected.

### Cheatsheet

```
lab layout
  [victim VM]  --- host-only/internal net ---  [services VM]
   Windows,                                      Linux (REMnux),
   FLARE-VM tools,                               inetsim (fake internet),
   snapshot: CLEAN                               tcpdump/wireshark
        |                                             |
        +------------- NO route to real LAN / internet

detonation workflow
  1. revert both VMs to CLEAN snapshot
  2. copy sample in (then disable the share)
  3. start capture on services VM
  4. detonate on victim VM, observe
  5. collect artifacts (network, files, registry)
  6. revert to CLEAN

sample hygiene
  store as password-protected zip (pw: infected)
  never run on the host; never leave shared clipboard/folders on during run
```

### Reading your setup for safety

- **A lab VM that can reach the real internet or LAN** is not a lab — it's a spreader. Verify isolation by trying to ping your gateway from the victim VM; it must fail.
- **inetsim (or equivalent) capturing the sample's callbacks** means you're getting C2/behavioural intel while nothing actually leaves — the goal state.
- **Shared folders/clipboard left enabled during detonation** are escape routes; confirm they're off before running anything.
- **A sample that refuses to run or behaves oddly** may be detecting the VM (anti-analysis) — a sign you may need bare-metal or anti-evasion tooling for that one.
- **No clean snapshot** means you can't safely reuse the VM; every analysis must start from a known-clean state.

### Pitfalls

- **Any network path to production.** The single most dangerous mistake. Host-only/internal networking, verified, before any sample runs.
- **Analysing on the host or a reused VM.** Detonate only in a revertible VM, and revert after every sample.
- **Trusting the VM as total containment.** Advanced malware detects or escapes VMs; use dedicated hardware and a patched hypervisor for serious work.
- **Careless sample handling.** An unprotected sample double-clicked on your host, or mailed in the clear, defeats the whole lab. Password-protect and move deliberately.
- **Leaving shared folders/clipboard on.** Convenient, and exactly the bridge malware uses to reach the host.

### References

- REMnux and FLARE-VM documentation
- INetSim documentation
- SANS FOR610 malware analysis lab guidance
- NIST SP 800-83 (Malware Incident Prevention and Handling)

## Inputs
- Relevant source code, logs, network traces, or system specifications.

## Outputs
- Analysis findings, security audit report, or generated code artifacts.