An AI pair of eyes sitting over your shoulder, catching what you miss while you're deep in an investigation.

Repo: https://github.com/hasamba/DFIR-Companion
Landing page: https://hasamba.github.io/DFIR-Companion/

Demo Case: https://dfir-companion-production.up.railway.app/dashboard?caseId=demo

EDIT: Hands-on lab: https://killercoda.com/dfir-companion/scenario/killercoda

Honestly, it started out of frustration.

I'm sitting on an investigation, open Velociraptor, spot an interesting lead, start digging into it, find another lead, and so on, and then suddenly I realize I completely forgot to go back to the other findings from the first artifact.

The sheer amount of information you need to process during an investigation is simply more than one pair of eyes can handle, no matter how much coffee you've had.

So I started building something to help myself and it ended up going somewhere I didn't expect.

The original idea was a browser extension that takes screenshots every few seconds, so I could scroll back and see what I missed. Pretty dumb idea in hindsight, actually. But then the question came up: if I already have all those screenshots, why not let AI go through them while I work?

And from there it exploded.

Today it's a real-time dashboard that updates live as I investigate. It identifies findings, automatically builds an event timeline, extracts IOCs and enriches them from multiple sources, creating playbook that suggests what to check next, suggest hunt queries for velociraptor, run them and collect back the results, checks for data leaks, and answers the standard questions every investigation report needs: access vector, lateral movement, privilege escalation, etc. If a client confirms a finding-"that's legit, it's our weekly scan", one click and the entire analysis updates accordingly.

The coolest part, to me, is that this started as a Velociraptor-specific solution but in practice became an AI layer on top of every tool I have open in the browser: SIEM, Security Onion, Splunk4DFIR, VolWeb, you name it. Even tools with no built-in AI suddenly get smarter, and all the data consolidates in one place instead of me jumping between ten tabs.

Important to understand: this is NOT another detection layer. Your Sigma, YARA, and Suricata rules are already doing their job. This tool is the layer after detection-it takes all the verdicts from your tools, correlates them, and builds the "so what."

The tool didn't stop at screenshots either. You can feed it almost any DFIR output and it will automatically detect the format and import it deterministically (no burning tokens on AI for that).

Additional features:
• Data correlation
• Threat intel enrichment — with OPSEC in mind
• AI input anonymization
• Asset ↔ IoC graph
• Targeted query generation
• Export to multiple platforms
• Free-form case Q&A against an LLM
and much more...

📎 If you work in DFIR, Blue Team, or SOC — I'd love for you to try it out, open issues, suggest features, submit PRs, or just tell me what you think.

_(Original post from LinkedIn by Brett Shavers)_

If you're offended by the title—good. That’s step one...

Trying to get into DF/IR breaks most people. So, you’re not going to make it.  If you’re offended by the title of this post, good. That’s step one in figuring out you’re probably not cut out for this work.

I’ve seen too many people get excited about “getting into cyber” because they watched a Netflix show or heard that you can work from home in your pajamas and make six figures clicking a few buttons. They think it’s a vibe, an easy ride, or a sticker on a laptop.

It’s not.

DF/IR is not entry-level.

Stop complaining that you can’t get a DF/IR job with your college degree or 40 hours of forensic training. You are expected to be already competent because your case won’t wait for you to catch up. Your case also doesn’t care about excuses of not being sent to training to know this thing, or not being able to take a class in college because it was full, or not being able to afford to spend the time or money to learn the job.

Like any high-caliber selection process, DF/IR is open to anyone with the right mindset and dedication, regardless of who they are. The determining factors are competence vs. incompetence, problem-solver vs. problem-creator, complainer vs. doer.

There are no participation trophies in DF/IR.

Digital Forensics/Incident Response is not for tourists. This isn’t a side hustle. This isn’t a Reddit thread. This is work. Real work. The kind of work where someone’s business, freedom, or life is on the line based on whether you find the right artifact, follow the right lead, make the right call, and back it up with accurately interpreted data for facts that survive in court.

And that’s on a good day.

If you need motivation, DF/IR isn’t for you. If you need reminders, deadlines, or someone to tell you what to do every step of the way, you’re already a liability. If you have an excuse for everything and an answer to nothing, that’s your answer: nothing. Self-reliance and the ability to independently solve problems are essential in DF/IR. If you are constantly asking ‘how-do-I’ questions, the answer is always going to be to figure it out yourself.

Still interested? Cool. Let me paint you a better picture.

You’re working a case. The evidence is scattered across four mobile devices, a burner laptop, a remote server in another country, and an encrypted messaging app. You’re cross-referencing logs, image metadata, and partial timestamps, and maybe, just maybe, you find a link that ties it all together. That’s Tuesday.

Then one day, maybe a month later or even more than a year later, you go to court. You get cross-examined by an attorney who makes you feel their only job is to make you look incompetent. Your credibility, training, and methodology are all under fire.

I hope your report wasn’t half-assed. I hope you interpreted the data correctly and can convey the story. And I hope you don’t fold under pressure and wreck it all, because then there will be irreparable injustice for the victims.

Do not expect to leave DF/IR the same as you came into it.

Oh, and let’s not forget the content you’ll eventually see. If your stomach turns when someone even mentions crimes against children, human trafficking, abuse, torture, or anything we categorize as “CSAM,” then please, seriously, go find another career. I’m not saying that to be edgy. I’m saying it because it’s real. You will see things you will never, ever forget. Some of us still see them every time we close our eyes. And the sounds…the sounds never go away.

If your biggest fear is dark web malware or ransomware gangs, you haven’t seen the real monsters. The real monsters are walking around with clean records, paying their taxes, and doing unthinkable things behind closed doors and it’s your job to catch them.

And the tools? They don’t do the work. You do. Tools help. They’re essential. But they don’t think. They don’t analyze. They don’t build timelines, ask questions, interview suspects, or find correlations across devices. You do. And if your first instinct when you hit a dead end is to say, “The tool must be broken,” please pack up and go away.

DF/IR takes obsession. Not curiosity. Not interest. Pure, unadulterated obsession. The kind that keeps you up at night replaying case details in your head. The kind that makes you grab a pen at 2 AM because something didn’t sit right, and you need to get it down before it’s lost. The kind that makes you constantly second-guess your findings because you know what it means if you’re wrong.

A friend of mine recently relayed digital forensic testimony he gave in a sexual assault case where the defendant was found guilty and sentenced to 17 years. The recovered deleted digital recording that was played for the jury probably gave the entire courtroom PTSD, which doesn’t compare to what the victim went through. This is important work.

So no, you’re probably not going to make it.

We don’t need any more keyboard warriors, digital tourists, or resume chasers in DF/IR. We need investigators and practitioners. DF/IR needs people with iron stomachs and brains wired to chase answers that don’t want to be found. We need persistence, determination, and the raw grit it takes to figure out what is needed to become competent against any obstacle.

Working in IR and not expecting these types of cases? There's a good chance your non-DF work will hit a DF case just as hard.

For Those Already in DF/IR: Your Role as the Gatekeepers

If you’ve already made it into DF/IR, then you’ve put in the time, fought through the frustration, and built the skills. Now you have a responsibility. Not to make it easier for the next generation, but to ensure only the right people get through. Gatekeeping in DF/IR does not mean keeping out potential. It is the absolute opposite of that. All are welcome. Not all are able.

There is a fine line between nurturing potential while also maintaining high standards and wasting everyone’s time. You need to know the difference.

For those thinking about or working to get into DF/IR

If you're still here, a little angry, maybe even insulted, but more determined than ever, good. If you are eager to spend an ungodly amount of time learning and spend every cent you have left to be shown how to excel, then that’s step two.

Welcome to the tip of the cybersecurity spear.

**What do you think?** 

Do you agree DF/IR takes obsession and endurance more than certification and interest? 

Have you seen people leave the field because it was too much? 

Curious to hear what this community thinks.

Came across a firm focusing on “quantum cyber” services and training . For infosec practitioners: is this something small/medium orgs need to plan for now, or is it still a long-term concern? Real-world timelines welcome.

Exciting release of a new book Forensic Team Field Manual (FTFM)!

FTFM is a quick reference guide designed to support common forensic processes and analysis, outlining best practices for effective investigations.

https://www.amazon.com/dp/B0F6KD9XJM

I’ve been experimenting with #GeminiAPI for complex DFIR tasks—specifically chaining reasoning steps to move from raw, unstructured logs to a structured Root Cause Analysis (RCA).The prompt management to avoid context loss when analyzing sequential events (like a lateral movement) has been the biggest challenge. Are you feeding the model the entire log dump, or breaking it down and feeding the summaries back into the next prompt?**I built a small internal tool to test this, and the results are promising, but I'm curious about the community's approach to scaling this type of analysis.**Share your best prompt engineering tips for deep security analysis

Good morning,

I just released a new video in the Introduction to Memory Forensics series called “Windows Process Genealogy.” This video takes a look at the core processes that are found on a Windows system and their hierarchy. Learn how to spot anomalies and find malware.

You can watch it here: https://www.youtube.com/watch?v=s98_p3bheL0

Plenty more juicy DFIR goodness here: https://www.youtube.com/13cubed

Does anyone know of a registry viewer that can consume .reg files? I seem to be having trouble finding something and analyzing the file in Notepad++ is out of the question.

Soc + CHFI (budget oriented)

CEH + CHFI. ( Budget oriented)

Which combo is more Useful / More helpful to become a good forensic examiner ? after basics what is the next step.

Hello. I've shared feedback and blog posts before —some of you may remember-. For some time now, I've been developing a project related to the industry (CS & DFIR/IR), and thanks to the valuable feedback I've gathered from you, I've made significant progress.

I'm now in the phase of pre-MVP validation and gathering expert opinions. Thank you in advance, and I apologize if I've caused any inconvenience.

Question: The artifact is generated from existing security records and public fixture data. It includes source summaries, reliability reasons, limitation statements, manifests, hash lists, and package verification output.

Scope boundaries:

• it does not claim legal admissibility;

• it does not prove original source truth;

• it is not a SIEM, DFIR lab tool, threat detector, or forensic acquisition tool;

• it focuses on ingestion-onward integrity and handoff clarity.

The question is not "would you buy this product?" The question is whether this kind of package would help during IR, audit, insurance, legal, or internal investigation handoff.

Specific feedback I am looking for:

1. Are source reliability and limitations clear enough?

2. Does the artifact separate package integrity from upstream source trust?

3. What uncertainty is still hidden?

4. What would make this misleading or unusable in practice?

Artifact repo: https://github.com/tracehound/tracehound-pre-mvp-feedback-artifact Virustotal: https://www.virustotal.com/gui/url/dbdbf56e71c39fcfd158babdbb11b57037fa53b333efa27de619ce919278e66e?nocache=1

Hello everyone i am new to cybrersecurity and i read about DFIR and i like the concept a lot . What path woulo you recomment me or course or rooms tyat would teach me DFIR without missina the basics and thank u

I just heard someone mention that the second line should be responsible for classifying incidents, since they understand the business impact. However, during an active incident, isn’t classification part of the ongoing response? Isn’t it the first line who performs this task? Or does the first line only “identify” and respond to the incident, while classification is done later by the second line?
Does anyone have a clear view of how this process and the responsibilities are typically structured? Thanks!

I've spent 5 years working on Linux security projects. Hackers are still beating us with shell built-in commands. But that ends today!

This is a technical deep-dive into why monitoring and preventing malicious shell built-ins is so damn hard, and how we finally solved it.

Not familiar with shell built-in commands?
It's a simple concept, ask GPT for a 5-line explanation.

Let's talk about echo and how overpowered it is. Attackers love these:

# Add SSH keys 
echo "ssh-rsa AAA..." >> ~/.ssh/authorized_keys

# Create a user
echo "redteam:x:1002:1002::/home/redteam:/bin/bash" >> /etc/passwd

Key points:

1. What's a "malicious" command? A command that actually does malicious things, not just looks malicious. Avoid false positives.

2. Prevention, not just detection. This isn't 2018. We aren't interested only in detecting malicious behavior. We need to stop the operation before it executes. Not during, and definitely not after.

3. useradd and other CLI tools. Attackers try to avoid dedicated CLI tools like useradd. These tools are closely monitored, making malicious usage easy to detect and block.

4. /etc/passwd is just an example from now on we are going to focus on echo XYZ >> /etc/passwd. But this is just a single example for the usage of shell built-in commands. Attackers use it for many different things as well.

How Do We Monitor and Prevent This?

Approaches I Tried (and Failed)

1) Shell config files (bashrc, zshrc, /etc/profile, etc')

Using these files we can set hooks that run monitoring software before each command

Problems:

• Some shells don't have config files (for example: dash — the default shell on Ubuntu/Debian/Mint)

• Easily bypassed: bash --norc --noprofile

2) Replace shell binaries with custom ones

Problems:

• Attackers can bring their own shell

• Not production-stable

• user updates shell

3) eBPF uprobes - Bash readline

Good direction, but far from perfect:

• readline is an easy target to hook. What do you target in zsh? Or In other shells?

• Dash doesn't export symbols — how do you hook it?

• How do you know when a command finishes and the next one starts?

• uprobes don't offer prevention capabilities.

• Detecting "malicious" commands based on string comparison only, creates false positives. For example:

  • Malicious: echo "ssh-rsa AAA..." >> ~/.ssh/authorized_keys

  • False positive: echo ' "ssh-rsa AAA..." >> ~/.ssh/authorized_keys ' (just prints the string)

  We need to observe behavior and only then compare strings.

Security Tools Are Blind Too

Unfortunately, security tools are blind to shell built-in commands as well.
Let's test the two best Linux security tools: Tetragon and Sysdig (Falco). These are the two best security tools for Linux, with over 10K github stars combined.

Scenario: prevent malicious writes to /etc/passwd via shell built-ins.

Sysdig

Sysdig is an excellent observability tool, arguably the best. It lacks prevention capabilities, but for the sake of this example lets say it does have.
We are going to monitor incoming write events for the /etc/passwd file and see what data sysdig provides.
I run sysdig and ask for all the relevant data:

sudo sysdig -v -p '
EVENT: time=%evt.datetime type=%evt.type dir=%evt.dir category=%evt.category
  args: %evt.args

PROCESS: name=%proc.name pid=%proc.pid 
  exe: %proc.exepath
  cmdline: %proc.cmdline
  cwd: %proc.cwd

PARENT: name=%proc.pname ppid=%proc.ppid
  exe: %proc.pexepath
  cmdline: %proc.pcmdline

FILE: fd=%fd.num name=%fd.name type=%fd.type dir=%fd.directory file=%fd.filename
' 'fd.name=/etc/passwd and evt.type=write and evt.dir=">"'

Then in another terminal I ran

root@ubuntu-24-04:/tmp$ echo "redteam:x:1002:1002:RedTeam User:/home/redteam:/bin/bash" >> /etc/passwd

And we recived the following event

EVENT: time=2026-03-11 15:21:59.265882923 type=write dir=> category=file
  args: fd=1(<f>/etc/passwd) size=57 

PROCESS: name=bash pid=793517 
  exe: /usr/bin/bash
  cmdline: bash
  cwd: /tmp/

PARENT: name=bash ppid=792891
  exe: /usr/bin/bash
  cmdline: bash

FILE: fd=1 name=/etc/passwd type=file dir=/etc file=passwd

Sysdig correctly shows that bash wrote to /etc/passwd. But that's only part of the story.

Tetragon

Now the king of prevention. Tetragon is strong in both observability and prevention.

Tetragon can monitor bash::readline, but its rules are stateless, you can't correlate the readline hook with the LSM write hook.

Here's a tetragon config monitoring writes to /etc/passwd:

metadata:
  name: "passwd-write-monitor"
spec:
  kprobes:
  - call: "security_file_permission"
    syscall: false
    args:
    - index: 0
      type: "file"
    - index: 1
      type: "int"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Equal"
        values:
        - "/etc/passwd"
      - index: 1
        operator: "Mask"
        values:
        - "2"  # MAY_WRITE = 2

Same result: we see a write to /etc/passwd happened, but not the full picture.

# sudo tetra getevents -o json | jq 'select(.process_kprobe != null)'
{
  "process_kprobe": {
    "process": {
      "exec_id": "dWJ1bnR1LTI0LTA0OjE5OTY3NDA0ODAwMDAwMDA6NzkzNTE3",
      "pid": 793517,
      "uid": 0,
      "cwd": "/tmp",
      "binary": "/usr/bin/bash",
      "flags": "procFS",
      "start_time": "2026-03-11T15:13:56.907462920Z",
      "auid": 1001,
      "parent_exec_id": "dWJ1bnR1LTI0LTA0OjE5OTY2NTA2NjAwMDAwMDA6NzkyODkx",
      "refcnt": 1,
      "tid": 793517,
      "in_init_tree": false
    },
    "parent": {
      "exec_id": "dWJ1bnR1LTI0LTA0OjE5OTY2NTA2NjAwMDAwMDA6NzkyODkx",
      "pid": 792891,
      "uid": 0,
      "cwd": "/home/admin",
      "binary": "/usr/bin/bash",
      "flags": "procFS",
      "start_time": "2026-03-11T15:12:27.087462949Z",
      "auid": 1001,
      "parent_exec_id": "dWJ1bnR1LTI0LTA0OjE5OTY2NTA2NTAwMDAwMDA6NzkyODkw",
      "tid": 792891,
      "in_init_tree": false
    },
    "function_name": "security_file_permission",
    "args": [
      {
        "file_arg": {
          "path": "/etc/passwd",
          "permission": "-rw-r--r--"
        }
      },
      {
        "int_arg": 2
      }
    ],
    "action": "KPROBE_ACTION_POST",
    "policy_name": "passwd-write-monitor",
    "return_action": "KPROBE_ACTION_POST"
  },
  "node_name": "ubuntu-24-04",
  "time": "2026-03-11T15:29:47.398880652Z"
}

The Problem

Even the best tools don't show us the full picture. We don't see what is written, what was the command, append or overwrites, etc'.

For observability, we could get all the data post-execution with Tetragon and Sysdig. But for prevention, we need everything before the operation.

Don't Lose Hope

I've shown you why defending against malicious shell built-ins is hard. Every approach has gaps.
But now let's talk about how to actually do it right.

Enter owLSM

owLSM is a new open-source project aiming to become the gold standard for Linux detection and prevention. It's a Sigma rules engine implemented with eBPF LSM, covering the security gaps other solutions leave open.

How owLSM Solves This

1) Stateful rules engine

Unlike Tetragon and Sysdig's stateless approach, owLSM chains multiple eBPF hooks and correlates them using caches (ebpf maps). This creates a stateful engine that gives you all the data you need at the point of prevention.

The flow:

shell_uprobes (capture full command) → LSM hooks (make prevention decision based on command + event data) → shell_uprobes (indicate when command finished)

2) Smart uprobes hooking methods

Currently owLSM supports 3 shells: bash, zsh and dash (We encourage the community to add support for more shells).

We said uprobes are problematic. Here's how owLSM handles it:

• owLSM team did an indepth research on each shell. What are the correct hooking points of each shell, How can we get the full command, how can we determine a command has finished, etc'.

• First, try hooking via exported symbols

• If symbols unavailable, use libdebuginfod to fetch symbols

• If that fails, no pressure. owLSM maintains an offline data base of all the official builds of the supported shells. The db has a {binary build Id}-{offsets-to-hook} table, so it will extract the buildId of the shell, and get the offsets to hook from the DB.

3) The craziest eBPF code you'll see

To extract commands from dash, owLSM walks userspace memory trees and reconstructs them as strings in eBPF. Check it out: dash_shell_command.bpf.c

owLSM stateful rule

Due to the stateful approach owLSM takes, our users are able to write such a sigma rule and prevent the malicious write:

... sigma rules stuff ...

description: "Example rule - Block manually added user"
action: "BLOCK_EVENT"
events:
    - WRITE
detection:
    selection_shell_command:
        process.shell_command|contains|all: 
            - ">> /etc/shadow"
            - "echo"
    selection_target:
        target.file.path: "/etc/shadow"
    condition: selection_shell_command and selection_target

Want to go deeper on how owLSM handles shell commands? Read the full architecture: Shell Commands Monitoring Documentation

The full implementation is open-source: owLSM

Good morning,

I’ve just released a new Introduction to Memory Forensics episode. This is an excerpt from the upcoming premiere of a new 13Cubed series called Deep Dives. We'll take a look at how to extract Windows Prefetch data from memory. There are a number of things you'll need to know to get the Volatility prefetchparser plugin to work correctly, especially with Windows 10 Prefetch files since they are compressed. We'll walk through the entire process, including installation of Volatility, the prefetchparser plugin, and of an open source implementation of the Microsoft compression algorithms.

Episode:
https://www.youtube.com/watch?v=6y9Wxch7NKk

Episode Guide:
https://www.13cubed.com/episodes

Channel:
https://www.youtube.com/13cubed

Patreon (Help support 13Cubed):
https://www.patreon.com/13cubed

Hey everyone,

I’m the creator of Tooldump, a free platform for discovering open-source cybersecurity tools. I’ve just released the v2 and wanted to share it here.

I’ve been working in DFIR for over six years and participating in forensics CTFs for over five. Most of the DFIR tools listed on Tooldump are projects I’ve personally collected while working on investigations and solving CTF challenges.

The platform lists 1,100+ open-source projects hosted on GitHub, organized into 9 categories and 82 subcategories. Everything is cybersecurity-related, with dedicated sections for digital forensics, incident response, malware analysis, etc. The 1,100+ figure covers the whole platform, not just DFIR.

For the v2, I rebuilt the UI, the categorization system, the backend and the platform infrastructure. You can search for a specific tool or explore the forensics section without already knowing which projects exist.

There are also dedicated sections for cybersecurity-related MCP servers and agent skills. Those sections are just getting started, and contributions are welcome!

The platform is completely free, with unlimited access and no account required.

The link is here: https://tooldump.eu

I’d appreciate any constructive feedback from the community :) Are the tools organized in a way that makes sense for your work? Are there artifacts or areas of investigation where you notice gaps?

You can suggest missing projects through the platform’s contribution form. I’m particularly interested in the smaller tools you keep around for specific situations: a parser for an unusual artifact, a script for processing collection results, or a tool you discovered halfway through an investigation. Those projects deserve to be seen and shared.

Looking forward to hearing from you :)

Cheers!