Validation and Lab Testing

Validation & Lab Testing

Detections should be validated before you trust production alerts. This page describes how to safely confirm the rules fire and how to confirm the tool-specific artifacts (which were sourced from observed behavior) match what you see in your own environment.

⚠️ Only run the tool in an isolated lab. Never execute BrowserSnatch on a production host, a machine with real credentials, or a network you don't own. Use a disposable VM with snapshots.

---

Lab setup

• Isolated VM — Windows 10/11, no network path to production, snapshot before each test.
• Disposable browser profiles — create throwaway browser profiles with fake saved passwords/cookies so nothing real is at risk.
• Telemetry — install Sysmon with a config that logs process creation (1), file create (11), and network (3); enable command-line auditing and scheduled-task auditing (see Coverage Matrix — telemetry prerequisites).
• Detection stack — forward logs to your SIEM/EDR with the Sigma rules deployed, and stage the YARA rule for on-demand scans.

---

Validation checklist

#	What to validate	How	Expected detection
1	Execution by name	Run the binary in the lab	Sigma 9.1, Hunt 1
2	Each command-line flag	Run with -pass, -cookies, -greed, etc.	Sigma 9.1
3	Credential-store access	Observe file-access events on Login Data/Cookies	Sigma 9.2, Hunt 2
4	Stealer DB output	Confirm output file location and name	Sigma 9.3
5	NTUSER.dat drop	Confirm whether/where C:\Users\Public\NTUSER.dat is written	Sigma 9.4, Hunt 4
6	Masquerade copy	Confirm the exact browser filenames and target paths used	Sigma 9.5, Hunt 5
7	Scheduled task	Capture the task name, trigger, and <Author> value	Sigma 9.6, Hunt 6
8	YARA match	Scan the binary and a memory dump	YARA rule

---

Confirm the tool-specific artifacts

The following IOCs are drawn from observed behavior and should be verified against your own sample, since exact paths/names can change between builds:

• NTUSER.dat path — confirm it is exactly C:\Users\Public\NTUSER.dat and note whether it is created every run or only in certain modes.
• Masquerade filenames/paths — confirm which of chrome.exe / msedge.exe / brave.exe are used and the precise destination directories (Program Files vs. a user-writable path).
• Scheduled-task details — capture the task name, path, trigger (logon/boot/interval), and confirm the <Author> is shaddy43.
• Flag behavior — verify which flags trigger persistence vs. collection so alert severity is assigned correctly.

Record findings and, if they differ from this wiki, update the pages via Contributing.

---

Tuning against false positives

After validation, baseline for a week and review:

• 9.2 — expect hits from backup/sync/EDR agents; add them to filter_browser or an allowlist.
• 9.5 — portable or nightly browser builds may be unsigned or oddly signed; allowlist known-good dev paths.
• 9.1 flag logic — if -history/-service/-pass are noisy, require the image name or 2+ flags.

---

Purple-team exercise idea

Run a scripted sequence — execute → snatch → stage NTUSER.dat → drop masquerade copy → register scheduled task, then confirm each step produces the mapped detection and that your analysts can reconstruct the chain from alerts alone. Use the Coverage Matrix as the scorecard.

Continue to → Contributing