The Audit Log That Exists as a Byproduct
HuskHoard uses Linux's fanotify API to intercept filesystem events — this is the mechanism that makes transparent tape access possible. But there's a significant secondary consequence of sitting in that event path: HuskHoard sees everything that happens to your files.
Every open. Every write. Every close. The process name and PID that initiated the event. The timestamp down to the microsecond. The file path. The size of the write. Whether the file existed before. Whether the extension changed.
Most backup systems record nothing like this. They take a snapshot at a scheduled time and compare it to the previous snapshot. They can tell you a file changed. They cannot tell you when it changed, what process changed it, whether that change was part of a pattern, or how many other files changed in the same window. HuskHoard's event log provides all of that — not as an additional feature that had to be bolted on, but as a natural consequence of how the core architecture works.
The log above shows exactly what a ransomware event looks like in the HuskHoard stream. Normal activity at 2:47am — a video editor writing a file. A user browsing a directory at 2:51. Then at 3:14am, the same process that was quietly reading contracts suddenly starts rewriting them with a .locked extension at 847 files per minute, and HuskHoard flags it automatically.
What Anomalous Activity Looks Like in the Event Stream
Ransomware, data exfiltration, and insider threats all produce distinctive patterns in a filesystem event stream. They look different from normal activity in ways that are detectable — if you're recording the activity at all. HuskHoard records it continuously, which means those patterns are always in the log, whether or not you're watching in real time.
Volume Spikes: The Earliest Warning Sign
Of all the signals above, write rate spikes are the most reliably detectable and the earliest to appear. Encryption has to touch every file it wants to lock, which means it generates a sustained burst of filesystem writes that stands out sharply against normal archive activity.
The chart above illustrates something important: the spike is not the first signal. Notice the elevated activity in the three hours before the spike — a period that looks like it could be reconnaissance, file enumeration, or the early stages of exfiltration. That window is also recorded in the event log, with process names and PIDs. When you do the post-incident forensic analysis, you may find the attack was telegraphed hours before the encryption started.
File Entropy and Format Anomalies
This is the more advanced signal, and one that HuskHoard is positioned to detect in a way that generic monitoring tools are not. Because HuskHoard knows your archive — its composition, the file types it contains, the extensions that belong there — it can detect when the character of the archive changes.
Encrypted files have a distinctive property: they are high entropy. A normal document or video file has structure — headers, repeated patterns, predictable byte sequences. An encrypted file looks like random noise. The bytes have no recognizable pattern because that's what strong encryption produces.
HuskHoard can sample the entropy of files being written to the archive and flag writes where the output is statistically inconsistent with the file's declared type. A file with a .docx extension should have the structure of a ZIP archive (which is what DOCX files are). A .docx file that is actually high-entropy random bytes is not a Word document — it is almost certainly an encrypted payload wearing a familiar name.
The sophistication of this detection matters. Some ransomware variants are smarter than the naive extension-changing approach — they overwrite files in place without changing the name, making them harder to detect from a directory listing alone. Entropy sampling catches this category of attack because it looks at the actual bytes, not just the filename.
Entropy sampling adds a small overhead to write operations — reading and hashing 4KB per write is fast, but it's not zero. For archive workloads where writes are infrequent and deliberate, this overhead is negligible. For high-throughput write paths like video ingest, sampling can be disabled per-directory or triggered only for specific file types. The default configuration samples all writes to directories marked as archive-tier.
After the Incident: Forensic Reconstruction
Even if you don't catch the attack in real time, the event log changes the quality of your post-incident analysis fundamentally. Most organisations that suffer a ransomware incident spend enormous time and money trying to answer basic questions: when did this start? What processes were involved? What data was accessed before encryption? Did the attacker exfiltrate anything before detonating?
With HuskHoard's event log, those questions have answers — timestamped, process-attributed answers that cover every file in your archive going back as far as the log retention you've configured.
This timeline tells you something a backup system never could: the attacker was in your system for hours before encrypting anything, and they read your contracts and legal files specifically. That's not just a recovery problem — it's a disclosure problem. Knowing the exfiltration scope before you notify your legal team or regulators is information that only the event log can provide.
Turning Signals into Alerts
The event log is valuable for post-incident forensics regardless of whether you're watching it live. But the real value is in real-time alerting — catching the event while it's happening, triggering an automatic response, and limiting the blast radius.
HuskHoard's alerting hooks let you define thresholds and connect them to any notification mechanism: email, webhook, a Slack message, or a script that takes automated action.
The exec action on the extension-change alert above is worth noting. When that alert fires, it runs a shell script that can eject the tape cartridge (physically disconnecting the media from the running attack), kill the offending process, and page an on-call contact. An automated response that happens in seconds has a very different outcome than a human who discovers the problem the next morning.
What This Is Not
It's important to be clear about what HuskHoard's event monitoring is and isn't. It is not an Endpoint Detection and Response (EDR) system. It is not a SIEM. It does not scan running processes for malware signatures, does not monitor network traffic, and does not correlate events across multiple machines.
What it is: a high-fidelity, continuous record of everything that happens to your archive filesystem, with configurable anomaly detection that understands the expected behavior of an archive. It sees things a backup system doesn't see, it records things a SIEM without filesystem instrumentation doesn't see, and it does both as a side effect of the architecture that makes HuskHoard's tape access work at all.
For a home lab or small team that isn't running a full security stack, this level of visibility is genuinely unusual. Most backup software tells you that a file changed. HuskHoard tells you what changed it, when, how fast, what it looked like afterward, and whether that pattern has ever appeared in your archive before. That's a different category of information — and it's there because fanotify was already listening.