Mid-Level Digital Forensic Examiner Interview Preparation Guide

Clarify scope & goals
Triage incoming forensic evidence at enterprise scale to quickly prioritize incidents, preserve chain-of-custody, and automate low-risk actions while preserving human oversight for legally-sensitive decisions.

High-level architecture

• Ingest layer: secure upload APIs, EDR connectors, SIEM feeds, removable-media intake stations. Files hashed (SHA-256), metadata extracted.
• Orchestration & Playbook Engine: rules engine + workflow runner (idempotent, versioned playbooks).
• Enrichment services: IOC/IOC-source lookup, reputation, YARA, hash-db, timeline extraction, artifact parsers.
• Evidence Preservation Store: WORM object store with immutable metadata and sealed custody records.
• Case Management & Analyst UI: task queues, manual review, annotated timelines.
• Audit & Legal Vault: append-only logs, signed events, exportable reports for court.

Playbook types

• IOC Enrichment (automated, low-risk): extract indicators, cross-check with threat intel, tag evidence, generate priority score.
• Rapid Containment (conditional): trigger containment (isolate host/quarantine file) only after meeting thresholds + human approval for high-impact systems.
• Evidence Preservation (mandatory): create forensic image, store in WORM, take cryptographic seals, capture volatile data snapshot.
• Preliminary Triage (automated + human): run timeline, keyword search, PII detectors, return summary for examiner.
• Escalation & Legal Notification: workflows that notify legal/LE and embargo actions.

Decision gates & risk scoring

• Multi-factor score: IOC severity, asset criticality, confidence, legal sensitivity -> map to actions (auto, require approval, no action).
• Gate examples:
  • Auto-action: high-confidence IOC on low-criticality host -> immediate quarantine.
  • Manual gate: containment on critical servers or any action affecting ESI retention or user data -> require SIRT lead approval.
  • Legal gate: seizure, external disclosure, or preservation hold -> require Legal/LE sign-off.

Human-in-the-loop controls

• Role-based approvals with step-up MFA for containment/legal actions.
• “Preview” mode showing expected commands and rollback plan.
• Escalation path, audit of who approved, timers for automatic rollback if no human action.
• Adjustable playbook dry-run for training and validation.

Audit & evidentiary logging

• Every event logged immutably: actor, timestamp (UTC), playbook version, inputs, outputs, decision rationale, approvals, cryptographic hashes.
• Logs stored in append-only ledger (e.g., WORM + blockchain anchoring) with exportable chain-of-custody report (PDF + signed manifest).
• Retention policies aligned to legal holds and EDR/SIEM integration for long-term preservation.

Trade-offs & controls

• Balance speed vs. legal risk: stricter gates on high-impact systems.
• Ensure reproducibility: versioned playbooks, signed binaries, test harnesses.
• Privacy: PII minimization, redaction, and need-to-know access controls.

Example: automated IOC enrichment flags malware hash on user laptop -> playbook computes score = medium, asset = non-critical → auto-create forensic image in Preservation Store and notify examiner; containment requires SIRT approval shown with preview and one-click quarantine if approved. Audit captures full chain for court.

Direct answer

For this scenario the report structure itself is standard; what makes it court-defensible is that every named constraint (the incomplete imaging metadata, the frozen cloud assets, the region-restricted supplier logs, and the pre-capture containment action) gets its own explicit, dated entry instead of being smoothed over to make the narrative read cleaner.

Outline

• Case Background and Authorization: detection timeline, containment actions taken (including that a suspected backdoor was removed before all logs were captured), and the legal basis for the investigation.
• Evidence Inventory: every item with acquisition tool, hash, timestamp, and operator, including a specific entry for imaging session B stating exactly which metadata fields are missing (for example, exact clock offset, operator sign-off) rather than omitting the item or silently backfilling the gap.
• Chain of Custody: standard transfer log (who, when, why, verification hash at each handoff), plus a note on how the frozen cloud assets are being tracked even though they can't yet be acquired.
• Methodology and Reproducible Steps: acquisition and analysis steps with enough command-level detail that another examiner could repeat them on the evidence that was actually captured.
• Findings: factual statements tied to specific evidence items, each one scoped to what that item can actually support.
• Gaps and Constraints, as its own section: the cloud-asset freeze and its scope, the supplier dispute limiting regional log access, and the fact that early containment removed the backdoor before full log capture. Each gets a plain statement of what it prevents you from confirming.
• Conclusions: bounded explicitly by the gaps above, not stated as if the missing evidence didn't matter.
• Remediation Recommendations: prioritized by risk and by what's actually actionable given the legal hold and the supplier access limitation, not a generic best-practices list.

Worked example

A finding written honestly against a real gap: "Outbound HTTPS connections from the finance server to [external domain] were observed in the server's local connection logs between the detection window's start and the containment action. Corresponding audit-trail records from the cloud provider for [region] could not be obtained due to the active supplier access dispute; as a result, this report cannot confirm the volume or content of any data transferred through the cloud path, only that outbound connections to the domain occurred." No fabricated volume figure fills the gap; the gap itself is the honest finding.

Trade-offs and pitfalls

The strongest pull under deadline and stakeholder pressure is to smooth the narrative so gaps read as minor footnotes instead of load-bearing limitations on the conclusion, which is exactly what a disclosure obligation and later cross-examination will punish. A second pitfall is writing remediation recommendations that assume access to logs or assets you don't actually have yet because of the legal hold, which makes the recommendations impossible to execute on the timeline given. The right move when a constraint blocks a conclusion is to say so plainly and recommend the specific follow-up action (obtain the region's logs once the dispute resolves, re-image once the freeze lifts) rather than guessing.

Overview (goal)
I would implement a repeatable automated forensic triage + collection workflow that preserves chain-of-custody, produces verifiable artifacts, and enforces manual checkpoints for defensibility.

1) SIEM triggers

• Medium-severity rule set (e.g., suspicious PowerShell, credential dump, lateral movement indicators).
• Trigger creates an incident ticket with host(s), attacker indicators, and a playbook ID.

2) Automated collection agents/scripts

• Pre-approved, signed collector (Python/PowerShell/Go) deployed via EDR that:
  • Gathers volatile data (pslist, netstat, memory metadata pointers), critical logs, and forensic disk image request.
  • Quarantines process artifacts as read-only copies.
• Collector runs in read-only mode; full disk imaging requires explicit manual approval.

3) Verification & logging

• Each artifact hashed (SHA-256) at collection and after transfer; hashes logged to immutable storage (WORM/append-only).
• Collector signs metadata with host-specific key; SIEM ingests hashes and signatures for correlation.

4) Secure transfer & storage

• TLS mutual-auth to centralized forensic server (air-gapped VLAN if high-sensitivity).
• Images stored encrypted (AES-256) on HSM-backed key management; immutable retention policy and indexed catalog.

5) Access controls & audit logging

• RBAC with least privilege; MFA and break-glass for emergency access.
• All actions logged to SIEM + separate write-once audit store; logs include operator ID, timestamp, artifact hash, ticket ID.

6) Manual checkpoints (defensibility)

• Human approvals required for disk imaging, legal hold, and cross-jurisdictional actions; digital signatures appended to case file.
• Forensic examiner performs formal chain-of-custody form (digital + PDF) stamped with hashes.

7) Testing & validation

• Monthly tabletop and live-playbook drills using seeded indicators and test images.
• Validate collector integrity (code signing), repeatability (identical hashes across runs), and end-to-end flow (SIEM trigger → collection → transfer → verify).
• Retain test evidence and after-action reports to prove procedure reliability in court.

I would document SOPs and preserve logs, signatures, and approvals to demonstrate integrity and adherence to legal standards.

Direct answer

My job as team lead isn't to pick which examiner is right; it's to direct a re-analysis rigorous enough that the answer becomes evidence-supported rather than opinion-supported, and to be honest in the deliverable if the disagreement genuinely can't be resolved. A conclusion the team quietly agreed to paper over is far more dangerous to credibility than one that's transparently unresolved.

Structured elaboration

Directing a reproducible re-analysis

• State the two competing hypotheses explicitly (user-initiated deletion versus an automated update removing the file) and, for each, list the observable artifacts that would support or contradict it. For a Windows host that means the recycle-bin metadata records (the paired $I and $R files written when something is sent to the bin), the change journal and file-system transaction log entries for that file's record, the parent directory index update, the MFT record's entry-modified time rather than the file's last-modified time, logon and session records showing whether an interactive user was even present at the moment of removal, the update service's own installer log of files it removed, and any endpoint telemetry or object-access auditing that names the process that performed the delete.
• Be explicit up front about which artifacts cannot settle this. A file's last-modified timestamp records the last write to its contents, not its removal, so a last-modified time sitting next to an update event is coincidence-shaped evidence and neither examiner should be leaning on it. Absence of a recycle-bin record is equally weak on its own: Shift+Delete, a command-line del, deletion from removable or network media, a file larger than the bin's size limit, and a bin that has been disabled all bypass the recycle bin, and an intentional user deletion is precisely the case where a user reaches for Shift+Delete.
• Have both examiners re-run their analysis against a freshly verified, hash-matched copy of the evidence (its cryptographic fingerprint recomputed and shown to be identical to the original's, which is what proves the copy carries no changes of its own) in a clean, isolated environment, not their original working copy, so neither result is contaminated by whatever assumptions or artifacts accumulated in their first pass.
• Require every step to be scripted and versioned (recorded commands, tool versions, and exact parameters) so a third party could rerun the same steps and get the same result.

Ensuring impartial verification

• Bring in an independent examiner, someone who hasn't already formed an opinion on this specific question, to replicate the scripted steps in their own separate environment using the same tool versions, and log their output independently.
• If the two original examiners used different tools to reach their conclusions, that's worth testing directly: run both toolchains against the same evidence copy and see whether the divergence is in the tools or in the interpretation.
• Where a hypothesis can be tested rather than argued, test it: on a matching build, run the same update package in a lab virtual machine and observe which artifacts an automated removal actually leaves, then compare that signature against the evidence. A reproducible experiment beats two experienced opinions.

Reconciling into a deliverable

• Where the re-analysis converges, produce a single conclusion with a stated confidence level and the specific artifacts supporting it.
• Where genuine disagreement remains after independent verification, the deliverable states both positions honestly: what evidence supports each, what would resolve the disagreement (a specific additional artifact or test), and an honest confidence level for each rather than false certainty.

Communicating to investigators and counsel

• Lead with a plain-language executive summary, then a technical appendix with the reproducibility artifacts for anyone who needs to go deeper.
• Be explicit about uncertainty rather than picking a side to sound confident; overstating confidence to avoid an awkward "we don't fully agree" conversation is what actually damages credibility if it later surfaces under cross-examination.
• Document that a structured, independent re-analysis process was followed, since that process itself, not just the conclusion, is part of what makes the finding defensible.

Worked example

The re-analysis in a clean environment starts by disposing of the artifact both original examiners had been arguing over: the file's last-modified timestamp sits 40 seconds after a scheduled update-service log entry. That proximity looks decisive and isn't, because a last-modified time records the last write to the file's contents, not the act of deleting it, so it is consistent with either explanation and with neither. Setting it aside is what forces the re-analysis onto artifacts that actually date and attribute a removal.

The independent third examiner replicates the scripted steps and finds three things neither original examiner had checked. First, the change journal carries a delete record for that file's reference number, which timestamps the removal itself rather than the last write. Second, that timestamp falls inside a window in which the logon records show no interactive user session on the machine at all, which is hard to reconcile with a person choosing to delete a file. Third, the update package's own log lists that exact path among the files it removed, and application execution artifacts confirm the updater ran in that window. The same replication also confirms there is no recycle-bin $I and $R pair for the file, and the report deliberately demotes that absence to weak corroboration rather than letting it carry the conclusion, since Shift+Delete, a command-line delete, deletion from removable or network media, and a file over the bin's size limit are all ordinary user actions that leave the bin equally empty.

Those three artifacts together, found only because the process required an independent re-check rather than trusting either original conclusion, shift the team's confidence meaningfully toward the automated-update explanation, though not to certainty: the report notes that a user with remote or scripted access could in principle produce the same absence of an interactive session, and names the endpoint telemetry that would have settled attribution outright had it been enabled on this host. The report states the conclusion, states the confidence level, and names the change-journal record and the session gap as the deciding artifacts, so anyone reviewing it can see exactly why the team moved from disagreement to a shared position and what would overturn it.

Trade-offs and pitfalls

The pressure in this situation is to resolve the disagreement quickly by deferring to the more senior examiner's judgment; that's a mistake, since seniority isn't evidence, and doing so risks shipping the wrong conclusion with false confidence attached. The subtler trap is the one this particular disagreement invites: treating the absence of an artifact as proof of a mechanism, when that artifact has several ordinary reasons to be missing. That is why the empty recycle bin is corroboration in the report rather than the conclusion, and why the artifacts that positively date and attribute the removal are what the conclusion rests on. The re-analysis takes real time the case may not have much of, but a report that says "we don't fully agree, here's why, and here's what would settle it" is more defensible under scrutiny than one that hides an unresolved internal disagreement behind an artificially unanimous conclusion.

I look at delivery confidence as a combination of evidence, not a gut feel.

Signals I check:

• Milestones: are we hitting key checkpoints on time, or slipping repeatedly?
• Critical path: are there unresolved items that could move the end date?
• Scope stability: is work still changing, or have requirements been settled?
• Dependency health: are product, design, platform, or vendor inputs arriving when needed?
• Team throughput: is the team burning down work (completing planned tasks at the rate the plan assumed, the way a sprint burndown chart tracks remaining work) at the expected pace?
• Risk trend: are risks being reduced, or are they aging without owners?

How I communicate it:
I avoid saying “we’re fine” or “we’re doomed.” I usually say, “Based on current scope, capacity, and dependency status, I have medium confidence in the date. The biggest variables are X and Y, and if they don’t move by Friday, confidence drops.” That is honest, specific, and actionable. In a real project, X and Y are concrete named risks rather than literal letters, for example: “The biggest variables are vendor API access and the pending legal review of the data-sharing agreement, and if they don’t move by Friday, confidence drops.”

What helps most:
I pair the status with the assumption behind it and the decision needed, so leadership understands both the probability and what would change it.

A timestamp discrepancy is a credibility test, not just a technical puzzle: how I handle it says more about my rigor than the discrepancy itself does, so I treat it as something to investigate methodically and disclose, not explain away.

Investigating the discrepancy

First I confirm the evidence itself is intact regardless of the timestamp question: compare the pre- and post-imaging hashes and show the image is bit-for-bit identical to the source, so the discrepancy is a documentation issue, not an integrity one. Then I gather every relevant clock source: the imaging tool's internal log, the device's own system clock and time zone setting, the examiner workstation's NTP (network time protocol, used to keep computer clocks synchronized) sync logs, and the custody log's own timestamps. I try to reproduce the pattern in a controlled setting, since a consistent, explainable offset (the tool logs in UTC while the custody log used local time, for example) looks very different from a random, unexplained drift.

Explaining it in court

I lead with the hash comparison, because that's the fact that matters most: the content is unchanged. Then I state the technical cause plainly, with a concrete number rather than a vague reassurance, for example: "the imaging tool recorded Coordinated Universal Time while the custody log used local time, which produced a fixed offset consistent with the time-zone difference." A simple visual, custody-log entry next to device clock next to imager log next to hash verification, makes the source of the offset visible rather than something the jury has to take on faith.

Remediating and strengthening provenance going forward

I update the custody log for this case to record both the device-reported time and my own workstation time, with the observed offset annotated, and attach the raw imaging-tool logs to the case file. Beyond this case, I push for a process fix: mandatory NTP-sync verification immediately before every acquisition, a standard of always logging in UTC, and a chain-of-custody checklist that explicitly captures the time source, not just the time value.

The pitfall to avoid is treating a small, explainable timestamp gap as beneath mentioning until it's raised on cross. Surfacing it myself, with the hash proof and the technical explanation already prepared, turns a potential credibility attack into a demonstration of exactly how careful the process was.

Direct answer

I'd treat this as three jobs done in a strict order: preserve first, since analysis actions themselves can destroy what's left; build a technical case for the tampering from sources the attacker likely couldn't reach; then attempt attribution carefully, tying activity to an authenticated session rather than overclaiming a specific person, all documented with observed fact, inference, and opinion kept clearly separate.

Structured elaboration

1. Preserve before doing anything else
If the system is still live, capture volatile memory first (RAM can hold remnants of what was wiped or timestomped, or the anti-forensic tool's own process still running), then other live state (network connections, logged-in sessions), then a full disk image with hashes and a write blocker. Immediately pull copies of remote evidence sources (centralized logging, a SIEM, meaning a security information and event management system, cloud logs, backups) before their retention windows roll off, since they're likely untouched by local tampering.

2. Detect and prove timestamp manipulation
Cross-check the NTFS (New Technology File System) $STANDARD_INFORMATION attribute, which holds the timestamps most tools display and most tampering tools alter, against the $FILE_NAME attribute, a second independent copy of timestamps that many timestomping tools never touch. Corroborate both against the USN Journal (a change log the filesystem maintains) and Volume Shadow Copies. A mismatch between the two attributes, or a gap where the journal shows activity the visible timestamps don't account for, is well-established technical proof of manipulation.

3. Detect and prove the slack-space zeroing
Slack space, the leftover bytes between a file's logical end and the end of its allocated disk cluster, normally holds fragments of whatever was previously stored there. Slack that's uniformly zero-filled rather than containing that expected residue is itself an anomaly, especially when it correlates with the specific files under suspicion rather than being spread evenly across the volume the way genuinely unused space would be.

4. Detect and prove deliberate metadata alteration
Look for execution evidence of the tampering tool itself (prefetch, ShimCache and AmCache entries, which are Windows artifacts that record program execution, PowerShell history, EDR meaning endpoint detection and response process-creation records) timed just before or after the target file's altered timestamps, linking a specific tool run to a specific alteration.

5. Attempt attribution carefully
Correlate the tool-execution artifacts with the authenticated session active at the time (Security Event Log logon and logoff events, session IDs) to establish which user account performed the activity. State explicitly that this ties activity to a session and account, not conclusively to a person, unless independent corroboration (no evidence of remote compromise, physical access records, other case context) rules out the "someone else used my account" explanation.

6. Document for litigation
Separate observed fact from inference from opinion, record tool versions and methodology so the work is independently repeatable, preserve original images and hashes so an opposing expert can verify, and be ready for the finding to face an evidentiary-reliability challenge (a Daubert challenge, in US federal practice) by showing the methodology is established and validated, not improvised for this case.

Worked example

Suppose a targeted file, contract_final.docx, shows in $SI: Created 2026-08-20 09:14, Modified 2026-08-20 09:14, nearly identical create and modify times, a classic timestomping tell since genuine edits almost never land on the exact same second as creation. Its $FN attribute, which most timestomping utilities never touch since updating it requires a rename or move, still shows Created 2026-08-14 16:52. The USN Journal has an entry at 2026-08-20 09:14:03 recording a rename-and-timestamp-change operation on that exact file, three seconds after the prefetch-recorded execution of a known secure-wipe utility. That three-way agreement, an altered $SI, an untouched $FN, and a journal entry timed to the same second as the tool's execution, is what turns "the dates look odd" into a documented finding of deliberate manipulation rather than a coincidence or a legitimate clock change.

Trade-offs and pitfalls

Attribution is the part most likely to overreach: an account and session are not automatically a person. State it as "activity performed under user X's authenticated session, no indication of remote compromise," not as naming an individual, unless independent evidence supports it. Skipping volatile capture in favor of jumping straight to disk imaging can permanently lose the one piece of evidence, the tool still resident in memory, or its network connection, that would have made attribution solid instead of circumstantial. Zeroed slack space alone, without correlating which files it's concentrated around, can be confused with ordinary unused disk space; the concentrated pattern is what makes it evidence. Chasing every possible artifact source can blow the case timeline; prioritize sources least likely to have been tampered with, meaning remote and independent logs, over exhaustively re-analyzing the compromised host.

Direct answer

Plaso (invoked as log2timeline.py) is the extraction and normalization engine: it walks a source (an image, a mounted volume, or a directory of extracted artifacts) and runs parsers for hundreds of known artifact types, emitting a single ordered event store. Timesketch is the collaborative front end: it ingests that event store and lets a team search, tag, annotate, and share the resulting timeline. Reach for this pair for broad, repeatable coverage of well-known artifact types; drop to a custom parser when the format is proprietary, malformed, or when a general-purpose tool's overhead is wrong for the job.

Structured elaboration

Typical workflow:

1. Acquire and hash-verify the evidence (image or extracted files).
2. Run log2timeline.py --storage-file case.plaso /mnt/evidence to ingest through Plaso's built-in parsers (EVTX, the file format Windows stores its Event Logs in; MFT, NTFS's Master File Table, the on-disk index of every file on the volume; plus registry hives, browser history, LNK shortcut files, Prefetch execution records, and many more), producing a Plaso storage file.
3. Run psort.py -o dynamic -w timeline.csv case.plaso to filter and export a normalized, UTC-sorted timeline (or use psteal.py, which combines the ingest-and-export steps into one invocation).
4. Import the result into a Timesketch sketch (via its web UI upload or the timesketch-import-client), where an investigator or team can run searches, tag events, add case notes, and layer multiple hosts' timelines into one shared view.
5. Export tagged, annotated events for the report.

When Plaso/Timesketch is the right call: many hosts or artifact types with well-supported parsers, a need for fast broad-spectrum triage, or a collaborative investigation where several analysts need a shared, taggable view of the same data.

When to write a custom parser instead: a proprietary or internal application log format Plaso has no parser for; a malformed or partially-corrupted artifact that trips Plaso's parser and needs bespoke recovery logic; or a narrow, very-high-volume single-artifact pass where a general-purpose tool's per-artifact overhead genuinely matters more than breadth.

Worked example

Suppose an EDR (endpoint detection and response) agent writes its own quarantine log, one line per event, in a format Plaso has no parser for:

[1701792000] QUARANTINE file=C:\Users\alice\Downloads\payload.exe sha256=3b1f...

A minimal custom parser to normalize this into a Plaso-comparable event dict:

import re
from datetime import datetime, timezone

LINE = re.compile(r"^\[(\d+)\] QUARANTINE file=(?P<path>.+?) sha256=(?P<hash>[0-9a-f]+)")

def parse_quarantine_line(line: str) -> dict:
    m = LINE.match(line)
    if not m:
        raise ValueError(f"unrecognized line: {line!r}")
    ts = datetime.fromtimestamp(int(m.group(1)), tz=timezone.utc)
    return {"timestamp": ts, "source_short": "EDR_QUARANTINE",
            "message": f"Quarantined {m.group('path')} (sha256={m.group('hash')})"}

sample = "[1701792000] QUARANTINE file=C:\\Users\\alice\\Downloads\\payload.exe sha256=3b1f8f9a"
event = parse_quarantine_line(sample)
print(event["timestamp"].isoformat(), "-", event["message"])

Output:

2023-12-05T16:00:00+00:00 - Quarantined C:\Users\alice\Downloads\payload.exe (sha256=3b1f8f9a)

This event dict is shaped the same way Plaso's own output is (timestamp, source label, message), so it can be merged into the same CSV or a second Timesketch timeline layer alongside the Plaso-generated events, giving you one unified view even though this one source needed hand-written parsing.

Trade-offs and pitfalls

Plaso's breadth costs processing time and memory on very large images; on a large case this is a batch job, not an interactive step. Never take Plaso's normalized timestamps on faith for a report-critical event, spot-check a sample against the raw artifact with an independent tool, since a parser bug silently mis-timestamps everything with equal apparent confidence. A custom parser needs the same validation discipline before it's court-usable: test it against known-good sample files with hand-verified expected output, not just "it ran without erroring."

A completed three-way handshake is three packets between the same pair of endpoints where the sequence and acknowledgement numbers chain together correctly; I confirm it by checking the flags first, then verifying the numbers actually agree, not just that three packets with plausible-looking flags happened to appear.

Isolating the exchange. Filter to the pair you care about, ip.addr == A && ip.addr == B && tcp, and look for three consecutive packets sharing the same 4-tuple (source IP, source port, destination IP, destination port), the first from the initiator, the next two alternating direction.

The three flags to check

Verifying it with sequence and acknowledgement numbers, not just flags. Flags alone can be spoofed or coincidental; the numbers are what actually prove both sides agreed. The first packet carries the initiator's Initial Sequence Number (ISN), call it x. The SYN-ACK carries the target's own ISN, call it y, and its acknowledgement number must equal x + 1, proving the target actually received and is acknowledging that specific SYN. The final ACK's sequence number must equal x + 1 (matching what the SYN-ACK expected) and its acknowledgement number must equal y + 1, proving the initiator received and is acknowledging the target's SYN-ACK in turn.

Worked example

Packet 1 (SYN):     seq = 1000, ack = 0      (initiator's ISN is 1000)
Packet 2 (SYN-ACK):  seq = 5000, ack = 1001   (target's ISN is 5000; ack = 1000 + 1)
Packet 3 (ACK):      seq = 1001, ack = 5001   (seq = 1000 + 1; ack = 5000 + 1)

Each number is exactly one more than the ISN it's acknowledging, that's the arithmetic that proves the handshake actually completed, as opposed to three packets that merely have the right flags set but don't reference each other's sequence numbers correctly (which would indicate a crafted or spoofed packet, not a real handshake).

Recognizing an aborted or reset attempt. A RST flag on any packet in the exchange means the connection was torn down immediately rather than established, note which side sent it and how quickly, an immediate RST from the target after a SYN usually means the port is closed rather than filtered. Repeated SYNs from the same source to the same destination with no SYN-ACK ever arriving suggests either the host is unreachable, the port is filtered by a firewall that drops rather than rejects, or you're looking at a SYN flood. A SYN followed by an ICMP "destination unreachable" message (rather than any TCP response) points to a network-layer failure, not an application-layer refusal, worth distinguishing in a report since they imply different causes.

Trade-offs and pitfalls. Don't conclude a handshake completed just because you see a SYN and a SYN-ACK; if the capture is missing the final ACK (dropped packet, incomplete capture window, or an intentional SYN scan that never intended to finish), the connection was never actually established even though two of the three packets look normal. And on a capture with retransmissions, you may see more than three packets for what is still logically one handshake attempt, match by sequence number, not by packet count, to avoid miscounting a retransmitted SYN as a second, separate connection.

Intended answer (Digital Forensic Examiner perspective)

Authorized roles by stage

• Intake: evidence custodian or intake officer (forensically trained technician) signs and a supervising examiner or chain-of-custody (CoC) coordinator witnesses.
• Transfer (internal movements): transferring technician signs, receiving custodian signs; supervisor/coordinator witnesses.
• Analysis: examiner assigned to case documents start/finish of analysis; a different peer (or supervisor) witnesses critical transfers of custody (e.g., device to workstation, or removal of the write-blocker, the hardware that sits between the evidence drive and the examiner's machine and permits reads while physically blocking every write).
• Release/Return: evidence custodian signs release, receiving agency/owner signs receipt; CoC coordinator or supervisor witnesses.

Segregation-of-duties principles

• Separate custody, analysis, and authorization: the person performing analysis should not be sole authorizer of evidence release.
• Require dual control for critical steps (signatory + witness).
• Role-based permissions in the LIMS (Laboratory Information Management System, the software that tracks cases, items, and workflow in a forensic lab) to enforce who can sign versus who can only witness.

Why limit signatory permissions

• Legal defensibility: shows independent checks, reduces risk of tampering allegations, and supports admissibility under chain-of-custody scrutiny.
• Internal control: minimizes fraud/error, provides audit trail, and preserves impartiality of examiners.

I would recommend documenting these rules in standard operating procedures (SOPs) and enforcing them via role-based access control (RBAC) inside the LIMS, backed by periodic audits.