WBP SI study materials
WBP SI study resources

A Hash Mismatch, a Seven-Hour Clock, and One Unreproducible Critical Finding

WBP SI · Put your knowledge to work in context.

All case studies

A Hash Mismatch, a Seven-Hour Clock, and One Unreproducible Critical Finding

The evidence package for a completed inspection contains 240 screenshots, 18 configuration exports, and a chain-of-custody log. Three problems surface during quality review. (1) Screenshots from one inspector's laptop show timestamps seven hours ahead of the NTP-synced server logs, and that inspector captured the only evidence for two high-severity findings. (2) A configuration export hashed at acquisition as SHA-256 3f9c... but the copy in the report hashes as b71e... because an analyst re-saved it to strip a plaintext database password. (3) The custody log has no signature for a transfer of the encrypted USB between two inspectors, and shows the USB was out of the safe for 14 hours. A critical finding rests on a single tool plugin output that cannot be reproduced. The audit committee meets in 24 hours.

1. How do you remediate and report the hash mismatch on the configuration export?

Read the worked answer

The mismatch is explainable, but it must be documented rather than quietly re-hashed.

Preserve the original. Retrieve the untouched file from write-once storage or the acquisition copy. Confirm its hash still equals 3f9c... That file remains the evidence of record. Never overwrite it with the redacted version.

Treat the report copy as a derivative. Give it its own hash (b71e...), label it 'redacted derivative - not the original', and attach a redaction log stating what was removed, by whom, when, and why (removal of a plaintext credential is a legitimate and necessary step).

Record the chain: original hash, derivative hash, the transformation performed, the tool used, and the operator. If the redaction tool preserves the rest of the file byte-for-byte, say so; if not, describe what changed.

In the report, reference the original hash for evidentiary purposes and the derivative for readability, and state plainly that the two differ because of redaction. A reviewer who recomputes the hash and finds a mismatch with no explanation will question the whole package; a documented redaction is routine and defensible.

Also fix the root cause: credentials should not be present in exports at all. Recommend the collection tooling mask secrets at acquisition so derivatives are unnecessary.

2. What is the impact of the seven-hour timestamp offset and the missing custody signature, and how do you address both?

Read the worked answer

Neither is automatically fatal, but both reduce the weight the evidence will bear and both must be disclosed.

Timestamp offset:

  • Establish the offset by comparing the laptop clock to a known-good source, and confirm the direction and magnitude (plus seven hours, not minus). Document the laptop's timezone setting and whether it was changed during the engagement.
  • Corroborate the two high-severity findings with server-side logs, authentication records, or change tickets. If server logs show the same activity at the corrected time, the findings survive with a documented normalization note. If not, their evidentiary weight drops sharply.
  • Record the correction method in the report so a reader can reproduce it. Do not silently adjust the images.

Missing custody signature and 14 hours out of the safe:

  • Reconstruct the transfer from other sources: door access logs, email or ticket records, the receiving inspector's contemporaneous notes, and the safe's access log.
  • Get a signed, dated statement from both inspectors describing the handover, marked as a reconstruction, not a contemporaneous record.
  • State the gap explicitly. An unexplained 14-hour gap with no signature is a defensible challenge to integrity; a disclosed gap with corroborating records is a managed weakness.
  • If the USB's contents can be re-verified against acquisition hashes, do so; that is the strongest answer to a custody challenge.

3. The critical finding cannot be reproduced. Do you include it, downgrade it, or drop it?

Read the worked answer

Do not drop it, and do not present it at critical severity as if confirmed.

First, attempt reproduction properly: same plugin version, same credentials, same target state, same configuration. Many 'unreproducible' results are version drift, a host that has since been patched, or a plugin that needs an authenticated context. Check whether the host changed between the original run and now.

Then classify honestly:

  • If it reproduces: confirmed, keep severity.
  • If it does not reproduce and the target has not changed: report as unconfirmed, retain the original output as evidence, describe the conditions of the original observation, and state that independent reproduction failed. Severity should reflect uncertainty - typically reported as an observation or a lower-confidence finding with a validation action.
  • If the target changed and that explains the difference: report as confirmed-at-time-of-test with a note that the condition may have been remediated; do not silently keep it as current.

What not to do: present a single plugin output as a confirmed critical finding because the report is due. If it is later shown to be a false positive, every other finding in the package is questioned.

In the 24-hour window, prioritise: correct the hash documentation, normalise the timestamps, disclose the custody gap, and reclassify the critical finding. A package with disclosed limitations is more defensible than one with a confident claim that will not survive re-testing.