agentsclimarketplace

Performing dynamic analysis in a sandbox

Skill meltedinhex/analyst-ai-pack/skills/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.From its SKILL.md

Install
npx -y skills add meltedinhex/analyst-ai-pack --skill performing-dynamic-analysis-in-a-sandbox

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.5 KB, 574 tokens by cl100k_base, as published. Nobody here has run it

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

What ships with it: 3 files

4.0 KB alongside SKILL.md, 1 of them executable

references/

scripts/

Keep looking

Skills are one crate of 326,970. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.