Phishing kits turn a link into a working login trap.

A phishing kit is the page code and operator service behind a fake sign-in, document portal or payment form. It can copy a familiar page, relay a real login as it happens or send the visitor to a genuine device sign-in that authorizes the operator's session.

email, message or QR code
  -> phishing host or compromised site
  -> CAPTCHA, fingerprint or proof-of-work gate
  -> fake form, relayed sign-in or device-code prompt
  -> credentials, MFA value, session cookie or OAuth token captured

Dedicated hosts dominate our captures

Phishing pages live in both places: domains and hosted projects set up for the campaign, and legitimate websites that somebody has compromised. Kali365 appears on hosted projects, object storage and attacker-controlled domains. FlowerStorm campaigns have used compromised aged domains, while Sneaky 2FA has appeared on compromised WordPress sites and attacker-controlled domains.

Our captures lean heavily toward standalone phishing infrastructure. Of the 4,063 phishing sites captured since 25 September, 22 ran WordPress and 9 requested Joomla core paths.

The page sits at the root, behind a long random path or under a hosted-project address. Some roots show a holding page while the phishing path stays active.

The gate decides who sees the page

A direct visit often stops at a CAPTCHA or a blank page. FlowerStorm can score mouse movement and time on page before redirecting. Gcore checks automation flags, crawler names, WebGL, browser languages and battery support. Sneaky 2FA variants make the browser solve a proof-of-work challenge or an image puzzle before serving the Microsoft sign-in page.

These checks separate a visitor from an automated scanner and preserve a value, cookie or path for the next request. Test the exact link from the message. Visiting the hostname alone can show a different page.

Credentials are one kind of capture

MassCollect takes a username and password, displays an error and clears the password field for another attempt. Legokit builds the page around the email address in the link, sends repeated password attempts to Telegram or a PHP handler, then redirects to the real domain. Miarroba page chains add phone numbers, card details, camera frames and verification codes to the same victim record.

Adversary-in-the-middle kits relay the login while it happens. FlowerStorm and Sneaky 2FA send the credentials and MFA response to the real service through their backend, then keep the authenticated session returned by that service. NakedPages takes a browser-in-the-middle approach: it streams a live login DOM into the page and sends typed, pasted and selected input back over Socket.IO.

Device-code kits avoid a copied password form. Kali365, EvilTokens and N0va give the visitor a short code and send them to Microsoft's real device sign-in. The credentials and MFA prompt belong to Microsoft, but the code authorizes the session started by the kit. Gcore uses another route, asking the visitor to approve OAuth scopes for an application.

The kits we track

Each kit has its own page: MassCollect, SessionSerpent, Legokit, Kali365, FlowerStorm, Gcore, Ghost, NakedPages, Miarroba, EvilTokens, AnonyMousKIT, N0va, Sneaky 2FA and Darcula.

Month	New sites
September	4,903
October so far	5,465

Checking a site

Open the exact reported path in a private browser with developer tools recording the page and network log. Use test values only. Check for:

• a root page that changes when the original long path is used
• Turnstile, a home-made CAPTCHA, an image puzzle or repeated browser-fingerprint requests before the form appears
• forms that post credentials, card details or codes to the same host, Telegram, Discord or an unfamiliar endpoint
• Socket.IO or WebSocket traffic while values are typed
• a device code copied to the clipboard and a link to a genuine Microsoft sign-in
• an OAuth consent form whose redirect address or requested scopes do not belong to the application
• scripts, PHP files, WordPress plugins or hosted-project deployments absent from the site's release

Remove the page and every gate or loader in front of it. Review DNS, hosting, CMS and deployment access, rotate the credentials that could have placed the files, clear caches and test the original path again.