The phishing kits today are not hacked together. They are developed software products that have modular architectures, evasion layers, real-time dashboards, and AI-aided content generation. Looking at one inside will alter your way of thinking about detection.
This year, a threat intelligence analyst at a mid-size financial security company was tipped off by a partner organization that a phishing kit targeting a large European bank was accidentally leaked to their staging server, which was misconfigured to have a directory listing. The analyst saved and locked down the kit prior to the exposure being closed an approximation of 340 files systematized as a hierarchical tree of directories with a README in fluent English.
The README contained installation instructions, a feature changelog, a contact handle for support on an encrypted messaging platform, and a pricing tier table. The kit was a commercial offering. It contained a version number. This was last revised eleven days ago.
The fact that the analyst discovered when she further investigated the file structure is interesting to look into in detail, as the structure of a 2026-era commercial phishing kit has significant differences from what most detection guidance describes, and it is critical to understand the difference between the threat model in the literature and the threat model in practice to create systems that actually work.

Top-Level Architecture: What the Directory Tree tells you.

Organizational maturity was the initial message that the directory structure conveyed. That kit was not a single PHP script, the most common format of phishing tooling used in the 2015–2020 epoch. It was divided into functional modules where each layer was distinctly separated with concerns: a front-end layer that dealt with the victim-facing interface; a backend layer that dealt with credential capture and exfiltration; an evasion layer that dealt with filtering of bot and sandbox detection; an administration layer that dealt with the operator dashboard; and a content generation layer that dealt with an external AI API to provide dynamic page content.
The functional module decomposition:
• /frontend: Assets of bank interface by target brand cloned. It consisted of 12 bank templates, each having mobile and desktop variant files with viewport breakpoints. CSS and JavaScript were obfuscated and minified. Template variables could inject the name, logo URL, and color palette of the target dynamically, using a central config file.
• /capture: PHP handlers to collect credentials, sorted by capture stage: initial login, OTP intercept, security question harvest, and card detail collection. Each handler sent data to an encrypted local log and, at the same time, infiltrated it to three configured destinations: one Telegram bot, one email address, and one remote API endpoint, to ensure redundancy in the event of any one of the exfiltration channels being unavailable.
• /evasion: The most technically advanced module. Includes IP reputation blocking, browser environment detection, auto crawler detection, sandbox detection heuristics, and geographic blocking logic. All this is in the following.
• /admin: A web-based operator dashboard that offers real-time tracking of victim sessions, captured credential view with copying capabilities, and statistics on campaigns, as well as configuration options. Authentication was done by a pre-shared token within the request header instead of the usual login form perhaps to ensure that the dashboard itself would not be indexed or found using the normal way.
• /ai-content: A thin API call wrapping an LLM call. It created a variant of the supporting copy of the page, the text with the important security notice, the footer disclaimer, and the error message texts on every new visitor session, using a prompt template that was stored in the config. This was intended by a comment in the source: defeats content fingerprinting and generates a unique hash per session.

The Evasion Layer: The Engineering Investment is on Display.

The most evident engineering sophistication of the kit could be found in the evasion module. It was used as a filter through which all the incoming requests were handled, and then the content facing the victims was delivered. Any requests that any of the evasion checks failed were simply redirected to the real site of the legitimate bank, a 302 redirect with no error message, which made the phishing infrastructure invisible to automated crawlers and sandboxed analysis environments.

IP Reputation and ASN Filtering.

The kit stored a locally bundled copy of a commercial IP reputation database, updated via a cron job, and hardcoded blocking rules of ASN ranges of major security vendors, cloud provider datacenter blocks likely to be used by sandboxes, and the IP range of the phishing target bank's own security operations infrastructure. Any request made out of a flagged ASN was delivered a silent redirect without any record of the visit. This implied that security vendor crawlers that attempt to detect phishing pages would always visit the legitimate banking webpage and not the phishing one.

Browser Environment Fingerprinting

A JavaScript probe that was run prior to the loading of the main page content and also checked a number of fourteen browser environment properties against desired values: WebGL renderer string, count of installed fonts, screen resolution versus declared user agent type, time zone consistency with the Accept-Language header, and presence or absence of automated browser flags within the navigator object. Headless browser environments and typical analysis tools were unable to pass several tests and got the redirect. The probe results were also recorded session-by-session, and this gave the operator an insight into which evasion methods were being activated most often, a native evasion-refinement feedback system.

OTUSSL Token System

The phishing URLs used in the campaign had a single-use, unique token in the query. The backend authenticated the token with the initial access, flagged it as used in a local SQLite database, and denied any further use with the same token with a redirect to the authentic bank. This implied that a URL, which was posted to a URL scanning service (which normally loads the URL), would use the token and present the scanning service with the legitimate bank site. The first time that the intended victim would have to click the link would be to the phishing page. A second scan of the same URL to analyze the scanned site would give the legitimate site. This architecture was a direct compromise of the most popular dynamic URL analysis method employed by anti-phishing services.

The Proxying Capability in Real Time.

The credential capture layer demonstrated a feature that represents a crucial advancement in relation to the previous phishing tools: real-time OTP proxying. Once a victim typed their username and password on the phishing site, the backend automatically forwarded said credentials to the real authentication server of the legitimate bank. In case an OTP challenge was initiated by the system of the bank, the phishing page presented an OTP entry form to the victim. The victim typed in the OTP thinking they were finishing the authentication process of the bank and the kit sent it to the actual bank in real time, finishing authentication and receiving a live session token before the OTP expired.
This architecture is also known as an adversary-in-the-middle or real-time phishing proxy, and this circumvents SMS OTP as a second factor completely. The victim performs authentication in a regular manner on their side. The attacker also manages to gain a valid authenticated session within the infrastructure of the real bank. The credential itself and OTP are effective only if established as long as the validity of the session token, which is usually fifteen to thirty minutes, during which the operator dashboard notifies the operator of the live session, which can then be exploited immediately.
With a live session notification system, a browser-based alert fired when a victim completes OTP entry, and a direct connection to take actions on the captured session-operated dashboard. The whole process of the victim clicking on the phishing link to the operator being notified of a live session was to take less than ninety seconds.

Detection Implications: What This Architecture Violates.

The architecture of the kit can be overlaid with commonly used anti-phishing detection strategies to understand what signals are being targeted with evasion measures and which are still valuable:
• Static URL scanning: One-time token architecture defeated by scanning of static URLs. On the second scan, the URL seems legitimate. It must be detected by either real-time first-access analysis or token-aware scanning, which can detect the parameter structure.
• Fingerprinting content: overcome by per-session content generation by AI. The hash-based content matching on known phishing page fingerprints does not work when the non-structural text content is per-visit unique content. A layout analysis and pattern of form fields, in the form of the structural analysis of the DOM layout, remains valuable to an extent.
• Automated crawler analysis: Bypassed by ASN filtering and browser environment fingerprinting. The legitimate bank site is reliably viewed by security vendor crawlers. It is needed to analyze unclassified residential IP infrastructure or to analyze physical devices with real consumer hardware.
• SMS OTP as second factor: Overpowered by real-time proxying. The phishing kit fulfills the OTP transaction on behalf of the victim. This strategy does not defeat FIDO2/WebAuthn hardware keys bound to origin domains, which are the authentication mechanism that the kit cannot proxy.
• Community-reported URL intelligence: Not defeated. Reports of phishing URLs made by the victim through community reporting sites, such as Scam Alerts, reveal the structure used in the campaign, whether or not that URL contains phishing content to be scanned later. The one-time token design conceals the page from automated analysis but does not stop a victim who has realized the attack from reporting the URL. The intelligence that is human-sourced is the most resistant to evasion by this architecture.

What Commercial Phishing Kits Are Telling Us About Where Detection Is Going To Have To Go.

The kit under consideration was nothing extraordinary. It was a reflection of the business level of phishing tooling in 2026, the mid-market product, but not the advanced persistent threat. Architectures with similar evasion capabilities can be purchased on cybercrime forums, some with active support and money-back guarantees.
The implication of detection is evident. The current generation of phishing kits has signature-based URL analysis, content hash matching, automated crawler scanning, and SMS OTP as a second factor on its own as an evasion target. They are not useless as layers of defense that do not work alone may also add signal when combined with others, but they must not be the top trust signal that any system relies on when the attacker has a commercial phishing kit in his or her tool arsenal.
These are signals that the kit was not evading and should be the ones to invest in: domain registration pattern analysis, infrastructure correlation across campaigns, FIDO2 authentication bound to origin domain, and community-based victim reporting via systems such as Scam Alerts. The evasion architecture of the phishing kit is a direct map of which detection mechanisms the attacker thought it might be worth evading and which they did not bother to evade because they could not.
One line of the README was marked by the analyst in her report as something that is especially worth retaining. Under the feature changelog of the current version was an item that read: "Better redirect logic of security vendor IPs tried on 14 major scanners, 14/14 pass.
The attackers are evading the detection stack. Whether the detection stack is testing itself against theirs or not is the question.