DHParser¶
What DHParser does¶
Microsoft Defender DetectionHistory examination
DHParser converts Microsoft Defender DetectionHistory binary records into
readable JSON. Depending on the record, output can include the detection GUID,
threat name, status ID, detected path, hashes, size, UTC tracking time, user,
spawning process, and security context.
Use the JSON as a structured representation of the acquired Defender artefact, not as independent proof that malware executed or that a named person initiated an action. Preserve the original path, numbered parent directory, record hash, parser version, exact command, messages, and output hash.
Reviewed reference implementation
This guide was checked against the official DHParser v1.0.1 repository in August 2026. The preserved screenshots show the same version. Record the exact executable or source revision and its SHA-256 for every examination.
Choose your journey¶
Obtain the parser, record provenance, and create verified evidence and output locations.
Complete when the executable and working input are attributable.Beginner · Windows · 10–20 min 02Parse and reviewRun single-file or controlled directory parsing, inspect messages, and review the JSON without overclaiming.
Complete when one result is traceable to its binary source.Practical · Command Prompt · 20–35 min 03Hands-on LabsInvestigate a safe Defender training detection in a browser simulation or isolated VM.
Complete when the finding separates detection from execution and intent.Guided · 25–100 minEvidence workflow¶
The binary record and its context remain primary. JSON makes the values easier to review, but a second analyst should still be able to identify the original record, reproduce the command, compare the output, and test the interpretation.
A verified working copy from ProgramData\Microsoft\Windows Defender\Scans\History\Service\DetectionHistory.
Host or image, original path, source SHA-256, DHParser version and hash, exact command, messages, JSON filename, and output SHA-256.
Defender retained a DetectionHistory record containing the displayed values at acquisition time.
Understand the artefact¶
Location
Numbered folder and GUID file¶
Records commonly appear beneath a numbered directory inside
DetectionHistory. Retain the complete original path because the parent folder
and filename help another analyst locate the same artefact.
Detection identity
GUID, threat name, and status¶
The record can contain a Defender detection GUID, threat label, and
ThreatStatusID. Preserve the raw status value and use authoritative Defender
context before translating it into a remediation claim.
Tracked object
Path, hashes, and size¶
The detected path and hash fields identify what Defender recorded. They do not prove the file still exists, completed execution, or was created by the named user.
Activity context
UTC time, user, and spawning process¶
ThreatTrackingStartTime is parsed from FILETIME and displayed in UTC. User and
spawning-process fields are valuable leads, but they require endpoint and event
corroboration before attribution or execution claims.
Choose the parsing mode¶
| Mode | Command pattern | Use when | Caution |
|---|---|---|---|
| Single file | dhparser.exe -f "record" -o "output" |
Learning, validation, or one case-relevant GUID file | Best starting point because input and output remain easy to trace. |
| Normal directory | dhparser.exe -rf "DetectionHistory" -o "output" |
The copied directory retains normal Defender naming | Record the source population and parsed, skipped, and failed counts. |
| Greedy directory | dhparser.exe -rgf "collected" -o "output" |
A trusted collection tool renamed files or removed expected naming | Can attempt unrelated extensionless files. Restrict the directory and preserve errors. |
The official documentation identifies -f and -o as required. Directory
processing adds -r; greedy processing adds -g. Start with the smallest mode
that answers the case question.
Evidence and interpretation boundaries¶
- Acquire before parsing
The live Defender tree is protected and can change. Prefer an authorised forensic acquisition, protect the source, and parse a verified working copy in an accessible case directory. - Keep the parser output separate
Write JSON to a new controlled folder, not beside or inside the protected evidence source. - Preserve failures and omissions
Header mismatch, permission, malformed-record, skipped-file, and parse errors are part of the result. Successful records do not erase failed ones. - Treat the record as Defender telemetry
A detection can be created without successful execution. Threat names are Defender classifications, not a complete behavioural finding. - Corroborate remediation and attribution
Compare Defender Operational events, protection history or management telemetry, quarantine context, file-system evidence, Prefetch, Amcache, process evidence, browser records, and case-specific network data.
Do not generate detections with harmful tooling
The historical screenshots include a credential-dumping tool download. They are retained only to preserve the original SUSA demonstration. For learning, use an instructor-provided synthetic record or an approved benign security test artefact in a disposable, authorised VM. Do not download or execute credential-dumping software to create lab data.
Claim boundaries¶
Supported observation
The acquired DetectionHistory record contains the displayed Defender threat label, path, hash, tracking time, identity, process, and status fields under the recorded parser conditions.
Not established alone
The detected object executed successfully, remained present, was malicious in the case context, was remediated as assumed, or was knowingly introduced by a particular person.