The Audit Trail Can Fail Before Storage
HyperAudit is a hypervisor-assisted system-auditing architecture for cloud platforms. Its central question is deceptively simple: when a guest operating system has been compromised, who still controls the audit evidence that the operating system has generated but not yet secured? This series follows that question from the failure of kernel-local collection to HyperAudit’s proposed boundary between a guest VM, a hypervisor, and a dedicated Secure VM. The practical judgment is not whether remote storage is useful—it is—but whether the collection path remains trustworthy long enough for remote storage to matter.
That distinction matters because audit logs are not merely a record of what a machine did. They support intrusion detection, provenance analysis, compliance checks, and reconstruction of an attack. In a cloud environment, they may also help an operator understand how a workload behaved when the workload itself can no longer be trusted. A missing or altered event can hide the first step of an intrusion, make a legitimate action look suspicious, or erase the sequence needed to decide what must be rebuilt.
The real job of an audit log
An audit log becomes useful when it can connect an action to enough surrounding context for another person or system to interpret it. A syscall record might identify an operation, its result, the process that issued it, and data associated with the call. Across many records, those details can reveal a new process, an unusual access path, or a change in behaviour. They can also provide a historical account after an incident, when the original process is gone and the system’s current state may have been deliberately modified.
The Australian Signals Directorate’s Australian Cyber Security Centre describes event logging in similarly operational terms. An effective logging solution should help defenders notice important changes, identify events that may indicate compromise, support incident response, monitor account compliance, reduce unhelpful alert volume, and keep the logs usable for analysts. That guidance groups the work into four connected concerns: an approved policy, central access and correlation, secure storage and integrity, and a detection strategy for relevant threats.
Those concerns expose why “we send our logs elsewhere” is an incomplete answer. A policy determines which events are worth collecting. Correlation makes separate records meaningful. Storage and access controls help preserve them. Detection rules and human investigation decide what they mean. But every one of those later steps depends on the first one: the event must be captured accurately and must not be silently changed before it reaches a place that can protect it.
Quality here does not mean collecting every possible byte. It means collecting the kinds of events that can answer the questions defenders will face later, with enough identity, timing, and surrounding detail to distinguish a real signal from an ordinary action. A large, well-formatted archive can still be weak if it omits the event that links a login to a privilege change or a process to the file it opened. Conversely, a focused stream can be more useful when it is structured consistently and can be correlated across systems. That is why the ACSC guidance treats collection policy, storage capacity, and analyst usability as connected decisions rather than separate checkboxes. HyperAudit addresses the integrity of one important collection layer; it does not decide what an organisation should value as evidence.
The evidence has a vulnerable middle
It is helpful to separate four moments that are often compressed into the single verb “logging.” First, an action occurs and the operating system generates an event. Second, a collector observes the event and places information in a buffer. Third, another component processes or forwards that information. Finally, a durable store makes it available for correlation and later investigation. An event can be real at the first moment and still fail as evidence at the second or third.
The buffer is the important middle state. It exists because sending every event immediately to a remote or higher-privilege service is expensive. The collector needs somewhere to hold data while the workload continues, and the receiving side needs time to process bursts. That delay is normally an engineering convenience. Under compromise, it becomes a security boundary.
In the auditing systems examined by HyperAudit’s authors, the collection module is placed inside or tightly coupled to the guest kernel. An attacker who has escalated to kernel privilege can then see the same memory and interfaces used by the collector. They may alter or remove events that are still waiting in the buffer, including traces from before the compromise. The log has been generated, but the attacker still controls the state in which the log is temporarily held.
The same design creates a second pressure. An attacker can generate a large volume of otherwise benign system calls. If the collector cannot transmit them quickly enough, the buffer fills. A system can respond by dropping later events, which harms integrity, or by blocking the workload until the collector catches up, which harms availability and performance. Either response gives the attacker leverage: one obscures activity, while the other makes the audited system more expensive to run.
The timing is consequential even when the interval is short. An investigator does not need an attacker to erase an entire history; removing a few events at the beginning of a sequence can make later activity look unconnected. Deleting a record of a new process, a change in permissions, or an unusual login can deprive a detection rule of the link that makes the next event suspicious. A full buffer creates a different kind of ambiguity: if records are dropped during a burst, an analyst may not know whether silence means that nothing happened or that the collector could not keep up. Integrity therefore includes continuity and known loss, not just protection of the records that happen to arrive.
A central destination still helps with local storage exhaustion and later correlation, but it is downstream of this vulnerable interval. The collector has to decide what to copy, the buffer has to hold it, and the submission path has to carry it across a privilege or system boundary. Each step can be a place where content, ordering, or availability changes. HyperAudit’s proposal begins by asking whether those steps should remain objects owned by the same kernel that an attacker may control.
This is why the location of the final database is not the whole story. A remote destination can protect a record after arrival while leaving the upstream collector and its queue exposed. The decisive question is not only where the log ends up, but which authority controls the evidence during the interval before it gets there.
Why the kernel becomes part of the attack surface
A guest kernel is the privileged core of an operating system. It manages memory, schedules processes, exposes system-call interfaces, and mediates access to devices and files. A kernel-level attacker is therefore not just another process competing for access. Within the threat model used by HyperAudit, that attacker can inspect and manipulate guest-accessible logging components, alter the structures on which they depend, and generate enough activity to pressure the collection path.
This creates a particularly awkward contradiction. The kernel is the most convenient place to observe system calls because it already sees them and already understands their arguments. It is also the place an audit framework can least safely trust after compromise. A collector that depends heavily on kernel interfaces inherits the kernel’s visibility and its failure modes. A collector that tries to defend itself with frequent submissions reduces the time during which evidence is exposed, but repeatedly pays for synchronisation or crossings between privilege levels.
The result is not simply that one implementation has a bug. The architecture has coupled two different responsibilities: executing the workload and protecting the account of that execution. Once the execution environment is compromised, the account becomes vulnerable too. The protection mechanism then has to compensate on every event, even during normal operation when no attacker is present.
This coupling also makes the meaning of a record depend on the health of the code that produced it. A collector may appear to be installed and may continue emitting plausible-looking entries while a privileged attacker quietly changes its inputs, its buffer, or its submission schedule. A later analyst who sees a clean remote archive cannot necessarily infer that the archive is complete. The missing evidence is precisely the evidence that a compromised collector had the opportunity to remove. Protecting the account of execution therefore requires controlling the collector’s authority, not only checking the final format of its output.
HyperAudit’s authors frame isolation as the way out of that loop. If the collection module does not expose useful interfaces to the guest kernel and does not rely on the kernel to perform its core work, a guest-level attacker has fewer ways to reach it. The system can then use an asynchronous path for ordinary transfer instead of treating every syscall as an emergency commit. That is a change in authority before it is a change in implementation.
HyperAudit changes the authority, not merely the destination
HyperAudit divides the work among three actors. A kernel-independent Log Collection Module is injected into the audited guest through the hypervisor. The Secure Hypervisor controls where that module and its buffer are mapped and which accesses are permitted. A dedicated Secure VM receives, processes, compresses, and persists the records. The guest VM still runs the workload, but it no longer owns every object involved in recording that workload.
This arrangement does not make the guest irrelevant. The collector must still intercept the guest’s system-call path, observe enough information to describe an event, and allow the original operation to continue. The important change is that the collector and the evidence it has buffered are placed under a higher-privilege authority. The Secure VM then provides a separate place for processing and storage, rather than asking the compromised guest to protect its own audit trail.
That division is useful only if the responsibilities remain distinct in operation. The guest should be able to run its workload without being able to rewrite the collector’s code or the records waiting for transfer. The hypervisor must enforce the memory boundary instead of merely documenting it. The Secure VM must receive and persist data quickly enough that the protected buffer does not become an availability bottleneck. And the resulting records must retain enough context to be useful after they leave the guest. HyperAudit is consequently a design about control flow and state ownership as much as it is a design about where a component is installed.
The boundary also clarifies what the proposed guarantee means. HyperAudit is designed to preserve the integrity of logs generated before the guest kernel is compromised. It does not claim that logs generated after that point remain forensically trustworthy when the attacker has full kernel control. The hypervisor and Secure VM are assumed to be trusted parts of the system, and the paper treats them as the foundation on which the stronger pre-compromise claim rests.
The next questions are therefore precise. How can the hypervisor hide and protect a collector without making ordinary operation prohibitively expensive? How can an isolated module obtain meaningful syscall context without asking the potentially compromised kernel to interpret everything for it? And once records are protected, can the receiving side keep up with the workload and provide the context that defenders need?
The answers will involve memory permissions, protected buffers, architectural state, deferred interpretation, compression, and asynchronous consumption. But the foundational lesson comes first: trustworthy auditing begins before persistence. It begins at the boundary that controls collection.