The phishing page that built itself

The Talos Q1 2026 IR trends report landed on April 22, and the top line is the sort of thing defenders read as a bellwether. Phishing is back to being the most commonly observed initial-access vector — over a third of engagements where the vector could be determined — for the first time since Q2 2025. MFA weaknesses showed up in thirty-five percent of engagements, up from Q4. Public administration and healthcare tied as the most targeted sectors, at twenty-four percent each. None of that is especially surprising on its own.

The surprising part is a case study in the middle of the report. Talos documents what it calls, with moderate confidence, the first observation of a specific AI application — Softr, a no-code "vibe-coding" app builder — used to host a live credential-harvesting page. The page imitated Microsoft Exchange and Outlook Web Access. It captured submitted credentials into a disposable Google Sheet. It emailed the operator on new captures. Talos assesses that the pattern dates back to at least May 2023 but has been accelerating through late 2025 and into Q1. Trend Micro's parallel tracking shows the same technique on Lovable, Netlify, and Vercel: fake CAPTCHA pages stood up on AI-builder subdomains, with the real credential form loaded behind the challenge.

The individual page is unremarkable. The hosting is the story.

What the chain actually looks like.

A no-code builder like Softr is, by design, a very short distance from a prompt to a live web application. You describe what you want, it generates the HTML and JavaScript, it deploys the result to its own infrastructure, and it gives you a free subdomain. That subdomain is a sibling of every other Softr customer's subdomain: something.softr.app. Softr handles the hosting, the TLS certificate, the CDN, the uptime. If you are an attacker who wants to run a credential-harvest page and you do not want to register a domain, buy a certificate, rent a VPS, or explain to anyone what you are hosting, this is an extraordinary value proposition.

What makes this particular chain interesting is that every link in it, with the exception of the attacker's own prompt and the attacker's own inbox, is a mainstream SaaS product doing exactly what it is advertised to do. Softr builds the page. softr.app hosts it under a subdomain. Google Sheets stores the harvested credentials. Gmail notifies the operator. An automated defender walking this chain top to bottom sees only reputable third parties. The chain is not hiding. It is wearing camouflage that the defense was built to classify as benign.

The blind spot in URL reputation.

Most URL-reputation systems — the ones that score a link as "safe," "suspicious," or "malicious" before your browser even finishes the TLS handshake — work the way a credit bureau works. They build a profile of the domain: how old it is, how well-known it is, whether its TLS certificate has a long history or a fresh Let's Encrypt one, whether it has ever been observed on a blocklist, whether its parent company is in good standing. The profile yields a number, the number yields a verdict, the verdict yields a color.

Run something.softr.app through that pipeline.

Every signal the reputation layer leans on is a property of softr.app the parent domain, and every answer the parent gives is the right one. It is six years old. Its certificate is valid. It is not on any blocklist. It serves HTTPS. It is a category the scorer has classified. The subdomain does not meaningfully change any of those. The page on the subdomain could be a birthday card or a credential-harvest form — the scorer has no way to tell, and structurally, within the design of URL reputation, no reason to look.

Talos's observation is that attackers figured this out a while ago and are now operationalizing it: build the page on a reputable SaaS, collect the credentials into a reputable SaaS, route the alerts through a reputable SaaS. Give the defender nothing to decline.

The right layer is the page, not the URL.

Defense has to move down the stack. The only signal that remains reliable once the hosting is laundered is what the page itself claims to be and what it actually is. An Outlook login form on onboarding-portal-8xq.softr.app is a phish. An Outlook login form on login.microsoftonline.com is not. The same form, different origin, different verdict. A system that can read the form and compare it to the origin has something to say about this page; a system that only reads the URL does not.

This is the layer Bromure's anti-phishing inspector already works at. Inside every Bromure tab, a content script watches the page as it loads, pulls out the signals a human would use to decide what the page claims to be — the visible text, the title, the logo's source, the shape of the forms, the fields being requested — and ships that bundle over a vsock channel to a small model that issues a verdict in plain language. "This page claims to be Microsoft Outlook but is hosted on softr.app" is the sort of sentence a trained reader lands on in a fraction of a second. The model lands there too, and the banner the user sees says it in one sentence, in the color that matches the verdict.

The content inspector is not magic and it is not a proof. It is a trained second opinion that answers a question URL reputation is structurally unable to answer: what does this page claim to be? That question has a sharper edge on a softr.app or a vercel.app or a lovable.app than almost anywhere else on the web, because on those subdomains the page content is almost the only signal that survives. Everything else has been laundered through the parent.

What Bromure still does not stop.

The content inspector, and the banner it paints, and the block it can impose, are the first line. The first line does not always hold. A user who has been primed by a convincing email, who is in the middle of their workday, who is used to clicking through Outlook login screens as a matter of habit, can click past a warning banner. A user can also land on a page the inspector has not yet evaluated, or one it evaluates as suspicious rather than outright phishing, and decide that suspicious is close enough to probably fine.

When that happens, the user types a password into a form, and the form captures it. No browser architecture in the world disables typing. This is the plainest and most important caveat of the post. Bromure does not prevent a user from entering a real password into an attacker's form. What it can shape is what happens after, and what happens after depends on where the rest of the user's work lives.

What browser-habit posture changes, and what it does not.

Some things the Bromure architecture changes, honestly, if a credential-phish gets past the banner:

• No password-manager autofill on the wrong origin. Password managers match saved credentials to the origin, and the origin here is softr.app, which the user's vault has never seen. The autofill will not fire. The user has to type. This is a real, cheap, boring defense — and it works as well in Chrome as it does in Bromure; it is worth naming only because it is a defense that does not rely on judgement, and judgement is what phishing defeats.
• No persistent profile in the phish tab. The tab that held the phish is an ephemeral Linux VM. When it closes, nothing that was loaded in it — cookies, storage, caches, fingerprints — persists. That does not un-leak the credentials the user typed. It does mean the page cannot quietly plant a marker in a long-lived profile to follow the user across sessions.
• A page that reaches for the host does not find it. The Talos case study is straight credential-capture. The broader pattern Trend Micro tracks across Lovable and Vercel includes pages that also stage a follow-on — a ClickFix paste, a "run this installer," a fake CAPTCHA that resolves to a native-app prompt. If the phish page tries to hand off to the host OS, the tab-VM severs that handoff at the hypervisor boundary. Same architectural reason as every other post on this blog.

And some things Bromure does not change:

• Credential replay from attacker infrastructure. Once the attacker has a username and a password, they can sign in to the real Outlook from their own infrastructure. Nothing on the victim's machine, Bromure included, participates in that session. MFA helps. Phish-resistant MFA — hardware keys, passkeys — helps more. Tenant-level policy that forbids legacy auth helps most. These are the fixes for this leg of the attack, and this blog is not going to pretend a browser architecture substitutes for them.
• Adversary-in-the-middle kits that relay live sessions. The Softr case Talos documents is a static credential-capture page, not an AiTM reverse proxy. The more sophisticated kit class — Tycoon, Evilproxy, and the lineage — does capture a live session cookie by relaying the victim's MFA challenge through the phish to the real provider. That session cookie lives in the attacker's infrastructure from the moment it is captured. Browser-side disposability helps with session hygiene going forward; it does not retroactively invalidate a cookie that already left the building. Cookie-binding at the server side — DBSC and its peers — is the fix that does.

Why this is a watershed and not a fad.

Talos's "first-attribution" framing is cautious, and the moderate- confidence assessment that the pattern dates to May 2023 suggests it has been quietly accelerating for close to two years before anyone labeled it. That is how the best attacker techniques arrive — not as an announcement but as a curve you notice on a graph someone finally drew. Trend Micro's September 2025 writeup on AI-builder-hosted phishing sketched the same curve from the other direction. The crossing point is here. Any defender who assumes their users will never click a link to *.softr.app, *.vercel.app, *.lovable.app, or *.netlify.app is assuming a world that already ended last quarter.

The cost structure is the reason. A decade ago, standing up a credible phishing page required either competence or money: a domain, a certificate, a server, a page that did not immediately leak its provenance. Today, a no-code builder handles all four in exchange for a free-tier signup. The marginal cost of another impersonation site is measured in minutes of prompting. The marginal cost of a takedown — because each page lives on a subdomain of a reputable provider, not on its own domain — is higher than it used to be. These two curves point the wrong way for the defense, and the mainstream response of "train users to spot bad URLs" is at this point a cost center, not a control.

The honest position for a browser that claims to protect users is that it has to do work URL-reputation systems cannot. It has to actually read the page. It has to decide, for each login-looking form on a non-login-looking domain, whether the form matches the domain or lies about it. It has to say so in a sentence a human can read, and it has to be right often enough that the sentence is worth reading.

One story, and what it predicts.

Talos wrote about one page. The page was built on one SaaS, harvested credentials into another, alerted the operator through a third. Every link in that chain is, to a reputation scorer, a good neighbor. The story Talos tells will stop being the exception before the end of this year. "Vibe-coded" phishing is not a label for a novelty; it is the name for the default way credentialed attackers will build attack pages from now on, because it is the cheapest and most forgiving way.

If your browser's only answer to phishing is a URL-reputation score, your browser does not have an answer to this. The reputation score will be green. The page will be red. Install Bromure — and put the second pair of eyes on the page where the mismatch actually lives.