El help desk es el nuevo perímetro: endurece el reset de MFA

Por qué el soporte se volvió el objetivo (la conclusión en una frase)

Si tu organización ya tiene MFA en todas las cuentas, el ataque más probable ya no intenta romperlo: intenta que alguien de tu equipo lo apague por él. Ese alguien casi siempre es el help desk. Un atacante que se hace pasar por un empleado bloqueado llama, pide un reset del segundo factor y, si el proceso de verificación es débil, se lleva el acceso sin explotar una sola vulnerabilidad técnica.

La conclusión, en una frase: el soporte se volvió el perímetro, y se endurece con proceso, no con más herramientas. El primer paso concreto, el que más rinde, es exigir una verificación fuera de banda antes de aprobar cualquier reset de MFA, para que la identidad del que llama no dependa de datos que cualquiera puede averiguar.

Vale la pena entender por qué este flanco pesa tanto. El marco 90-5-5 de Cisco estima que cerca del 90 por ciento de las brechas involucran un factor humano, y el help desk concentra ese factor en un punto de decisión: una persona, bajo presión, autorizando un cambio sensible por teléfono. No es descuido, es el diseño mismo del trabajo de soporte, que existe para desbloquear gente rápido. El atacante no ataca una falla del sistema, ataca la vocación de ayudar.

Cómo el atacante convierte al soporte en el atajo que salta el MFA

El engaño rara vez empieza en la llamada. Suele empezar antes, por correo. Según CISA, más del 90 por ciento de los ciberataques exitosos comienzan con un correo de phishing, y ese primer correo le da al atacante el insumo que necesita: una contraseña filtrada, un nombre real, el nombre del jefe, la jerga interna. Con eso arma un pretexto creíble y entonces sí levanta el teléfono. La llamada al soporte no reemplaza al correo, se suma a él como el segundo movimiento que convierte una credencial robada en acceso pleno. La ingeniería social por teléfono contra el soporte viene creciendo con fuerza en 2026, y buena parte del acceso inicial de hoy nace de credenciales que ya estaban expuestas.

El guion es siempre parecido. El atacante se presenta como un empleado con un problema urgente: un viaje, una reunión con un cliente, un celular perdido, y pide resetear el MFA para volver a entrar. Aporta justo los datos que un proceso débil pide como prueba, los últimos dígitos de un documento, la fecha de ingreso, el nombre del gerente. Todos esos datos se filtran o se compran. Cuando el agente de soporte, con la mejor intención, aprueba el reset, el atacante inscribe su propio dispositivo como segundo factor, y a partir de ahí el MFA lo protege a él.

Lo que viene después es rápido, y esa velocidad es la que sube la apuesta. Según el M-Trends 2026 de Mandiant (Google Cloud), el tiempo de traspaso entre el acceso inicial y el actor que ejecuta el ataque se desplomó de más de ocho horas en 2022 a 22 segundos en 2025. Traducido al help desk: entre que el reset se aprueba y el intruso empieza a moverse lateralmente casi no queda ventana para reaccionar. El control tiene que estar antes del reset, nunca después.

Paso 1: exige verificación fuera de banda antes de cualquier reset

El principio es simple: la prueba de que alguien es quien dice no puede viajar por el mismo canal desde el que pide el favor. Si la solicitud llega por teléfono, la verificación sale por otro lado. En la práctica esto significa devolver la llamada al número registrado del empleado en el directorio (no al número desde el que llamó), enviar un código a un canal ya validado, o exigir una confirmación por video con el documento a la vista para los roles sensibles.

La regla que no se negocia: quien pide el reset no controla el canal por el que se verifica su identidad. Ese solo cambio derrumba la mayoría de los pretextos, porque el atacante puede imitar una voz y un tono, pero no puede contestar el teléfono del empleado real ni recibir el código en su dispositivo registrado.

Paso 2: separa quién solicita de quién aprueba (doble control)

Un reset de MFA aprobado por una sola persona es un único punto de falla, y los atacantes lo saben: eligen la hora de más carga, el turno de la madrugada, el agente recién llegado. La defensa es el doble control. Para las cuentas de mayor riesgo, personal de finanzas, direcciones, administradores de sistemas, que quien recibe la solicitud no sea quien la aprueba.

El agente registra el pedido y un segundo rol, un supervisor o el propio dueño de la cuenta por un canal separado, da el visto bueno. No hace falta aplicarlo a los mil empleados por igual, se aplica donde el daño de un reset indebido es mayor. Así la fricción se concentra donde de verdad importa, y el atacante pierde el eslabón único que venía a buscar.

Paso 3: endurece la prueba de identidad más allá de datos que se filtran

El error más común es verificar identidad con datos que hace rato dejaron de ser secretos. El número de documento, la fecha de nacimiento, el cargo, la fecha de ingreso, incluso los últimos movimientos, todo eso aparece en brechas, se ve en redes sociales o se compra en foros. Preguntarlo da una falsa sensación de rigor.

La prueba fuerte se apoya en algo que el atacante no tiene: un factor que la empresa controla de punta a punta. Sirven un código de un solo uso enviado a un dispositivo previamente registrado, una llave de seguridad física para los roles críticos, o una prueba de vida por video con el empleado mostrando su documento para los resets más delicados. El criterio de fondo es uno solo: si la respuesta se puede averiguar, no prueba nada.

Paso 4: registra, limita y revisa cada reset de MFA

Todo lo anterior se cae si nadie mira lo que pasa. Cada reset de MFA se registra con quién lo pidió, quién lo aprobó, por qué canal se verificó y a qué hora. Ese registro convierte un evento invisible en una señal auditable.

Sobre él se ponen límites: alertar cuando una misma cuenta pide varios resets en poco tiempo, cuando el pedido llega fuera del horario del empleado, o cuando se concentran varios en una franja corta. Y se revisa: una lectura semanal de los resets aprobados detecta el patrón que un solo agente, en el momento, no alcanza a ver. El objetivo no es frenar al soporte, es dejar rastro para que un reset fraudulento no pase inadvertido justo en los días en que más daño hace.

Cómo pruebas y validas que el soporte resiste el engaño

Un proceso escrito no prueba nada hasta que alguien intenta romperlo. Por eso el soporte, como cualquier rol de alta exposición, se pone a prueba: se simula el intento de engaño y se mide cómo responde el equipo bajo presión real, no en un examen donde la persona sabe que la evalúan.

Y aquí conviene una distinción que la evidencia respalda. Hay trabajo revisado por pares, el de Grant Ho y su equipo en el IEEE Symposium on Security and Privacy de 2025, y antes el de Daniele Lain y colegas en 2022, que muestra que completar una capacitación no predice por sí solo que la persona actúe distinto frente a un ataque real. Lo que demuestra el cambio no es el curso, es volver a probar el comportamiento semanas después, con otro escenario, y ver si el equipo aplicó lo aprendido. A eso lo llamamos retest, y es la diferencia entre suponer que el soporte aprendió y comprobarlo.

Este texto endurece el proceso; para entender la anatomía del ataque telefónico que lo pone a prueba, escribimos aparte sobre el vishing al soporte técnico, que describe el fraude en sí, no cómo blindar el reset. Son piezas complementarias: una explica el ataque, esta levanta la defensa.

En Fensivo tratamos al equipo de soporte como lo que es, un rol de alta exposición, y lo probamos con simulaciones de phishing por correo personalizadas según su función, no con un curso genérico. Cuando alguien cae, la capacitación llega enseguida y, semanas después, un retest con otra plantilla valida si el comportamiento cambió de verdad. No operamos tu help desk ni reemplazamos tu proceso de verificación: te damos la señal de qué roles resisten el engaño y cuáles todavía no, para que endurezcas el reset donde más falta hace. Puedes ver cómo encaja en nuestros casos de uso.

Así que la pregunta incómoda es esta: si un atacante llamara hoy a tu help desk haciéndose pasar por tu director financiero y pidiera resetear su MFA, ¿qué se lo impediría, tu proceso o la suerte del agente que conteste?

Fuentes y referencias

• Cisco, "The 90-5-5 Concept: Your Key to Solving Human Risk in Cybersecurity", 27 de mayo de 2025: https://blogs.cisco.com/security/the-90-5-5-concept-your-key-to-solving-human-risk-in-cybersecurity
• CISA, "4 Things You Can Do To Keep Yourself Cyber Safe": https://www.cisa.gov/news-events/news/4-things-you-can-do-keep-yourself-cyber-safe
• Mandiant (Google Cloud), "M-Trends 2026 Report": https://cloud.google.com/security/resources/m-trends
• Ho, G. et al., "Understanding the Efficacy of Phishing Training in Practice", 2025 IEEE Symposium on Security and Privacy: https://ieeexplore.ieee.org/document/11023357
• Lain, D., Kostiainen, K. y Čapkun, S., "Phishing in Organizations: Findings from a Large-Scale and Long-Term Study", 2022 IEEE Symposium on Security and Privacy: https://ieeexplore.ieee.org/document/9833766