EvilTokens llega a América Latina: cuando la víctima autentica al atacante en una página legítima de Microsoft

El mensaje puede llegar durante una mañana ordinaria. No contiene amenazas grandilocuentes, premios improbables ni una traducción defectuosa. Habla de una factura cuyo número coincide con el formato utilizado por la empresa, menciona una licitación compatible con la actividad del destinatario o solicita revisar un documento relacionado con un proceso que efectivamente existe. La firma parece correcta. El vocabulario pertenece al sector. Incluso la urgencia está bien calibrada: suficiente para provocar una acción, pero no tanta como para despertar sospechas.

La persona abre el enlace y llega a una interfaz que reproduce el lenguaje visual de una plataforma de productividad. Después aparece una instrucción aparentemente inocua: continuar hacia Microsoft e introducir un código para acceder al documento, revisar la invitación o completar la autenticación. La página final pertenece realmente a Microsoft. El dominio es legítimo. El certificado es válido. La autenticación multifactor funciona exactamente como fue diseñada. No hay una contraseña falsa esperando ser capturada ni una copia rudimentaria del portal corporativo.

La víctima se autentica correctamente. Ese es el problema.

EvilTokens representa una transformación significativa del phishing corporativo porque no intenta necesariamente robar la contraseña ni derrotar directamente la autenticación multifactor. Convence al usuario de autorizar una sesión que fue iniciada por otra persona. El atacante solicita un código mediante el flujo de autorización de dispositivos de OAuth 2.0 (protocolo utilizado para conceder acceso limitado a aplicaciones y dispositivos sin compartir directamente la contraseña), entrega ese código a la víctima y espera a que ella complete el proceso en una página auténtica de Microsoft.

Cuando el usuario introduce el código, Microsoft interpreta que está autorizando un dispositivo que desea utilizar. La identidad es real, la autenticación es válida y la aprobación proviene del propietario legítimo de la cuenta. Sin embargo, el dispositivo que recibe los tokens de acceso se encuentra bajo control del atacante.

Este detalle altera buena parte del modelo mental con el que las organizaciones han tratado el phishing durante años. La recomendación de revisar el dominio continúa siendo útil, pero resulta insuficiente cuando el dominio visible es legítimo. La autenticación multifactor continúa siendo esencial, aunque no evita una autorización concedida voluntariamente dentro de un flujo permitido. Cambiar la contraseña puede ser necesario durante la respuesta, pero no garantiza por sí solo que todos los tokens y sesiones hayan sido invalidados.

EvilTokens convierte una decisión legítima del usuario en una delegación ilegítima de acceso. La víctima no entrega una llave. Firma, sin comprenderlo, una autorización para que otra persona entre.

En las últimas semanas me ha tocado revisar casos locales compatibles con esta lógica operacional. No corresponde identificar a las organizaciones ni anticipar atribuciones que todavía requieren evidencia concluyente. Sí resulta responsable señalar que la amenaza ya no debe observarse como una anomalía distante descrita por laboratorios extranjeros. La infraestructura, los mensajes y los patrones de autenticación asociados han comenzado a aparecer dentro de operaciones dirigidas a organizaciones de nuestro entorno.

La llegada a América Latina no necesita una campaña anunciada ni una infraestructura exclusiva para la región. Los operadores compran acceso al servicio, seleccionan objetivos, adaptan el lenguaje y utilizan infraestructura distribuida en servicios legítimos de nube. El mismo kit puede atacar una empresa industrial en Europa por la mañana, un proveedor logístico americano por la tarde y una organización local al día siguiente. La geografía del atacante importa cada vez menos. El contexto de la víctima importa cada vez más.

Una función legítima convertida en infraestructura de intrusión

El flujo de código de dispositivo fue diseñado para resolver un problema auténtico. Algunos dispositivos, como televisores inteligentes, terminales compartidos, impresoras, equipos de videoconferencia o sistemas con interfaces limitadas, no permiten escribir cómodamente una contraseña compleja. En esos casos, el dispositivo muestra un código y pide al usuario abrir una dirección web en otro equipo. La persona introduce el código, completa su autenticación y concede acceso al dispositivo original.

En términos normales, el televisor solicita autorización y el teléfono la concede. En EvilTokens, el atacante ocupa el lugar del televisor.

La operación comienza cuando la infraestructura maliciosa solicita a Microsoft un código de dispositivo asociado con una aplicación o servicio compatible. Ese código posee una vigencia limitada. Los primeros ataques de esta categoría dependían de que la víctima actuara rápidamente, una restricción que reducía su efectividad. Las plataformas recientes resolvieron el problema mediante generación dinámica: el código se crea cuando la persona pulsa el enlace o alcanza la etapa final de la interacción. El reloj comienza a correr solo cuando existe una probabilidad razonable de que el usuario continúe.

La página utilizada para iniciar el recorrido puede alojarse en infraestructura comercial legítima, servicios de despliegue rápido, plataformas de funciones en la nube, dominios previamente comprometidos o redes de distribución de contenido. El objetivo no consiste únicamente en ocultar la ubicación. También busca heredar reputación. Una conexión hacia infraestructura ampliamente utilizada se mezcla con el tráfico normal y vuelve más costoso aplicar bloqueos generales sin interrumpir procesos empresariales.

Luego aparece el código. La víctima es redirigida hacia el portal real de Microsoft o recibe instrucciones para visitarlo. Allí completa el inicio de sesión, responde al segundo factor y observa una experiencia visual conocida. Desde su perspectiva, la seguridad funcionó. Desde la perspectiva del proveedor de identidad, también.

Una vez autorizado el flujo, la infraestructura del atacante recibe un token de acceso (credencial digital temporal que permite utilizar recursos específicos) y, según las condiciones de la sesión, un token de actualización (credencial que permite solicitar nuevos tokens de acceso sin repetir inmediatamente la autenticación). Estos objetos no son simples equivalentes técnicos de una contraseña. Representan una autorización ya concedida, con aplicaciones, recursos, permisos y tiempos de vida determinados.

El atacante puede utilizar esos tokens para acceder a Outlook, consultar información mediante Microsoft Graph (interfaz que permite interactuar programáticamente con identidades, correos, archivos, calendarios, contactos y otros recursos), revisar documentos en OneDrive o SharePoint, observar conversaciones en Teams y reconocer la estructura de la organización. El alcance exacto depende del cliente utilizado, de los permisos concedidos, de las políticas del tenant (entorno lógico de Microsoft 365 perteneciente a una organización) y de los controles de acceso condicional activos.

El ataque tampoco requiere mantener una ventana del navegador abierta en el equipo de la víctima. La sesión autorizada pertenece a la infraestructura controlada por el operador. El usuario puede cerrar la página, apagar su computador e incluso cambiar posteriormente su contraseña sin comprender que existe otra autorización activa. La persistencia no reside necesariamente en un malware instalado. Reside en la confianza que el sistema de identidad todavía concede al token.

Esta característica explica por qué el concepto de “bypass de MFA” debe utilizarse con precisión. EvilTokens no rompe criptográficamente la autenticación multifactor ni adivina el segundo factor. La desplaza. El usuario completa la autenticación fuerte, pero lo hace para una sesión iniciada por el adversario. La autenticación verifica quién aprueba; no siempre verifica qué está aprobando.

La distinción parece semántica hasta que comienza una investigación. Un equipo que busque solamente contraseñas robadas, páginas falsas o intentos fallidos puede concluir que no ocurrió nada. Los registros mostrarán una autenticación exitosa y un flujo permitido. La evidencia aparece al correlacionar el método de autenticación, la dirección de origen, la aplicación cliente, el comportamiento posterior, el acceso a correo y la secuencia temporal completa.

La inteligencia artificial no escribe solamente el correo: construye el personaje

La parte más inquietante de EvilTokens no está limitada al mecanismo de captura. Su arquitectura incorpora funciones de inteligencia artificial para aumentar la credibilidad antes y después del compromiso. Esto modifica la economía del fraude porque reduce el trabajo artesanal que antes separaba una campaña masiva de una operación de compromiso de correo empresarial cuidadosamente preparada.

Durante la fase inicial, los operadores pueden recopilar información pública sobre la organización y sus empleados. Perfiles profesionales, publicaciones corporativas, sitios web, documentos públicos, anuncios de contratación, noticias, registros de proveedores y mensajes en redes sociales permiten inferir funciones, relaciones jerárquicas, proyectos, viajes, tecnologías utilizadas y ciclos comerciales. Un modelo generativo puede convertir esa información dispersa en un perfil operativo del objetivo.

La inteligencia artificial no necesita conocer toda la verdad. Le basta con generar una historia compatible con ella.

Un director financiero puede recibir una solicitud asociada con una auditoría, una refinanciación o el cierre mensual. Un gerente de operaciones puede recibir documentación sobre mantenimiento, transporte o continuidad. Un responsable de compras puede ser abordado mediante una licitación, una cotización o una actualización contractual. Un ejecutivo puede recibir una invitación relacionada con una reunión, una presentación o una revisión confidencial. La temática deja de ser genérica porque el sistema puede seleccionar el pretexto según la función del destinatario.

La adaptación lingüística también mejora. Los mensajes pueden utilizar español local, fórmulas habituales del país y términos propios de la industria. Un operador sin conocimiento profundo del idioma puede producir correos gramaticalmente correctos y culturalmente razonables. Puede solicitar versiones más breves, más ejecutivas, más cercanas o más formales. Puede eliminar las expresiones que los filtros históricos asocian con fraude y generar variantes diferentes para cada destinatario.

La IA permite que mil correos compartan una intención, pero no necesariamente una redacción. Esto debilita los mecanismos que dependen de identificar frases repetidas, plantillas estáticas o errores previsibles.

Después del compromiso, la capacidad se vuelve más peligrosa. EvilTokens puede utilizar el acceso obtenido para extraer correos, reconocer conversaciones relevantes y localizar hilos asociados con pagos, facturas, contratos, transferencias, adquisiciones o cambios de cuentas bancarias. Un sistema automatizado puede clasificar mensajes, identificar participantes, resumir el contexto y sugerir cuál conversación ofrece mejores condiciones para insertar un fraude.

El atacante deja de leer manualmente miles de correos. La plataforma puede presentar las oportunidades mejor puntuadas.

A partir de un hilo real, la inteligencia artificial puede generar una respuesta coherente con el tono de los participantes. Puede conservar referencias previas, mencionar documentos auténticos y respetar el estilo observado en la conversación. La manipulación financiera ya no aparece como un mensaje aislado. Se integra en una relación comercial existente.

Esta es la transición desde el phishing asistido por IA hacia el fraude corporativo asistido por contexto. La máquina no se limita a escribir mejor. Decide qué historia tiene mayor probabilidad de funcionar, qué interlocutor posee autoridad, qué momento resulta favorable y qué información debe conservarse para evitar contradicciones.

El modelo de servicio incluye además paneles para administrar víctimas, visualizar tokens capturados, consultar cuentas comprometidas y desplegar páginas. Algunas variantes ofrecen navegadores preparados para cargar sesiones robadas y operar varias identidades simultáneamente. Otras incorporan bots de mensajería para comprar licencias, desplegar infraestructura, recibir notificaciones y coordinar campañas.

El resultado se parece menos a una herramienta aislada y más a una plataforma comercial clandestina. Hay soporte, actualizaciones, documentación, automatización, suscripciones y segmentación de productos. El operador principal desarrolla la capacidad; los afiliados la utilizan contra sus propios objetivos. La innovación ofensiva deja de depender de que cada delincuente domine OAuth, Microsoft Graph, infraestructura web, inteligencia artificial y fraude financiero. El servicio empaqueta esas competencias.

La inteligencia artificial no reemplaza al estafador. Le entrega memoria, contexto, escala y una capacidad de imitación que antes exigía semanas de observación.

De EvilTokens a Kali365: una categoría comienza a multiplicarse

EvilTokens adquirió visibilidad durante 2026 como una oferta especializada en phishing mediante código de dispositivo para Microsoft 365. Sin embargo, el nombre no debería convertirse en una frontera artificial. La técnica existía antes del kit y continuará existiendo aunque cambien sus operadores, canales de venta o marcas.

Kali365 aparece dentro de este mismo movimiento. Se comercializa como una plataforma de phishing como servicio capaz de capturar tokens de Microsoft 365, automatizar campañas y ofrecer señuelos generados con inteligencia artificial. Su aparición confirma que el mercado clandestino ha identificado una oportunidad rentable: explotar flujos de autorización legítimos en vez de concentrarse exclusivamente en formularios falsos de credenciales.

También existen antecedentes y herramientas relacionadas con phishing de código de dispositivo, proxies adversary-in-the-middle (infraestructura que se interpone entre la víctima y el servicio legítimo para capturar credenciales y sesiones), aplicaciones OAuth maliciosas y abuso de consentimientos. No todas funcionan igual. Algunas capturan cookies de sesión en tiempo real. Otras inducen al usuario a autorizar una aplicación. EvilTokens explota principalmente la autorización de un dispositivo iniciado por el atacante.

Esta precisión importa porque las defensas no son intercambiables. Una organización puede haber reforzado sus controles contra páginas falsas y continuar permitiendo flujos de código de dispositivo sin restricciones. Puede haber desplegado autenticación resistente al phishing y aun así conservar excepciones operacionales demasiado amplias. Puede monitorear consentimientos de aplicaciones, pero no correlacionar autenticaciones mediante código de dispositivo con accesos posteriores a Exchange Online.

Las variantes también pueden modificar la presentación. Un correo puede incluir directamente el código. Otro puede conducir a una página intermedia que lo genera dinámicamente. Algunos recurren a documentos compartidos, notificaciones de voz, firmas electrónicas, invitaciones de Teams o solicitudes de propuesta. Otros pueden utilizar mensajes enviados desde cuentas previamente comprometidas, lo que añade legitimidad de origen y continuidad conversacional.

El compromiso inicial puede transformarse rápidamente en una cadena. El atacante accede al buzón, estudia los contactos, identifica conversaciones valiosas, crea reglas para ocultar respuestas, elimina notificaciones y utiliza la cuenta para atacar a otras personas. Una víctima se convierte en infraestructura de distribución.

La creación de reglas de bandeja es especialmente útil. Los mensajes que contienen determinadas palabras pueden trasladarse a carpetas menos visibles, marcarse como leídos o eliminarse. Las respuestas de proveedores y advertencias internas dejan de aparecer en la bandeja principal. La cuenta parece funcionar con normalidad mientras el atacante administra una conversación paralela.

Microsoft Graph permite acelerar el reconocimiento. El adversario puede consultar contactos, grupos, archivos y relaciones organizacionales, siempre dentro del alcance autorizado por los tokens. Puede identificar a quienes trabajan en finanzas, administración, compras o dirección. Puede localizar documentos que describen procesos internos y utilizarlos para perfeccionar el engaño.

La exfiltración tampoco necesita una descarga masiva y ruidosa. Los sistemas automatizados pueden buscar palabras clave, seleccionar mensajes y extraer solamente la información útil. Esta economía de acceso reduce el volumen y mejora la pertinencia del material obtenido.

En América Latina, el ecosistema encuentra condiciones favorables. Muchas organizaciones han migrado sus procesos críticos hacia Microsoft 365, pero mantienen configuraciones de identidad heredadas, excepciones amplias y capacidades de monitoreo desiguales. Algunas disponen de autenticación multifactor, aunque todavía la interpretan como una barrera definitiva. Otras reciben registros de Entra ID y Exchange Online, pero no los correlacionan con acciones posteriores sobre buzones, reglas y archivos.

A esto se suma una extensa red de proveedores, estudios jurídicos, operadores logísticos, empresas industriales y servicios profesionales conectados mediante correo. El atacante no necesita comenzar por la organización mejor protegida. Puede comprometer a un tercero, estudiar una relación legítima y avanzar desde allí con un mensaje que ya contiene contexto compartido.

Los casos locales que he podido observar muestran precisamente esa transición. El mensaje deja de ser una pieza torpe enviada al azar. Se acerca a la conversación real, utiliza servicios legítimos y conduce al usuario hacia una autorización que parece parte de su rutina digital. La amenaza se vuelve difícil de narrar porque muchos de sus componentes, observados de manera aislada, son normales.

El momento posterior a la autenticación

Una vez obtenido el token, la operación entra en una fase distinta. La prioridad ya no consiste en engañar al usuario original, sino en convertir el acceso en inteligencia, persistencia y dinero.

El operador valida qué servicios puede utilizar, revisa la antigüedad de la cuenta, identifica su función y evalúa el valor de sus comunicaciones. Las cuentas financieras y ejecutivas son evidentes, pero no son las únicas relevantes. Un asistente puede controlar agendas y documentos. Un responsable de compras conoce proveedores. Un abogado maneja contratos. Un administrador tecnológico puede recibir alertas que ayuden a ocultar la intrusión.

La plataforma puede consultar correo reciente, buscar conversaciones financieras y reconocer patrones de facturación. La IA resume hilos extensos, extrae entidades, identifica montos, fechas, cuentas y participantes. También puede observar el estilo de escritura de la víctima: extensión de los mensajes, saludos, puntuación, nivel de formalidad y palabras recurrentes.

Con ese material, el atacante puede responder dentro de un hilo existente. Puede anunciar un cambio de cuenta bancaria, solicitar una transferencia urgente o introducir un documento adulterado. La autenticidad técnica del correo aumenta porque el mensaje proviene de la cuenta real. Los mecanismos tradicionales de validación del dominio, como SPF, DKIM y DMARC (controles destinados a verificar que un servidor está autorizado para enviar correo por un dominio), no detectan por sí mismos el fraude cuando la plataforma legítima está enviando el mensaje.

El adversario también puede utilizar la cuenta para distribuir nuevas solicitudes de código de dispositivo. Los destinatarios reconocen al remitente y encuentran conversaciones previas. Así se forma una secuencia de compromisos donde cada cuenta aporta reputación, contexto y nuevos objetivos.

El acceso a OneDrive y SharePoint amplía la comprensión del entorno. Políticas, organigramas, contratos, minutas, presentaciones y planillas financieras entregan información que antes exigía reconocimiento prolongado. Incluso un documento aparentemente inocuo puede revelar nombres de sistemas, proveedores, proyectos y aprobadores.

La permanencia depende de la duración de los tokens, de la capacidad de renovarlos y de los controles aplicados por la organización. Algunas acciones del usuario o del administrador pueden invalidarlos, pero no debe asumirse que un cambio de contraseña resuelve automáticamente todas las sesiones. La respuesta correcta requiere revocar sesiones y tokens, revisar métodos de autenticación, dispositivos registrados, consentimientos, aplicaciones, reglas de correo y actividad posterior.

El análisis forense debe reconstruir una línea temporal. La recepción del correo, el clic, la generación del código, la autenticación, la emisión del token y el primer acceso desde la infraestructura adversaria pueden ocurrir en pocos minutos. Después pueden aparecer consultas mediante Microsoft Graph, lectura intensiva o selectiva de mensajes, creación de reglas, modificaciones de reenvío y accesos desde redes que no corresponden al patrón del usuario.

Buscar solamente una dirección IP conocida produce una visión frágil. Los operadores utilizan plataformas legítimas, recursos efímeros y nodos compartidos. Un indicador puede desaparecer mientras la técnica permanece. El hunting (búsqueda proactiva de señales de compromiso) debe combinar indicadores con comportamiento.

El método de autenticación mediante código de dispositivo merece especial atención. También resulta relevante observar secuencias donde aparece inicialmente un error asociado con la espera de autorización y, poco después, una autenticación exitosa dentro de la misma correlación. El acceso posterior desde una dirección diferente a la del usuario que completó la autenticación puede aportar una señal adicional.

Las operaciones sobre Exchange Online deben revisarse con igual profundidad. La creación o modificación de reglas de bandeja, el reenvío externo, la delegación inesperada, el acceso a grandes cantidades de mensajes o el uso anómalo de Microsoft Graph pueden revelar lo que el inicio de sesión aislado no muestra.

El evento de autenticación cuenta quién abrió la puerta. La actividad posterior revela quién entró realmente.

Prevenir EvilTokens dentro de Microsoft 365

La defensa más efectiva comienza por una decisión arquitectónica: determinar si la organización necesita realmente el flujo de código de dispositivo. En muchos tenants, la función permanece disponible por compatibilidad histórica aunque ninguna operación actual dependa de ella.

Microsoft Entra permite utilizar acceso condicional (motor de políticas que evalúa identidad, aplicación, dispositivo, ubicación, riesgo y método de autenticación antes de conceder acceso) para bloquear explícitamente el flujo de código de dispositivo. La política debería abarcar a todos los usuarios y aplicaciones, manteniendo solamente excepciones justificadas, documentadas y revisadas.

La implementación no debe realizarse a ciegas. Primero corresponde auditar el uso legítimo del flujo, identificar dispositivos o aplicaciones dependientes y comprobar si existen alternativas modernas. Después puede activarse la política inicialmente en modo de solo informe, observar su impacto y avanzar hacia el bloqueo. Las cuentas de emergencia requieren tratamiento específico para evitar que una configuración incorrecta produzca un bloqueo administrativo, pero esas excepciones tampoco deben transformarse en rutas permanentes sin monitoreo.

La transferencia de autenticación también merece control. Este mecanismo permite iniciar una autenticación en un dispositivo y completarla en otro. Allí donde no exista una necesidad operacional clara, conviene restringirlo mediante acceso condicional.

La autenticación resistente al phishing, mediante llaves FIDO2, passkeys (credenciales criptográficas vinculadas al usuario y al servicio) y Windows Hello for Business, continúa siendo una pieza fundamental. Sin embargo, debe combinarse con restricciones sobre los flujos que una persona puede autorizar. Una credencial fuerte protege el acto de autenticación; la política protege el contexto en que ese acto puede utilizarse.

Microsoft Defender for Office 365 puede detectar campañas apoyándose en el comportamiento del remitente, la temática y la cadena de redirecciones, aun cuando el destino final sea un dominio legítimo de Microsoft. Safe Links (capacidad que analiza y reescribe enlaces para evaluar su riesgo durante la entrega y el clic) aporta señales adicionales, pero no debería interpretarse como garantía absoluta. Los atacantes generan páginas dinámicas, usan infraestructura efímera y alteran la secuencia según el visitante.

Defender XDR y Microsoft Entra ID Protection pueden detectar autenticaciones anómalas, infraestructura conocida, sesiones sospechosas y actividad compatible con phishing mediante código de dispositivo. Su valor aumenta cuando las fuentes se encuentran integradas. El correo recibido, el enlace pulsado, el inicio de sesión, el token emitido y el acceso posterior deben aparecer como partes del mismo incidente, no como cinco alertas inconexas.

El tenant también debe registrar y conservar información suficiente. Los logs de inicio de sesión de Entra ID, auditoría unificada, Exchange Online, Microsoft Graph, Defender for Office 365 y actividad de aplicaciones entregan perspectivas complementarias. Sin retención adecuada, una investigación iniciada semanas después puede encontrar solamente fragmentos.

La detección debería buscar autenticaciones mediante device code flow, clientes inusuales, accesos desde redes atípicas, cambios rápidos de geografía, uso inesperado de Microsoft Graph y actividades posteriores sobre correo. Las reglas de bandeja creadas inmediatamente después de una autenticación sospechosa poseen mayor valor que cualquiera de esos eventos por separado.

También conviene revisar reenvíos SMTP externos, configuraciones de entrega simultánea, delegaciones de buzón, permisos SendAs y SendOnBehalf, aplicaciones OAuth autorizadas, consentimientos de usuario y nuevos dispositivos registrados. La persistencia puede desplazarse entre distintas capas y sobrevivir a una corrección parcial.

Las organizaciones deberían limitar el consentimiento de aplicaciones por parte de usuarios, establecer flujos de aprobación administrativa y mantener inventarios de aplicaciones empresariales. Aunque EvilTokens no depende necesariamente de registrar una aplicación maliciosa tradicional, el control del ecosistema OAuth reduce caminos alternativos y facilita distinguir lo esperado de lo anómalo.

La capacitación requiere una actualización sustancial. Enseñar solamente a buscar dominios falsos prepara a las personas para la generación anterior del problema. Los usuarios deben comprender que un código de dispositivo solo debe introducirse cuando ellos mismos hayan iniciado conscientemente una autenticación en un equipo conocido. Un código recibido por correo, chat, llamada o documento debe considerarse sospechoso aunque la página donde se ingrese pertenezca realmente a Microsoft.

La advertencia debe ser simple: nadie necesita enviarte un código de dispositivo para compartir un archivo contigo.

Los procesos financieros también necesitan controles fuera del correo. Un cambio de cuenta bancaria, una transferencia extraordinaria o una modificación de instrucciones de pago debe validarse mediante un canal independiente y previamente establecido. No sirve llamar al número incluido en el mismo mensaje sospechoso. La verificación debe utilizar datos conocidos antes del incidente.

La segmentación de privilegios reduce el impacto. Las cuentas administrativas no deberían utilizarse para correo cotidiano ni recibir documentos externos. Los roles privilegiados deben activarse solo cuando se necesiten, mediante Privileged Identity Management (sistema para conceder privilegios administrativos de forma temporal y controlada), y estar protegidos por políticas más estrictas.

La protección de cuentas ejecutivas, financieras y de proveedores críticos debe considerar su exposición pública y su capacidad de autorizar pagos. Estas identidades merecen monitoreo reforzado, no porque sean las únicas atacadas, sino porque ofrecen mayor retorno al adversario.

Responder sin dejar vivo el acceso

Cuando existe sospecha de compromiso mediante EvilTokens, cambiar la contraseña es apenas una parte de la contención. La prioridad es invalidar el acceso autorizado y entender qué hizo el atacante mientras el token estuvo activo.

La organización debe revocar las sesiones del usuario y todos los tokens de actualización aplicables. También corresponde revisar y, cuando sea necesario, restablecer los métodos de autenticación multifactor. Deben examinarse los dispositivos registrados, las aplicaciones autorizadas, los consentimientos OAuth, las sesiones activas y cualquier modificación reciente de la identidad.

El buzón necesita una revisión independiente. Las reglas de entrada, reenvíos, delegaciones, permisos, respuestas automáticas y configuraciones de transporte pueden mantener el fraude después de la revocación inicial. Los mensajes eliminados o movidos deben recuperarse y analizarse. Las búsquedas de auditoría tienen que determinar qué correos fueron leídos, descargados, enviados o manipulados.

OneDrive, SharePoint y Teams también forman parte del alcance. La investigación debe establecer qué archivos fueron consultados, qué enlaces se generaron y qué conversaciones pudieron haber sido utilizadas para extender el ataque. Cuando la cuenta comprometida envió mensajes a terceros, la respuesta incluye notificar a los destinatarios por canales confiables y buscar compromisos secundarios.

La revocación puede tardar en propagarse en determinados servicios y escenarios. Por ello, la contención debe verificarse mediante evidencia, no asumirse a partir de una acción administrativa. Después de revocar, corresponde observar si continúan apareciendo solicitudes, tokens, accesos o modificaciones asociadas con la cuenta.

También es necesario preservar el correo original, sus encabezados, la cadena de redirecciones, las direcciones visitadas, los códigos presentados y los tiempos exactos. Esa información permite correlacionar el clic con la autenticación y distinguir una exposición frustrada de un acceso exitoso.

La búsqueda no debería limitarse al usuario reportado. Las campañas suelen dirigirse a varias personas de una misma organización o utilizar una cuenta comprometida para contactar a otras. Deben localizarse mensajes similares, remitentes relacionados, dominios intermedios, URLs compartidas y autenticaciones mediante el mismo flujo.

En escenarios de fraude financiero, la velocidad tiene un peso especial. La coordinación con tesorería, bancos, proveedores, asesoría legal y equipos de respuesta debe comenzar tan pronto como exista evidencia razonable. Esperar una atribución perfecta puede consumir el tiempo disponible para detener una transferencia o advertir a terceros.

Una respuesta madura distingue entre exposición, autorización, acceso y abuso. Una persona puede haber abierto el correo sin introducir el código. Puede haber completado el flujo, pero una política bloqueó el token. Puede existir acceso sin actividad posterior observable. También puede haber una operación completa de compromiso de correo empresarial.

Esa clasificación permite comunicar el incidente con rigor y evitar dos errores frecuentes: minimizarlo porque no hubo robo de contraseña o sobredimensionarlo antes de confirmar el uso efectivo del acceso.

La identidad se ha convertido en el perímetro ejecutable

EvilTokens expone una tensión que acompañará a la seguridad digital durante los próximos años. Los sistemas de identidad fueron diseñados para permitir que personas, dispositivos y aplicaciones deleguen acceso de manera flexible. Esa capacidad sostiene el trabajo moderno, las aplicaciones móviles, los servicios conectados y la automatización. También crea una superficie donde una autorización técnicamente válida puede nacer de una narrativa falsa.

La inteligencia artificial aumenta la presión sobre ese punto. Puede investigar al destinatario, construir un pretexto, adaptar el idioma, analizar el buzón comprometido y generar la siguiente intervención. Cada etapa aprende del contexto obtenido en la anterior.

La defensa no puede descansar en la esperanza de que el usuario detecte una falta ortográfica. Las faltas están desapareciendo. Tampoco puede confiar exclusivamente en el dominio visible, porque parte del proceso ocurre en sitios legítimos. Ni siquiera la presencia de autenticación multifactor permite cerrar el análisis.

La organización debe controlar qué flujos de autenticación admite, desde qué dispositivos, hacia qué aplicaciones y bajo qué condiciones. Debe observar los tokens como credenciales operativas, no como artefactos invisibles del protocolo. Debe correlacionar identidad, correo, aplicaciones y datos. Y debe diseñar procesos financieros capaces de sobrevivir a un mensaje técnicamente auténtico enviado desde una cuenta real.

Los casos locales ya observados deberían terminar con la idea de que esta amenaza pertenece a otro mercado. La infraestructura criminal no necesita instalarse físicamente en un país para operar dentro de sus empresas. Le basta con comprender el idioma, identificar una relación comercial y conseguir que alguien complete una autorización.

EvilTokens no demuestra que la autenticación multifactor haya fracasado. Demuestra que se le atribuyó una responsabilidad que nunca pudo asumir por sí sola.

Una identidad fuertemente autenticada también puede ser socialmente manipulada. La próxima frontera defensiva no consiste únicamente en comprobar quién eres, sino en verificar con claridad qué estás autorizando, para quién y desde qué contexto.