What are phishing kits? How they work & detection - Email security - Learn

What they are#

A phishing kit is a pre-packaged collection of files, HTML templates, JavaScript, server-side scripts (typically PHP), and configuration files, that an attacker deploys to a web server to create a functional credential harvesting operation. Kits commoditize phishing by reducing the technical skill required. An operator downloads a ZIP archive, uploads it to a compromised or rented server, and has a working phishing site within minutes.

Modern kits have evolved well beyond simple login page clones. Many include admin panels for managing campaigns, real-time credential logs, Telegram bot integration for instant exfiltration notifications, and built-in evasion techniques.

What's inside a typical kit#

HTML/CSS templates. Pixel-perfect replicas of login pages for Microsoft 365, Google Workspace, banking portals, or shipping services, often with responsive design and localization, a form of brand impersonation at scale
JavaScript. Client-side logic for form validation, credential capture, and sometimes clipboard manipulation or browser fingerprinting
Server-side backends. PHP scripts that receive submitted credentials, validate them, log them to a local file or database, and forward them via email, Telegram, or HTTP POST to a command-and-control endpoint
Anti-analysis features. Bot detection (checking user-agent strings and IP ranges), geofencing (blocking visitors from security researcher regions), and crawler evasion (serving benign content to known scanner IPs)
Admin interfaces. Web dashboards where the operator views captured credentials, configures target branding, manages multiple campaigns, and sometimes resells access

Static kits vs. reverse-proxy kits#

The kits described above are static kits, self-contained file bundles deployed to a single server. The login page is a frozen HTML clone of the target service. When the legitimate site updates its UI or changes form field names, the clone diverges and may stop working entirely. Credentials are harvested locally by the kit's PHP backend and exfiltrated to the operator. Because the kit never interacts with the real service, it cannot complete multi-factor authentication (MFA) challenges or capture session tokens.

Reverse-proxy kits (also called adversary-in-the-middle, or AiTM, kits) operate on a fundamentally different architecture. Instead of hosting a static clone, the attacker's server acts as a live proxy that forwards every request to the legitimate service in real time. The page rendered in the victim's browser is always current because it is the real page, relayed through attacker-controlled infrastructure. To maintain this illusion, the proxy rewrites all domain references in HTML, JavaScript, CSS, HTTP headers, and cookies so that every subsequent request continues to flow through it. The proxy also injects client-side scripts (typically into the <head> element) that hook form inputs and capture authentication events as they occur. Because the full adversary-in-the-middle login flow completes in real time, the proxy captures session tokens after MFA succeeds, giving the attacker authenticated access without ever needing the one-time code.

This architectural shift changes the detection landscape. Static kit detection relies heavily on HTML fingerprints, structural artifacts, and known file paths, all of which are absent from proxy-based kits because no cloned files exist on disk. The content is dynamically relayed, so each page load reflects the legitimate site's current markup rather than a stale template. Detection of reverse-proxy kits depends more on network-level signals (anomalous TLS certificates, suspicious redirect chains, infrastructure reputation) than on content-based signatures.

Distribution and the phishing-as-a-service model#

Kits circulate through Telegram channels and dedicated phishing-as-a-service (PhaaS) platforms. Some operate on a subscription model, operators pay a monthly fee for access to updated templates, infrastructure automation, and support. Platforms like EvilProxy and Caffeine have offered turnkey adversary-in-the-middle phishing kits with reverse-proxy functionality built in, lowering the barrier to session-hijacking attacks.

Kit authors sometimes embed hidden backdoors that silently copy harvested credentials to the author's own collection endpoint, meaning the kit's operator is also being exploited.

Detection signals#

Common HTML fingerprints. Many kits share structural patterns, specific <div> class names, JavaScript variable names, or embedded comments, that persist across deployments
Hosting patterns. Kits often deploy to compromised WordPress installations, free hosting platforms, or newly registered lookalike domains with Let's Encrypt certificates
Directory structure artifacts. Default kit file names like next.php, post.php, or configuration files left in publicly accessible directories
Certificate Transparency. New certificates issued for domains mimicking well-known login portals
URL structure patterns. Phishing kit URLs frequently include paths like /login/, /signin/, or /verify/ combined with brand-related subdomains

Limitations of kit-based detection#

Kit authors actively monitor public detection research and update their templates to evade known signatures. A detection rule based on a specific HTML pattern may work for weeks, then break when the kit pushes an update. Effective detection combines static fingerprinting with behavioral signals like rapid domain registration, hosting infrastructure reputation, and credential submission patterns.

What are phishing kits?