PhishingSimulatorTool
Final Year Project · SETU · April 2026

A phishing simulation platform designed to train, not to catch.

A Django-based tool that lets researchers and security teams run realistic phishing campaigns in controlled, ethical environments — then immediately teaches participants what they missed.

Author Stephen Foley
Degree BSc (Hons) Cybercrime & Cybersecurity
Institution South East Technological University
Licence GNU GPL v3.0
01 · What it does

End-to-end phishing campaigns, with training built into every click.

The platform runs the full lifecycle of a phishing awareness exercise from one place — template design, target management, scheduled delivery, live behaviour tracking, risk profiling, and immediate post-click training.

Campaigns can pair any of five realistic cloned login pages (Google, Microsoft 365, DocuSign, OneDrive, IT Helpdesk) with customisable HTML email templates that support variable substitution, sender spoofing, and randomised send windows. DocuSign even routes to a fake Microsoft sign-in via a federated flow that preserves the tracking session across pages.

Every click is captured with device, OS, and browser detection. A risk score from 0–100 is calculated per participant, weighted across click behaviour, time-to-click, scenario difficulty, and positive reporting behaviour — the latter reduces a participant’s score, because the tool rewards people who spot the phish.

Ethics-first design

Every participant is assigned a permanent anonymous identifier (P-XXXXX) — no name, email, or PII ever appears in the dashboard. Informed consent and consent-withdrawal flows are built into the tool itself. No submitted credential is ever persisted to disk; only the fact of submission is recorded. Post-submission training is automatic and immediate.

02 · Features

Fifteen database models, one cohesive platform.

A quick survey of what’s inside:

01

Campaign engine

Create, schedule, and launch phishing campaigns with Celery-backed randomised send windows (up to four hours) to avoid obvious batch patterns.

02

Five cloned landing pages

Google, Microsoft 365, DocuSign, OneDrive and IT Helpdesk — each with authentic two-stage flows matching real 2026 provider designs.

03

Federated sign-in

DocuSign offers “Continue with Microsoft” and hands the target off to a fake Microsoft login while preserving the same tracking session.

04

Full tracking pipeline

Open via 1×1 pixel, click with device/OS/browser detection, form capture, and training completion — every event logged.

05

Risk scoring (0–100)

Weighted algorithm: click behaviour 50%, time-to-click 15%, scenario difficulty 15%, positive reporting 20% (reduces risk).

06

Anonymous participants

Every target gets a permanent P-XXXXX identifier. No PII visible anywhere in the researcher dashboard or admin panel.

07

Informed consent

Consent form, confirmation page, and consent-withdrawal flow built into the tool — designed to support GDPR requirements.

08

Instant training

Submit credentials and you’re immediately redirected to scenario-specific training highlighting the red flags you missed.

09

QR code campaigns

Auto-generated QR codes with device-specific redirects — different URLs for mobile and desktop scanners.

10

Analytics dashboard

Live event feed, risk distribution charts, campaign funnels (sent → opened → clicked → submitted → trained).

11

CSV import & export

Bulk target import with group assignment, and CSV export of campaign results and risk reports for researchers.

12

65 automated tests

Coverage across models, utilities, tracking views, landing-page routing, federated flow, and CSV import.

03 · By the numbers

Scope at a glance.

15
Database models
driving the platform
5
Cloned login pages
built from scratch
65
Automated tests
across 15 test classes
9
Event types tracked
in the audit log
0
Credentials
ever stored
04 · The platform

How it looks.

Real screenshots of the platform.

PhishingSimulatorTool researcher dashboard with funnels and risk charts
Dashboard — campaign funnels, risk distribution, live event feed.
Cloned DocuSign landing page with Continue with Microsoft option
Fake DocuSign landing page — cloned to match the real 2026 design, with federated Microsoft sign-in.
Post-submission training page showing red flags for the scenario
Post-submission training — scenario-specific red flags, shown immediately after any simulated credential submission.
Informed consent flow with GDPR-aware messaging
Informed consent flow — built into the tool, GDPR-aware, with a one-click withdrawal path.
Per-campaign analytics view with funnel and risk stats
Per-campaign analytics — the full funnel from sent through trained, broken down by anonymous participant ID.
Anonymised target list showing P-XXXXX codes and departments only
Anonymised target list — only P-XXXXX codes and departments shown, never names or emails.
05 · Built with

A deliberately boring stack, used deliberately.

No exotic dependencies, no framework-of-the-month. The technology choices are conservative on purpose — a final-year project is a place to demonstrate depth on mainstream tooling, not to chase novelty.

Backend

Django 6.0.1 Django REST Framework 3.16.1 PostgreSQL 15 Celery 5.6.2 Redis 7 WhiteNoise Gunicorn

Frontend & tooling

Django templates Bootstrap 5 Chart.js BeautifulSoup 4 qrcode user-agents Docker & Compose pytest Sphinx
06 · What I learned

The parts that taught me something.

Five things I now know because I built this project, and wouldn’t know in the same detail otherwise.

Django · security

Production security middleware can break your tests silently.

The first time I ran the full test suite, every HTTP test failed. SECURE_SSL_REDIRECT=True was silently redirecting the test client to HTTPS, stripping POST bodies. The fix — a dedicated test_settings.py module — taught me that test environments need carefully controlled configuration that’s independent of production.

JavaScript · DOM

Capture-phase event listeners are a surgical tool.

The injection script that turns cloned HTML into live phishing pages relies on stopImmediatePropagation() at the capture phase to intercept form submissions before the page’s own JS sees them. Making the two-stage login flow work required understanding that <button> and <a> tags behave completely differently under event interception.

Ethics · design

Privacy isn’t a feature you bolt on.

The anonymous P-XXXXX identifier system, the consent flows, the decision to never persist submitted credentials, the automatic training redirect — these all came out of thinking about the ethics before writing the code. Retrofitting any of them later would have meant schema migrations and rewrites.

Distributed systems

Celery’s Linux-first assumptions bite on Windows.

The prefork process pool doesn’t exist on Windows at all. The fix is a single flag (-P solo), but discovering it meant reading through Celery’s source to understand what wasn’t being loaded. The randomised send-time feature on top of that taught me about distributed task queues, message brokers, and persistent beat scheduling.

Full-stack

A real project lives across the whole stack.

Relational modelling with Django ORM, REST API design with DRF, server-side templating, client-side JavaScript injection, HTML and CSS for five cloned sites, MIME multipart emails with inline QR images, Docker containerisation. No individual piece was hard; making all of them work together was the work.

07 · Real-world test

I ran it on actual people. Carefully.

A small controlled test with consenting participants, using the DocuSign scenario with the federated Microsoft sign-in flow.

Most participants recognised the email as phishing and didn’t click. One clicked out of curiosity but backed out before submitting; one went all the way through and saw the training page immediately. The full end-to-end pipeline — pixel tracking, click capture, session handover to the Microsoft page, form submission, risk scoring, automatic training redirect — worked under real user sessions, not just Django’s test client.

The sample is far too small to draw behavioural conclusions from. That wasn’t the point. The test was there to verify that the platform holds up outside an automated test harness, and to check that the ethical design decisions — instant disclosure, no stored credentials, anonymous identifiers — actually worked the way they were supposed to when a real person got caught. They did.