Phishpedia: a consistency-based phishing detector that names the brand it thinks you are impersonating

The problem Phishpedia targets: binary verdicts with no explanation

Reference-based phishing detectors, as the README describes them, tend to fail in three specific ways. They return a binary decision, legit or phish, with no indication of which brand was being imitated. They are biased toward their phishing training set, which the README frames as a distribution shift problem at test time. And the field lacked a large public benchmark. Phishpedia's answer is to stop classifying pages as phish or benign and instead check consistency between the page's domain and the brand its logo suggests. The output is a pair: a verdict and, when phishing is reported, the target brand. That brand is the visual explanation. The audience is therefore narrower than a general anti-phishing product: it is researchers reproducing a USENIX Security 2021 result, and engineers who want a logo-matching component they can read and modify. The README also notes the authors ran a monitoring system over emerging domains from CertStream and report discovering 1,704 real phishing pages, 1,133 of them zero-days not flagged by VirusTotal. That is a claim from the paper's authors, not something a reader can verify from the repository alone.

Two models in sequence: Faster R-CNN for logos, a Siamese network for brand identity

The pipeline takes a URL and a screenshot and produces Phish or Benign plus a phishing target. Step 1 runs a deep object detection model that predicts logos on the page. The README is explicit that the detector's other inputs are not used for the later prediction and exist only for explanation, so the logo boxes are the only thing carried forward. Step 2 feeds the detected logo into a deep Siamese model. If the Siamese model reports no target, the system returns Benign, None. If it reports a target, the system returns Phish and the phishing target. The repository layout matches this split: logo_recog.py holds the object detection model, logo_matching.py holds the Siamese model, and models/ contains rcnn_bet365.pth, faster_rcnn.yaml, resnetv2_rgb_new.pth.tar, a domain_map.pkl, and an expand_targetlist directory of per-brand folders such as Adobe and Amazon. The targetlist is where the 277-brand figure comes from; the README states the paper used 181 brands and this repository expands it to 277. The consistency idea is the interesting design choice. Because the model was not trained on a phishing dataset, the decision rests on whether the page's domain agrees with the brand the logo implies, not on a learned phish-or-not boundary.

Installing Phishpedia with Pixi and running the CLI on a test folder

The prerequisite is Pixi, and the README links to the Pixi installation page rather than vendoring it. On Linux or macOS the documented sequence clones the repository, installs the environment, and runs a setup script. The KMP_DUPLICATE_LIB_OK export appears in the README's own block, so keep it as written.

export KMP_DUPLICATE_LIB_OK=TRUE
git clone https://github.com/lindsey98/Phishpedia.git
cd Phishpedia
pixi install
chmod +x setup.sh
./setup.sh

Windows users get a PowerShell variant that skips the chmod and calls setup.bat instead of setup.sh.

git clone https://github.com/lindsey98/Phishpedia.git
cd Phishpedia
pixi install
setup.bat

Once the environment is in place, the main script is phishpedia.py and it takes a folder argument. The README's example points at ./datasets/test_sites.

pixi run python phishpedia.py --folder <folder you want to test e.g. ./datasets/test_sites>

That folder is not a flat list of images. Each site is its own directory containing info.txt with the URL and shot.png with the screenshot, and you should expect one verdict per site directory in the output.

Limitations: screenshots are your job, and the brand list is finite

The most consequential constraint is not stated as a limitation but falls out of the interface. Phishpedia consumes a URL and an existing screenshot. The repository contains no crawler in its top-level entries; the README mentions Scrapy only in the miscellaneous notes about the paper's experiments, not as part of the detection pipeline you install. If you have a list of domains and no screenshots, Phishpedia will not produce verdicts for you. The second constraint is coverage. Detection depends on matching a detected logo against the expand_targetlist folders, so a phishing page imitating a brand outside that set has no target to match and the Siamese step reports no target. The README does not describe what happens for pages with no logo at all, and it does not document a confidence threshold or a way to add brands beyond placing folders in expand_targetlist. The third is operational: there is no packaged service, no API, and no documented rollback path. The WEBtool directory and the Plugin_for_Chrome directory are pointers, and the README sends readers into those folders rather than describing their interfaces. Treat Phishpedia as a research artifact with a CLI, not a deployable sensor.

How Phishpedia differs from a classifier-based detector

The obvious alternative is a supervised classifier trained on labelled phishing pages, which is what the README says existing reference-based detectors do. The difference is where the decision boundary lives. A classifier learns a boundary from a phishing training set, so its errors track the composition of that set, which is the distribution shift the README names. Phishpedia never sees a phishing training set; it learns brand identity from legitimate brand logos through the Siamese model and then asks whether the page's domain is consistent with the brand it just identified. That reframing is why the output includes a brand name. It also changes the failure mode: a classifier fails by mislabelling a page, while Phishpedia fails by not recognising a logo or by not having the brand in its targetlist. The authors maintain a separate repository, PhishingBaseline, for the detection and identification baselines from the paper, which is the right place to look if you want to reproduce the comparison rather than run Phishpedia itself.

Maintenance, licence, and what upgrading costs you

The repository is not archived, and the last push was on 2026-06-05. There are no retrieved releases, so upgrades happen by pulling the main branch. That matters because the environment is pinned through pixi.toml and the model weights live as files in models/, including rcnn_bet365.pth and resnetv2_rgb_new.pth.tar. A pull that changes pixi.toml means re-running pixi install, and the setup scripts exist precisely because there is more to prepare than the Python environment. The licence is CC0-1.0, which the repository states in its LICENSE file. CC0 is a public domain dedication rather than a permissive software licence with attribution conditions, so the practical question for adopters is not attribution but whether your organisation's policy accepts a public domain dedication for code you redistribute or embed. That is a question for your own legal review; the repository does not discuss it, and the README's citation request is a scholarly courtesy, not a licence term.

Editorial conclusion

Phishpedia fits research groups and security teams that need an explainable, logo-based verdict and can supply their own screenshots, because the repository does not crawl pages for you. Teams wanting a drop-in production filter should look elsewhere: the pipeline expects a folder of site directories with info.txt and shot.png, and the README does not document rollback or a hosted API. Before adopting it, run the CLI against ./datasets/test_sites, confirm the 277-brand targetlist covers your brands, and check the CC0-1.0 LICENSE file against your own redistribution plans.

Frequently asked questions

Official sources

1. Issues
2. License: CC0-1.0
3. lindsey98/Phishpedia on GitHub
4. README