Die Phishing-Seite, die sich selbst gebaut hat

Der Talos-Q1-2026-IR-Trends-Bericht erschien am 22. April, und die Schlagzeile ist die Art von Befund, den Verteidiger als Wegweiser lesen. Phishing ist erstmals seit Q2 2025 wieder der am häufigsten beobachtete Erstzugangs-Vektor — in über einem Drittel der Einsätze, in denen der Vektor bestimmbar war. MFA-Schwächen tauchten in fünfunddreißig Prozent der Einsätze auf, ein Anstieg gegenüber Q4. Öffentliche Verwaltung und Gesundheitswesen lagen mit je vierundzwanzig Prozent gleichauf als meistbetroffene Branchen. Für sich genommen ist davon nichts besonders überraschend.

Überraschend ist eine Fallstudie in der Mitte des Berichts. Talos dokumentiert dort, mit mittlerer Konfidenz, die erste Beobachtung einer konkreten KI-Anwendung — Softr, einen No-Code-„Vibe-Coding“- App-Baukasten — im Einsatz für eine aktive Seite zum Abgreifen von Zugangsdaten. Die Seite imitierte Microsoft Exchange und Outlook Web Access. Sie schrieb eingegebene Zugangsdaten in ein wegwerfbares Google Sheet. Sie schickte dem Betreiber bei jedem neuen Fang eine E-Mail. Talos schätzt, dass das Muster mindestens bis Mai 2023 zurückreicht, sich aber durch das späte 2025 und in Q1 hinein beschleunigt hat. Die parallele Beobachtung von Trend Micro zeigt dieselbe Technik auf Lovable, Netlify und Vercel: gefälschte CAPTCHA-Seiten, die auf KI-Baukasten-Subdomains stehen, mit dem eigentlichen Zugangsdatenformular hinter der Abfrage.

Die einzelne Seite ist unauffällig. Die Geschichte ist das Hosting.

Wie die Kette tatsächlich aussieht.

Ein No-Code-Baukasten wie Softr ist, schon vom Konzept her, eine sehr kurze Strecke vom Prompt zur lauffähigen Webanwendung. Man beschreibt, was man will, er erzeugt das HTML und JavaScript, er deployt das Ergebnis auf seine eigene Infrastruktur und stellt eine kostenlose Subdomain bereit. Diese Subdomain ist ein Geschwister jeder anderen Softr-Kundensubdomain: irgendwas.softr.app. Softr kümmert sich um Hosting, TLS-Zertifikat, CDN, Uptime. Wer als Angreifer eine Zugangsdaten-Abgreif-Seite betreiben will, aber keine Domain registrieren, kein Zertifikat kaufen, keinen VPS mieten und niemandem erklären will, was dort gehostet wird, dem bietet das ein außergewöhnliches Preis-Leistungs-Verhältnis.

Das Besondere an dieser Kette ist, dass jedes Glied — bis auf den Prompt des Angreifers und seinen Posteingang — ein Mainstream-SaaS- Produkt ist, das genau das tut, wofür es beworben wird. Softr baut die Seite. softr.app hostet sie unter einer Subdomain. Google Sheets speichert die abgegriffenen Zugangsdaten. Gmail benachrichtigt den Betreiber. Ein automatisierter Verteidiger, der diese Kette von oben nach unten abläuft, sieht ausschließlich seriöse Drittparteien. Die Kette versteckt sich nicht. Sie trägt eine Tarnung, die die Abwehr als harmlos einzustufen gelernt hat.

Der blinde Fleck der URL-Reputation.

Die meisten URL-Reputationssysteme — jene, die einen Link als „sicher“, „verdächtig“ oder „bösartig“ einstufen, noch bevor der Browser den TLS-Handshake abgeschlossen hat — arbeiten ähnlich wie eine Wirtschaftsauskunftei. Sie legen ein Profil der Domain an: wie alt sie ist, wie bekannt sie ist, ob ihr TLS-Zertifikat eine lange Historie hat oder ein frisches Let's Encrypt ist, ob sie schon einmal auf einer Blockliste stand, ob die Muttergesellschaft einen guten Ruf hat. Aus dem Profil wird eine Zahl, aus der Zahl ein Urteil, aus dem Urteil eine Farbe.

Jagt man irgendwas.softr.app durch diese Pipeline, passiert Folgendes.

Jedes Signal, auf das sich die Reputationsschicht stützt, ist eine Eigenschaft der Eltern-Domain softr.app, und jede Antwort, die die Eltern-Domain gibt, ist die richtige. Sie ist sechs Jahre alt. Ihr Zertifikat ist gültig. Sie steht auf keiner Blockliste. Sie liefert HTTPS aus. Sie ist eine Kategorie, die der Scorer klassifiziert hat. Die Subdomain ändert an alldem nichts Wesentliches. Die Seite auf der Subdomain könnte eine Geburtstagskarte sein oder ein Formular zum Zugangsdaten-Abgriff — der Scorer hat keine Möglichkeit, das zu unterscheiden, und strukturell, im Design von URL-Reputation, keinen Grund hinzusehen.

Was Talos beobachtet: Angreifer haben das vor einer Weile verstanden und operationalisieren es nun. Baue die Seite auf einem seriösen SaaS, sammle die Zugangsdaten in einem seriösen SaaS, leite die Meldungen über einen seriösen SaaS. Gib dem Verteidiger nichts, was er ablehnen könnte.

Die richtige Schicht ist die Seite, nicht die URL.

Die Abwehr muss tiefer in den Stack rücken. Das einzige Signal, das zuverlässig bleibt, sobald das Hosting gewaschen ist, ist das, was die Seite selbst zu sein behauptet, und das, was sie tatsächlich ist. Ein Outlook-Anmeldeformular auf onboarding-portal-8xq.softr.app ist ein Phish. Ein Outlook-Anmeldeformular auf login.microsoftonline.com ist keins. Dasselbe Formular, andere Herkunft, anderes Urteil. Ein System, das das Formular lesen und mit der Herkunft vergleichen kann, hat etwas zu dieser Seite zu sagen; ein System, das nur die URL liest, nicht.

Genau auf dieser Schicht arbeitet der Anti-Phishing-Inspektor von Bromure bereits. In jedem Bromure-Tab beobachtet ein Content Script die Seite beim Laden, extrahiert die Signale, die ein Mensch verwenden würde, um zu entscheiden, was die Seite zu sein behauptet — den sichtbaren Text, den Titel, die Quelle des Logos, die Form der Formulare, die verlangten Felder — und schickt dieses Paket über einen vsock-Kanal an ein kleines Modell, das ein Urteil in Klartext ausspricht. „Diese Seite gibt vor, Microsoft Outlook zu sein, wird aber auf softr.app gehostet“ ist der Satz, bei dem ein geübter Leser in Bruchteilen einer Sekunde landet. Das Modell landet ebenfalls dort, und das Banner, das der Nutzer sieht, sagt es in einem Satz, in der Farbe, die zum Urteil passt.

Der Inhaltsinspektor ist keine Magie und kein Beweis. Er ist eine trainierte Zweitmeinung, die eine Frage beantwortet, die URL-Reputation strukturell nicht beantworten kann: Was behauptet diese Seite zu sein? Diese Frage hat auf einer softr.app-, einer vercel.app- oder einer lovable.app-Subdomain eine besonders scharfe Kante — schärfer als fast irgendwo sonst im Web —, weil auf diesen Subdomains der Seiteninhalt fast das einzige Signal ist, das überlebt. Alles andere wurde durch die Eltern-Domain gewaschen.

Was Bromure immer noch nicht verhindert.

Der Inhaltsinspektor, das Banner, das er zeichnet, und die Sperre, die er verhängen kann, sind die erste Linie. Die erste Linie hält nicht immer. Ein Nutzer, der durch eine überzeugende E-Mail vorbereitet wurde, der mitten in seinem Arbeitstag steckt, der aus Gewohnheit durch Outlook-Anmeldemasken klickt, kann sich über ein Warnbanner hinwegsetzen. Ein Nutzer kann auch auf einer Seite landen, die der Inspektor noch nicht bewertet hat, oder die er als verdächtig statt als eindeutig Phishing einstuft, und entscheiden, dass verdächtig nah genug an wahrscheinlich okay ist.

Wenn das passiert, tippt der Nutzer ein Passwort in ein Formular, und das Formular fängt es ab. Keine Browser-Architektur der Welt schaltet das Tippen aus. Das ist die schlichteste und wichtigste Einschränkung dieses Beitrags. Bromure hindert einen Nutzer nicht daran, ein echtes Passwort in das Formular eines Angreifers einzugeben. Was es gestalten kann, ist das, was danach passiert — und was danach passiert, hängt davon ab, wo der Rest der Arbeit des Nutzers lebt.

Was die Browser-Gewohnheits-Haltung ändert — und was nicht.

Einige Dinge ändert die Bromure-Architektur ehrlich, wenn ein Zugangsdaten-Phish am Banner vorbeikommt:

• Kein Passwortmanager-Autofill auf der falschen Herkunft. Passwortmanager ordnen gespeicherte Zugangsdaten der Herkunft zu, und die Herkunft hier ist softr.app, die der Tresor des Nutzers noch nie gesehen hat. Das Autofill wird nicht auslösen. Der Nutzer muss tippen. Das ist eine echte, billige, langweilige Verteidigung — und sie funktioniert in Chrome ebenso gut wie in Bromure; sie ist nur deshalb erwähnenswert, weil sie nicht auf Urteilsvermögen angewiesen ist, und Urteilsvermögen ist das, was Phishing aushebelt.
• Kein dauerhaftes Profil im Phish-Tab. Der Tab, der den Phish enthielt, ist eine flüchtige Linux-VM. Wenn er geschlossen wird, bleibt nichts, was in ihm geladen war — Cookies, Storage, Caches, Fingerprints — erhalten. Das macht die Zugangsdaten, die der Nutzer getippt hat, nicht ungelesen. Es bedeutet aber, dass die Seite in einem langlebigen Profil nicht still eine Markierung setzen kann, um den Nutzer über Sitzungen hinweg zu verfolgen.
• Eine Seite, die nach dem Host greift, findet ihn nicht. Die Talos-Fallstudie ist reines Zugangsdaten-Abgreifen. Das breitere Muster, das Trend Micro über Lovable und Vercel verfolgt, umfasst Seiten, die zusätzlich einen Follow-on inszenieren — ein ClickFix-Einfügen, ein „Dieses Installationsprogramm ausführen“, ein gefälschtes CAPTCHA, das in einer nativen App-Abfrage endet. Wenn die Phish-Seite versucht, an das Host-Betriebssystem zu übergeben, kappt die Tab-VM diese Übergabe an der Hypervisor- Grenze. Dieselbe architektonische Begründung wie in jedem anderen Beitrag in diesem Blog.

Und einige Dinge, die Bromure nicht ändert:

• Credential-Replay aus Angreiferinfrastruktur. Sobald der Angreifer Nutzername und Passwort hat, kann er sich aus seiner eigenen Infrastruktur am echten Outlook anmelden. Nichts auf dem Rechner des Opfers, Bromure eingeschlossen, ist an dieser Sitzung beteiligt. MFA hilft. Phishing-resistente MFA — Hardware-Schlüssel, Passkeys — hilft mehr. Mandantenrichtlinien, die Legacy-Auth verbieten, helfen am meisten. Das sind die Fixes für dieses Bein des Angriffs, und dieser Blog wird nicht so tun, als würde eine Browser-Architektur sie ersetzen.
• Adversary-in-the-Middle-Kits, die Live-Sitzungen weiterleiten. Der Softr-Fall, den Talos dokumentiert, ist eine statische Zugangsdaten-Abgreifseite, keine AiTM-Reverse-Proxy-Operation. Die anspruchsvollere Kit-Klasse — Tycoon, Evilproxy und ihre Verwandten — fängt ein Live-Sitzungs-Cookie ab, indem sie die MFA-Abfrage des Opfers durch den Phish an den echten Anbieter weiterreicht. Dieses Sitzungs-Cookie lebt ab dem Moment seines Abgriffs in der Angreiferinfrastruktur. Browser-seitige Wegwerfbarkeit hilft bei der Sitzungshygiene in die Zukunft; sie entwertet rückwirkend kein Cookie, das das Gebäude bereits verlassen hat. Cookie-Binding auf Serverseite — DBSC und Verwandte — ist der Fix, der das tut.

Warum das eine Wasserscheide ist und keine Modeerscheinung.

Die „Erstzuschreibungs“-Formulierung von Talos ist vorsichtig, und die mittlere Konfidenz, mit der das Muster auf Mai 2023 datiert wird, legt nahe, dass es sich fast zwei Jahre lang still beschleunigt hat, bevor ihm jemand ein Etikett gegeben hat. So kommen die besten Angreifertechniken an — nicht als Ankündigung, sondern als Kurve, die man auf einem Diagramm bemerkt, das jemand endlich gezeichnet hat. Der Trend-Micro-Artikel vom September 2025 zu KI-Baukasten-gehostetem Phishing skizzierte dieselbe Kurve von der anderen Seite. Der Schnittpunkt ist jetzt. Jeder Verteidiger, der davon ausgeht, seine Nutzer würden niemals auf einen Link zu *.softr.app, *.vercel.app, *.lovable.app oder *.netlify.app klicken, geht von einer Welt aus, die schon im letzten Quartal zu Ende gegangen ist.

Die Kostenstruktur ist der Grund. Vor zehn Jahren erforderte das Hochziehen einer glaubwürdigen Phishing-Seite entweder Kompetenz oder Geld: eine Domain, ein Zertifikat, einen Server, eine Seite, die ihre Herkunft nicht sofort verrät. Heute erledigt ein No-Code-Baukasten alle vier im Tausch gegen eine Gratis-Anmeldung. Die Grenzkosten für eine weitere Imitationsseite lassen sich in Prompt-Minuten messen. Die Grenzkosten eines Takedowns — weil jede Seite auf einer Subdomain eines seriösen Anbieters liegt, nicht auf einer eigenen Domain — sind höher als früher. Diese beiden Kurven zeigen für die Verteidigung in die falsche Richtung, und die Standardantwort „Nutzer schulen, schlechte URLs zu erkennen“ ist an diesem Punkt ein Kostenblock, kein Kontrollmechanismus.

Die ehrliche Position eines Browsers, der behauptet, Nutzer zu schützen, ist, dass er Arbeit leisten muss, die URL-Reputationssysteme nicht leisten können. Er muss die Seite tatsächlich lesen. Er muss für jedes anmeldeähnliche Formular auf einer nicht-anmeldeähnlichen Domain entscheiden, ob das Formular zur Domain passt oder über sie lügt. Er muss das in einem Satz sagen, den ein Mensch lesen kann, und er muss oft genug richtig liegen, dass der Satz das Lesen wert ist.

Eine Geschichte, und was sie voraussagt.

Talos hat über eine einzige Seite geschrieben. Die Seite wurde auf einem SaaS gebaut, sammelte Zugangsdaten in einem anderen und meldete den Betreiber über einen dritten. Jedes Glied in dieser Kette ist für einen Reputationsscorer ein guter Nachbar. Die Geschichte, die Talos erzählt, wird vor Ende dieses Jahres aufhören, die Ausnahme zu sein. „Vibe-Coded“-Phishing ist kein Etikett für eine Kuriosität; es ist der Name für die künftige Standardart, auf die berechtigungshungrige Angreifer Angriffsseiten bauen werden, weil es der billigste und nachsichtigste Weg ist.

Wenn die einzige Antwort Ihres Browsers auf Phishing eine URL-Reputations-Bewertung ist, hat Ihr Browser auf genau das hier keine Antwort. Die Reputations-Bewertung wird grün sein. Die Seite wird rot sein. Installieren Sie Bromure — und setzen Sie das zweite Augenpaar dort auf die Seite, wo die Abweichung tatsächlich lebt.