Founder Perspective · 7 min read
How Proxy Exam Services Actually Beat Proctoring Software
By Akshay Aggarwal · May 13, 2026
One proxy exam service names its competition directly on its sales page. Pearson Vue. Prometric. Respondus LockDown Browser. Proctorio. ProctorU. Safe Exam Browser. Not as platforms it works with, as platforms it claims to bypass, with what it calls "100% secure" evasion.
The service is called CBTProxy. It runs Google Ads. It has a professional FAQ. It offers a pay-after-pass model that removes the upfront-payment risk that makes other services look like scams. It has been operating, openly, for years.
I built upskillfinder.com and personally completed more than 30 certifications across cloud, security, and project management. I know how those proctoring environments work from the inside. I wrote earlier about how proxy rings sell credentials for around $200 and the downstream cost to the hiring signal. This post is about something more specific: the technical mechanism behind the evasion, and why browser-based proctoring is structurally unable to stop it.
The Service Offer, Plainly Stated
The operation works like this. The candidate logs in on exam day and completes identity verification. Once the exam questions appear, a remote operator takes control of the candidate's keyboard and mouse while the candidate remains in front of the webcam. After all questions are answered, the operator uninstalls their tools and disconnects. The certificate is issued to the candidate's name.
Pay-after-pass means the service only charges once a vendor-confirmed passing score is received. The scam risk that plagued earlier cheating-for-hire markets, upfront payment with no delivery, is structurally eliminated.
Pricing follows credential difficulty. A basic cloud or IT associate exam runs $150 to $200. An enterprise architect or security certification from the same provider runs $400 to $600. The economics work because the credential can justify a salary increase of $15,000 to $40,000.
The Timing Window They Exploit
The key technical detail is when proctoring software does its lockdown check: at launch.
When a candidate opens Respondus LockDown Browser or Proctorio, the browser scans the system for prohibited processes, open windows, screen-recording tools, and clipboard history. If anything trips a rule, the exam does not start.
Proxy services install their remote access agent before the lockdown browser opens. By the time the security scan runs, there is no prohibited process actively running in a detectable state. The remote desktop agent is already resident, its connection pre-established, its presence normalized in the system process list under a generic name.
The lockdown browser's scan produces a clean result. The session starts. The remote operator connects through the pre-established channel and begins answering questions.
This is the same pattern used in rootkit deployment: establish persistence before the guard process activates. Browser-based proctoring was not designed to defend against pre-loaded agents because its threat model assumed the session environment was clean at launch.
The Webcam Problem: Solved with Choreography
The obvious response is that webcam proctoring catches this because the person answering the questions is not the person on camera.
Except the person answering the questions is the person on camera. The candidate sits in frame, eyes forward, while the remote operator's keystrokes arrive over the network. The webcam sees exactly what it is supposed to see.
Services instruct candidates on behavioral detail. Eyes forward. Deliberate pauses to mimic reading. Occasional re-reads of questions to match normal gaze patterns. Some services insert deliberate wrong answers into the response set: a perfect score on every question in minimum time produces a psychometric outlier profile that some platforms flag. An intentionally imperfect session looks like a real person working through a hard exam.
For higher-stakes certifications, the proxy is not remote at all. A human assistant is physically present, out of camera frame, feeding answers verbally or through a discreet earpiece. No remote desktop required. No network traffic to block. The proctoring software sees one candidate, one screen, and a clean session.
The second-device variant follows the same logic. The candidate reads the question, formulates it mentally, and types it into an AI assistant on a phone below the camera line. The proctoring software cannot see a second device on the same Wi-Fi network. The candidate glances down, indistinguishable from checking the time, and reads the response.
What Process Scanning Cannot See
Browser-based proctoring collects four categories of evidence: which processes are running, what windows are visible, clipboard events, and where tab focus sits. Against its original threat model, a candidate Googling answers in another tab, this is adequate.
Against pre-loaded remote access, it covers none of the relevant surface.
Process-list scanning checks names, not connection state. A remote desktop agent listed under a generic system service name passes the name check. The active TCP connection it holds to the operator's relay server does not appear in the process list. It is connection-table state, a separate data structure that browser-level proctoring does not inspect.
Screen monitoring captures what is visible on the display. It does not record which process generated each keystroke.
Clipboard monitoring triggers on paste events within the browser. The remote operator's keystrokes do not come through the clipboard. They arrive as low-level input events that are indistinguishable from physical keyboard input.
The gap is architectural. Browser proctoring runs as an application. Remote desktop injection happens at the kernel input layer. The application-layer tool has no visibility into what is happening below it.
The Scale of What Gets Through
In 2025, Meazure Learning's security team intervened in nearly 50,000 exam sessions due to security concerns and shut down 4,700 remote-control proxy sessions. That 4,700 figure is what was detected and stopped. It is not the total volume.
The Texas teacher certification scheme shows what the undetected fraction looks like at scale. A proctoring coordinator accepted cash to allow proxy testing, over 400 fraudulent certifications were processed before detection, and the scheme involved at least 200 educators. Detection came from an informant, not from automated session monitoring.
The services advertising 100% pass rates are not making an empty claim. When the evasion operates below the detection layer, the base rate on getting caught is genuinely low.
What Actually Closes the Gap
The structural problem with browser-based detection is that it operates at the application layer while the evasion operates below it. The fix requires going below too.
Network-layer enforcement blocks the protocols that remote access depends on before they can carry exam content. Remote Desktop Protocol traffic on port 3389. VNC on port 5900. TeamViewer's relay handshake. AnyDesk's tunneling protocol. Screen-sharing services. These are identifiable at the network layer by protocol fingerprint, not just by port number.
DNS enforcement adds a second layer. Every AI API call begins with a domain resolution: api.openai.com, api.anthropic.com, generativelanguage.googleapis.com. A network-layer guard that controls the session's DNS resolver breaks the chain at its first link, before any payload leaves the device.
The critical property of this approach is that it does not try to identify the proxy agent by name. It removes the network conditions the agent requires to operate. An undetected remote desktop agent that cannot reach its relay server is inert. A second-device AI assistant that cannot resolve its API endpoint is a blank screen.
The evasion services have adapted to every browser-level control deployed against them. They have done so for years. Network-layer enforcement is structurally different: it does not try to identify their tools. It removes the conditions their tools require to function.
Aiseptor enforces exam integrity at the network and OS layer, blocking remote-access protocols, AI API endpoints, and screen-sharing services before the first exam question loads. See how the enforcement works
Frequently Asked Questions
How do proxy exam services bypass webcam proctoring?
The candidate sits in front of the webcam maintaining normal forward gaze while a remote operator controls keyboard and mouse via a pre-installed remote access agent. The webcam sees the registered candidate; exam answers arrive from elsewhere over the network. Some services use a co-located human assistant physically out of camera frame, requiring no remote network connection at all.
Can Respondus LockDown Browser detect proxy exam services?
Respondus checks for running processes and screen-sharing applications at session start. Remote access agents installed before the browser launches, or those presenting under generic system service names, are not reliably caught. Process-list scanning does not inspect network connection state, which is where established remote sessions persist. CBTProxy explicitly lists Respondus as a platform its service bypasses.
What actually stops proxy exam services from working?
Network-layer enforcement blocks the TCP connections that remote desktop and relay tools require to function. Unlike process-list scanning, network enforcement operates below the application layer, severing the relay connection before exam content is loaded. Remote access agents cannot reach their operators and AI assistance tools cannot reach their API endpoints. The evasion tooling is rendered inert without being identified by name.