La campagne Scamwich utilise des proxies inverses pour voler les paiements de livraison de restaurants

Des chercheurs en sécurité ont identifié une campagne sophistiquée d'écrémage de paiements, surnommée « Scamwich », qui cible les clients de grandes chaînes de restaurants. Active entre juillet et octobre 2026, l'opération utilisait de faux domaines promus via des annonces sur Google Search pour intercepter les détails des cartes bancaires lors du processus de paiement. Les attaquants ont employé la technologie de proxy inverse pour reproduire en temps réel les sites web légitimes des restaurants, garantissant que les menus et les prix semblaient authentiques tout en redirigeant silencieusement les données de paiement vers leurs propres serveurs.

Ce qui s'est passé

La campagne reposait sur un réseau d'au moins 820 domaines imitatifs, dont beaucoup avaient été enregistrés peu avant d'être promus via des annonces payantes dans les moteurs de recherche. Ces annonces imitaient les listes officielles de restaurants pour des marques telles que Jersey Mike’s, dirigeant les utilisateurs vers des sites frauduleux hébergés derrière Cloudflare. Comme Cloudflare émettait automatiquement des certificats TLS valides auprès de Google Trust Services, les navigateurs affichaient un indicateur de connexion sécurisée, conférant une fausse crédibilité aux sites d'arnaque. Au 4 novembre 2026, 367 de ces domaines étaient toujours actifs et diffusaient du contenu, bien que les campagnes publicitaires spécifiques aient été retirées de la plateforme de Google.

Une fois qu'un utilisateur atterrissait sur l'un de ces sites clonés, un serveur proxy inverse se situait entre la victime et le site web légitime du restaurant. Ce proxy récupérait chaque page, élément de menu et prix directement depuis le vrai site, garantissant que les horaires d'ouverture et les stocks étaient toujours à jour. Le système réécrivait les URL et les en-têtes à la volée, remplaçant les noms d'hôtes réels de la marque par le domaine factice. Cette technique permettait aux fonctionnalités principales comme la recherche d'adresse, la connexion et la gestion du panier de fonctionner parfaitement, car ces requêtes étaient toujours routées vers les API backend légitimes via le proxy.

La tromperie se produisait exclusivement au stade du paiement. Les attaquants injectaient trois scripts spécifiques dans chaque page pour manipuler le flux de commande. Un bloqueur de scripts empêchait le chargement d'outils tiers légitimes, tels que les bannières de cookies ou les services de redirection d'applications. Un autre script, intitulé _jmu(), utilisait un MutationObserver pour remplacer continuellement l'iframe de paiement légitime par un faux hébergé sur le serveur de l'escroc. Un troisième script, _chkT(), surveillait le bouton du total de la commande toutes les demi-secondes pour s'assurer que le faux formulaire de paiement affichait le montant correct. Lorsque les utilisateurs saisissaient les détails de leur carte, les données étaient envoyées via une connexion socket.io en direct aux opérateurs, qui traitaient ensuite manuellement les transactions frauduleuses ailleurs.

Détails clés

• La campagne a utilisé au moins 820 domaines uniques, dont 367 étaient encore actifs au 4 novembre 2026.
• Les attaquants ont diffusé au moins 47 annonces textuelles sur Google Search sous 46 comptes annonceurs différents utilisant des noms commerciaux sans rapport.
• Le kit de fraude utilisait un proxy inverse pour récupérer le contenu en direct des vrais sites, garantissant que les menus et les prix étaient toujours exacts.
• Trois scripts injectés géraient le blocage des scripts, le remplacement du cadre de paiement et la synchronisation du total de la commande.
• Les données de cartes volées étaient transmises via socket.io à des opérateurs humains qui contornaient les vérifications 3-D Secure en temps réel.
• Les victimes ayant réussi leur transaction étaient redirigées vers des sites concurrents légitimes via des liens href.li après qu'un cookie valid=77777 ait été défini.

Contexte

Un proxy inverse est un serveur situé entre les appareils clients et les serveurs backend, transmettant les requêtes et renvoyant les réponses. Dans les cas d'utilisation légitimes, les proxies inverses améliorent les performances, gèrent l'équilibrage de charge et fournissent une sécurité. Dans cette attaque, cependant, le proxy a été armé pour créer un miroir parfait du site web cible. En récupérant dynamiquement le contenu du vrai site, les attaquants évitaient la nécessité de maintenir des copies statiques des menus ou des prix, qui deviendraient rapidement obsolètes. Cette approche leur permettait également de réutiliser la même base de code pour plusieurs marques de restaurants simplement en modifiant l'URL cible et la configuration du domaine.

L'utilisation de réseaux de distribution de contenu (CDN) comme Cloudflare a joué un rôle critique dans la crédibilité de l'arnaque. Les CDN fournissent souvent une gestion automatique des certificats TLS, ce qui signifie que les domaines frauduleux affichaient des connexions HTTPS valides. Pour la plupart des utilisateurs, la présence d'une icône de cadenas dans la barre d'adresse du navigateur est un signal principal de confiance. En exploitant cette infrastructure, les attaquants ont fait en sorte que les indicateurs techniques de sécurité ne déclenchent pas d'alarmes, obligeant les utilisateurs à compter sur des indices visuels subtils ou une inspection de l'URL pour détecter la fraude.

Pourquoi c'est important

Pour les équipes qui gèrent des logiciels auto-hébergés ou des applications web internes, cet incident met en lumière les limites des défenses périmétriques traditionnelles. L'attaque n'a pas exploité une vulnérabilité dans le code ou l'infrastructure du restaurant ; elle a plutôt exploité la confiance que les utilisateurs placent dans les résultats de recherche et les indicateurs de sécurité du navigateur. Les organisations qui proposent des services web destinés aux clients doivent reconnaître que leur identité de marque peut être détournée externement sans aucune violation de leurs propres serveurs. Cela signifie que la surveillance de l'usurpation externe de la marque est tout aussi critique que la correction des vulnérabilités internes.

La sophistication du mécanisme d'injection de scripts démontre que la détection automatisée des bots et les contrôles d'intégrité standard peuvent ne pas suffire face à des adversaires déterminés. Les attaquants ont spécifiquement ciblé et désactivé les scripts qui auraient pu révéler la fraude, tels que ceux redirigeant les utilisateurs mobiles vers les applications officielles. Pour les dirigeants informatiques, cela souligne la nécessité d'une visibilité plus approfondie sur le comportement des scripts tiers et sur la manière dont des entités externes pourraient manipuler le Document Object Model (DOM) de leurs sites publics. Cela soulève également des questions sur la dépendance à l'émission automatisée de certificats sans étapes supplémentaires de validation de domaine pour les transactions à haut risque.

Ce que vous pouvez faire

• Surveillez régulièrement les archives des annonces des moteurs de recherche pour détecter toute utilisation non autorisée de votre nom de marque ou de domaines imitatifs.
• Implémentez des en-têtes stricts de Content Security Policy (CSP) pour restreindre quels scripts peuvent charger et où les données peuvent être envoyées.
• Utilisez des hachages d'intégrité des sous-ressources (SRI) pour les fichiers JavaScript critiques afin d'empêcher la falsification ou le remplacement par des proxies.
• Éduquez vos clients pour qu'ils vérifient le nom de domaine exact dans la barre d'adresse du navigateur avant de saisir leurs informations de paiement.
• Mettez en place des alertes pour les nouveaux domaines enregistrés contenant des variations de votre nom de marque ou des fautes d'orthographe courantes.
• Envisagez d'implémenter une authentification mutuelle TLS ou d'autres méthodes fortes de vérification client pour les points de terminaison API sensibles.