The Inefficiency in Digital Forensics
Updated: 27.06.2025
When I started my career in digital forensics and incident response, I quickly noticed a pattern. Analysts — including myself — spent countless hours online, scrolling through PDFs, blogs, tweets, and posts, collecting valuable insights about where to hunt for forensic evidence. Everyone maintained notebooks filled with tips on registry keys, log file locations, suspicious file patterns, and remote session artifacts. It was fascinating but incredibly repetitive.
Don’t get me wrong; I deeply appreciate forensic analysts sharing their findings publicly. This exchange of information is vital for the community. But there’s an inherent inefficiency. Each analyst individually translating these insights into their own manual checks or scripts felt unnecessary and wasteful.
I’ve deliberately chosen not to include screenshots or specific examples from social media or blogs here. While I initially considered showing anonymized posts, I decided against it to avoid unintentionally shaming individuals. Those who actively follow digital forensic analysts and detection engineers on platforms like LinkedIn or X will know what I mean: posts that share interesting forensic ideas or queries, which often end up as entries in someone’s notebook or trigger manual work. These posts are informative, but rarely directly actionable — they’re starting points, not detection rules.
I remember a conversation years ago with someone from an IR firm in Switzerland. They openly admitted preferring manual, slower methods — three days investigating manually instead of one day with automation — because their billing structure incentivized extended analysis time. They feared automation might “miss something,” but also recognized they’d bill far less if they adopted automated tools.
This perspective echoes the frustration I described in my earlier blog post, The Bicycle of the Forensic Analyst, where I compared manual forensic work without automation to riding a bike without pedals — a tedious and exhausting endeavor.
Bridging Human and Machine: Strengths and Weaknesses
The mindset of deliberately avoiding automation never sat well with me. In incident response, where every minute counts, the only thing that matters is: what gets us the best result with the least friction? And the answer is rarely binary. Both humans and machines bring something useful to the table — but they also come with blind spots.
Human analysts are excellent at interpreting ambiguous clues and applying context. They spot strange filenames, sketchy paths, or odd timestamps and intuitively flag them as suspicious — even without a matching rule. But they’re slow. And sometimes distracted. And, frankly, limited in how much raw volume they can process before errors creep in.
Machines, on the other hand, are fast, consistent, and relentless. They apply detection rules to thousands of hosts or millions of files without breaking a sweat. But they lack context. They won’t raise an eyebrow at a weird PowerShell command unless it matches a known pattern.
This creates a natural division of labor — and you can chart it like this:
- On the left, we see the human territory: low volume, high ambiguity — exactly where human judgment shines.
- On the right, we have the machine territory: high volume, low ambiguity — where automation is most effective.
- In between is a gap: situations where evidence is subtle, slightly ambiguous, but still needs to be reviewed at scale.
Below is a compact summary of the typical human errors and machine limitations I’ve observed (and written about before):
What’s missing from that article, though, is the inverse: the strengths. That’s what this chapter is about. Machines are fast, precise, and tireless — but lack understanding. Humans are insightful, contextual, and flexible — but slow and inconsistent at scale. Marrying both is the only realistic path forward.
Limitations of Manual Automation: The Case of Hunts
A common approach in the community is using hunting platforms that refer to scheduled or on-demand actions as “hunts.” In tools like Velociraptor, a hunt can mean many things — from retrieving all ShimCache entries on an endpoint to collecting registry keys or running a targeted triage check. While this is technically automation, it often only automates the collection step. The result is usually a large volume of raw forensic data that still needs to be reviewed manually.
Now, these hunts can be extremely useful when you’re looking for something specific: a known persistence method, a particular tool, or a file with a known name or location. In those cases, hunts act more like targeted triage. But once the goal becomes more exploratory — when you don’t know what you’re looking for — it gets inefficient fast. You’d need to run dozens or hundreds of these hunts, then sift through all their outputs. And since most of these outputs are verbose by design, you end up with millions of lines of raw data to review. That just doesn’t scale. So unless you’re dealing with very targeted cases, relying on a large hunt library isn’t efficient.
In contrast, effective automation should continuously run a comprehensive rule set, immediately alerting only on significant matches. Analysts then focus solely on relevant results, significantly reducing analysis time. People may argue they prefer manual oversight because they trust their own judgment more than a machine. This concern is valid. That’s precisely why our tools also include detailed, verbose logging to allow manual cross-checks for those who need that additional assurance.
Embracing Automation and Detection Engineering
This realization drove me towards detection engineering. I started taking forensic insights, previously stored in hundreds of notebooks, and translating them into detection rules and scanners. These tools automate checks across forensic evidence, immediately surfacing relevant findings. Analysts can then directly pivot from meaningful, actionable results rather than starting every case from scratch.
It’s admittedly frustrating to see analysts continue sharing primarily manual screenshots or textual descriptions of suspicious findings online. We already have tools — both free and commercial — that bridge the gap between forensic insights and operational detection. All it takes is manual effort from skilled detection engineers to encode this knowledge into reusable, actionable rules.
Interestingly, this process isn’t easily replaced by AI. While I’m genuinely impressed with recent advancements and actively exploring their integration, detection engineering — beyond basic IOC matching — remains safely within the human domain for now.
My call to action for the digital forensic community is straightforward: Let’s embrace efficiency. Continue sharing valuable insights, but also commit to translating them into tools and standards we can collectively reuse. It benefits everyone, especially the customer who urgently needs clear, actionable findings during an incident.
Let’s spend our time wisely.
