Scamwich-Kampagne nutzt Reverse-Proxys, um Restaurant-Lieferzahlungen zu stehlen

Sicherheitsforscher haben eine ausgefeilte Payment-Skimming-Kampagne identifiziert, die als "Scamwich" bezeichnet wird und Kunden großer Restaurantketten ins Visier nimmt. Die Operation war zwischen Juli und Oktober 2026 aktiv und nutzte gefälschte Domains, die über Google-Suchanzeigen beworben wurden, um Kreditkartendaten während des Checkout-Prozesses abzufangen. Die Angreifer setzten Reverse-Proxy-Technologie ein, um legitime Restaurant-Websites in Echtzeit zu spiegeln, sodass Menüs und Preise authentisch wirkten, während Zahlungsdaten unbemerkt auf ihre eigenen Server umgeleitet wurden.

Was passiert ist

Die Kampagne basierte auf einem Netzwerk aus mindestens 820 täuschend ähnlichen Domains, von denen viele kurz vor der Bewerbung über bezahlte Suchanzeigen registriert wurden. Diese Anzeigen imitierten offizielle Restaurant-Einträge für Marken wie Jersey Mike’s und leiteten Nutzer auf betrügerische Websites weiter, die hinter Cloudflare gehostet wurden. Da Cloudflare automatisch gültige TLS-Zertifikate von Google Trust Services ausstellte, zeigten Browser einen sicheren Verbindungsindikator an, was den Betrügerseiten falsche Glaubwürdigkeit verlieh. Stand 4. November 2026 waren 367 dieser Domains noch aktiv und lieferten Inhalte, obwohl die spezifischen Kampagnen von Googles Plattform entfernt worden waren.

Sobald ein Nutzer auf einer dieser Klon-Seiten landete, saß ein Reverse-Proxy-Server zwischen dem Opfer und der legitimen Restaurant-Website. Dieser Proxy rief jede Seite, jeden Menüpunkt und jeden Preis direkt von der echten Website ab, um sicherzustellen, dass Öffnungszeiten und Bestände immer aktuell waren. Das System schrieb URLs und Header dynamisch um und ersetzte die tatsächlichen Hostnamen der Marke durch die gefälschte Domain. Diese Technik ermöglichte es Kernfunktionen wie Adresssuche, Login und Warenkorbverwaltung nahtlos zu nutzen, da diese Anfragen weiterhin über den Proxy an die legitimen Backend-APIs geleitet wurden.

Der Betrug fand ausschließlich in der Zahlungsphase statt. Die Angreifer injizierten drei spezifische Skripte in jede Seite, um den Checkout-Ablauf zu manipulieren. Ein Skript-Blocker verhinderte das Laden legitimer Drittanbieter-Tools, wie Cookie-Banner oder App-Redirect-Dienste. Ein weiteres Skript mit der Bezeichnung _jmu() verwendete einen MutationObserver, um das legitime Zahlungs-iFrame kontinuierlich durch ein gefälschtes iFrame auf dem Server des Betrügers zu ersetzen. Ein drittes Skript, _chkT(), überwachte alle halbe Sekunde die Schaltfläche für die Gesamtsumme der Bestellung, um sicherzustellen, dass das gefälschte Zahlungsformular den korrekten Betrag anzeigte. Wenn Nutzer ihre Kartendaten eingaben, wurden diese über eine Live-Socket.io-Verbindung an die Betreiber gesendet, die dann manuell betrügerische Transaktionen an anderer Stelle verarbeiteten.

Wichtige Details

• Die Kampagne nutzte mindestens 820 einzigartige Domains, von denen 367 am 4. November 2026 noch aktiv waren.
• Die Angreifer schalteten mindestens 47 Google-Suchtextanzeigen unter 46 verschiedenen Werbekonten mit nicht zusammenhängenden Firmennamen.
• Das Betrugs-Toolkit verwendete einen Reverse-Proxy, um Live-Inhalte von echten Websites abzurufen, wodurch Menüs und Preise stets korrekt blieben.
• Drei injizierte Skripte kümmerten sich um das Blockieren von Skripten, das Ersetzen des Zahlungs-Frames und die Synchronisierung der Bestellsumme.
• Gestohlene Kartendaten wurden über Socket.io an menschliche Betreiber übermittelt, die 3-D-Secure-Prüfungen in Echtzeit umgingen.
• Erfolgreiche Opfer wurden nach dem Setzen eines valid=77777-Cookies über href.li-Links auf legitime Konkurrenzseiten umgeleitet.

Hintergrund

Ein Reverse-Proxy ist ein Server, der zwischen Client-Geräten und Backend-Servern sitzt, Anfragen weiterleitet und Antworten zurückgibt. In legitimen Anwendungsfällen verbessern Reverse-Proxys die Leistung, übernehmen das Lastmanagement und bieten Sicherheit. Bei diesem Angriff wurde der Proxy jedoch weaponisiert, um ein perfektes Spiegelbild der Zielwebsite zu erstellen. Durch das dynamische Abrufen von Inhalten von der echten Website vermieden die Angreifer die Notwendigkeit, statische Kopien von Menüs oder Preisen zu pflegen, die schnell veraltet wären. Dieser Ansatz ermöglichte es ihnen auch, denselben Codebase für mehrere Restaurantmarken wiederzuverwenden, indem sie einfach die Ziel-URL und die Domain-Konfiguration änderten.

Der Einsatz von Content Delivery Networks (CDNs) wie Cloudflare spielte eine entscheidende Rolle für die Glaubwürdigkeit des Betrugs. CDNs bieten oft automatisiertes TLS-Zertifikatsmanagement, was bedeutet, dass die betrügerischen Domains gültige HTTPS-Verbindungen anzeigten. Für die meisten Nutzer ist das Vorhandensein eines Schlosssymbols in der Browser-Adressleiste ein primäres Vertrauenssignal. Durch die Nutzung dieser Infrastruktur stellten die Angreifer sicher, dass technische Sicherheitsindikatoren keine Alarmzeichen auslösten, sodass Nutzer auf subtile visuelle Hinweise oder die URL-Inspektion angewiesen waren, um den Betrug zu erkennen.

Warum das wichtig ist

Für Teams, die Self-Hosted-Software oder interne Webanwendungen verwalten, hebt dieser Vorfall die Grenzen traditioneller Perimeter-Sicherheitsverteidigungen hervor. Der Angriff nutzte keine Schwachstelle im Code oder in der Infrastruktur des Restaurants aus; stattdessen machte er sich das Vertrauen zunutze, das Nutzer in Suchergebnisse und Browser-Sicherheitsindikatoren setzen. Organisationen, die kundengerichtete Webdienste betreiben, müssen erkennen, dass ihre Markenidentität extern gekapert werden kann, ohne dass ihre eigenen Server kompromittiert werden. Das bedeutet, dass die Überwachung externer Markenimpostionen genauso kritisch ist wie das Patchen interner Schwachstellen.

Die Raffinesse des Mechanismus zur Skript-Injektion zeigt, dass automatische Bot-Erkennung und Standard-Integritätsprüfungen gegen entschlossene Gegner möglicherweise nicht ausreichen. Die Angreifer zielten gezielt auf Skripte, die den Betrug hätten offenbaren können, wie solche, die mobile Nutzer zu offiziellen Apps weiterleiten, und deaktivierten diese. Für IT-Leiter unterstreicht dies die Notwendigkeit einer tieferen Einsicht darin, wie sich Drittanbieter-Skripte verhalten und wie externe Entitäten das Document Object Model (DOM) ihrer öffentlich zugänglichen Websites manipulieren könnten. Es wirft auch Fragen zur Abhängigkeit von automatisierter Zertifikatausstellung ohne zusätzliche Domain-Validierungsschritte für risikoreiche Transaktionen auf.

Was Sie tun können

• Überwachen Sie Suchmaschinen-Anzeigenarchive regelmäßig, um unbefugte Nutzung Ihres Markennamens oder täuschend ähnliche Domains zu erkennen.
• Implementieren Sie strenge Content Security Policy (CSP)-Header, um einzuschränken, welche Skripte laden dürfen und wohin Daten gesendet werden können.
• Verwenden Sie Subresource Integrity (SRI)-Hashes für kritische JavaScript-Dateien, um Manipulationen oder Ersetzungen durch Proxys zu verhindern.
• Schulen Sie Ihre Kunden darin, den exakten Domain-Namen in der Browser-Adressleiste zu überprüfen, bevor sie Zahlungsinformationen eingeben.
• Richten Sie Warnmeldungen für neu registrierte Domains ein, die Variationen Ihres Markennamens oder häufige Rechtschreibfehler enthalten.
• Erwägen Sie die Implementierung von Mutual-TLS-Authentifizierung oder anderen starken Methoden zur Client-Verifizierung für sensible API-Endpunkte.