Where this started

The concept began as my MSc Cybersecurity thesis on Forensics-as-a-Service: the argument that digital forensics, historically a slow, manual, expert-bound discipline, could be restructured as an automated cloud service without losing the evidentiary rigour that makes forensic findings mean anything.

The academic work established the model. Zabta is the attempt to build it properly, with the parts that only become visible once you try to make it work at production scale.

The problem

Every enterprise runs endpoint detection. CrowdStrike, Microsoft Defender, SentinelOne. These tools are good, and they all rest on one assumption: that the agent can see what is happening on the machine.

Sometimes it cannot. A kernel-level implant operates beneath the agent's visibility. A malicious driver unhooks it. Malware runs entirely in memory and never touches disk, where most detection logic is looking. And by the time an incident is detected, the attacker has typically been resident for around two weeks.

At that point the investigating team faces a harder question than "what is running now?" It is "what changed?", and without a record of what normal looked like, answering it takes days of forensic work before the real investigation can begin.

What Zabta does

Zabta is an independent verification layer. Not another detection product, but a way to establish whether the detection products are telling the truth.

A lightweight collector runs on a schedule and computes a structural fingerprint of each machine's live state: the process tree with image hashes, loaded modules and drivers, kernel integrity markers, regions of executable memory with no corresponding file on disk, network listeners and their owning processes, and the full persistence surface.

That fingerprint is roughly a megabyte. It carries no memory contents, no credentials, no personal data. Only hashes and structural metadata.

It is compared against a known-good baseline captured before anything went wrong. The output is not an alert stream. It is a specific, evidence-linked answer to the question of what is different from the machine we knew.

What takes years to build

The analysis tools underpinning digital forensics are open source and widely available. Assembling them behind an interface is a few months of work and produces nothing another team cannot reproduce. Zabta's value sits in four assets that only accumulate.

A symbol corpus that compounds daily. Interpreting the structure of a Linux kernel's memory requires a symbol table matching that exact build, down to the compiler version and compilation timestamp. A near-match produces output that looks plausible and is silently wrong. Those symbols come from debug packages distributions do not keep indefinitely, so for an older kernel they may no longer exist anywhere. Zabta harvests them nightly into a permanent indexed archive. Every day it runs the gap widens, and no amount of funding recovers builds that have already aged off the mirrors.

Symbol capture at the source. Because Zabta controls the collector, it takes the kernel's type information directly from the live machine at the moment of acquisition rather than reconstructing it later from an archive that may be gone. This inverts the hardest problem in memory forensics. Anyone analysing a dump after the fact still has it.

A corpus of known-good machine state. Every fingerprint collected sharpens the picture of what normal looks like across operating system builds, patch levels and application stacks. This is the difference between surfacing four thousand changes and surfacing the three that matter. It cannot be bought or bootstrapped.

A validated method. Automated forensics is worth nothing if its conclusions do not survive challenge. Zabta maintains a regression corpus of images with known ground truth, runs the full pipeline against it on every release, and versions every component so any finding traces back to the exact software that produced it.

Design decisions

Nothing leaves the host that should not. A raw memory image contains cleartext credentials, session tokens, private keys and personal data. Asking a bank to upload one to a shared cloud is a conversation that ends quickly. Computing the derivative at the edge removes that objection entirely, and makes the economics work: shipping a megabyte a week costs a fraction of shipping four gigabytes.

Baselines must exist before the incident. Forensic readiness is something an organisation either arranged in advance or did not. Zabta is built around capturing normal while it is still normal.

Evidence has to survive scrutiny. Every artefact is hashed before it is transformed, sealed with a trusted timestamp, and written to immutable storage under a retention lock. The chain of custody is cryptographically linked, so tampering with history is detectable. Reports are built for auditors, insurers and, where it comes to it, court.

Degradation is never silent. When symbols cannot be resolved, the report states it in the header. A partial analysis presented as complete is an evidentiary failure, so the system is designed to fail loudly rather than quietly.

On AI

A hallucinated finding in a forensic report is not a poor user experience. It is an evidence integrity failure that could collapse an insurance claim or have an expert report excluded.

Zabta uses language models for triage and summarisation only. They are never a source of fact. Findings are generated deterministically from tool output and cryptographically sealed. Any AI-assisted narrative is labelled as such, requires a named human signature before release, and passes through a verifier that rejects any sentence whose claims do not resolve to a specific piece of underlying evidence.

Computing on data we cannot read

The privacy problem in cloud forensics is not incidental. It is the reason the category has struggled. The most useful evidence is the most sensitive material an organisation holds, and no serious security team wants it processed somewhere they cannot control.

The structural fingerprint solves most of this by never collecting the sensitive material in the first place. The remainder is a cryptographic problem, and it is one Zabta treats as foundational rather than as a feature to add later.

Two applications matter. Fleet prevalence lookups, where a customer needs to know whether an artefact appearing on one of their machines is common across the wider population without revealing the artefact or learning anything about anyone else's estate. And corpus queries, where the same requirement runs in reverse. Both are cases where the answer is valuable and the question itself is confidential, which is exactly the shape that privacy-preserving computation addresses: encrypted set intersection for membership, and homomorphic techniques for aggregate counts computed without decrypting the inputs.

Alongside this, the analysis plane is designed to run inside hardware-attested enclaves, so that where sensitive data must be processed, it is decrypted only inside an environment the operator cannot inspect, and the customer can verify that cryptographically rather than taking it on trust.

The principle underneath all of it: a forensic platform should be able to prove what it cannot see, not merely promise it.

Engineering constraints

The collector leaves almost no trace. A single compiled binary, no installer, no persistent service. It is invoked, runs for seconds, and exits. Nothing stays resident for an attacker to unhook or a change board to object to.

Analysis is isolated and reproducible. Forensic images are hostile input by definition. Each step runs sandboxed with its own timeout, so one bad artefact degrades a single result rather than a pipeline. Re-running any job produces byte-identical output, which is an evidentiary requirement rather than a performance nicety.

Storage is write-once and provably so. Evidence is committed under a retention lock that cannot be lifted once applied, encrypted under keys the customer can revoke, with every access recorded in a cryptographically chained log.

The control plane never needs to read evidence. Scheduling and metadata are handled separately from the material being analysed, which is what allows the analysis to run inside a customer's own infrastructure or a hardware-attested enclave without redesign.

Everything is versioned, including the reasoning. Each finding records the software, symbol table and scoring logic behind it. When scoring changes, historical findings keep their original values. Silently re-scoring the past is convenient and indefensible.

Where it is

Operational. The symbol acquisition pipeline is running and accumulating nightly. This was deliberately the first thing built, because it is the only component whose value depends on elapsed time rather than effort. Kernel builds age off distribution mirrors continuously, and every night the archive runs is coverage that cannot be recovered later at any price.

In development. The collector for Linux, covering live structural acquisition and symbol capture at source. Alongside it, the comparison engine: identity resolution across process, module, kernel and persistence records, and the scoring model that decides which differences warrant an analyst's attention. Signal-to-noise is the real problem here, not detection. Surfacing four thousand differences is easy and useless.

Next. Evidence handling with chain of custody and retention locking. Windows structural acquisition. Deterministic report generation suitable for audit and legal review.

Under evaluation. Kernel integrity verification without loading a driver is at the edge of what is currently possible on both Linux and Windows, and how far it can be taken is being established empirically rather than assumed. Where it cannot be, the system is designed to state so explicitly rather than return a partial answer dressed as a complete one.

Design partners. Conversations opening with incident response practices and managed security providers. The intent is to validate against real engagements rather than synthetic tests, and to measure the effect on investigation time honestly rather than model it.