PhishKill

The problem

Most phishing filters work from rules: blocklists, keyword matches, known-bad domains. Phishing emails get past them by changing their wording, and the tricks they rely on (urgency, a fake authority, a plausible-looking link) are about meaning, not keywords. My final-year project in Computer Science asked whether a language model could read an email and say why it looks like phishing, next to a few checkable facts such as the headers and the links, in one tool.

It was graded and presented to a panel, and my lecturers and the panel received it well.

What it does

You register, log in and paste in a suspicious email or its raw headers. The app then:

• Scores the email body. It returns a risk score from 0 to 100, the indicators behind it (urgency language, a mismatched sender and so on) and plain safety tips. It also pulls every URL out of the text.
• Reads headers. It parses raw headers with Python's email library (sender, reply-to, return path, the chain of Received hops, and the Authentication-Results line) and asks the model to flag spoofing and odd routing. The model does the judging. The app doesn't run SPF, DKIM or DMARC checks itself.
• Looks up links. The link check searches urlscan.io for earlier scans of that URL and reports whether there's history, with a link to it. It doesn't decide whether a link is malicious.
• Keeps a history. Each analysis is saved per user, shown in a log and on a trend chart, and can be exported as a PDF or Markdown report.
• Runs without API keys. A simulation mode returns canned results so the whole interface can be shown offline.

It runs locally; there's no live deployment.

What I wrote and what I directed

I wrote the original prototype: the Python script that sends an email to a model and gets back a risk score and indicators, including the first AI integration, with OpenAI, and the Flask app around it with the classify and history endpoints and the SQLite store. Coding agents then extended it to multiple providers under my direction. They also built the rest of the application under my direction: the fallback between providers, header analysis, the link lookup, accounts and sessions, the PDF and Markdown reports, the analytics charts, the Spanish interface and rate limiting. I set what each part had to do and tested the result as a whole.

The project began in December 2025 as an earlier iteration, a phishing-simulation app in a private repo, and PhishKill grew out of it.

Decisions worth mentioning

• One interface over three providers. The AI layer talks to Groq (Llama 3), OpenAI and Gemini behind the same two methods, one for email bodies and one for headers. It asks each for a strict JSON object, tries the next provider if one fails, and records which provider answered. Groq and Gemini each try a short list of model names in turn.
• A failed or malformed reply falls through. Each provider's reply is parsed as JSON, and any error becomes a provider failure that moves on to the next one instead of crashing the request.
• Facts next to the model's opinion. The model's score is a judgement, so the interface puts checkable evidence beside it: the links extracted from the email, the parsed header fields, and the urlscan.io history.
• Per-user data. Every query that reads or deletes a saved analysis is scoped to the logged-in user's id, so one account can't read or remove another's history. The analysis endpoints are rate-limited per IP to protect the API credits.
• Testing on real emails. Besides the automated tests, I ran it against real emails to see how it behaved. I didn't measure an accuracy figure and won't claim one.

Outcome

It was submitted as my final-year project and presented to a panel. The source is public on GitHub.