PhishGuard: Phishing-Awareness Simulator & Mail-Header Analyser for a College (PHP/MySQL)

PhishGuard is a defensive security-awareness web application built for a fictional 1,200-student arts and science college in Karnataka. It lets the college run consent-based phishing simulations on a closed lab network and gives students a safe place to practise spotting and reporting fake mails.

The faculty coordinator (Admin) picks a scenario from a template library modelled on scam patterns actually reported across India — fake scholarship mails, "your KYC has expired" bank warnings, fee-refund hooks, UPI cashback offers and authority-impersonation threats. The campaign engine (PHPMailer + a local MailHog SMTP sink) delivers the synthetic mail only to students who opted in, and nothing can leave the lab network. When a volunteer clicks, they land on a teachable moment page that explains the red flags they missed — the system never collects credentials; only the click itself is recorded.

A second module, the mail-header analyser, lets a student upload or paste the headers of any suspicious mail and get a plain-language verdict: the Python module parses the Received chain, reads SPF/DKIM/DMARC authentication results, flags lookalike domains and shortened URLs, and explains its reasoning.

Dashboards show delivery, open, click and report rates, a per-department awareness score, and improvement across successive campaigns — exportable to CSV for Power BI. The stack is PHP 8, MySQL, JavaScript and Python, exactly the languages the BCU SEP 2024 BCA syllabus teaches; MailHog and PHPMailer are industry-standard open-source extras, acknowledged in the report.

Students at a typical Indian college receive scholarship offers, fee-payment reminders, "KYC expiry" warnings and internship mails daily, and scammers actively target them — India's I4C recorded thousands of impersonation and phishing-linked fraud cases each month in 2024–25. The college's only defence is an annual lecture, which changes knowledge but not clicking behaviour, and there is no safe, consent-based way for students to practise resisting a realistic lure or reporting one. The administration has no baseline measurement of susceptibility, no way to know which departments are most exposed, and no tool a student can use to check whether a suspicious mail's headers show failed SPF/DKIM/DMARC authentication or a lookalike domain. There is a need for a closed, ethics-first simulation and analysis platform that trains through experience, measures improvement, and never puts a real credential or a real outsider at risk.

Abstract

Phishing remains the most common way intruders get a foothold, and in India the human target is the target: India's cyber-crime coordination centre (I4C) reported roughly ₹1,935 crore lost to "digital arrest" impersonation scams in 2024, while the RBI's Be(A)ware booklet and CERT-In's advisories keep warning that fake KYC updates, scholarship offers and UPI collect-request tricks are the everyday lures. College students are prime targets — scholarship mails, fee-payment notices and internship offers land in inboxes that have never been trained to distrust them.

Introduction

Nandanavanam Degree College (fictional) teaches cyber-hygiene as a one-hour lecture once a year. A lecture changes knowledge, not behaviour: nobody clicks in the classroom, so nobody learns what falling for a lure actually feels like, and nobody practises the report button. Security research worldwide agrees that measured, repeated simulation plus immediate coaching is what moves click rates down and report rates up.

Existing System

• Awareness is delivered as annual lectures and posters; there is no practice and no measurement.
• Real scam mails forwarded on WhatsApp are the only "examples" students see — after the harm is done.
• The college has no baseline: it cannot say what fraction of students would click a convincing fake mail today, let alone whether the number improved.
• Students who receive a genuinely suspicious mail have nowhere to check it: no tool to read SPF/DKIM/DMARC results or spot a lookalike domain.
• Limitations: no consent framework, no safe environment, no feedback loop, no data.

Proposed System

• A web portal (PHP 8/MySQL) with three roles — Coordinator (Admin), Volunteer, Viewer — and bcrypt-hashed logins.
• A template library of 12 synthetic phishing scenarios based on documented Indian scam patterns, each tagged with its red flags.
• A campaign engine that sends simulated mails only to opted-in volunteers through a local MailHog SMTP sink bound to 127.0.0.1 — delivery outside the lab is structurally impossible.
• A teachable-moment landing page on click, and a one-click Report Phishing action; only anonymous events are stored, never credentials.
• A Python header analyser for .eml files: Received-chain parse, SPF/DKIM/DMARC verdicts (RFC 7208/7489), lookalike-domain and URL-shortener checks, with an explained risk verdict.
• Per-department awareness scores, campaign-over-campaign comparison and CSV export for Power BI.

Feasibility Study

• Technical: The LAMP stack is taught in the syllabus (24BCA51 Web Programming, DBMS with MySQL). MailHog captures all mail locally, so no external mail server is ever involved. The analyser is a standalone Python CLI — no extra services needed.
• Economic: Everything is open-source; ₹0 licence cost, runs on one lab PC.
• Operational & ethical: Volunteers sign a consent form, can opt out at any time, and results are anonymised by department. The design follows the data-minimisation spirit of the DPDP Act, 2023, and CERT-In's advice that awareness training is a core control.

In scope

• One fictional college, one lab-network deployment, three user roles.
• Volunteers who opt in via a signed consent form (and can opt out at any time); results anonymised to department level.
• 12 synthetic templates; campaigns scheduled and sent by the Coordinator only.
• Tracking of delivery / open / click / report events inside the closed network.
• Mail-header analyser for pasted or uploaded .eml files (RFC 7208 SPF, RFC 7489 DMARC verdicts, lookalike-domain checks).
• Micro-lessons, quizzes, awareness dashboard, CSV export.

Out of scope (v1)

• Sending anything outside the college lab network — the SMTP sink is local-only by design.
• Integration with the college's production mail server or a mail-gateway plug-in.
• Credential capture of any kind, even fake ones.
• Mobile apps, WhatsApp/SMS simulation channels, and real-time inbound-mail filtering.
• Code-generated attack templates — all templates are hand-written and reviewed by the coordinator.

The project follows the Incremental SDLC model: each increment delivers a working slice (portal → campaign engine → analyser → analytics), which is demoed to the guide and refined in the next cycle — a good fit for the 12-week BCU Sem-5 project window and its three internal reviews.

Team split: Member 1 — portal, roles and campaign engine; Member 2 — tracking, teachable-moment flow and Python analyser; Member 3 — analytics dashboard, quiz module, testing and documentation.

Testing approach: unit tests for the analyser's verdict logic and the awareness-score formula; integration tests that a campaign produces exactly one mail per opted-in volunteer inside MailHog; black-box test cases per screen; and a supervised pilot whose data becomes the project's results chapter.

PhishGuard is a three-tier application plus a small offline analysis tool:

1. Presentation tier — server-rendered PHP 8 pages styled with HTML5/CSS3; Chart.js (industry-standard open-source) draws the dashboard charts; works on lab desktops and phones.
2. Application tier — Apache + PHP implements business rules: RBAC checks on every page, campaign scheduling, event recording, score computation. All input is validated server-side; all SQL uses prepared statements.
3. Data tier — MySQL 8 stores users, consent records, templates, campaigns, events, lessons and reports.
4. Mail path — PHPMailer hands messages to MailHog, a local SMTP sink bound to 127.0.0.1:1025. MailHog holds every message in memory and exposes a web inbox — no DNS, no relay, no exit to the internet.
5. Analyser — a Python 3 CLI (analyser/analyse.py sample.eml) that parses headers, reads authentication results, and writes a report row back to MySQL.

flowchart LR
  C["Coordinator browser"] -->|"HTTP on lab LAN"| AP["Apache + PHP 8 application"]
  V["Volunteer browser"] --> AP
  AP --> AU["Auth & RBAC (bcrypt, prepared statements)"]
  AU --> DB[("MySQL 8")]
  AP --> CE["Campaign engine"]
  CE --> MH["MailHog SMTP sink<br/>127.0.0.1:1025 — local only"]
  MH --> TM["Teachable-moment landing page"]
  TM -->|"click / report events"| DB
  AP --> AN["Python header analyser CLI"]
  AN --> DB
  AP --> DASH["Dashboard + CSV export"]

ER diagram

erDiagram
  USER ||--o| VOLUNTEER : "extends"
  USER ||--o{ CAMPAIGN : "creates"
  TEMPLATE ||--o{ CAMPAIGN : "is used by"
  CAMPAIGN ||--o{ MAIL_EVENT : "produces"
  VOLUNTEER ||--o{ MAIL_EVENT : "triggers"
  USER ||--o{ ANALYSIS_REPORT : "saves"
  LESSON ||--o{ QUIZ_ATTEMPT : "is assessed by"
  VOLUNTEER ||--o{ QUIZ_ATTEMPT : "makes"

  USER {
    int id PK
    string email UK
    string passwordHash
    string role
  }
  VOLUNTEER {
    int id PK
    int userId FK
    bool consentGiven
    string department
  }
  TEMPLATE {
    int id PK
    string scenario
    string redFlags
    string subjectLine
  }
  CAMPAIGN {
    int id PK
    int templateId FK
    datetime scheduledAt
    string status
  }
  MAIL_EVENT {
    int id PK
    int campaignId FK
    int volunteerId FK
    string eventType
    datetime occurredAt
  }
  ANALYSIS_REPORT {
    int id PK
    int userId FK
    string spfResult
    string dkimResult
    string dmarcResult
    string verdict
  }
  LESSON {
    int id PK
    string title
    string bodyMarkdown
  }
  QUIZ_ATTEMPT {
    int id PK
    int lessonId FK
    int volunteerId FK
    int scoreOutOf10
  }

DFD — Level 0 (context diagram)

flowchart LR
  C(["Coordinator"]) -- "template, campaign schedule" --> SYS(("PhishGuard"))
  SYS -- "click rate, report rate, awareness scores" --> C
  V(["Volunteer"]) -- "consent, report click, quiz answers" --> SYS
  SYS -- "simulated mail, lesson, quiz" --> V
  E(["Viewer: HOD / Principal"]) -- "read-only request" --> SYS
  SYS -- "anonymised dashboard" --> E

The awareness score per department is 100 × (reports + 0.5 × no-click-no-report) / delivered, computed in SQL and cached on the dashboard; the analyser's risk verdict is Low / Medium / High based on weighted findings (authentication failures, lookalike distance ≤ 2 from a known domain, shortened URLs, risky attachment extensions).

• Domain health report for the college's own domain: scheduled SPF/DKIM/DMARC lookups that flag misconfigurations an attacker could exploit.
• WhatsApp-forward checker: paste a forwarded message and get a checklist verdict against known scam patterns.
• Kannada and Hindi template variants to measure awareness across language backgrounds.
• Gamified leaderboard (department-level, anonymised) to sustain participation across semesters.
• A lightweight classifier trained on labelled header features (authentication results, link reputation, domain heuristics) to suggest verdicts for mails the rule engine is unsure about.
• Inbound-gateway mode: an optional plug-in that scores real incoming mail with the same analyser rules, running strictly inside the college network.