OK, here I am, a university academic, about to give you a simple ‘How-To’ for cheating in online exams at a university (or school, polytechnic, college, …). How dare I?
Truth be told, this post isn’t really for students. They (and their helpers) likely already know much of what I’m about to share — and have probably been practicing it without their teachers or administrators noticing. This is for you: The technical support teams in educational institutions. What do you say to colleagues in education who think that Bring-Your-Own-Device (BYOD) proctored online exams are an affordable and secure solution? They need a wake-up call. Here’s what you need to know to convince them otherwise.
Also, some assessment practices are so dangerously naïve that they deserve to be put out of their misery by showing how easy they are to fool. As you’ll learn here, BYOD supervised online exams fall squarely into this category.
And, yes, this is very much a technical blog because networking technology (and the lack of understanding thereof) is the key enabler of cheating in this scenario.
Why is this even important? Why should you care? Because, right now, there is a generation of students in the process of graduating from some of the world’s most reputable universities who have, to a significant percentage, only a faint clue of the subject they are about to obtain their degree in. For the last few years, they’ve been able to outsource almost every assessment.
As you shall see here, just bringing them back to campus to sit online exams doesn’t necessarily change that. They’ll soon be responsible for making sure that the buildings you spend time in don’t collapse, that the software of the planes you will fly on won’t make them crash. They’ll be responsible for your health, your money, your rights, and your kids’ education. Do you think they should know more than just how to use ChatGPT? Then read on.
Setting the scene
COVID-19 forced many educational institutions into online assessments. Cheating was rife for all to see, with course pass rates surging to well above 90% where previously a third of students or more might have failed. Then came artificial intelligence, which made cheating even easier — you no longer had to find someone knowledgeable who could provide the answers for you. ChatGPT could produce them for free.
The strategy after COVID-19 seemed clear: Let’s bring the students back into a secure environment on campus, so they can’t access ChatGPT, friends, or cheating websites. So far, so good.
But online exams have also brought advantages for teachers. No more deciphering illegible student handwriting, no more handling hundreds of pages coated in germs from students who should have applied for a medical waiver, and no more worrying about lost or stolen scripts — or accidentally spilling coffee or letting a chewy dog near them.
Letting the students sit online exams under supervision thus became an attractive proposition. You don’t even need to buy any extra computers. Simply let them use their own, get them to connect to the Internet via university campus Wi-Fi, give them a lockdown browser that stops them from accessing the rest of the Internet, and have a few spare laptops at hand in case their machine fails. Easy. What could possibly go wrong?
Heaps, as it turns out.
Before the exam
To use the lockdown browser, students must download software to install on their device (which will usually be a laptop). This software — if it’s halfway clever — detects numerous threats to exam integrity before you even start your exam. This includes for example extra screens (not really an issue under supervision, you’d think, but certainly during remotely proctored take-home exams) and whether the software has been put inside a Virtual Machine (VM).
However, lockdown browsers don’t check for everything. One issue that is difficult to check for is back doors into the student machine — back doors that allow another party to see and interact with the student’s screen as if it were their own, without the student’s screen going dark. Such back doors may be the result of a virus infection, part of a student’s legitimate setup when involved in outside work, or — and this is where it hurts — an arrangement to have an external party supply answers during the assessment.
We know that virus infections are relatively common, and so must conclude that if we let thousands of students’ devices sit lockdown browser exams, we’d have to expect a few backdoors on these machines just from infections. An astute lockdown browser should flag back doors. But the one that the author’s university has used thus far didn’t flag anything, because it clearly didn’t check for their presence. This meant that any backdoor checks were at least quite incomplete.
In fact, we were able to show that its environment check passes with an active back door in place: We used an open source ‘Sunshine’ server on the student machine, running over a Tailscale VPN overlay network, giving full simultaneous access to the assessment to a remote helper with a ‘Moonlight’ client. If the browser had checked for this combination, that’d been great, but there are countless other ways, too. There are dozens of similar remote desktop applications available to create and exploit back doors, such as VNCs. These are generally easily modified to escape detection by renaming the executables and changing the ports in use. The setup required by the student is minimal — comparable to lockdown browser installation in complexity.
But let’s assume for a moment that you could build a lockdown browser that could check for back doors. Fine, except that, well, this software runs on the student’s laptop as a client program that talks to the exam system server on the Internet. That exam system server has no way of telling whether the copy of the lockdown browser software that runs on the student’s laptop is a genuine copy or perhaps a ‘patched’ copy that bypasses the integrity checks above while giving the ‘All OK, nothing to see here’ message to the server.
There was a time when developers needed to learn that their web server-side software would receive data from any form, not just the form they had developed for the purpose and that this could feed maliciously crafted data to the server. This lesson seems to have been forgotten here, though. A quick Google search shows that ‘patches’ for many popular lockdown browsers are readily available online. Some are from students for students. To your exam system, they look like the genuine thing. Even if they’re not.
If your lockdown browser doesn’t have a patch yet, consider yourself lucky — it probably will soon. One of our students developed a patch for ours that bypasses the VM check , enabling cheating students to access the Internet using ChatGPT and messaging applications simply by sliding the VM window with the lockdown browser to the side. It only took the student 20 minutes to create this modification. He has since — investing less than a full day’s work — come up with a version that also bypasses all other security checks, including the backdoor checks (turns out they do exist, but only in the form of a highly incomplete executable blacklist), checks for second screens, screen video, webcam and microphone recording, as well as a number of other features. If remote proctoring is your thing, take note also!
These weaknesses are likely already being exploited, at least by commercial contract cheating providers. How do we know? When we implement measures that make it harder for students to cheat, there’s usually some pushback. This time? Silence.
Entering the exam room
Besides cheating, there’s also the possibility of sabotage by pranksters or the disgruntled. Let’s digress for a moment. Remember those old stories of students breaking into the safe to steal all print copies of an upcoming exam the night before — that’s an analogue version of a Denial-of-Service (DoS) attack.
But with technology, saboteurs can do better, without the risk of getting caught by a CCTV camera they’ve failed to spot. And I’m not talking about Distributed Denial-of-Service (DDoS) attacks on exam server infrastructure — much of which sits in the cloud and is hard to suppress — but on a much more vulnerable component: Your campus Wi-Fi network.
The easiest way to cause a little mischief is to turn off the mobile data on a phone and configure it to hotspot as a Wi-Fi access point under the same network name (SSID) as the campus network. Turned to silent and left in a student bag, any student laptop closer to the bag than to the Wi-Fi access point in the exam room will now try to log into the phone hotspot rather than the campus Wi-Fi. None of these students will be able to access their exams now.
This starts the exam off with an unexpected problem that will probably not be shared by too many in the room — running the risk of innocent students getting labelled frivolous complainants. Remember, all you need for this is a mobile phone; no special software is required.
Technically more ambitious pranksters might want to head for GitHub instead and grab a piece of software that sends a disassociation request to the university Wi-Fi access point whenever a laptop sends an association request. The effect is similar, except now, you can disrupt the entire room, rather than just the folk close by.
Moreover, you can throw red herrings by restricting the disassociation requests to device MAC addresses of laptops from certain manufacturers: Apple, ASUS, Dell, or whoever you’d like to target, based on a matching Organizational Unique Identifier (OUI) in the association request. That’ll send tech support down the wrong alley wondering what’s wrong with the victim’s Wi-Fi drivers. The possibilities are endless.
Remember, this issue affects the class as soon as they enter the room. Your lockdown browser supplier’s sales reps may have assured you that students are covered if the Wi-Fi goes down and can submit their exam later — but no, they can’t even access the exam in the first place.
Your exams office might think about offering Wi-Fi-outage-afflicted students the use of USB-to-Ethernet dongles: Make sure they know that each such dongle needs a cable to be plugged into an Ethernet socket. Decent-size lecture theatres might have half a dozen such sockets — not necessarily all usable — and you’ll have dozens of students competing for one. The dozens of long cables to them are a significant health and safety tripping hazard, too.
Also, if your network team pays any attention to network security, they won’t let student devices connect to the institution’s wired network anyway. Even if that is allowed, they’d need to ensure that the dongles can get an IP address wherever they are needed. This might work at your university, but it sure doesn’t at mine.
During the exam
Let’s assume for a moment that no one is interfering with the Wi-Fi. Your exams office has the students in the room, but are the people in the room actually the ones taking the exam? They’re supposed to be, but your exam system server is on the Internet — and, in all likelihood, it doesn’t care whether a student login comes from your exam room or the other side of the world. This is largely because many system providers serve customers globally and determining who should access the system from which network adds complexity and cost.
So, your cheating student, with a helper ready to assist, shows up to the exam room just to make an appearance. Even without creating a backdoor, their helper can log in as the student from outside the room and use ChatGPT to answer the exam questions. Room supervisors might not notice this, even when a lockdown browser is in use. Students can employ various techniques to make it seem like they’re actively engaging with the exam when, in reality, someone else is doing the work remotely.
So, you’ve anticipated this and are protecting the exam with an access code only issued in the exam room? Well, we’ve already seen several cases where the code has mysteriously leaked: spied through windows, smuggled out during toilet breaks, or perhaps noted before the student launched the lockdown browser. And who would deny a diligent student the chance to visit the bathroom during a two-hour exam?
Remember, most exams can now be solved by ChatGPT in a fraction of the time it takes a human. We’ve observed questions being answered and submitted at a rate of about two per minute. What about students who finish early and leave after 20 minutes? Could they step outside and complete unanswered questions there?
OK, so you’ve anticipated that too and set up a dedicated Wi-Fi network for the exam room, requiring students to log in to access the exam. Great. But don’t forget to sweep the area outside the room — Wi-Fi signals don’t stop at walls; they just weaken slightly. Also, keep in mind that if the exam is restricted to campus Wi-Fi, it can be accessed from anywhere on campus, and the server won’t be able to tell the difference. If you had used a computer lab with wired university machines, this wouldn’t be an issue.
After the exam
Historically, a lot of cheating gets detected after exams. What have we available here to check that our exam was all above board? There is realistically zero chance of detecting a phone spoofing campus Wi-Fi — the evidence would walk out with the students and be lost forever. ‘Patched’ lockdown browsers don’t stick around after the exam either. Privacy considerations will probably prohibit you from checking student devices for their presence anyway. The same applies to back doors.
Where students do leave a footprint of sorts is in the logs of the exam system server, provided it logs the lockdown browser client IP address that accessed the server. When a student engages an outside helper to run the lockdown browser session on their behalf directly rather than via a back door to the student machine, the helper’s session will come from an IP address outside the exam room.
This also applies to exams in computer labs with wired computers, whose addresses are generally known. If an unknown address turns up in the log, you know it’s not a lab computer that supplied the answers. We’ve successfully prosecuted numerous students who tried just that.
But you didn’t choose a wired network for the exam with devices you had control over. You chose Wi-Fi and student-controlled devices. And who knows what you did to prevent students from accessing the exam from pretty much anywhere on the planet. This means that now you have a few problems.
Firstly, even if you allowed campus Wi-Fi only, you can’t easily tell whether the device was inside or outside the exam room.
Good on you if your system logs which access points were used — at least this gives you the ability to flag accounts accessing from remote corners of the campus. However, this requires matching each student in the exam room to the access point they used, and there likely aren’t systems in place to automate this. Many IT staff (perhaps rightly) believe it’s not their job to act as academia’s ambulance at the bottom of the cliff.
Even if you can identify the Wi-Fi access points used, some of them may naturally be visible outside the exam room. That’s also where you might find helpers, who — if they’re nearby — could even connect to access points within the room itself.
By the way, forensics requires quick access to the IP logs from the exam server. Do you have to submit a support ticket to retrieve them, one class at a time? Welcome to the world of commercial online assessment systems!
If the exam isn’t restricted to campus addresses only… oh dear. You’ll encounter the student who purportedly ran a VPN on their device and forgot to turn it off before logging into the Wi-Fi. Or perhaps they claim to have used a SIM card with mobile data in their laptop, allowing Internet access from virtually anywhere. In either case, your exam system server will observe unusual IP addresses — even if the student didn’t cheat at all. Any evidence of an external third party’s involvement evaporates. You might just see a suspiciously large percentage of students in those categories.
By the way, we’ve seen students use VPNs to hide helpers for years. In one of our unsupervised online exams, nearly half the class appeared to the server as connecting from multiple devices and IP addresses in a variety of locations — even though no one told them that multiple parallel sessions were possible, and no one asked whether it was acceptable to use multiple devices or VPNs. If we hadn’t investigated, we’d have had no idea this was happening.
A lot of these IP addresses were VPN exit points — we just couldn’t tell whether it was the student or their helpers using the VPNs. A 2023 investigation into a university-provided student VPN at my university found that almost none of its users had a legitimate need for it. In fact, almost all had concurrent non-VPN logins to the university — in many cases accessing from campus. Most students seen on the VPN in an assessment context had existing disciplinary records. But that doesn’t equate to evidence in individual cases.
You could make the use of VPNs or non-campus Internet an examination offence, true. But be prepared for students to claim they left their VPN or mobile data on by accident (‘I don’t know why my computer keeps turning it on by itself!’). In a small number of cases, this might even be genuine — yes, sometimes the dog really does eat the homework. So how do you prove a student was cheating in such instances? After all, it was your decision to relinquish control of the student’s device, creating the opportunity for cheating in the first place.
Lastly — and this should be obvious for anyone still insisting on BYOD exams — you’ll want to ensure that students who weren’t recorded as being in the exam room at the time their answers were logged don’t end up with non-zero marks for the exam. This simply requires cross-checking the exam room roll against student submissions. You might be surprised by what you discover, but it will certainly reveal what some students think they can get away with.
Dr Ulrich Speidel is a senior lecturer in Computer Science at the University of Auckland with research interests in fundamental and applied problems in data communications, information theory, signal processing, information measurement and assessment integrity.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.