Un mensaje malicioso llegó desde la aplicación legítima del retailer británico, exponiendo cómo el control de canales de confianza redefine el perímetro de la ingeniería social.
Esta semana, clientes de ASOS abrieron sus teléfonos y encontraron una notificación push hostil entregada a través de la aplicación oficial del retailer. El mensaje afirmaba que el ambiente Snowflake de la compañía había sido comprometido y dirigía a ASOS a comunicarse con los atacantes vía Telegram. La compañía confirmó posteriormente a Sky News que se había enviado una notificación no autorizada y que estaba investigando actividad vinculada a plataformas de terceros utilizadas para comunicaciones con clientes. ASOS indicó que información personal básica — nombres y detalles de contacto — pudo haber sido accedida, mientras que datos de tarjetas de pago y contraseñas de cuenta no se vieron afectados. Snowflake informó a Sky News que su investigación no encontró compromiso de la plataforma Snowflake en ese momento. Las afirmaciones más amplias de los atacantes permanecen sin verificar.
Cuando el mensaje llega desde la app real, las señales tradicionales de alerta desaparecen
La mayoría de las recomendaciones de concientización en seguridad asumen que habrá algo sospechoso que el destinatario pueda notar: un remitente desconocido, un dominio levemente incorrecto, una solicitud fuera de contexto. Esas verificaciones pierden utilidad cuando el mensaje llega a través de la aplicación genuina instalada en el teléfono de alguien. Los atacantes ya venían moviéndose en esta dirección en otros contextos. Investigación de Rapid7 sobre phishing basado en calendario mostró cómo contenido malicioso puede aparecer dentro de flujos de trabajo familiares, mientras que análisis previos sobre la evolución de la ingeniería social exploraron el uso creciente de herramientas de colaboración y otras plataformas cotidianas para hacer que los ataques parezcan rutinarios.
El incidente de ASOS traslada ese problema a un entorno de cara al cliente. Una vez que un atacante tiene acceso a un sistema que puede hablar en nombre de una empresa, la confianza construida alrededor de ese sistema puede trabajar también a favor del atacante. Douglas McKee, director de inteligencia de vulnerabilidades en Rapid7, señaló que un atacante prefiere tomar prestada la confianza que ya existe en lugar de invertir tiempo en construir la propia. Una notificación que sale de una app real le da al atacante esa ventaja inicial: no hay dominio extraño ni remitente desconocido que detectar, por lo que la actividad puede verse como una tarde de martes normal.
Actividad sospechosa dentro de servicios legítimos — el desafío de investigar sin infraestructura maliciosa obvia
Un atacante no siempre necesita infraestructura obviamente maliciosa para crear daño. Una cuenta legítima, integración o plataforma SaaS usada de manera inesperada puede proporcionar acceso a empleados, clientes o socios mientras genera actividad que puede parecer relativamente ordinaria cuando se ve de forma aislada. Si un servicio de comunicaciones con clientes envía repentinamente una notificación inusual, el equipo de seguridad necesita entender qué sucedió alrededor de ella: quién accedió a la plataforma, si cambiaron credenciales o permisos, qué servicios conectados estuvieron involucrados y si apareció actividad sospechosa en otra parte del entorno.
ASOS indicó que la actividad involucró plataformas de terceros utilizadas para comunicaciones con clientes, mientras que TechRadar reportó que la conexión alegada con Snowflake podría haber sido indirecta — a través de servicios corriendo sobre la plataforma — en lugar de evidencia de un compromiso de Snowflake en sí. Ese tipo de entorno puede dejar a los investigadores trabajando a través de varios proveedores, identidades y sistemas antes de tener una imagen completa de lo ocurrido. Cuando los atacantes usan identidades legítimas, integraciones, servicios en la nube o plataformas de comunicación, los analistas necesitan conectar comportamiento a través de sistemas en lugar de depender de una dirección IP conocida como maliciosa o una firma de malware para contar la historia.
El primer mensaje crea una segunda ola de riesgo — phishing oportunista sobre un incidente real
Un incidente visible puede dar a otros atacantes material útil. Una vez que los clientes saben que algo sucedió, un correo electrónico o mensaje de texto de phishing que ofrezca una actualización de cuenta, reembolso, restablecimiento de contraseña o verificación de seguridad tiene inmediatamente un evento creíble detrás. Investigación de Rapid7 sobre exposición de huella digital ha mostrado cómo información filtrada puede combinarse con datos disponibles públicamente para respaldar phishing, suplantación y fraude más convincentes. Nombres y detalles de contacto pueden parecer limitados comparados con contraseñas o información de pago, pero aún pueden volverse valiosos cuando se combinan con un incidente real y una marca reconocible.
Para América Latina, donde el comercio electrónico transfronterizo con retailers europeos y estadounidenses ha crecido sostenidamente en los últimos años, este tipo de incidente expone una vulnerabilidad estructural: los equipos de seguridad locales rara vez tienen visibilidad directa sobre las plataformas de terceros que usan esos proveedores para comunicarse con clientes en la región. Un mensaje malicioso enviado desde la app oficial de un retailer internacional puede llegar a usuarios en México, Brasil o Argentina sin que exista capacidad local de detección temprana, y la barrera idiomática puede retrasar aún más la respuesta cuando el incidente se reporta primero en medios angloparlantes. La dependencia de servicios SaaS globales para notificaciones push, email marketing y gestión de clientes significa que un compromiso en la cadena de comunicación afecta simultáneamente a múltiples mercados sin que cada uno tenga control individual sobre el canal.
Nuestro análisis
El caso de ASOS marca un punto de inflexión en cómo pensamos el perímetro de confianza en comunicaciones corporativas. Durante años, la industria de seguridad ha entrenado a usuarios finales para que desconfíen de remitentes desconocidos, dominios sospechosos y enlaces inesperados. Ese modelo asume que el canal de comunicación en sí es neutral y que el riesgo viene del contenido o del origen. Cuando un atacante puede enviar mensajes desde la aplicación oficial de una empresa — no una copia, no un dominio parecido, sino la app real instalada en el teléfono del cliente — ese modelo se quiebra. No hay señal técnica que el usuario pueda verificar: el certificado es correcto, la app es legítima, el canal es el esperado. La única anomalía está en el contenido del mensaje, y eso requiere un nivel de contexto y criterio que no se puede automatizar ni delegar completamente en el usuario final.
Lo que todavía no sabemos es cómo los atacantes obtuvieron acceso al sistema de notificaciones push de ASOS. La mención de plataformas de terceros sugiere que el compromiso no fue directo en la infraestructura de ASOS, sino en algún proveedor de servicios de comunicación con clientes — posiblemente una plataforma de marketing automation, un servicio de notificaciones móviles o un sistema de gestión de campañas. Esa cadena de dependencias es común en el comercio electrónico moderno: un retailer puede usar un proveedor para email, otro para SMS, otro para push notifications, y cada uno de esos proveedores puede a su vez correr sobre infraestructura de nube de un cuarto actor. Investigar un incidente en ese entorno significa reconstruir permisos, integraciones y actividad a través de múltiples plataformas que pueden no compartir logs de manera uniforme. Si este patrón se repite en otros retailers con arquitecturas similares, ¿cuántos equipos de seguridad tienen hoy visibilidad completa sobre quién puede hablar en nombre de su empresa a través de canales que los clientes ya confían?