La campaña Scamwich usa proxies inversos para robar pagos de entregas de restaurantes

Investigadores de seguridad han identificado una sofisticada campaña de skimming de pagos, bautizada como "Scamwich", que tiene como objetivo a clientes de grandes cadenas de restaurantes. Activa entre julio y octubre de 2026, la operación utilizó dominios falsos promocionados mediante anuncios de búsqueda de Google para interceptar los detalles de las tarjetas de crédito durante el proceso de pago. Los atacantes emplearon tecnología de proxy inverso para clonar sitios web legítimos de restaurantes en tiempo real, asegurando que los menús y precios parecieran auténticos mientras redirigían silenciosamente los datos de pago a sus propios servidores.

Qué ocurrió

La campaña se basaba en una red de al menos 820 dominios similares (look-alike), muchos de los cuales fueron registrados poco antes de ser promocionados mediante anuncios pagados en buscadores. Estos anuncios imitaban las listas oficiales de restaurantes de marcas como Jersey Mike’s, dirigiendo a los usuarios a sitios fraudulentos alojados detrás de Cloudflare. Dado que Cloudflare emitía automáticamente certificados TLS válidos de Google Trust Services, los navegadores mostraban un indicador de conexión segura, otorgando una falsa credibilidad a los sitios estafa. A 4 de noviembre de 2026, 367 de estos dominios seguían activos y sirviendo contenido, aunque las campañas publicitarias específicas habían sido eliminadas de la plataforma de Google.

Una vez que un usuario llegaba a uno de estos sitios clonados, un servidor de proxy inverso se situaba entre la víctima y el sitio web legítimo del restaurante. Este proxy recuperaba cada página, elemento del menú y precio directamente del sitio real, garantizando que los horarios de apertura y el inventario estuvieran siempre actualizados. El sistema reescribía URLs y cabeceras sobre la marcha, reemplazando los nombres de host reales de la marca con el dominio falso. Esta técnica permitía que funcionalidades clave como la búsqueda de direcciones, el inicio de sesión y la gestión del carrito funcionaran sin problemas, ya que esas solicitudes seguían siendo dirigidas a las API backend legítimas a través del proxy.

El engaño ocurría exclusivamente en la etapa de pago. Los atacantes inyectaban tres scripts específicos en cada página para manipular el flujo de checkout. Un bloqueador de scripts impedía que herramientas legítimas de terceros, como banners de cookies o servicios de redirección de apps, se cargaran. Otro script, etiquetado como _jmu(), usaba un MutationObserver para reemplazar continuamente el iframe de pago legítimo por uno falso alojado en el servidor del estafador. Un tercer script, _chkT(), monitoreaba el botón del total del pedido cada medio segundo para asegurar que el formulario de pago falso mostrara el monto correcto. Cuando los usuarios ingresaban los datos de su tarjeta, la información se enviaba mediante una conexión socket.io en vivo a los operadores, quienes luego procesaban manualmente transacciones fraudulentas en otro lugar.

Detalles clave

• La campaña utilizó al menos 820 dominios únicos, con 367 aún activos a fecha de 4 de noviembre de 2026.
• Los atacantes ejecutaron al menos 47 anuncios de texto en Google Search bajo 46 cuentas de anunciantes diferentes utilizando nombres de negocio no relacionados.
• El kit de fraude usaba un proxy inverso para obtener contenido en vivo de sitios reales, asegurando que los menús y precios fueran siempre precisos.
• Tres scripts inyectados manejaban el bloqueo de scripts, el reemplazo del marco de pago y la sincronización del total del pedido.
• Los datos de tarjetas robados se transmitían vía socket.io a operadores humanos que evadían las verificaciones 3-D Secure en tiempo real.
• Las víctimas exitosas eran redirigidas a sitios legítimos de competidores mediante enlaces href.li después de establecerse una cookie valid=77777.

Antecedentes

Un proxy inverso es un servidor que se sitúa entre los dispositivos cliente y los servidores backend, reenviando solicitudes y devolviendo respuestas. En casos de uso legítimos, los proxies inversos mejoran el rendimiento, gestionan el balanceo de carga y proporcionan seguridad. Sin embargo, en este ataque, el proxy fue utilizado como arma para crear un espejo perfecto del sitio web objetivo. Al obtener contenido dinámicamente del sitio real, los atacantes evitaban la necesidad de mantener copias estáticas de menús o precios, que rápidamente quedarían obsoletos. Este enfoque también les permitía reutilizar la misma base de código para múltiples marcas de restaurantes simplemente cambiando la URL objetivo y la configuración del dominio.

El uso de Redes de Entrega de Contenido (CDN) como Cloudflare jugó un papel crítico en la credibilidad de la estafa. Las CDN a menudo proporcionan gestión automática de certificados TLS, lo que significa que los dominios fraudulentos mostraban conexiones HTTPS válidas. Para la mayoría de los usuarios, la presencia de un icono de candado en la barra de direcciones del navegador es una señal primaria de confianza. Al aprovechar esta infraestructura, los atacantes aseguraron que los indicadores técnicos de seguridad no generaran alarmas, forzando a los usuarios a depender de pistas visuales sutiles o de la inspección de la URL para detectar el fraude.

Por qué importa

Para los equipos que gestionan software autoalojado o aplicaciones web internas, este incidente destaca las limitaciones de las defensas tradicionales de perímetro de seguridad. El ataque no explotó una vulnerabilidad en el código o la infraestructura del restaurante; en cambio, explotó la confianza que los usuarios depositan en los resultados de búsqueda y los indicadores de seguridad del navegador. Las organizaciones que ejecutan servicios web orientados al cliente deben reconocer que su identidad de marca puede ser secuestrada externamente sin ninguna violación de sus propios servidores. Esto significa que monitorear la suplantación externa de marca es tan crítico como parchear vulnerabilidades internas.

La sofisticación del mecanismo de inyección de scripts demuestra que la detección automatizada de bots y las comprobaciones estándar de integridad pueden no ser suficientes contra adversarios determinados. Los atacantes apuntaron específicamente y deshabilitaron scripts que podrían haber revelado el fraude, como aquellos que redirigen a los usuarios móviles a las apps oficiales. Para los líderes de TI, esto subraya la necesidad de una mayor visibilidad sobre cómo se comportan los scripts de terceros y cómo entidades externas podrían manipular el Modelo de Objetos del Documento (DOM) de sus sitios públicos. También plantea preguntas sobre la dependencia de la emisión automática de certificados sin pasos adicionales de validación de dominio para transacciones de alto riesgo.

Qué puedes hacer

• Monitorea regularmente los archivos de anuncios de motores de búsqueda para detectar el uso no autorizado de tu nombre de marca o dominios similares.
• Implementa estrictas cabeceras de Política de Seguridad de Contenido (CSP) para restringir qué scripts pueden cargarse y dónde se pueden enviar los datos.
• Usa hashes de integridad de subrecursos (SRI) para archivos JavaScript críticos para prevenir la adulteración o el reemplazo por parte de proxies.
• Educa a los clientes para que verifiquen el nombre exacto del dominio en la barra de direcciones del navegador antes de ingresar información de pago.
• Configura alertas para nuevos dominios registrados que contengan variaciones de tu nombre de marca o errores ortográficos comunes.
• Considera implementar autenticación TLS mutua u otros métodos fuertes de verificación de cliente para endpoints de API sensibles.