Vishing contra Microsoft 365 y Entra

Si tu organización usa Microsoft 365, este caso te interesa aunque no tengas un equipo grande de seguridad. Los atacantes ya no se limitan a pedir contraseñas por correo o a mandar enlaces falsos. Ahora están usando llamadas telefónicas para convencer a usuarios de que registren una passkey en Microsoft Entra, y con eso pueden tomar control de la identidad sin necesitar la contraseña original.

La idea es sencilla y por eso funciona: si logran que la víctima apruebe el enrolamiento de una clave de acceso en un dispositivo o sesión controlada por el atacante, el acceso futuro queda ligado a esa passkey. No es un ataque masivo de ruido alto; es una operación de ingeniería social más precisa, pensada para entornos donde MFA ya existe y donde el usuario confía demasiado en el proceso de registro.

Qué está pasando con este ataque

El caso reportado por BleepingComputer muestra una combinación que cada vez se ve más: vishing, abuso de flujos legítimos de identidad y passkeys. En vez de intentar romper la autenticación, el atacante intenta convertirse en parte del proceso de autenticación. Eso cambia el problema de “robar credenciales” a “secuestrar el alta de credenciales”.

En Microsoft Entra, el registro de métodos de autenticación es una superficie sensible. Si un usuario puede agregar una passkey después de una llamada convincente, el atacante puede terminar con un método de acceso resistente al phishing, pero registrado bajo su control. El resultado es especialmente delicado porque la organización puede seguir viendo actividad aparentemente válida: un usuario autenticándose con un método moderno, no una contraseña filtrada.

Por qué el vishing sigue funcionando

El teléfono sigue siendo un canal eficaz porque introduce presión, urgencia y contexto humano. La víctima escucha una voz, recibe instrucciones inmediatas y suele bajar la guardia más que frente a un correo. Si además el atacante se presenta como soporte interno, mesa de ayuda o equipo de seguridad, el margen de duda se reduce todavía más.

No necesitas imaginar un ataque sofisticado de película. Basta con una llamada breve, un motivo creíble y una ventana de tiempo en la que el usuario está ocupado. En muchas empresas, el proceso de enrolamiento de nuevos métodos de autenticación todavía no está tan vigilado como un cambio de contraseña o una solicitud de restablecimiento de MFA.

Qué hace distinto a este caso

La novedad no es solo el canal, sino el objetivo. Antes, muchos ataques contra Microsoft 365 buscaban phishing de credenciales, token theft o consentimiento malicioso de aplicaciones. Aquí el foco está en registrar una passkey, que en teoría es una defensa más fuerte que la contraseña. El atacante usa una defensa a su favor.

Eso obliga a cambiar el enfoque operativo. Ya no basta con decirle al usuario que no comparta códigos. También hay que enseñar que no debe registrar métodos de autenticación por teléfono, ni seguir instrucciones de supuestos técnicos fuera de un proceso verificado.

Cómo funciona el secuestro de identidad con passkeys

Una passkey es una credencial basada en criptografía de clave pública. En términos simples, el dispositivo guarda una clave privada y el servicio conserva la pública. Cuando el usuario autentica, el sistema verifica que quien responde posee la clave privada y que la respuesta corresponde al origen correcto. Según la documentación oficial de Microsoft, Entra soporta passkeys como método de autenticación moderno y resistente al phishing.

El problema no está en la tecnología en sí. El problema aparece cuando el alta de esa credencial se realiza bajo control del atacante o bajo engaño. Si la víctima aprueba el enrolamiento en un contexto manipulado, el atacante puede terminar con un método de acceso vinculado a una sesión o dispositivo que él maneja.

Flujo típico del ataque

Un flujo posible, basado en lo descrito por la fuente y en cómo operan estos escenarios, sería este:

1. El atacante llama al usuario y se hace pasar por soporte o TI.
2. Le dice que hay un problema de seguridad, una migración o una verificación pendiente.
3. Le pide iniciar sesión o aprobar el registro de una passkey.
4. La víctima sigue instrucciones en una página legítima o muy parecida a la real.
5. El atacante termina con un método de acceso válido para entrar después.

No hace falta que el usuario entregue una contraseña. A veces ni siquiera hace falta que vea una URL rara. Por eso este tipo de ataque es tan difícil de frenar solo con filtros de correo o con capacitación básica sobre phishing.

Qué gana el atacante

Si el registro sale bien para el atacante, obtiene persistencia. Ya no depende de una contraseña robada que pueda expirar o ser reseteada. También puede evadir controles tradicionales que detectan reutilización de passwords o intentos de login desde ubicaciones conocidas.

Además, una passkey puede dar una falsa sensación de seguridad al equipo interno. Si ves una autenticación con un método fuerte, puedes asumir que el usuario la aprobó de forma legítima. Precisamente ahí está el riesgo: el método es fuerte, pero el proceso de enrolamiento fue manipulado.

Señales de alerta para TI y seguridad

Si administras Microsoft 365 o Microsoft Entra, este tipo de ataques te obliga a mirar logs y procesos con otra lente. El foco no es solamente quién inició sesión, sino cómo se registró ese método de acceso y desde dónde. Un enrolamiento fuera de patrón puede ser la primera pista de compromiso.

También conviene revisar si tus usuarios pueden agregar métodos nuevos sin fricción adicional. En organizaciones con mucha rotación, soporte tercerizado o equipos distribuidos, los atacantes aprovechan cualquier proceso que dependa demasiado de confianza humana.

Indicadores que deberías revisar

No todos los indicadores significan compromiso, pero juntos pintan un patrón. Si tu equipo solo revisa inicios de sesión exitosos y no monitorea el alta de métodos, estás viendo la mitad de la película.

Qué logs te conviene mirar

En Microsoft Entra, revisa eventos relacionados con autenticación, registro de métodos y cambios en la cuenta. La documentación oficial de Microsoft sobre autenticación y métodos de seguridad te sirve como punto de partida para identificar qué eventos están disponibles en tu tenant. También conviene revisar alertas de Identity Protection si tienes licencias que lo permitan.

Si centralizas telemetría en tu SIEM, busca correlaciones entre:

• alta de método de autenticación,
• cambio de dispositivo o ubicación,
• acceso a aplicaciones críticas como Exchange, SharePoint o Teams,
• y creación de reglas sospechosas en buzones o reenvíos.

Qué puedes hacer hoy para reducir el riesgo

La buena noticia es que no necesitas rediseñar toda tu identidad para empezar a bajar exposición. Hay medidas concretas que puedes aplicar en Microsoft 365 y Entra con impacto real. El objetivo es poner fricción donde el atacante necesita velocidad y confianza.

No se trata de bloquear passkeys. Se trata de controlar quién puede registrarlas, cuándo, desde dónde y bajo qué verificación adicional. Si tu organización quiere adoptar passkeys, mejor hacerlo con proceso robusto que dejar la puerta abierta a enrolamientos guiados por teléfono.

Controles prioritarios

1. Restringe el registro de métodos de autenticación a usuarios que realmente lo necesiten.
2. Exige verificación adicional para agregar nuevos métodos, especialmente desde ubicaciones no confiables.
3. Aplica Conditional Access para bloquear accesos desde países o redes que no forman parte de tu operación.
4. Habilita alertas para cambios en métodos de autenticación y revísalas en tiempo casi real.
5. Fortalece la mesa de ayuda con verificación fuera de banda antes de aceptar solicitudes de enrolamiento.
6. Entrena al usuario final para que nunca registre una passkey por instrucción telefónica no verificada.

Controles técnicos que valen la pena

Microsoft publica guías para administrar métodos de autenticación en Entra y para proteger el acceso con Conditional Access. Si todavía no las has revisado, este es un buen momento para hacerlo. También puedes apoyarte en la documentación oficial de Microsoft sobre passkeys y autenticación sin contraseña:

• https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passwordless
• https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-methods-manage
• https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview

En la práctica, lo que más ayuda es combinar política y proceso. Por ejemplo, si un usuario solicita registrar una passkey, la mesa de ayuda puede validar la identidad por un canal distinto al teléfono entrante, y el sistema puede exigir un segundo factor o aprobación administrativa según el perfil del usuario.

Qué debe hacer tu equipo de seguridad y TI

Si administras un tenant de Microsoft 365 en una empresa mediana o grande, este caso debería entrar en tu lista de revisión. No porque sea el único vector, sino porque expone una tendencia clara: los atacantes están atacando la identidad como proceso, no solo como secreto.

Para equipos de TI, esto implica revisar procedimientos. Muchas veces el problema no está en la tecnología, sino en la forma en que soporte valida solicitudes urgentes. Si alguien puede convencer a un agente de mesa de ayuda de registrar un método nuevo, el control técnico queda corto.

Plan de acción en 30 días

• Revisa qué usuarios pueden registrar passkeys y bajo qué condiciones.
• Audita los eventos de enrolamiento de métodos de autenticación de los últimos 90 días.
• Identifica cuentas privilegiadas con procesos de alta demasiado flexibles.
• Actualiza el playbook de respuesta para incluir secuestro de identidad por enrolamiento fraudulento.
• Simula un caso de vishing con el equipo de soporte y mide cuánto tarda en detectarse.

Un ejercicio útil es medir el tiempo entre la llamada falsa y el primer acceso anómalo. Si tu detección depende de que el usuario reporte el problema, llegas tarde. Si detectas el enrolamiento extraño en minutos, todavía tienes margen para revocar sesiones, resetear métodos y bloquear persistencia.

Cómo hablar con usuarios sin saturarlos

No necesitas mandar un manual de 40 páginas. Mejor usa mensajes cortos y concretos. Por ejemplo: “Si alguien te llama diciendo que es de TI y te pide registrar una passkey o aprobar un código, corta la llamada y verifica por el canal oficial”. Ese tipo de instrucción se recuerda más que una política larga.

También ayuda explicar el motivo. Cuando el usuario entiende que una passkey puede ser segura pero que el enrolamiento puede ser manipulado, deja de pensar que todo lo que suena moderno es automáticamente confiable.

Tabla resumen

Este caso deja una lección bastante clara: la adopción de passkeys no elimina el riesgo humano, solo cambia dónde se concentra. Si la organización no controla el alta de credenciales, el atacante no necesita romper la autenticación; le basta con conseguir que alguien la configure por él.

La parte útil para tu equipo es que el problema sí se puede trabajar. Con monitoreo de enrolamiento, políticas de acceso más estrictas, capacitación puntual y procesos de soporte más duros, reduces mucho la probabilidad de que una llamada termine en toma de control de identidad.