Desde abril de 2026, una campaña de phishing activa está atacando a organizaciones hoteleras en Europa y Asia, utilizando archivos comprimidos con «fotografías» para entregar un implante JavaScript en las estaciones de trabajo de recepción y front office. Según datos de Microsoft, la campaña explota la infraestructura legítima de Calendly y Google para eludir la autenticación del correo, y el objetivo final de los operadores aún no se ha establecido: no hay casos confirmados de robo de datos ni de despliegue de ransomware. La ausencia de atribución a una agrupación conocida y la falta de claridad sobre la fase final hacen que esta amenaza sea especialmente inquietante para la industria de la hospitalidad.
Mecanismo de entrega: «blanqueo de autenticación»
Los correos de phishing utilizan el nombre para mostrar «Booking Manager (via Calendly)» y explotan puntos débiles típicos del negocio hotelero: quejas de huéspedes, avisos sobre chinches, solicitudes de reserva, amenazas de inspecciones sanitarias y reseñas negativas. Se han observado correos en japonés, danés y neerlandés, predominando el japonés. El asunto del correo no contiene el nombre del destinatario ni el del establecimiento, lo que apunta a un envío masivo a listas de distribución y no a phishing dirigido.
La característica técnica clave es lo que Microsoft ha denominado authentication laundering (blanqueo de autenticación). Los mensajes se enrutan a través del sistema de notificaciones de Calendly, gracias a lo cual superan las comprobaciones SPF, DKIM y DMARC: los correos se envían realmente desde una infraestructura autorizada. Los protocolos de autenticación confirman que el remitente tiene derecho a enviar correo, pero no dicen nada sobre las intenciones del mensaje. Esta es una brecha fundamental que los operadores de la campaña explotan deliberadamente.
A continuación, la víctima atraviesa una cadena de redireccionamientos de varios pasos: enlace de Calendly → share.google → redirección de Google → un dominio recién registrado en la zona .cfd, protegido por Cloudflare. En la página de destino se utiliza Cloudflare Turnstile, que al mismo tiempo cumple la función de protección frente al análisis automatizado.
Cadena de infección: del ZIP al implante Node.js
Tras superar el CAPTCHA, la víctima descarga un archivo comprimido con un nombre del tipo photo-<números>.zip. En su interior se encuentra un acceso directo de Windows que se hace pasar por una imagen: en la primera oleada, IMG-<números>.png.lnk, y en la segunda, PHOTO-<números>.png.lnk.
Al abrir el archivo LNK se ejecuta un script de PowerShell que:
- Utiliza aritmética BigInt para decodificar una URL de descarga oculta
- Escribe un script .ps1 intermedio en el directorio %TEMP%
- Descarga el entorno de ejecución legítimo Node.js v24.13.0 desde nodejs.org en el espacio de usuario
- Ejecuta el implante JavaScript a través del runtime descargado sin necesidad de instalar Node.js en el sistema
El uso de un runtime legítimo es una elección deliberada: el binario de Node.js está firmado y no suele activar las soluciones antivirus, mientras que toda la lógica maliciosa se concentra en el código JavaScript.
Implante TonRAT e infraestructura de gestión
El implante, que en los informes de SOC Prime se rastrea como TonRAT, aplica un enfoque poco habitual para la resolución de direcciones de los servidores de mando: los dominios C2 se obtienen a través de la API de la blockchain TON, tras lo cual se establece un canal de comunicación cifrado mediante WebSocket. La obtención dinámica de direcciones C2 hace que las listas de bloqueo estáticas resulten poco eficaces: los operadores pueden cambiar la infraestructura de mando y control actualizando los registros en la blockchain.
Después de la compromisión, el implante se conecta a direcciones IP fijas mediante puertos no estándar: 8443, 8445, 8453, 5555 y el rango 56001–56003. En algunos hosts comprometidos se han observado acciones adicionales:
- Automatización de un navegador sin interfaz gráfica (headless) con los parámetros
--headless --no-sandbox - Verificación de la geolocalización a través de ip-api.com
- Apagado forzoso del sistema con el comando
cmd /c shutdown -s -t 0
La automatización del navegador podría indicar una preparación para el robo de sesiones de reserva o de credenciales desde interfaces web de sistemas de gestión hotelera, aunque Microsoft no ha confirmado escenarios de explotación concretos.
Contexto y cronología
La campaña fue documentada por primera vez aproximadamente dos semanas antes de la publicación de Microsoft: ITOCHU y SOC Prime describieron una cadena de infección similar: desde el phishing con temática hotelera, pasando por un archivo LNK hacia PowerShell y de ahí a un implante Node.js. Microsoft confirmó que sus conclusiones son coherentes con estos informes.
El phishing relacionado con reservas dirigido a empleados de hoteles es un patrón persistente en el panorama de amenazas. Sin embargo, esta campaña destaca frente a los esquemas habituales: el uso de la blockchain para la resolución de C2, el despliegue de un runtime completo en el espacio de usuario y la doble persistencia evidencian un mayor nivel de preparación por parte de los operadores.
Evaluación del impacto
Los sistemas de recepción, reservas y front office de los establecimientos hoteleros son los que corren mayor riesgo: son estas estaciones de trabajo las que procesan las solicitudes entrantes de los huéspedes y las que con más probabilidad abrirán la «foto» adjunta a una queja. La compromisión de estos sistemas puede abrir potencialmente el acceso a datos personales de huéspedes, información de pago y cuentas de sistemas de gestión hotelera.
La ausencia de una fase final de ataque confirmada no reduce la gravedad de la amenaza; significa que los operadores aún no han activado la carga útil definitiva o que sus acciones pasan desapercibidas. Un acceso persistente a los sistemas de un hotel puede monetizarse de múltiples formas: desde el robo de datos de tarjetas de crédito hasta la venta de accesos a otras agrupaciones.
Recomendaciones para detección y erradicación
Para la completa erradicación de la amenaza es necesario eliminar ambos mecanismos de persistencia: eliminar solo uno deja el otro activo:
- Eliminar la entrada del registro RunOnce que apunte al directorio ProgramData
- Eliminar la clave de registro Run correspondiente a Node.js
- Eliminar el runtime y los archivos .js del directorio
AppData\Local\Nodejs - Comprobar la existencia de conexiones salientes a los puertos 8443, 8445, 8453, 5555, 56001–56003
- Identificar procesos de Node.js iniciados desde directorios de usuario, y no desde las rutas de instalación estándar
Para la protección preventiva:
- Bloquear la ejecución de archivos LNK desde archivos ZIP a nivel de políticas de seguridad
- Configurar la monitorización de ejecuciones de PowerShell iniciadas por procesos explorer.exe con argumentos que contengan operaciones BigInt
- Restringir las conexiones salientes a dominios en la zona .cfd y a puertos no estándar desde las estaciones de trabajo de front office
- Formar al personal de recepción y reservas para que reconozca el phishing que se hace pasar por notificaciones de Calendly
La comprobación prioritaria debe abarcar todas las estaciones de trabajo de recepción, reservas y front office en busca de los artefactos descritos, ya que estos sistemas son el objetivo principal de la campaña. Dado que los correos superan las comprobaciones estándar de autenticación, las organizaciones del sector hotelero deberían considerar reglas de filtrado adicionales para las notificaciones entrantes de Calendly que contengan enlaces con redirecciones a través de Google hacia dominios en la zona .cfd.
