Nadie explotó nada: quién verifica que eres tú antes de resetear tu MFA

El viernes 7 de agosto, Levi Strauss & Co. presentó un 8-K a la SEC para contar que un tercero no autorizado accedió a tres ordenadores propiedad de la empresa mediante ingeniería social y se llevó información corporativa. El documento no menciona ningún CVE ni ninguna versión sin parchear: el único vector que declara es ese. No hay nada ahí que se pudiera haber cerrado el martes anterior aplicando actualizaciones, y esa es exactamente la parte que nos interesa. El trabajo con el que la mayoría medimos la seguridad —parchear, actualizar, reiniciar— no habría cambiado nada.

Escribimos esto desde una posición incómoda. El aviso conjunto de CISA y el FBI sobre Scattered Spider, referencia AA23-320A, describe a un grupo que ataca a grandes empresas y a los help desks de IT que esas empresas tienen contratados. Nosotros somos un help desk de IT contratado: damos soporte gestionado 24x7 a empresas. Cuando alguien llama diciendo que ha perdido el móvil y no puede entrar en el correo, quien decide qué pasa a continuación es una persona de nuestro equipo. El aviso habla de compañías grandes, y conviene decirlo para no inflar la alarma; pero el procedimiento que describe se ejecuta igual en una empresa de treinta personas, con menos gente para verificar y más confianza previa. Así que este artículo va, en primer lugar, de nuestro propio procedimiento.

Lo que dice el 8-K y lo que no dice

Conviene ser preciso, porque en dos días esta historia ya se contaba de varias maneras distintas. El texto que Levi Strauss registró dice que un tercero no autorizado accedió y exfiltró determinada información corporativa tras entrar en tres ordenadores de empresa mediante un ataque de ingeniería social. Añade que la respuesta contuvo el acceso, que no hubo interrupción de las operaciones, que la compañía cree que no se vieron afectados datos de consumidores y que no considera que el incidente vaya a tener un impacto material. La investigación sigue abierta con ayuda externa.

Y ahora lo que no dice, que es igual de importante: no dice cómo fue la ingeniería social. No sabemos si fue una llamada, un mensaje por Teams, un correo o una mezcla. No hay atribución: ningún grupo lo ha reivindicado, y las relaciones que algunos medios han apuntado con campañas de suplantación telefónica son hipótesis, no un hecho confirmado. Nosotros no hemos participado en la respuesta a ese incidente y no tenemos información privilegiada de nada. Si alguien te cuenta el guion exacto de la llamada, se lo está inventando.

Con eso basta para lo que aquí importa. Tres ordenadores. Ninguna vulnerabilidad de por medio. Una empresa con presupuesto de seguridad de multinacional. Y un vector que no era técnico.

El 65% ya no entra por un CVE

El informe anual de respuesta a incidentes de Unit 42, la unidad de Palo Alto Networks, publicado el 17 de febrero de 2026 sobre los más de 750 incidentes graves que atendieron durante 2025, pone el número: el 65% del acceso inicial se consigue con técnicas basadas en identidad —robo de credenciales, evasión del MFA y configuraciones erróneas de IAM—. Y las debilidades de identidad tuvieron un papel material en casi el 90% de las investigaciones que hicieron. Es lo que se encontraron al entrar a limpiar, no una proyección. Tampoco es la primera cifra de esta familia que citamos este verano, y todas empujan hacia el mismo sitio.

Ese dato incomoda sobre todo por dónde deja el esfuerzo. Un ciclo de parcheo decente cuesta dinero, ventanas de mantenimiento, reinicios nocturnos y discusiones con quien no quiere que le toquen el servidor. Todo eso sigue siendo necesario y lo defendemos cada semana. Pero cubre la parte minoritaria del problema. La mayoritaria se decide en tres minutos de conversación, sin registro técnico, con una persona cansada al otro lado que quiere ayudar y cerrar el ticket.

El fallo no es de quien coge el teléfono

El aviso AA23-320A, actualizado el 29 de julio de 2025, describe el método con una sequedad que agradecemos: los atacantes se hacen pasar por empleados para convencer al personal de IT o del help desk de que facilite información sensible, resetee la contraseña del empleado y traslade su MFA a un dispositivo que ellos controlan. Y añade el detalle que más nos hizo pensar: usan técnicas «en capas», con varias llamadas y contactos previos cuyo único objetivo es averiguar qué pasos exige un reseteo en esa organización concreta.

Léelo otra vez. El atacante no rompe el procedimiento: lo estudia. Llama a las nueve, pregunta una tontería, cuelga. Llama a las once con otra excusa y comprueba si le piden el número de empleado. A la tercera ya sabe qué le van a preguntar y trae las respuestas. Contra eso, la formación anti-phishing del empleado sirve de poco: quien recibe la llamada es de los nuestros, y está haciendo su trabajo exactamente como se le pidió.

Aquí está la tesis de todo el artículo, y es una acusación al procedimiento, no a las personas: en muchísimas organizaciones —también en muchas que se auditan y certifican— sonar convincente cuenta como identidad. Saber el nombre del jefe, el departamento, los cuatro últimos dígitos del DNI o el día que entraste a trabajar no prueba nada, porque todo eso está en LinkedIn, en una filtración antigua o en la firma de cualquier correo. Si tu verificación se apoya en cosas que se pueden saber, tu verificación es un cuestionario, no una prueba.

El reseteo es la puerta de atrás de cualquier factor

Hay una respuesta muy extendida a esto que es correcta a medias y por eso resulta peligrosa: «nosotros ya tenemos MFA resistente a phishing». Escribimos hace unas semanas sobre la retirada del SMS como segundo factor en Microsoft Entra y sobre por qué las claves de acceso son mejores. Lo siguen siendo. Pero un factor criptográfico protege el uso de la credencial, no su inscripción. Si el mostrador de soporte puede registrar un factor nuevo para una cuenta a petición de quien llama, el atacante no necesita romper nada: se inscribe él.

Dicho de otra forma: la fortaleza de tu autenticación es la del camino más débil para obtenerla, y ese camino casi nunca es el criptográfico. Es el formulario de «he perdido el móvil». Merece la pena mirar esto con la misma lupa con la que miramos el acceso privilegiado del proveedor: hace unos días contábamos que el agente de gestión remota de tu proveedor de IT es superficie de ataque, y esto es el mismo problema visto desde el otro lado del cable. Uno da acceso al equipo; el otro, a la identidad. En la práctica, acaban en el mismo sitio.

Ocho puntos que pedimos antes de resetear

Esto es criterio nuestro, no una norma que puedas citar en una auditoría. Es lo que consideramos mínimo para que un reseteo de contraseña o una reinscripción de MFA no dependa de lo convincente que suene una voz. Ocho puntos, y ninguno necesita comprar software:

• Devolución de llamada al número del directorio. No al número que aparece en la pantalla ni al que dicta quien llama. Si el número del directorio está desactualizado, el problema es el directorio y toca arreglarlo, no saltarse el paso.
• Aprobación fuera de banda de un responsable identificado. Un segundo humano, en otro canal, que confirme que esa persona es quien dice. Y con nombre: «lo aprobó alguien de RRHH» no vale.
• Prohibir los datos «conocibles» como prueba. DNI, fecha de alta, nombre del responsable, número de empleado: sirven para localizar el expediente, nunca para autorizar el cambio.
• Verificación en vídeo con documento para las cuentas que lo merecen. Es incómodo y lento. También es lo único que no se resuelve leyendo un perfil público.
• Lista corta de cuentas que el soporte no resetea nunca por teléfono. Administración global, dirección, finanzas, quien firma pagos. Para esas, presencial o con un segundo aprobador de la propia empresa.
• Aviso automático al usuario legítimo por un canal distinto. Si a alguien le resetean el MFA y no ha sido él, que se entere en el mismo minuto y sepa a quién llamar.
• Cuarentena después de reinscribir un factor. Unas horas en las que esa identidad no llega a lo más sensible. Un empleado real que ha perdido el móvil puede esperar a mañana para entrar en la banca de la empresa; un atacante con prisa, no.
• Permiso explícito para decir que no. Por escrito y firmado por la dirección del cliente: nadie de soporte será reprendido por hacer esperar a un director que no pudo verificarse. Sin esto, los siete puntos anteriores son decoración.

El octavo es el que de verdad decide si esto funciona, y es el único que no depende de nosotros. La presión jerárquica es la herramienta principal del ataque: quien llama exagera la urgencia y su cargo precisamente porque sabe que a las siete de la tarde nadie quiere ser quien le dice que no al director financiero.

El precio, en minutos y en enfados

Un reseteo que hoy se resuelve en tres minutos pasa a tardar veinte o treinta, y algunos no se resuelven hasta el día siguiente. Alguien se va a enfadar, y con razón, porque llega tarde a una reunión por culpa de un procedimiento nuestro. Ese es el precio real y no lo vamos a disfrazar: la seguridad de la identidad se paga en fricción, no en licencias.

Por eso esta no es una decisión del departamento de IT. Un proveedor no puede imponer fricción a los usuarios de su cliente sin que la dirección del cliente la haya aceptado antes por escrito, porque a la tercera queja la fricción desaparece y vuelve el «bueno, a este ya le conozco». La conversación difícil, cuando esto se define bien, es acordar a quién se le puede hacer esperar.

Cuatro atajos que no vamos a tomar

• Contratar más formación anti-phishing y darlo por resuelto. Ayuda con el correo. El problema es otro: aquí decide tu personal de soporte, y lo que le falta es un procedimiento que le permita negarse.
• Fiarnos del identificador de llamada. Falsificar el número de origen es más difícil que hace dos años: desde junio de 2025, y por la Orden TDF/149/2025, los operadores españoles tienen que bloquear las llamadas internacionales que se presentan con numeración española. Pero ese bloqueo no cubre lo que se origina dentro de España ni convierte el identificador en una prueba. Que en la pantalla salga el número interno de la empresa no autoriza nada.
• Aplicar el procedimiento duro a todo el mundo. Si verificar en vídeo cuesta lo mismo para el becario que para el director financiero, el becario deja de llamar y se apaña por su cuenta, que es peor. Gradúalo por lo que la cuenta puede hacer.
• Dar por hecho que un incidente así se ve en el ticket. Un reseteo aprobado no genera ninguna alerta: es una operación legítima hecha por gente legítima. Solo se ve después, en lo que la cuenta hace a continuación.

Y después de la llamada

El último punto de la lista anterior es el que enlaza con la otra mitad del trabajo. Si el acceso se consigue por la puerta y con las llaves buenas, ninguna barrera de entrada lo va a detener; lo que queda es notar lo que pasa después. Un buzón que de repente crea una regla de reenvío, una cuenta que entra desde un sitio nuevo veinte minutos después de un reseteo, un portátil que empieza a leer carpetas compartidas que nunca había abierto. Eso es detección y respuesta gestionada, y es el segundo control cuando el primero se ha saltado limpiamente.

Con un matiz que llevamos repitiendo desde que escribimos sobre la fatiga de alertas: una alerta de reinscripción de MFA que llega a un buzón que nadie mira es exactamente igual de útil que no tenerla. Si vas a activar avisos por cada cambio de factor, decide antes quién los lee un domingo por la tarde y qué hace con ellos. Si la respuesta es «ya lo vemos el lunes», mejor no encenderlos y no engañarse.

Nada de esto es novedad, y ese es el problema. El aviso de CISA lleva desde 2023 explicando el método, se actualizó hace un año largo y sigue describiendo con precisión lo que pasó el viernes en una empresa muchísimo más grande que la mayoría de las que atendemos. Si no has escrito nunca qué se pide antes de resetear un MFA, hoy es un buen día. Y si quieres que lo revisemos contigo, hablamos y lo miramos con lo que ya tengas escrito.