Introducing OroStat: Rootkit-Resistant Exam Monitoring From Below the OS

Most exam-integrity software shares a quiet assumption: that the operating system tells the truth. Ask Windows which programs are running, which network connections are open, which files exist — and trust the answer. For ordinary problems that assumption is fine. Against a determined insider, it is the whole vulnerability.

Because a kernel-level rootkit does not break that question. It answers it. Whatever a monitoring tool asks the OS, the rootkit decides what the OS replies. The tool reports nothing wrong because it was told nothing is wrong.

The cheat that looks like nothing

Picture an examination centre running computer-based tests — the standard format now for government recruitment, banking exams, professional certifications and university assessments across India and beyond. The threat here is not the candidate and not an outside hacker. It is a trusted insider: a centre employee with physical access to the machines before the exam begins.

Conceptually, the attack has two halves. Beforehand, the insider installs a rootkit that conceals a remote-desktop session from the host operating system. During the exam, an accomplice somewhere else watches the candidate's screen through that hidden session and relays answers back — by audio, a second device, or pre-arranged signals. The candidate looks like they are working alone. The exam software sees a normal local session. The examination body sees nothing at all. This is not theoretical; organised remote-assistance networks have surfaced repeatedly in Indian recruitment exams, with centre staff, remote helpers, and candidates paying real money for a session. We wrote about why this kind of organised fraud is so hard to stamp out in exam fraud is an ecosystem problem.

Why the usual tools come back empty

Every standard countermeasure runs on the same machine as the rootkit and asks the OS for its information — so every one of them inherits the rootkit's answer. A process scan sees a process table the rootkit has already edited. A connection check reads a network table the rootkit has already cleaned. File scans, the built-in security centre, the host firewall, even local screen recording — all of them either query the OS or sit at a layer the rootkit operates beneath. The pattern is the same one we keep running into: monitoring at the wrong layer cannot see what was removed before it looked, just as screen-capture proctoring can't see an overlay that excludes itself from capture (the invisible AI overlay).

Any tool that asks the operating system for the truth gets the rootkit's version of it. So we stopped asking the operating system.

Watch from below the OS

OroStat is built on one stubborn idea: monitor from a layer the rootkit cannot reach. A kernel rootkit on Windows owns the Windows kernel. It does not own a separate virtual machine running its own independent system. So OroStat puts a minimal VM between the physical network card and the host machine. Every byte the exam PC sends or receives passes through that VM first — and is captured and inspected there, before the rootkit has any chance to hide it.

The host carries on exactly as before. Its internet works, the exam software behaves identically, and to the candidate nothing has changed. The difference is invisible to them and, crucially, invisible to the rootkit: confined to the host OS, it has no window into the VM watching beneath it. A remote-desktop session can be hidden as deeply as you like from Windows; at the network layer it is still a connection leaving the building.

The VM itself is deliberately tiny — a roughly one-megabyte, read-only, static image with no package manager, no shared libraries, and no services beyond capture and routing. That smallness is a security property, not a vanity metric: there is almost nothing on it to attack, inject into, or modify, and the host cannot write to it even if it tries.

Why a VM and not a box of hardware

You can get the same below-the-OS visibility with a hardware network tap or a managed switch doing port mirroring. We tried that maths. It does not survive contact with three hundred examination centres.

The VM ships as a single portable appliance image, imports into a hypervisor in a couple of minutes, and auto-configures its own networking. Total setup is under five minutes per machine and needs no networking expertise on site. And if the VM ever fails to start, traffic falls back to the physical card so the exam is never interrupted — while the central dashboard flags that centre for a look.

What it actually flags

At the network layer, the signal is much harder to fake than a process list. OroStat watches for the known remote-access protocols during an active exam window, and applies heuristics for the cleverer cases — a session that opens just after the exam starts and closes just before it ends, a long-lived tunnel during the test, or the lopsided traffic shape of a screen being streamed out while only keystrokes come back. Sensitivity is tied to the exam schedule, so legitimate maintenance outside exam hours doesn't drown anyone in false alarms.

What it does not do

OroStat catches network-based cheating. It will not catch an earpiece, a phone under the desk, memorised answers, or plain collusion that never touches the network — and we would rather say so than pretend otherwise. A custom encrypted tunnel on an unusual port can still slip past simple port matching, which is why the heuristics exist and why deeper traffic fingerprinting is on the roadmap. And the model assumes the hypervisor itself is sound; a hypervisor-level attacker is a different, far more sophisticated adversary than the insider this is built for. OroStat is one layer of an integrity programme, not the whole thing — it sits alongside identity checks, physical security, trained invigilators, and delivery integrity tools like OroLink.

Open at the core, on purpose

Putting a monitoring tool on an exam machine raises a fair question: what is it actually doing, and what is it collecting? A closed binary cannot answer that honestly — you just have to trust the vendor. So OroStat's core — the VM build, the network bridge, the detection agent, the threat model — will be published as open source under the GPL v2, for examination bodies, researchers and regulators to read line by line. That is the same reasoning behind open source as a trust strategy: a security claim you can verify beats one you are asked to believe. The multi-centre dashboard, cloud log aggregation, integrations and support are the commercial tier for bodies running at scale.

OroStat is in pre-release today, with the core slated for public release under the GPL v2; you can follow our open work at the Orospor GitHub org. It fits into the broader platform integrity work we do for high-stakes systems. If you run examinations and the insider-rootkit scenario sounds uncomfortably plausible, that is the conversation we would like to have — get in touch.

OroStat is pre-release research and development from Orospor's Cyber Defense Division. It is a defensive monitoring tool for examination operators; this article describes the threat and the detection approach, not a method for evading either.