Día 0: un mensaje de RR. HH. que parecía rutinario
Un correo electrónico que parecía provenir de Recursos Humanos anunciaba un cambio en los turnos y en la forma de calcular las horas. Los empleados debían confirmar sus datos antes del viernes. El enlace dirigía a una copia del portal del empleado, idéntica a la real.
El dependiente de la tienda introdujo su nombre de usuario y contraseña. Ese portal no solicitaba verificación en dos pasos. Se consideró innecesaria porque el portal "solo se accedía desde la tienda". Las mismas credenciales funcionaban desde fuera y, esa misma noche, alguien las utilizó. Nadie informó de nada.
Días 1 a 3: un mapa de quién es quién
La cuenta de un dependiente no puede hacer mucho, pero sí puede observar. Los sistemas internos de cualquier empresa contienen, por diseño, una guía de la organización: nombres, cargos, números de empleado y quién tiene permisos sobre qué.
En tres días, el atacante había identificado al pequeño grupo de personas que administran todos los sistemas de la empresa. A partir de ese momento, el objetivo dejó de ser la red y pasó a ser una de esas personas.
Día 4: cuatro minutos al teléfono
El atacante llamó al servicio de asistencia técnica y se hizo pasar por uno de esos administradores, utilizando su nombre, cargo y número de empleado. La historia era urgente y creíble: estaban en una tienda, habían perdido su teléfono y no podían validar su acceso.
El agente hizo exactamente lo que dictaba el procedimiento. Verificó el nombre, el cargo y el número de empleado, y los tres eran correctos. Restableció el acceso. Media hora después, el atacante administraba los sistemas de la empresa con los mismos permisos que la persona a la que había suplantado.
La llamada duró menos de cuatro minutos. Nadie fue negligente, ya que el procedimiento verificó datos que el atacante ya poseía.
Este patrón está bien documentado más allá de un solo caso. Mandiant rastrea grupos como UNC3944 que atacan a los servicios de asistencia técnica de TI para eludir la autenticación multifactor y obtener acceso inicial (Mandiant M-Trends 2026, marzo de 2026). El Center for Internet Security describe a atacantes que se hacen pasar por empleados para conseguir que el personal de soporte restablezca contraseñas. Otros piden que se traslade el registro de MFA a un dispositivo que el atacante controla (Center for Internet Security, agosto de 2026).
Días 4 y 5: la copia antes del bloqueo
Antes de romper nada, el atacante pasó un día y medio copiando información de la empresa: registros de empleados, clientes del programa de fidelización, contratos y contabilidad. Los datos salieron durante el horario laboral, a través de un canal que parecía una sincronización rutinaria desde el interior.
Casi nadie espera este paso, y es precisamente el que hace que las copias de seguridad no sean la solución.
Día 6: todo se detiene de golpe
Durante la noche, desde un único punto de administración, el atacante desactivó las copias de seguridad y cifró los sistemas. No ocurrió máquina por máquina. Todo cayó al mismo tiempo.
Las cajas registradoras, el inventario, la logística, la nómina y el correo electrónico se detuvieron justo antes del horario de apertura. Las tiendas que pudieron se pasaron al papel, y el resto no abrió. Todas las pantallas mostraban el mismo mensaje: un identificador, una dirección de contacto y una fecha límite.
La extorsión: dos relojes, un guion
La nota establecía dos plazos. Uno marcaba la cuenta atrás hasta el momento en que el rescate se duplicaría, y el otro hasta la publicación de los datos robados. Esa misma mañana, la empresa activó su plan de crisis y llamó a su firma de respuesta a incidentes, a su aseguradora y a las autoridades.
Al otro lado no había ningún fanático. Había un operador con un horario laboral y un guion. Su argumento no era el cifrado, sino la información que habían obtenido dos días antes. El cifrado paraliza, pero lo que se cobra es la información. Al tercer día publicaron una muestra con el nombre de la empresa, por lo que el plazo también corrió de forma pública.
La empresa no pagó. Restauró los sistemas a partir de las copias de seguridad que se habían mantenido a salvo, y llevó semanas porque nadie había ensayado el orden en el que debían restablecerse los sistemas. Los datos se publicaron de todos modos. Luego llegó la notificación a la autoridad de protección de datos, los avisos a clientes y empleados, y un expediente que duró mucho más que la interrupción del servicio.
Pagar no habría evitado nada de eso. Una vez que la información está fuera, un rescate solo compra una promesa.
Por qué funcionó el ataque
El ataque tuvo cinco eslabones y ninguno requirió herramientas avanzadas. Cada uno explotó una decisión razonable que nadie había vuelto a revisar.
El objetivo fue la persona más accesible, no la más importante. El empleado no manejaba datos valiosos. Tenía credenciales válidas y ninguna razón para desconfiar del mensaje.
Una excepción abrió la puerta. Prescindir de la verificación en dos pasos para el personal de tienda tenía sentido el día que se decidió. Nadie lo revisó cuando esas mismas credenciales empezaron a funcionar desde el exterior.
El servicio de asistencia es un control de seguridad. Es el único punto de la organización cuyo trabajo explícito es devolver el acceso a alguien que dice haberlo perdido. Rara vez se le forma como tal.
Las señales existían, pero nunca se cruzaron. Una conexión externa a medianoche desde una cuenta de tienda. Una transferencia de datos inusual durante dos días. Cada señal llegó a un lugar distinto y nadie las puso en común.
La formación anual no sobrevive al momento de la decisión. Pasan meses entre el curso y el correo electrónico. Entre el correo y el clic, pasan segundos. El conocimiento permanecía intacto, pero nunca se activó bajo presión.
El margen de maniobra estaba antes de la negociación
La negociación fue la única etapa del incidente en la que la empresa ya no tenía margen. Todo el margen estaba antes: en el correo electrónico que nadie reportó y en la llamada que nadie cuestionó.
Eso cambia dónde debe mirar un líder de seguridad. La pregunta habitual es cómo detener el cifrado. Una más útil es qué decisiones ordinarias, tomadas por qué roles, puede activar un extraño con una historia plausible.
Visto así, el empleado y el agente de soporte eran dos personas tomando decisiones rutinarias con la información que tenían delante. El proceso que los rodeaba asumía que esa información era privada. El comportamiento es el sistema que hay que mejorar y, en este caso, podría haberse medido mucho antes del incidente.
Qué significa esto para los equipos de seguridad
Empiece por el servicio de asistencia. Un procedimiento de verificación basado únicamente en el nombre, el cargo y el número de empleado solo comprueba lo que un atacante puede obtener de la primera cuenta comprometida. Ponerlo a prueba con una llamada realista, utilizando a un empleado real, un dato correcto y una urgencia razonable, demuestra si el procedimiento es sólido o si solo lo parece.
Revise las excepciones de forma programada, no solo cuando se crean. Una regla que era segura cuando las credenciales solo funcionaban dentro de la tienda deja de serlo cuando cambia el contexto. Lo mismo se aplica a cualquier control omitido para un grupo de personal porque el riesgo parecía bajo.
Trate los informes como un resultado que debe medir. Cuántas personas denunciaron el correo electrónico de RR. HH. y con qué rapidez le dice más sobre su exposición que cuántas personas hicieron clic. Un solo aviso temprano le habría dado a la empresa varios días para reaccionar, no horas.
Capacite por roles, en el momento en que importa. Un dependiente de tienda y un agente de soporte técnico se enfrentan a ataques diferentes a través de canales distintos. Un programa que solo simule el phishing por correo electrónico habría detectado el primer eslabón de este ataque y habría pasado por alto el que lo cerró.
Esta es la parte del incidente que podemos medir, entrenar y reducir en Zepo. El ataque tuvo cinco eslabones y el cifrado fue el último. Los dos que lo abrieron y lo cerraron fueron personas haciendo su trabajo con la información que tenían.
Preguntas frecuentes
¿Qué es el vishing? El vishing es el phishing por voz: un atacante llama a un objetivo y utiliza una historia creíble, a menudo con nombres y datos de empleados reales, para obtener acceso o información. Mandiant lo clasificó como el segundo vector de infección inicial más común en 2025, representando el 11% de las intrusiones (Mandiant M-Trends 2026, marzo de 2026).
¿Cómo superan los atacantes la verificación del servicio de asistencia? Recopilan los detalles que solicita el procedimiento, como el nombre, el cargo y el número de empleado, a partir de una cuenta comprometida o de fuentes públicas. El agente verifica entonces datos que el atacante ya posee, por lo que una respuesta correcta no demuestra nada.
¿Por qué las copias de seguridad no son suficientes contra el ransomware? Los atacantes suelen copiar los datos antes de cifrarlos. Restaurar desde copias de seguridad recupera los sistemas, pero no recupera la información robada, que el atacante aún puede publicar o vender.
¿Cómo se comprueba si un servicio de asistencia resiste la ingeniería social? Realice una simulación de llamada realista con la identidad de un empleado real, datos de verificación correctos y una razón urgente plausible. Mida si el agente restaura el acceso, escala la situación o solicita un segundo canal de verificación.