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 |
|---|---|
onConnect | 0x140001480 |
onMessage | 0x140001560 |
onDisconnect | 0x140001510 |
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.
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 garbage 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 confirms my finding: the opcode-3 branch is gated behind an internal flag that's only set by a prior, successful opcode-2 message. What actually makes it fire is a two-message sequence.
Tear 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 bug that is well-known and has been regurgitated again and again in Windows minifilter drivers.
What's confirmed is that the the disconnect path destroys key handles unconditionally. What i haven't confirmed yet is whether a message mid-flight necessarily touches the exact struct fields disconnect but just zeroed.
Eyes that don't sleep: 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. This is also why i think it attaches to every volume without any operation callbacks. It's (kind of) legit and a low-cost guarantee that the driver is present systemwide.
What it does monitor is broader than "the exam browser." At boot, it unconditionally registers PsSetCreateProcessNotifyRoutineEx, PsSetCreateThreadNotifyRoutine, and PsSetLoadImageNotifyRoutine which are kernel callbacks that fire for every process, thread, and module load on the entire machine, all the time and 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 + 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.
A few capabilities i want to point out that i find interesting: 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 and isn't necessarily a deliberate anti-tampering technique.
