Dead disks tell stories. This site turns those stories into reproducible methods, lean tools, and guidance you can actually run—at 3 a.m., when only truth and recovery matter. I publish as deaddisk to keep the focus on methodology, not identity. Day-to-day I work across DFIR, security engineering, tool-building, and pentesting—practical, defensible work you can copy, adapt, and trust.

Who this is for: defenders, incident responders, security engineers, and hands-on pentesters who prefer evidence over vibes.

The problem we’re here to fix#

Too much security content is:

  • High-level and unhelpful under pressure,
  • Tool-first without an evidence model, or
  • Vendor-shaped instead of reality-shaped.

Responders and engineers need repeatable workflows and small, sharp tools that turn telemetry into decisions—with proofs you can show to leadership or a courtroom.

deaddisk exists to close that gap.

What we’re bringing to the table#

1) Engineering-grade DFIR workflows#

Step-by-step playbooks you can hand to an operator or defend later:

  • Required artifacts (specific WEVTX channels, registry hives, file metadata),
  • Acquisition pitfalls,
  • Verification steps and negative controls,
  • Chain-of-custody and reporting checklists.

Examples: blast-radius mapping, decryptor safety testing, Windows timelines from WEVTX + registry + filesystem metadata, “last known good” service/driver reconstruction.

2) Open, auditable tooling#

Utilities in Rust and PowerShell that:

  • Parse Windows Event Logs/Sysmon and normalize artifacts,
  • Generate timelines and cross-link evidence deterministically,
  • Wrap proven tools with safer defaults and traceable output.

Design ethos: fast, predictable, minimal dependencies, and easy to review.

3) Security engineering patterns#

Reference architectures and patterns for:

  • Building repeatable log pipelines and storage/retention that actually serve DFIR,
  • Making checks “fail safe” (idempotent scripts, checksums, clear exit codes),
  • Turning procedures into CI-style tests where possible.

4) Pentest-informed reality checks#

Pentest techniques used to pressure-test assumptions and validate detections and controls—bridging the gap between how systems break and how we detect/fix them.

5) Reproducibility over rhetoric#

Posts ship with precise inputs, copy-runnable commands, expected outputs (with hashes where it matters), and explicit limits. If a method breaks on a Windows build or retention scenario, we call it out.

Our goals#

  1. Shorten time-to-truth in ransomware and intrusion response.
  2. Raise the floor with free, defensible SOPs any competent team can adopt.
  3. Shrink toolchains to reduce fragility under pressure.
  4. Engineer for reliability: tests, fixtures, and deterministic outputs.
  5. Teach by showing: evidence, not vibes.

How we’re different#

  • Artifact-centered writing. Claims are tied to concrete evidence and verification steps.
  • Vendor-agnostic paths. If a platform is mentioned, an OSS route is shown.
  • Ops-tested. Everything must pass the Tuesday-at-3-a.m. test.
  • Transparent limits. Edge cases, false-positive risks, and costs are documented.
  • Privacy first. Real cases are generalized and sanitized.

What to expect here#

  • DFIR deep dives: Windows internals, Windows Event Logs, registry, services/drivers, VSS, AD artifacts.
  • Tool posts (Rust & PowerShell): annotated source, usage guides, and benchmarks.
  • Security engineering notes: pipeline patterns, storage/retention tuning, automation guardrails.
  • Pentest write-ups (defender-oriented): technique breakdowns with practical mitigations.
  • Reference cards: “just the facts” for common tasks (e.g., Prove process execution without 4688, Infer ransomware start time from $STANDARD_INFORMATION drift).

Roadmap (near-term)#

  • Windows Timeline, Fast: From raw WEVTX + registry to a defensible sequence in minutes.
  • Decryptor Safety Harness: Snapshots, canaries, and side-effects testing before touching production data.
  • Rust for DFIR: Robust parsers/CLIs with testable modules and reproducible binaries.
  • PowerShell with Guardrails: Wrapping popular forensics tools with safer defaults and logging.
  • Pentest-to-DFIR Bridges: Taking a common attack path and mapping the exact artifacts and fixes.

Principles#

  • Reproducibility > rhetoric
  • Defensibility > novelty
  • Simplicity > cleverness
  • Transparency > perfection

When we’re wrong, we’ll publish a correction and why.

On anonymity#

This site avoids personal identifiers by design. The aim is to help defenders—not to build a personality brand. If something here risks exposure, say so and it’ll be fixed quickly.

Call to action#

  • Run the playbooks in a lab and measure your time-to-truth.
  • Use the fixtures to test your pipeline before incidents.
  • File issues or PRs when steps are ambiguous or brittle.
  • Share your constraints—we’ll bake them into revisions.

Welcome to deaddisk. Less drama, more signal.