Phishing detector

New module · brand protection

The Phishing detector protects the bank’s brands (and its merchants) from phishing clones: fake websites, mobile apps and social media accounts. The flow: protected asset → clone detection → threat ticket with evidence → takedown.

Protected assets

Phishing detector → Protected assets is the register of what we protect: the official website, mobile app or social/messenger account. An asset has a status (active / paused) — paused assets are not monitored.

For a web asset the system stores a fingerprint of the official site (favicon, page structure, colour palette, brand keywords, forms) — suspicious pages are compared against it. Fingerprints are versioned: history is never overwritten.

Canary

The fastest way to catch a live clone is the canary snippet: a small piece of JavaScript embedded on the official website (available on the asset page). If the page is copied and hosted on another domain, the snippet reports the clone’s address by itself — a threat ticket appears in the officer’s queue the moment the first victim opens the fake. It works on any domain and even over plain HTTP.

Repeated beacons for the same address do not multiply tickets — the detection counter is incremented instead. A daily cap of new tickets per asset protects against junk floods.

Canary for a mobile app

For mobile assets the canary catches repackaged clones — when the bank’s real APK is decompiled, injected with malicious code and distributed re-signed. The asset page offers two levels (hand them to the bank’s mobile team):

1. Self-check + beacon — a code snippet for the official app: at startup it compares its own credentials against the release ones and, on a mismatch (repackaging/resign), sends a beacon, so a threat ticket appears the moment the clone first starts on a victim’s device. The official build never sends a beacon. The snippet becomes available once the asset’s mobile fingerprint is captured; the platform is chosen from it:
   • Android — a Kotlin snippet comparing the package and APK signature SHA-256 (credentials are filled from the fingerprint automatically).
   • iOS — a Swift snippet comparing bundle ID and Apple Team ID via code-signing. Apple does not expose the Team ID publicly, so the officer enters it manually (“Set Team ID”) on top of the auto-captured bundle ID — until then the iOS canary is unavailable. It catches resigned clones; App Store fakes are covered by store monitoring.
2. Honeytoken — a “dead” configuration URL placed into the APK resources and never requested by the app’s code. The real app stays silent, while sandboxes, analysers and clone builders fetch every URL found in the resources — so a hit creates a ticket already at the APK teardown stage, before any clone appears. All hits collapse into a single ticket for the asset with a detection counter.

Limits of the method: the canary is powerless against lookalike fakes written from scratch (they contain no bank code) — those are covered by automatic store monitoring (see “App clones” below). A self-check can be stripped out during decompilation, so we recommend duplicating it in several places in the code; an unremovable level of protection (server-side Play Integrity / App Attest attestation) is discussed with the bank separately.

Threat tickets

Phishing detector → Threat tickets is the queue of detected threats. A ticket is created automatically (canary, auto-monitors) or manually by an officer — e.g. from a customer complaint. Duplicates for the same address collapse into a single ticket with a detection counter.

Lifecycle: Monitoring → “Start work” → In progress → “Blocked” → Blocked. From any open status a ticket can be closed as a False positive — such a threat acts as a whitelist entry and never returns to the queue (repeated detections only accumulate in the counter). A closed ticket can be reopened.

The navigation badge shows the number of open tickets.

Evidence

Immutable evidence is attached to the ticket: a screenshot of the clone page, an HTML snapshot and a geo-cloaking flag (the clone serves different content by geography). Evidence is append-only — each snapshot is tied to the moment of detection and can be neither changed nor deleted: the legal basis for complaints to registrars and regulators.

Takedown

From the ticket page the officer files a takedown request — a complaint against the phishing resource:

1. Choose the recipient: the domain registrar, the hosting provider or a platform (Google Play, App Store, a social network — for fake apps and accounts).
2. The “Find abuse contact” button fills the email from RDAP (domain and IP registries). For platforms there is a directory with addresses and step-by-step instructions.
3. The letter is generated from a template (threat details and evidence are inserted automatically) — it can be edited and opened in the mail client.
4. The request is recorded on the ticket with a response status: Pending → Acknowledged → Actioned / Rejected.

Automatic monitors

Beyond the canary and manual registration, the system hunts for clones on the scanner side:

• Lookalike domains — generates typos and permutations of the brand domain (dropped and swapped letters, keyboard substitutions, IDN homoglyphs, other TLDs), cross-checks them against issued-certificate logs and raises a ticket for registered domains.
• Website clones — compares suspicious pages against the official site’s fingerprint (favicon, brand keywords, palette) and, above the threshold, creates a ticket with evidence.
• App clones — searches Google Play and the App Store for apps carrying the brand and compares icon and name against the reference.

In development: detection of visually altered clones via embeddings, and monitoring of fake accounts on social networks and messengers.