Activaste el MFA en todo Microsoft 365. Hiciste bien. Y aun así, un atacante puede entrar a la cuenta de tu gente sin robar la contraseña y sin que nadie apruebe una notificación falsa en el teléfono.
No es un fallo de tu configuración. Es que el ataque más común de 2026 no ataca la parte que protegiste. Esta nota es la anatomía de cómo funciona, contada desde el lado del que se defiende: qué pasa paso a paso, cómo se detecta, y por qué hay una sola defensa que lo corta de raíz mientras las demás apenas lo demoran.
Es la continuación técnica de ya tenés MFA y no alcanza: ahí está el qué; acá está el cómo.
Aclaración de entrada, porque marca el tono de todo lo que sigue: no vas a encontrar acá ninguna instrucción para montar el ataque. Entender el mecanismo es lo que te permite defenderte; los pasos para ejecutarlo no aportan nada a esa defensa y no van.
Lo que el atacante quiere no es tu contraseña
Empecemos por corregir la imagen mental equivocada. Cuando pensás en "robo de cuenta" imaginás a alguien adivinando o robando tu contraseña. El MFA se inventó justamente para que eso no alcance: aunque tengan la clave, les falta el segundo factor.
El ataque moderno acepta esa premisa y la esquiva. No pelea contra el MFA: espera a que vos lo completes y le roba el resultado.
Ese resultado tiene nombre: el token de sesión (o cookie de sesión). Cuando iniciás sesión en Microsoft 365 y aprobás el segundo factor, el servidor te entrega una credencial temporal que dice "esta persona ya se autenticó, dejala trabajar sin volver a preguntarle". Tu navegador la guarda y la presenta en cada pedido siguiente. Es lo que hace que no tengas que poner la contraseña cada vez que abrís un correo.
Si un atacante consigue esa cookie, hereda tu sesión ya autenticada. No necesita tu contraseña, no necesita tu segundo factor, no necesita tu teléfono. Para el servidor, presenta la misma credencial que vos presentaste, así que es vos.
El mecanismo, paso a paso
El ataque se llama adversary-in-the-middle (AiTM), adversario en el medio. La pieza central es un servidor intermedio que el atacante pone entre vos y Microsoft, haciendo de espejo. La técnica está documentada por Microsoft en su guía sobre autenticación resistente a phishing y es la que explica por qué el segundo factor común no alcanza.
Paso a paso, del lado de la víctima:
- Llega el correo. Un mensaje convincente —una factura, un documento compartido, un aviso de que "tu contraseña vence"— con un enlace. La puerta de entrada casi siempre es el correo, y por eso reforzarlo es la primera línea; la comparativa de seguridad de email para PyMEs y la guía de SPF, DKIM y DMARC atacan ese frente.
- El enlace lleva al espejo, no a Microsoft. La página se ve idéntica a la de Microsoft porque es la de Microsoft: el servidor intermedio le pide las páginas reales a Microsoft y te las reenvía. No es una copia mal hecha con un logo pixelado; es el sitio verdadero, servido a través del intermediario.
- Ponés tu contraseña. Funciona. El intermediario se la pasa a Microsoft en tiempo real. Microsoft la valida.
- Te pide el segundo factor. Lo completás. Funciona. El intermediario también reenvía eso. Desde tu lado, todo se comportó exactamente como siempre, porque efectivamente te estás autenticando contra Microsoft de verdad.
- Microsoft entrega la cookie de sesión. Y como toda esa conversación pasó por el intermediario, la cookie pasa por sus manos antes de llegar a vos. Ahí es donde la copia.
A partir de ese momento el atacante tiene tu sesión. Vos seguís trabajando sin notar nada —tu sesión también funciona—, mientras él usa la copia desde otra máquina, en otro país, sin que a nadie se le pida un nuevo segundo factor.
Esto dejó de ser artesanal. Hoy existen kits comerciales de "phishing como servicio" —Tycoon 2FA es uno de los nombres que circula en los informes de 2026— y herramientas de proxy inverso de código abierto como Evilginx que automatizan todo el montaje. Nombrarlos es contexto defensivo: son las herramientas cuyo tráfico tu equipo tiene que aprender a reconocer, no un instructivo.
Por qué el MFA común no lo frena
Porque el MFA común valida quién sos al entrar, y este ataque no discute quién sos al entrar: te deja entrar de verdad y roba lo que pasa después. El código de seis dígitos, la notificación en la app, el SMS: todos confirman tu identidad en el momento del login, y todos son reenviables por el intermediario porque suceden antes de que se emita la cookie.
Es la distinción que casi nadie hace y que ordena toda la defensa: hay factores que se transmiten —un código que tu teléfono muestra y vos tecleás— y factores que no se transmiten nunca. Todo lo que se transmite, se puede interceptar y reenviar. El código más largo del mundo, si viaja por la red, viaja también por el intermediario.
Cómo saber si te está pasando
El robo de sesión no se ve en el login, porque el login es legítimo. Se ve después, en el comportamiento de la sesión, y esas señales sí quedan registradas. Todo esto es del lado defensivo, con tus propios registros.
- Cambio de IP dentro de la misma sesión. Una sesión que empieza en una IP y sigue desde otra distinta, sin que haya habido una nueva autenticación en el medio, es la señal más clara de una cookie replicada.
- Viaje imposible. Un inicio de sesión en Buenos Aires y, veinte minutos después, actividad de esa misma sesión desde otro continente. Microsoft Entra ID tiene detección de viaje imposible entre sus señales de riesgo, y es de lo primero que conviene tener encendido.
- Actividad desde rangos de proveedores de hosting. Tu gente se conecta desde redes hogareñas y de oficina, no desde un centro de datos. Una sesión que aparece desde el rango de IP de un proveedor de nube que ese usuario nunca usa es sospechosa por definición.
- Huella de dispositivo que no coincide. La autenticación ocurrió desde Windows con Chrome; de golpe la misma sesión actúa desde Linux con Firefox. Misma cookie, dispositivo distinto.
Ninguna de estas señales aparece si solo mirás "¿el login tuvo MFA?". Todas requieren mirar la sesión después de iniciada, que es donde vive el ataque.
La defensa que lo corta de raíz
Hay una sola, y es un cambio en el tipo de segundo factor, no en la contraseña ni en la vigilancia: autenticación resistente a phishing, que en la práctica hoy significa FIDO2/WebAuthn, ya sea con una llave física o con passkeys.
La razón por la que funciona es elegante y vale entenderla, porque es lo que separa esta defensa de todas las demás. Según la documentación de Microsoft, FIDO2 usa criptografía de clave pública: al registrarte, tu dispositivo genera un par de claves único para ese dispositivo, esa cuenta y ese servicio. La clave privada nunca sale del dispositivo; solo se comparte la pública.
Y acá está el punto que rompe el ataque: la credencial queda atada al dominio exacto del servicio. Cuando te autenticás, el dispositivo firma un desafío criptográfico, pero solo firma si el dominio que lo pide es el dominio real para el que se registró la clave. El servidor intermedio del atacante vive en otro dominio. Cuando le pide a tu llave que firme, la llave mira el dominio, ve que no es el que corresponde, y se niega a firmar. No hay nada que reenviar, porque nunca se generó una firma válida. No viaja ningún secreto reutilizable por la red.
En criptografía esto se llama origin binding —atadura al origen— y es la propiedad que ningún código de seis dígitos puede tener, porque el código no sabe a qué sitio lo estás tecleando. La llave sí lo sabe, y por eso no se deja engañar.
Las opciones concretas:
- Passkeys, disponibles en todas las ediciones de Entra ID incluida la gratuita, así que la plataforma no agrega costo. Para buena parte del equipo, es la respuesta.
- Llaves físicas como las YubiKey 5 Series para las identidades de más privilegio: administradores, finanzas, quien pueda mover dinero o accesos. Si conviene la inversión y para quién, está en el análisis de costo total de las YubiKey en Argentina, cuya conclusión es que no para todos, pero sí para ese núcleo.
- Cisco Duo y las demás plataformas de la categoría también ofrecen métodos resistentes a phishing; el catálogo está en MFA y autenticación.
Qué hacer, en orden
- Encendé las señales de riesgo de sesión en Microsoft 365: viaje imposible, actividad desde rangos de hosting, anomalías de sesión. Es gratis en las ediciones que ya lo incluyen y es lo que te avisa si ya está pasando.
- Pasá a passkeys al grueso del equipo. Cuesta cero en licencia y convierte el ataque de "posible" a "no funciona" para esas cuentas.
- Llaves físicas para las cuentas de privilegio elevado. Administradores primero. Es el núcleo donde un robo de sesión hace más daño y donde la inversión cierra.
- Reforzá el correo, que es la puerta. Sin el mensaje inicial, el ataque no arranca; la comparativa de seguridad de email baja a producto.
- Acortá la vida de las sesiones de las cuentas sensibles, para que una cookie robada caduque antes. No frena el ataque, pero le reduce la ventana.
Mi lectura, marcada como opinión: los pasos 2 y 3 son los que importan; el resto reduce daño pero no cierra el agujero. Si tuvieras que hacer una sola cosa, es mover a las cuentas de administrador a autenticación resistente a phishing, hoy.
Y si esto te llega porque un cliente te está por auditar, el robo de sesión y su defensa son exactamente lo que hay detrás de la pregunta de MFA en cualquier cuestionario de seguridad: un evaluador con oficio no pregunta "¿tenés MFA?", pregunta "¿de qué tipo?".
Preguntas frecuentes
Si ya tengo MFA, ¿estoy en riesgo igual?
Si tu segundo factor es un código, una notificación en una app o un SMS, sí: todos son reenviables por el intermediario porque se transmiten por la red. El MFA sube muchísimo la barrera contra el robo simple de contraseña, pero no frena el robo de sesión. La defensa específica es la autenticación resistente a phishing.
¿Las passkeys y las llaves físicas son de verdad inmunes a esto?
Contra el robo de sesión por adversario en el medio, sí, y por una razón estructural: la credencial está atada al dominio real y el dispositivo se niega a firmar para el dominio falso del atacante. No se genera nada reutilizable. Ninguna defensa es absoluta contra todo, pero contra este ataque específico, el origin binding lo corta de raíz.
¿Me sirve un antivirus o un EDR contra esto?
Poco, porque el ataque no instala nada en la máquina de la víctima: pasa en el navegador y en la red. Lo que sirve es el tipo de segundo factor y la detección de anomalías de sesión del lado de la nube, no el endpoint. Es un buen recordatorio de que no todo se resuelve en la computadora.
¿Cómo entra el ataque en primer lugar?
Casi siempre por un correo con un enlace a la página espejo. Por eso reforzar el correo con buen filtrado anti-phishing y con SPF, DKIM y DMARC bien configurados es la primera línea: si el mensaje no llega, el ataque no empieza.
¿Cada cuánto tendría que revisar los inicios de sesión sospechosos?
Las señales de viaje imposible y anomalía de sesión conviene tenerlas como alerta automática, no como revisión manual periódica: el valor está en enterarte en minutos, no en descubrirlo la semana siguiente. Configuralas para que te avisen, y revisá manualmente solo cuando salte una.
