Higher Education / IoT Security Research

Threats & Attacks on an IoT-Based Smart Campus System

Independent Research — Qarshi University, Lahore

Penetration TestingIoT Security AssessmentThreat Modeling

The challenge

Smart campuses connect parking, libraries, ID cards, attendance and exams onto one IoT network — a single flat attack surface if nothing authenticates who's actually on it. This project set out to design that architecture, then attack it, to find out exactly how far a single compromised device could reach.

What we did

  • Designed a smart-campus IoT architecture (Raspberry Pi + Arduino sensor nodes) covering parking, library, ID card, attendance, exams and timetable systems.
  • Modelled the threat surface against a six-layer security framework: physical, network, data, service, application and management.
  • Built and executed a full on-path attack chain inside an isolated academic lab: ARP spoofing → traffic interception → DNS spoofing → content substitution → script injection → HTTPS downgrade.

Result

  • Demonstrated that a single compromised device is enough to pivot into an entire smart-campus network segment.
  • Identified unauthenticated ARP and DNS resolution — not the sensors or cloud backend — as the true root-cause layer.
  • Produced a full threat-and-mitigation matrix mapping every attack type to a concrete countermeasure.

Read the report

Flip through the summary below, or request the full write-up — methodology, the complete six-layer analysis and the technical walkthrough of every attack stage.

FIELD REPORT // IOT SECURITY

Threats & Attacks on an IoT-Based Smart Campus System

How a university campus becomes an attack surface — and what a full on-path compromise chain looks like from the inside.

Independent research · Qarshi University, Lahore · BS Computer Science final year project

Executive Summary

Smart campuses connect parking, libraries, ID cards, attendance, exams and building systems onto one IoT network — convenient for students and staff, and a single flat attack surface for anyone who gets a foothold on it.

This project designed a smart-campus IoT architecture (Raspberry Pi and Arduino sensor nodes reporting to a cloud/local backend) and then, entirely inside an isolated academic lab, built and executed a full on-path attack chain against it — from network reconnaissance through to spoofing traffic and injecting content into live sessions.

The goal wasn't to build an exploit for its own sake. It was to show, concretely, why “we're on a closed campus network so it's fine” is not a security model.

What Was Built

The target: a working smart-campus IoT design covering the modules students actually touch every day.

  • Smart parking — IR sensors + camera-based lot detection and guidance
  • Smart library & canteen — requests served through a phone app talking to the backend
  • Smart ID card — access control, payments and attendance tied to one credential
  • Smart attendance — RFID-based check-in replacing manual roll calls
  • Smart examination monitoring — per-question timing telemetry sent to a web app
  • Smart timetable — live scheduling data pushed to every connected device

Six-Layer Security Model

The threat model behind campus-cloud IoT deployments, layer by layer.

  • Physical security — site, equipment and transmission-medium hardening
  • Network security — topology, segmentation, load balancing and intrusion detection
  • Data security — access control, encryption, isolation and backup/restore
  • Service security — identification, authentication and availability under load
  • Application security — AAA (authentication, authorization, accounting) and traceable access
  • Management security — audit trails and administrative accountability

Threat & Attack Matrix

A condensed view of the classification used to score every attack in this study.

Passive eavesdroppingLow

Silent traffic analysis, no alteration

Man-in-the-middleLow–Medium

Alters or steals unencrypted data in transit

Data gatheringMedium–High

Skimming, tampering across wired/wireless links

Active tamperingHigh

Alters integrity, blocks or re-routes messages

Imitation / spoofingHigh

Impersonates a trusted device to steal data or spread malware

Privacy disclosureHigh

Exposes sensitive individual or group information

InterruptionHigh

Takes availability away from authorized users

Blocking / DoSExtremely High

Jamming, flooding, malware saturating the network

FabricationExtremely High

Injects false data, breaking authenticity outright

The Attack Chain — What Was Actually Executed

Seven stages, each building on the last, run end-to-end against the lab environment.

  • 1. Reconnaissance — mapped every device on the local segment
  • 2. ARP spoofing — poisoned the gateway’s ARP cache to sit on-path between clients and the network
  • 3. Traffic interception — sniffed the redirected traffic for credentials and session data
  • 4. DNS spoofing — redirected specific hostnames (e.g. the smart-library portal) to an attacker-controlled host
  • 5. Content substitution — swapped a real timetable or result file for a forged one served through the poisoned DNS entry
  • 6. Script injection — pushed arbitrary JavaScript into an intercepted session (cookie theft, fake alerts, a foothold for further control)
  • 7. HTTPS downgrade — used an SSL-stripping proxy to force secure pages back to plaintext before repeating the steps above

Key Findings

  • A single compromised device on a large campus network is enough to pivot into the entire smart-campus segment — attackers don’t need to breach every machine, just one weak link.
  • None of the seven techniques required specialised hardware — commodity tools were sufficient to execute the full chain.
  • The weakest layer wasn’t the sensors or the cloud backend — it was unauthenticated ARP and DNS resolution at the network layer, underneath all of it.
  • Services trusting a plain IP address rather than an authenticated identity turned out to be the recurring root cause across almost every attack in the chain.

Recommendations

  • Dynamic ARP Inspection or static ARP entries on campus switches to shut down ARP spoofing at the source
  • DNSSEC and DNS-over-TLS for internal resolution, so a poisoned cache can’t silently redirect students to a fake portal
  • Mutual TLS between IoT sensor nodes and the backend, not plain HTTP
  • HSTS with preload site-wide, so an SSL-stripping proxy has nothing left to downgrade
  • Network segmentation — IoT sensor VLANs isolated from the student-facing app network
  • Signed, authenticated updates for anything served to end-user devices, so content-substitution attacks fail integrity checks

Read the Full Report

Every technique above was built and tested exclusively inside a controlled academic lab. The attack scripts are not for use against live systems — campus or otherwise — and doing so is illegal under Pakistan’s cyber law and everywhere else.

The full report includes the complete methodology, the six-layer security analysis in detail, and the technical walkthrough of every attack stage.

Page 1 / 9

// access request

Get the full report

Threats & Attacks on an IoT-Based Smart Campus System — tell us a little about why you'd like it, and we'll unlock the download.

Want results like these?

Book a free consultation and let's talk through your setup.

Book a free consultation Email us