Experiment on Monish Kumar's Blog

Barbwire: an eBPF based behavioral correlator

Sun, 08 Mar 2026 16:42:18 +0530

Introduction

After the eBPF learning phase I wrote about in the last post, I wanted to build something that looked like a real security tool. Not because I thought I’d ship it, but because the programs I tried before where stupid. At some point you need a problem with actual constraints.

Barbwire is that project. It’s a lightweight behavioral correlator for Linux. It watches for processes that open sensitive files and then make network connections within a short time window. This is classic exfil behavior and rough fingerprint for credential harvesting and so on. It’s not a production EDR. It’s an experiment. It’s on my Github if anyone’s interested.

The core design decision

The first instinct when building something with eBPF is to put logic in the BPF side. It’s running in the kernel, it’s fast, why not do the correlation there?

I thought about it and decided against it early. The BPF verifier gets unhappy with complex logic. It’s harder to debug, less portable across kernel versions, and for this use case, unnecessary. Userspace is fast enough. The design I landed on: BPF is a dumb data collector, userspace does the thinking.

The BPF side attaches tracepoints to three syscalls. sys_enter_openat for file opens, sys_enter_connect for network connections, and sys_enter_execve for process execution to track lineage. All three write into a single shared ring buffer with an event type field. Userspace reads and routes.

I used a ring buffer over a perf event array deliberately. Perf event arrays are per-CPU, so you have to poll multiple buffers and deal with out-of-order events. A ring buffer is a single shared buffer, better throughput, simpler consumer. So obviously I wanted the path of least resistance.

How correlation and scoring works

On the userspace side, three in-memory maps hold state. Recent file opens per PID, process lineage from exec events, and a deduplication map to avoid alerting on the same PID repeatedly. A cleanup goroutine evicts stale entries every 30 seconds.

The correlation window is configurable. I have it set to 5 seconds. When a connect event comes in, Barbwire looks back at that PID’s recent file opens and checks if any fall within the window. If they do, it scores the pair.

Scoring is based on file and connect pairs, not individual signals. A process connecting to the network is normal. Opening /etc/passwd on its own is normal. Both within 5 seconds is suspicious. The score comes from which file category was accessed:

suspicious_files:
  - category: "credential access"
    base_score: 3
    patterns:
      - "/etc/passwd"
      - "/etc/shadow"
      - "/.aws/credentials"
  - category: "ssh key exfiltration"
    base_score: 3
    patterns:
      - ".ssh/id_rsa"
      - ".ssh/id_ed25519"

Process lineage modifies the score up or down. A shell spawning a process that reads credentials and connects out is more suspicious than the same behavior happening under systemd:

suspicious_parents:
  - comm: "bash"
    modifier: 2
  - comm: "sshd"
    modifier: 3

legit_parents:
  - comm: "systemd"
    modifier: -2
  - comm: "dockerd"
    modifier: -2

Alert threshold and severity thresholds are decoupled. The threshold decides if the alert is an actual alert, severity is a classification of the alert. When a connect event comes in, Barbwire picks the highest scoring file match for that PID and emits one alert. One alert per connect event per process, no duplicates (hopefully).

A fired alert looks like this:

┌─ barbwire alert — PID 41890  ─────────────
│  command  : python
│  file     : /etc/passwd
│  connect  : 2404:6800:4007:821::200e:80
│  severity : HIGH
│  reasons  : credential access, suspicious parent: fish
│  parent   : fish (pid 13387)
│  gparent  : tmux: server (pid 9483)
└─────────────────────────────────────────────

My Screwups while building it

A few things broke in ways that were actually instructive. The first one was actually two bugs hiding behind each other, which made it genuinely annoying to debug.

There was a constant mismatch between the C and Go sides. EVENT_EXEC, the event type for sys_enter_execve tracepoint, was 2 and EVENT_CONNECT, the event type for sys_enter_connect, was 3 in the BPF code, but I had them swapped in Go. At the same time, I had attached the exec tracepoint and called Close() on it immediately without a defer, so it detached right after attaching (Yeah this is embrassing).

The symptom was simple, in terms of events I had none. Thing was execve events were being routed to the connect handler. Since those events carry no IP address family, they got dropped as invalid. Meanwhile connect events were being routed to the exec handler, which was already closed. Everything was failing quietly in a different place than where I was looking.

I spent a while staring at the correlation logic before going back to basics and checking whether the tracepoints were even active. Once I caught the missing defer, connect events started showing up, but in the wrong handler. That’s when I found the swapped constants. Two separate bugs, one symptom, neither pointing at the other. Really annoying

The most useful bug involved stale memory in the event struct. bpf_ringbuf_reserve gives you a pointer to uninitialized memory. If you skip the __builtin_memset before writing your fields, whatever was in memory from the previous event bleeds into the fields you didn’t set. I had filenames with garbage characters appended, leftovers from longer filenames earlier in the buffer. The fix is one line. But you have to know it’s needed.

Limitations and takeaways

The biggest problem with Barbwire is the one that can’t be tuned away.

For example, curl reads /etc/passwd on every invocation. Here is it making the call:

Not because it’s malicious, but because that’s how it works. I believe, basically any program using libc networking does this. Barbwire flags it every time. No matter how hard I tuned the knobs, I couldn’t get rid of such alerts. Then it hit me, single-process correlation without broader context has a ceiling.

Evidently, production security tools handle this differently. Binary hash whitelisting instead of process name matching, which is spoofable. Process ancestry graphs that track behavioral chains across multiple processes. Behavioral baselines built up over time. A shell that reads /etc/passwd and then forks a child that connects out would be caught by a graph-based correlator. Barbwire misses it because the file open and the connect are in different PIDs.

Building this made that limitation concrete in a way I don’t think I’d have gotten from just reading about EDR design. Honestly, I never even thought of these before. You also understand why process ancestry graphs exist when your tool fails exactly where they’d succeed.

The other thing I took away: the BPF to userspace boundary is unforgiving. Memory layout, pointer semantics, which helper functions apply where, what the verifier accepts. The documentation covers the what, but the why only shows up when things break.

All things considered, I had fun with all this. That’s the whole point if you think about it.

Honeyfused: An intrusion detection script using FUSE filesystem

Tue, 26 Aug 2025 18:24:58 +0530

Introduction

First things first, what is Honeyfused? It’s a fun little side project that I spent some time on. It is on my github repo if anyone’s interested.

Honeyfused is in a sense an intrusion detection application using honey-files. The program emulates filesystem mounted on directories and presents files that are actually not part of the original filesystem. Since the program emulates folders that usually contains secrets and API keys, intruders and infostealers may try to access it and possibly exfil the files. Since we control the filesystem, we can generate alerts whenever the file is accessed or modified. That is the gist of it. In this article you’ll find why I did this, how I did this and things like that.

How did I get here?

I very recently learnt that you can implement virtual filesystems, that is, filesystem that are not actually present on the disk, using FUSE bindings. All one had to do is override the operating system filesystem function calls to mimic an actual filesystem and you can literally pull show a filesystem out of nowhere.

Armed with the knowledge, I thought “why can’t I just implement a decoy filesystem with decoy files and generate alerts whenever the files are accessed?”. But this is basically honey-files with extra steps, that is, the virtual filesystem. Then I thought a honey-file is always the same, always there in the same place, and it is usually something like “passwords.txt” or “keys.csv”. So what if I could dynamically generate new file contents in important places, places where applications usually keep their tokens, secrets and keys, places which are more believable and look like legit files to an attacker, places which an infostealer would automatically enumerate. And hence, I got started to find out.

The filesystem implementation

There are a few libraries that provide libfuse bindings in Python. Namely fusepy, python-fuse, mfusepy etc. I choose to work with mfusepy as it is one of the still maintained one. I couldn’t find any documentation about the module. But lucky for me, they maintain a folder of example implementations. One of those aligns closely with what I want, a pure in-memory virtual filesystem implementation. Even though it did not clearly specify what should be actually done, it did give me a gist of how to do it.

However the example script didn’t quite work out-of-the-box for me. So I made some modifications and additions of my own to emulate an actual filesystem. At the end of it, I had a script to create a virtual filesystem that can contain and display files, create new files, delete existing ones, create a directoy and so on.

What to generate?

Now that, I can mount an filesystem whereever I want, I need to generate files. Not just any files, files that appear to be legit, files that should be placed in places where popular applications places them. Then I spent some time researching in popular applications and their configurations. Nah, I’m kidding. I used ChatGPT to tell me how popular applications stored their configs and keys. At the end of it, I had a list of applications that seemed to be good candidates for the decoy files. I settled for Kubernetes’s kubeconfig, AWS’s credential and config file, Azure’s credentials.json, GCP’s default application config file, Terraform’s credential file, Docker’s config file and lastly Bitcoin’s config and wallet files. Mostly developer centric, I know.

With an list of candidate application, I then again asked ChatGPT to give me a blueprint of configuration files and what kind of data should I use to fill it with. With that, I used Python’s string.template to craft template of files and wrote generator functions to dynamically populate the templates. It took me some time to cover this aspect of the ground but it was fine.

Putting things together

At this point, I have a script to mount a fake filesystem anywhere I want and generator functions that can give me realistic looking files that popular applications use. Only thing left is to put these things together. I used a YAML file (config.yml) as the configuration file for user. With that user can specify which applications can the script emulate and present decoys for. Because we don’t want to present decoys for already present applications.

It took going a little back and forth on things, until I finally managed to put it together. So now my script (actually scripts), managed to generate decoy files for applications provided in config.yml and mount it in place I wanted.

The logging

I’ll admit, I haven’t done a lot of logging stuff in Python. Since mfusepy already provided debug logs for the filesystem, I tried to implement logging that gives debug information for my script. So I read the documentation (yes I actually did that), and implemented it. And then I remembered that I had to log alerts as well, because that is the whole point of the application. But I didn’t want to throw all the log at once. So I seperated logs from myfusepy, debug information from my script and the alerts I want to give out. Turns out it’s surprisingly easy than it sounds.

Conclusion

It took me over an week to put all these together. I mean I didn’t spent all my time on this, but okay. So basically I got an Intrusion detection system out that puts fake files on your filesystem and then alerts you when someone accesses it. It is geared more towards developers who keep these kinda files in their storage. But at the end this is just a stupid experiment. So I hope no one uses it as an actual security measure. Still it was pretty fun convincing the system that a filesystem exists when it doesn’t and generate configuration files for various applications.