Phishing Kit Fingerprinting: Finding 16Shop and xBalti Variants Before They Phish

A phishing domain is infrastructure. A phishing kit is the weapon. Takedown teams that focus only on domains are dismantling infrastructure one piece at a time while the same weapon gets redeployed on a new domain within hours. Understanding phishing kits — how they're structured, how they're fingerprinted, and what their presence tells you about attacker intent and identity — changes the economics of brand protection work significantly.

This article covers the technical mechanics of kit fingerprinting: how static file signatures, DOM structure hashes, and referrer-based bot-blocking patterns combine to give reliable kit identification across novel domains, and what you can do with that attribution once you have it.

What a Phishing Kit Actually Is

A phishing kit is a packaged HTML/PHP/JavaScript bundle — typically distributed as a ZIP archive — that an attacker deploys to a web server to create a convincing clone of a legitimate brand's login page or payment flow. Kits are reusable by design. A kit author creates the package once, tests it against a target brand, and sells it to multiple buyers on underground forums or through Telegram channels.

The major named kits that appear consistently in brand-protection telemetry include:

• 16Shop: One of the most widely distributed phishing-as-a-service kits, historically targeting Apple, Amazon, PayPal, and financial services. Characterized by a modular PHP structure, a prominent antibot PHP script (often named antibot.php or block.php), and harvested credentials exfiltrated via email or Telegram bot. Multiple generations (v2, v3, v4) have been identified by researchers, each incrementally improving evasion of screenshot-based detection.
• xBalti: Primarily targets Gulf-region banking and financial services brands. Characterized by Arabic-language content, mobile-first layout optimized for Saudi and UAE banking portal aesthetics, and credential exfiltration via a Telegram bot C2 using a hardcoded bot token pattern.
• Frankenstein (also called "kit-stitcher" class): Not a single kit but a class of kits assembled by combining components from multiple source kits — login page HTML from one kit, credential handling PHP from another, antibot from a third. These are harder to fingerprint via static hash but still leave structural patterns in the DOM and PHP include hierarchy.

Static File Signature Fingerprinting

The most reliable fingerprinting method for known kits is static file signature matching. Kit authors are creatures of habit: they name their files consistently (index.php, login.php, verify.php, step2.php), use consistent directory structures (/images/, /css/, /js/, /panel/), and often leave the same copyright comments, charset declarations, and JavaScript variable names across deployments.

Consider the 16Shop kit's antibot script: its core logic checks the visitor's user-agent, IP ASN, and HTTP Accept-Language header against a blocklist, returning a 403 or redirect for known bot ASNs (Google, Cloudflare, security vendors). Across hundreds of documented 16Shop deployments, this script follows a highly consistent structure — the same PHP function names, the same conditional flow, the same blocklist format. Computing an MD5 or SHA-256 hash of the normalized script (whitespace-stripped, comments removed) produces a fingerprint that matches across deployments even when the attacker has renamed the file.

For a concrete synthetic example: in mid-2024, a financial services brand monitoring campaign detected a domain securepay-verify[.]net via CT log monitoring. Standard keyword scoring flagged it as high-risk. Automated HTTP crawling retrieved the page content. File hash matching against the kit signature library returned a match against the 16Shop v3 apple-themed variant — specifically the normalized hash of the PHP antibot wrapper and the hardcoded credential email destination pattern. That single match told us: this isn't a one-off attacker building a custom page. It's a kit deployment, meaning other domains running the same kit likely exist, and the attacker has used this kit before — check historical detections for the same hash cluster.

DOM Structure Hashing

When a kit is modified enough that static file hashes no longer match — attacker renaming files, adding obfuscation layers, swapping out images — DOM structure hashing provides a secondary fingerprinting layer. Rather than hashing the raw HTML, you parse the document into a DOM tree and hash a normalized structural representation: tag names, attribute names (without values), child ordering, and nesting depth.

The result is a structural fingerprint that is invariant to changes in text content, image URLs, and CSS class names, while remaining sensitive to changes in the fundamental page architecture. Two pages that look visually identical and share the same DOM structure will produce the same structural hash even if every text string on the page has been changed. This catches kit variants where the author has replaced the target brand's login form text but kept the underlying form structure, input field IDs, and PHP submission path intact.

We're not saying DOM structure hashing is a complete substitute for static file matching. For highly customized kits, an attacker who understands structural fingerprinting can defeat it by adding or removing form fields, changing nesting depth, or inserting meaningless wrapper divs. The technique is a layer in a signature stack, not a standalone solution. Its value is in reducing the analyst review queue for medium-confidence matches that don't hit a static hash but exhibit structural kinship with known-bad pages.

Referrer Pattern and Bot-Blocking Detection

Kit deployments almost universally implement some form of antibot protection — the attacker's incentive to avoid having their infrastructure scanned by security vendors or included in threat intel feeds. The antibot implementation itself becomes a fingerprint. The behavioral pattern of how a server responds to an automated HTTP GET with a generic user-agent versus a spoofed mobile browser user-agent versus a request with a known threat intel vendor IP is a characteristic of the kit's antibot implementation.

The 16Shop antibot, for example, returns HTTP 302 redirects to the legitimate brand's real website when it detects a bot user-agent — maintaining plausible deniability while blocking analysis. Other kits return 403 for bot ASNs but 200 for residential IP ranges. Mapping the response pattern matrix (response code × user-agent × source ASN) produces a behavioral signature that is kit-specific even when all static content has been modified.

This technique is particularly valuable for detecting phishing pages that have not yet been fully deployed — pages that return the legitimate brand's visual design to authenticated scanners but redirect to a credential harvesting page for victims visiting from mobile residential IPs. If your kit fingerprinting relies only on static content analysis, these conditional deployments will appear to be benign redirects to the legitimate brand's domain.

Telegram Bot C2 Attribution

A significant fraction of modern phishing kits — particularly xBalti and similar regional variants — exfiltrate harvested credentials via Telegram bot API rather than email or PHP-based logging. The kit contains a hardcoded Telegram bot token and chat ID. When a victim submits credentials, the kit makes a server-side POST to https://api.telegram.org/bot{TOKEN}/sendMessage with the harvested data.

The bot token is frequently visible in the kit's PHP source code, recoverable via static analysis of the page's source or via forensic extraction from a decompiled kit archive. A single Telegram bot token may appear across dozens of phishing deployments run by the same operator. Clustering detections by bot token therefore provides threat actor attribution at a level that domain-by-domain detection cannot: when the same bot token appears in deployments targeting three different brands across two different registrars in the same month, you're looking at a single operator or tight-knit group running a multi-brand campaign.

This attribution has operational value beyond individual takedown decisions. If a known bot token is associated with a cluster of active phishing domains, a new domain appearing in CT logs — even before any content is deployed — can be pre-emptively escalated if it is registered by an infrastructure that has hosted previous deployments using that same bot token. This is proactive posture based on threat actor infrastructure patterns, not reactive response to live phishing pages.

The Limits of Kit Fingerprinting

Kit fingerprinting is a strong tool against commodity campaigns but has real limits against bespoke attacks. A sophisticated threat actor targeting a high-value brand — a large financial institution's corporate credentials, for example — may build a custom phishing page with no kit heritage, custom-obfuscated JavaScript, and a novel antibot implementation written for this campaign specifically. No kit signature will match. Detection in this scenario depends on visual similarity analysis (the page looks like the brand's legitimate site), CT log and WHOIS monitoring (the domain name is suspicious), and DNS/hosting infrastructure correlation (the server is in an ASN previously associated with phishing infrastructure).

Kit fingerprinting addresses the 80-90% of phishing volume that is commodity. The remaining 10-20% — targeted, bespoke campaigns — requires a different detection approach. Brand protection programs that focus only on kit fingerprinting will have excellent coverage of high-volume, low-sophistication campaigns while being underequipped for the incidents that are most likely to cause significant damage. Both layers need to be running in parallel.

What kit fingerprinting gives you that domain-by-domain monitoring cannot is actor continuity. When you track a kit variant across 40 deployments over three months, you're building a picture of a threat actor's operational patterns, preferred registrars, hosting providers, and target brand selection. That operational intelligence shapes both defensive posture and the efficiency of the takedown queue — recognizing a known kit family in a new detection means you also know the likely credential exfiltration channel, the expected antibot behavior, and the typical lifespan of deployments before the operator rotates to a new domain. That context reduces the per-incident analysis overhead significantly.