Blender Scanner

Blender Scanner

Blender compares your payload's runtime IOCs against a snapshot of every running process on the host, and surfaces the processes that share the most behavior with your payload. The intent is target selection: when a payload's memory anomalies look a lot like chrome.exe's, chrome.exe is a good injection / impersonation candidate because the EDR has already accepted those anomalies as normal for that process.

It's a doppelganger module, not part of the file/dynamic detection score — Blender output drives the /doppelganger?type=blender page only.

---

Pipeline

1. snapshot       2. parse              3. compare
host scan         per-process IOCs      payload vs snapshot

┌─ take_system_sample ──┐  ┌──────────────────┐  ┌─ compare_payload ──┐
│ Moneta system-wide    │  │ name/PID grouping │  │ load latest scan   │
│ HSB system-wide       │ ─►│ DLL grouping      │ ─►│ load payload IOCs  │
│ HollowsHunter (PIDs)  │  │ severity tagging  │  │ overlap %          │
└───────────────────────┘  └──────────────────┘  └────────────────────┘
        │                                                 │
        ▼                                                 ▼
 BlenderScan_<MMDDYYYY>.json                  ranked process list

---

Snapshot — take_system_sample()

Run from the Dashboard ("Run Blender scan") or via POST /doppelganger {type: blender, operation: scan} / the doppelganger-scan --type blender CLI.

For every visible process the scanner runs three baseline tools:

Tool	What it contributes
Moneta	Memory IOCs — Modified Code, Unsigned Module, Missing PEB, Modified PE Header, Inconsistent Execution, Phantom Image, Private Executable, Non-Image Thread, Non-Image Base
HSB (Hunt Sleeping Beacons)	Sleep-pattern / thread-timing anomalies (per-process structured findings)
HollowsHunter	Process-hollowing detections, PE-Sieve-style memory modifications

The output lands as Utils/DoppelgangerDB/Blender/BlenderScan_<MMDDYYYY>.json. The dashboard reads the most recent file and shows its mtime — that's how you know whether the snapshot is current enough to be useful.

---

Compare — compare_payload(payload_hash)

Triggered by GET /doppelganger?type=blender&hash=<md5> or the doppelganger-analyze <hash> --type blender CLI command. The comparator:

1. Loads the latest BlenderScan_*.json (the snapshot).
2. Loads the payload's dynamic_analysis_results.json (must exist — run dynamic analysis first).
3. Extracts the same per-IOC + per-DLL structure from the payload.
4. Walks every process in the snapshot, scoring overlap.

Scoring is overlap-percentage based — same IOC types and instance counts on the same DLLs score higher. Memory addresses and file paths are normalized out before comparison so two processes loading the same ntdll.dll with the same anomaly pattern match even when the addresses differ.

Top matches are returned ranked by similarity, with a per-IOC breakdown so the operator can see which specific findings overlapped.

---

Parsers

The Blender comparator owns three parser helpers that extract a uniform IOC shape from each tool's output:

• parse_moneta_findings(stdout) — line-based parsing; finds <process> : <pid> headers, walks indented IOC and DLL Image rows, builds a per-process+per-DLL IOC list.
• parse_hsb_findings(json_blob) — structured Hunt-Sleeping-Beacons output; extracts process_name, pid, and the per-finding type + description array.
• parse_process_scanner_findings(json_blob) — handles HollowsHunter / PE-Sieve JSON output; maps tool-specific detection codes into the same IOC type vocabulary Moneta uses, tagging severity (HIGH / MEDIUM) and instance count.

The unified shape is what makes payload-vs-snapshot comparison possible — different tools, same vocabulary downstream.

---

When to use it

• Pre-deployment target selection — find a process that already exhibits the IOCs your payload would create. Inject there.
• Post-detection review — if your payload was flagged for a specific IOC, Blender shows which legitimate processes ALSO have that IOC (= false-positive surface for the rule that fired).
• Rule-tuning input — IOCs that match many legitimate processes are noisy detection signals.

It is not:

• A standalone detection tool — it doesn't decide if your payload is malicious.
• A score contributor — Blender output never feeds the Detection Score Explained number.

---

Storage

File	Purpose
Utils/DoppelgangerDB/Blender/BlenderScan_<MMDDYYYY>.json	Per-day system snapshot
Results/<hash>_<name>/dynamic_analysis_results.json	Source of payload IOCs (read-only)

Old snapshots accumulate — the cleanup endpoint clears them along with everything else. The doppelganger DB path is configurable in Config/config.yaml under analysis.doppelganger.db.path.

---

See also

• FuzzyHash Scanner — the other doppelganger module (file-block similarity vs. tool DB)
• Detection Score Explained — what feeds the file's score (Blender doesn't)
• Application Architecture — where Blender sits relative to the rest of the analyzers