141 lines
5.0 KiB
Markdown
141 lines
5.0 KiB
Markdown
---
|
|
name: setting-up-an-isolated-malware-analysis-lab
|
|
description: 'Builds a safe, isolated environment for detonating and analyzing malware
|
|
using virtualization, host-only or simulated networking, and snapshotting. Activates
|
|
for requests about creating a malware lab, sandbox VM, isolated analysis environment,
|
|
or safe detonation setup.'
|
|
domain: cybersecurity
|
|
subdomain: lab-foundations
|
|
tags:
|
|
- malware
|
|
- lab-setup
|
|
- virtualization
|
|
- isolation
|
|
- inetsim
|
|
- flare-vm
|
|
version: 1.0.0
|
|
author: analyst-ai-pack
|
|
license: Apache-2.0
|
|
mitre_attack:
|
|
- T1564
|
|
- T1497
|
|
d3fend:
|
|
- D3-DA
|
|
- D3-EAL
|
|
references:
|
|
- 'INetSim documentation — https://www.inetsim.org/documentation.html'
|
|
- 'FLARE-VM — https://github.com/mandiant/flare-vm'
|
|
- 'REMnux documentation — https://docs.remnux.org/'
|
|
---
|
|
|
|
# Setting Up an Isolated Malware Analysis Lab
|
|
|
|
## When to Use
|
|
|
|
- You need to run unknown or known-malicious binaries to observe behavior without risk to
|
|
production systems or the internet.
|
|
- You are standing up a repeatable analysis environment for static and dynamic work.
|
|
- You want a reverting, snapshot-based workflow so each sample starts from a clean state.
|
|
|
|
**Do not use** this as guidance for detonating samples on a host OS or a cloud VM with live
|
|
egress; that risks self-spreading malware escaping. Use a dedicated, network-isolated
|
|
hypervisor instead.
|
|
|
|
## Prerequisites
|
|
|
|
- A host with a type-2 hypervisor (VMware Workstation/Fusion or VirtualBox) or a dedicated
|
|
type-1 host. At least 16 GB RAM and 200 GB disk for two guests.
|
|
- A **victim** guest (Windows 10/11) for detonation — e.g. built with FLARE-VM tooling.
|
|
- An **analysis services** guest (REMnux, Linux) to simulate internet services and capture
|
|
traffic.
|
|
- Host networking able to provide a **host-only / internal** network with no NAT or bridged
|
|
adapter on the victim.
|
|
|
|
## Safety & Handling
|
|
|
|
- The victim VM must have **no bridged or NAT adapter** — host-only/internal only. All
|
|
"internet" is simulated by the REMnux guest running INetSim.
|
|
- Disable shared folders, drag-and-drop, and clipboard sharing on the victim before
|
|
detonation; these are escape and contamination paths.
|
|
- Take a **clean base snapshot** before any sample touches the VM and revert to it after
|
|
every run.
|
|
- Store samples in password-protected archives (`infected`) and only extract them inside the
|
|
victim VM.
|
|
|
|
## Workflow
|
|
|
|
### Step 1: Create and harden the victim VM
|
|
|
|
Install Windows in a new VM, apply analysis tooling, then strip escape paths:
|
|
|
|
```text
|
|
VM settings (victim):
|
|
Network adapter -> Host-only (vmnet1) or Internal network
|
|
Shared folders -> Disabled
|
|
Clipboard/DnD -> Disabled
|
|
USB controller -> Disabled
|
|
Snapshots -> enabled
|
|
```
|
|
|
|
### Step 2: Stand up simulated internet on REMnux
|
|
|
|
On the REMnux guest (same host-only network), give it a static IP and run INetSim so the
|
|
victim's DNS/HTTP/SMTP requests are answered locally:
|
|
|
|
```bash
|
|
# REMnux guest, e.g. 10.0.0.2 on the host-only network
|
|
sudo nano /etc/inetsim/inetsim.conf # set service_bind_address and dns_default_ip
|
|
sudo systemctl start inetsim
|
|
```
|
|
|
|
Point the victim's DNS and default gateway at the REMnux IP so all resolution and traffic
|
|
flow to the simulator.
|
|
|
|
### Step 3: Start packet capture
|
|
|
|
Capture from the REMnux side so the victim never sees a sniffer:
|
|
|
|
```bash
|
|
sudo tcpdump -i eth0 -w /cases/<sample-sha256>.pcap
|
|
```
|
|
|
|
### Step 4: Snapshot, detonate, observe, revert
|
|
|
|
```text
|
|
1. Snapshot victim as "clean-base"
|
|
2. Transfer the sample into the victim (read-only ISO or one-way copy)
|
|
3. Run procmon / process monitoring, then execute the sample
|
|
4. Observe for 3-10 minutes; collect artifacts (pcap, procmon log, dropped files)
|
|
5. Revert victim to "clean-base"
|
|
```
|
|
|
|
Use the helper script to verify a victim VM's adapters are isolated before you detonate.
|
|
|
|
```bash
|
|
python scripts/analyst.py --check-config vmx/victim.vmx
|
|
```
|
|
|
|
## Validation
|
|
|
|
- From the victim, `nslookup example.com` resolves to the REMnux IP (proves DNS is
|
|
simulated, not real).
|
|
- A browser request from the victim returns INetSim's default page, not live content.
|
|
- `tcpdump` on REMnux shows the victim's traffic; nothing reaches a real upstream gateway.
|
|
- Reverting the snapshot returns the victim to the exact clean state (no dropped files
|
|
persist).
|
|
|
|
## Pitfalls
|
|
|
|
- Leaving a NAT/bridged adapter "just to download a tool" — malware will use it. Install all
|
|
tooling before isolating, then remove the adapter.
|
|
- Forgetting to disable VMware Tools / guest additions clipboard, which some samples abuse.
|
|
- Detonating before snapshotting, so you cannot cleanly revert.
|
|
- Some samples detect INetSim's generic responses; if behavior stalls, consider FakeNet-NG
|
|
or tailored service responses.
|
|
|
|
## References
|
|
|
|
- See [`references/api-reference.md`](references/api-reference.md) for the config-check tool
|
|
and full source list.
|
|
- INetSim, FLARE-VM, and REMnux documentation (linked in frontmatter).
|