LockDownService215.sys
The kernel minifilter driver. Loaded at boot (SERVICE_SYSTEM_START), attached to every mounted volume, and running independent of whether LockDown Browser or an exam session is active.
An eye for an eye, a tooth for a tooth
The driver opens a single communication port (\ApDriverPort) via FltCreateCommunicationPort, with MaxConnections hard-capped at 1, only one client process can hold the port at any moment. The security descriptor is built with FltBuildDefaultSecurityDescriptor, which per Microsoft's own documentation, independent of the specific access mask passed, restricts the object to processes already running as SYSTEM or Administrator. Every finding below on this driver is an admin-to-kernel attack surface.
Three callbacks sit behind the port, reached through a vtable dispatch at offsets +16 and +32:
| Method | Address | Confidence |
|---|---|---|
onConnect | 0x140001480 | Confirmed |
onMessage | 0x140001560 | High-confidence inference |
onDisconnect | 0x140001510 | Confirmed |
Client authorization: signature-based, not binary-specific
onConnect checks the connecting process's PID against a single stored "authorized PID" slot. That slot is populated by ImageMonitor::imageCallback, registered via PsSetLoadImageNotifyRoutine which fires on every image load system-wide, not just new process creation, including a plain LoadLibrary call inside any already-running process.
When the slot is empty, the loading image is run through an Authenticode verification pass: CodeIntegrity::validateSignature (0x1400032CC) opens the file, walks its signature chain, and checks two literal strings: the signer's Common Name equals "Respondus, Inc.", and the issuing intermediate CA equals "DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1". Only if both match does the loading process's PID get recorded as authorized.
That blocks the naive attack of renaming malware to LockDownBrowser.exe. But the check verifies only that an image is validly signed by Respondus under that certificate chain, not which Respondus binary it is, and it isn't scoped to new-process creation. Respondus ships at least three independently-obtainable binaries under the same signing chain: the main executable, the updater, and the hook DLL itself. Because the authorized-PID slot resets to empty the moment its holder exits (confirmed in ProcessMonitor::processCallback's exit branch), it should be feasible in principle for any local process to win the authorization race by loading any legitimately-obtained Respondus-signed module before or after the real browser claims or releases the slot.
Confirmed narrowing gap in the trust model, but not necessarily a memory-safety bug, and still gated behind the admin/SYSTEM precondition above.
Candidate: unchecked read past a 4-byte buffer
The message handler receives whatever a connected client sends via FltSendMessage: an input buffer, its claimed length, and an output buffer. The only upfront validation is a check that the input is at least 4 bytes, after which the first 4 bytes are read as an opcode. Several opcode branches then read further into the buffer without ever re-checking that the claimed length covers those offsets.
The clearest case is opcode 3. It reads a 4-byte value at byte offset 260 of the input buffer with no length check beyond the initial 4-byte minimum, adds 264 to it, allocates a new kernel pool buffer of that size, and memmoves that many bytes starting from the beginning of the caller's original (possibly 4-byte) buffer into the new allocation.
Two concrete failure modes follow directly. If the out-of-bounds "length" happens to be very large or point at unmapped memory, the allocation or the copy can fault which causes a locally triggerable kernel crash. And because the newly allocated buffer is threaded straight back through the message-response path, whatever kernel memory happened to sit adjacent to the original tiny buffer can end up copied into data eventually returned to the calling user-mode process, a kernel-to-userspace information disclosure primitive (CWE-125 combined with CWE-200).
A follow-up decompilation pass refined the trigger further: the opcode-3 branch is gated behind an internal flag that's only set by a prior, successful opcode-2 message. The real trigger is a two-message sequence, not a single request. The underlying unchecked read and oversized allocation are otherwise exactly as described. Candidate, reasoned entirely from decompiled code; the driver was never loaded and no message was ever sent to it.
Candidate: key material torn down with no lock
onDisconnect unconditionally destroys the encrypted channel's cryptographic key handles (BCryptDestroyKey on three keys, BCryptCloseAlgorithmProvider on two algorithm providers) with no lock or interlock of any kind visible in the disassembly. onMessage's entry sequence has no locking either. Because MaxConnections: 1 means exactly one live port instance exists, all three callbacks operate on the same shared object, and FLT Manager itself does not guarantee mutual exclusion between the message and disconnect notifications for a given port. So, serializing them is the minifilter author's own responsibility. This is a well-documented, recurring bug class in Windows minifilter drivers.
What's confirmed: the disconnect path destroys key handles unconditionally, with no visible synchronization anywhere nearby. What isn't yet confirmed: whether a message mid-flight necessarily touches the exact struct fields disconnect just zeroed. Candidate race condition, CWE-416, gated behind the same SYSTEM/Administrator precondition as everything else on this port.
What it monitors, and what it doesn't
One clarification in the driver's favor first: its FLT_REGISTRATION struct sets OperationRegistration and ContextRegistration to null, and zeroes all nine remaining file-system callback slots. Despite being architecturally a minifilter attached to every volume, it registers zero file-system I/O interception: it never reads, inspects, or modifies file content. Attaching to every volume without any operation callbacks is a legitimate, low-cost way to guarantee the driver is present system-wide; it isn't evidence of file-content monitoring.
What it does monitor is broader than "the exam browser." At boot, it unconditionally registers PsSetCreateProcessNotifyRoutineEx, PsSetCreateThreadNotifyRoutine, and PsSetLoadImageNotifyRoutine: kernel callbacks that fire for every process, thread, and module load on the entire machine, all the time, not scoped to an active exam session. It can also attach into and read the memory of any arbitrary process by PID, confirmed via the PsLookupProcessByProcessId → KeStackAttachProcess → (inspect) → KeUnstackDetachProcess pattern.
For every process it observes, it extracts and can report: the image path, CompanyName, FileVersion, and OriginalFilename (pulled by a hand-rolled kernel-mode parser of the target's VS_VERSION_INFO resource), plus the on-disk file owner account of the executable, resolved through ZwQuerySecurityObject and RtlGetOwnerSecurityDescriptor. That last field is the file's NTFS owner, typically an installer or admin account, not the running process's own user token.
A few capabilities round out the picture without adding to the concerns above: a dedicated fileless-execution detector (ThreadMonitor::detectFilelessExecution), SHA-1/SHA-256 hashing of loaded images as part of the signature pipeline, and a second, separately-tracked PID reserved specifically for dwm.exe, plausibly related to the screen-capture-exclusion feature needing the Desktop Window Manager's cooperation. The driver also imports KeBugCheckEx with code 0x139, which is simply the standard MSVC /GS stack-cookie violation handler present in virtually every compiled kernel driver, not a deliberate anti-tamper "crash the machine" design, despite how it might read out of context.
