104 lines
3.6 KiB
Markdown
104 lines
3.6 KiB
Markdown
---
|
|
name: performing-dynamic-analysis-in-a-sandbox
|
|
description: 'Runs a sample in an instrumented sandbox to observe behavior: process tree, file
|
|
and registry changes, network activity, and persistence, then summarizes the behavioral
|
|
report into capabilities and IOCs. Activates for requests to detonate a sample, do dynamic
|
|
or behavioral analysis, or interpret sandbox output.'
|
|
domain: cybersecurity
|
|
subdomain: malware-analysis
|
|
tags:
|
|
- malware
|
|
- dynamic-analysis
|
|
- sandbox
|
|
- behavioral
|
|
- procmon
|
|
- detonation
|
|
version: 1.0.0
|
|
author: analyst-ai-pack
|
|
license: Apache-2.0
|
|
mitre_attack:
|
|
- T1055
|
|
- T1071
|
|
- T1547
|
|
- T1497
|
|
d3fend:
|
|
- D3-DA
|
|
- D3-PSA
|
|
references:
|
|
- 'CAPE Sandbox — https://github.com/kevoreilly/CAPEv2'
|
|
- 'Sysinternals Process Monitor — https://learn.microsoft.com/sysinternals/downloads/procmon'
|
|
---
|
|
|
|
# Performing Dynamic Analysis in a Sandbox
|
|
|
|
## When to Use
|
|
|
|
- Static analysis is blocked by packing/obfuscation and you need to observe runtime behavior.
|
|
- You want a behavioral picture: spawned processes, dropped files, registry edits, and C2.
|
|
- You are confirming capabilities hypothesized from static analysis.
|
|
|
|
**Do not use** dynamic analysis as the only method — evasive samples may sleep, detect the
|
|
sandbox, or require arguments. Pair it with static/RE work.
|
|
|
|
## Prerequisites
|
|
|
|
- An isolated lab with a victim VM and simulated internet (see the lab-setup skill).
|
|
- A sandbox stack (CAPE/Cuckoo) or manual instrumentation: Process Monitor, Process Explorer,
|
|
Regshot, and a packet capture on the services guest.
|
|
- A clean base snapshot to revert to.
|
|
|
|
## Safety & Handling
|
|
|
|
- Detonate only inside the isolated victim VM; revert the snapshot after each run.
|
|
- Route all network through the simulated-internet guest; never allow live egress.
|
|
- Defang any captured URLs/IPs before they leave the lab.
|
|
|
|
## Workflow
|
|
|
|
### Step 1: Prepare instrumentation
|
|
|
|
Start Process Monitor (filtered to the target), Regshot baseline, and packet capture on the
|
|
services guest. Snapshot the victim as clean.
|
|
|
|
### Step 2: Detonate with the right context
|
|
|
|
Many samples need a parent (Office, rundll32), an export (`rundll32 dll,Export`), or arguments.
|
|
Match the original delivery context or the sample stalls.
|
|
|
|
### Step 3: Observe for the full behavior window
|
|
|
|
Watch process creation, file drops, registry Run keys/services, scheduled tasks, and network
|
|
beacons. Give it several minutes; some samples sleep first.
|
|
|
|
### Step 4: Summarize the report
|
|
|
|
Feed the sandbox JSON (or your collected logs) to the summarizer to group events into
|
|
capabilities and IOCs:
|
|
|
|
```bash
|
|
python scripts/analyst.py summarize report.json
|
|
```
|
|
|
|
### Step 5: Diff the system state
|
|
|
|
Compare Regshot/file baselines pre- and post-run to capture persistence and dropped artifacts.
|
|
|
|
## Validation
|
|
|
|
- The observed process tree and network match the static-analysis hypothesis.
|
|
- Persistence mechanisms found dynamically are confirmed in registry/task artifacts.
|
|
- Re-running from the clean snapshot reproduces the core behavior.
|
|
|
|
## Pitfalls
|
|
|
|
- Detonating without the required parent/args, so the sample exits early ("sandbox evasion"
|
|
that is really a context problem).
|
|
- Too-short observation windows that miss sleeping or staged payloads.
|
|
- Trusting a single sandbox verdict; tune and corroborate.
|
|
- Allowing real network egress and contaminating live infrastructure.
|
|
|
|
## References
|
|
|
|
- See [`references/api-reference.md`](references/api-reference.md) for the report summarizer.
|
|
- CAPE Sandbox and Process Monitor (linked in frontmatter).
|