vlad/reverse-skills-max
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
reverse-skills-max/vendor-new/analyst-ai-pack/skills/performing-dynamic-analysis-in-a-sandbox/SKILL.md

3.6 KiB
Raw Permalink Blame History

name, description, domain, subdomain, tags, version, author, license, mitre_attack, d3fend, references
name description domain subdomain tags version author license mitre_attack d3fend references
performing-dynamic-analysis-in-a-sandbox 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. cybersecurity malware-analysis
malware
dynamic-analysis
sandbox
behavioral
procmon
detonation
1.0.0 analyst-ai-pack Apache-2.0
T1055
T1071
T1547
T1497
D3-DA
D3-PSA
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:

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