Entraron como tu aplicación, y Entra ID no pidió ningún MFA

Una sola dirección IP alojada en Polonia firmó 412 intentos de inicio de sesión en siete días contra registros de aplicación de Microsoft Entra ID, en ráfagas de hasta 24 entradas en 10 segundos y con bucles de reintento de once segundos. Ninguno de esos intentos pidió un segundo factor, chocó con tus políticas de acceso condicional ni pasó por tu cortafuegos. Eran aplicaciones autenticándose solas con su propio secreto, y ese secreto lo tenía el atacante.

Los números, con su fuente

Quien lo vio primero y lo publicó con detalle fue Todyl, el 3 de noviembre de 2026. Su primer registro es del 1 de noviembre a las 08:45 UTC y el último intento, ya bloqueado, del 3 de noviembre a las 21:31 UTC. En medio: unos 45 registros de aplicación atacados en torno a 18 organizaciones, más de 33 autenticaciones con éxito y acceso efectivo a 27 organizaciones —las atacadas directamente más los clientes alcanzados a través de ellas—. Sectores: administración pública, energía, alimentación y agricultura, transporte, construcción, ingeniería, legal, educación y tercer sector.

Lo que el actor hizo dentro, según el mismo informe: unas 25 búsquedas en inquilinos, 81 ficheros descargados —a un ritmo de alrededor de un fichero por segundo desde SharePoint— y unos 2.279 elementos de buzón consultados. El 95 % de los inicios de sesión venían de clientes programados, no de un navegador. Y el orden era casi siempre el mismo: primero un token de Azure Resource Manager, después Key Vault —a menudo en cuestión de segundos—, y luego Microsoft Graph, Storage y Cognitive Services. En un caso documentado pasaron dos minutos y medio entre descargar el archivo de un conector y autenticarse como la aplicación de ese conector.

Microsoft publicó su propia investigación el 5 de noviembre y añadió un dato que mueve la fecha de inicio hacia atrás: vio inicios de sesión de servicio con éxito desde esa misma IP ya el 28 de octubre, cuatro días antes del primer avistamiento de Todyl. Y una frase de Todyl que conviene no perder de vista: «No Microsoft vulnerability is involved.» No hay ninguna vulnerabilidad de Microsoft implicada. Nadie reventó nada. El atacante tenía credenciales válidas y las usó.

Por qué tu MFA no pinta nada aquí

La frase de Todyl que explica la mitad del asunto es esta: «Because these are app sign-ins, there is no MFA prompt, user-scoped Conditional Access doesn't apply, and firewall rules never see the traffic.» Como son inicios de sesión de aplicación, no hay petición de MFA, el acceso condicional con alcance de usuario no se aplica y las reglas del cortafuegos nunca ven ese tráfico.

Es el flujo de credenciales de cliente funcionando exactamente como está diseñado, y eso es lo incómodo. Una aplicación presenta su identificador y su secreto, Entra ID le devuelve un token y la aplicación trabaja. No hay persona a la que preguntar nada, así que no se le pregunta. La propia página de Microsoft sobre acceso condicional para identidades de carga de trabajo lo resume en tres rasgos de estas identidades: «Can't perform multifactor authentication», «Often have no formal lifecycle process» y «Need to store their credentials or secrets somewhere». No pueden hacer segundo factor, casi nunca tienen un ciclo de vida formal y necesitan guardar su credencial en alguna parte. Es el mismo territorio que ya recorrimos con el token que nunca pide MFA, con una diferencia importante: allí el atacante se colaba por un consentimiento que alguien daba; aquí no hace falta engañar a nadie, basta con tener la contraseña de la aplicación.

El control que lo para se vende aparte

Sí existe una política que habría bloqueado esto por dirección IP: el acceso condicional para identidades de carga de trabajo. El informe cuenta que el 3 de noviembre, a las 18:12 UTC, el acceso condicional llegó a bloquear tokens de refresco reutilizados —de usuarios, y sin precisar con qué tipo de política—, así que algo funciona. Todyl la recomienda y avisa de que exige la licencia Workload ID Premium. Lo que casi nunca aparece es el precio: 3 dólares por identidad de carga de trabajo y mes.

Y aquí está el segundo precio, que no se paga en dólares. Microsoft escribe en la página de acceso condicional para identidades de carga de trabajo, la que la propia FAQ enlaza: «Policy can be applied to single tenant service principals that are registered in your tenant. Microsoft and third-party SaaS applications, including multitenant apps, are not covered by these policies. Managed identities aren't covered by policy.» Las aplicaciones multiinquilino quedan fuera. Y multiinquilino es justamente la forma de la aplicación que un proveedor externo —el tuyo, o nosotros— tiene dentro de tu inquilino. El control de 3 dólares al mes alcanza a tus aplicaciones propias y se detiene donde empieza el caso de este episodio.

La credencial que el propio fabricante te dice que no uses

La credencial que está en el centro de todo esto —el secreto de cliente— es exactamente la que Microsoft desaconseja. Su página sobre credenciales de aplicación lo escribe así: «Client secrets are less secure than certificate or federated credentials and therefore should not be used in production environments.» No deberían usarse en producción. Y están en producción en casi todas partes.

La misma página pone dos cifras encima de la mesa: la vida de un secreto de cliente está limitada a dos años (24 meses) o menos y no se puede pedir un periodo mayor; y Microsoft recomienda fijar una caducidad inferior a 12 meses. El techo son dos años; la recomendación del propio fabricante es menos de la mitad. Merece la pena mirar qué fecha tienen los tuyos.

Cinco minutos

De dónde salieron esos secretos es la pregunta que de verdad cambia cosas. Microsoft y Todyl apuntan a ARTEX, un marco ofensivo agéntico —es decir, automatizado con un modelo que decide los siguientes pasos— que desde agosto de 2026 lanza grandes volúmenes de consultas a GitHub buscando secretos. Las consultas, según Microsoft, suelen combinar el nombre de la organización objetivo con palabras clave de secretos y de servicios en la nube.

Ese número rompe una cuenta corriente, aunque no se diga: «si se me escapa una clave en un repositorio, tengo margen para rotarla». El margen existía porque encontrarla era caro. Buscar ya no cuesta nada, y lo que antes era una tarea de alguien ahora es un bucle que no duerme. Es la misma mecánica que describíamos al hablar de quién figura en el registro cuando trabaja un agente de IA: el agente no aparece, aparece la credencial que alguien le prestó. Microsoft amplió la cobertura el 6 de noviembre con un segundo aviso sobre el mismo marco apuntando al sector financiero, así que esto no se ha cerrado.

Todyl añade un detalle sobre el origen que, si tienes proveedores, deberías leer dos veces: varios de los secretos iniciales solo se habían usado desde equipos del personal o desde redes de oficina, y algunos llegaron en pares de versión vigente y caducada, lo que para ellos sugiere un almacén de ficheros o un sistema en funcionamiento, no un repositorio público. Un secreto con su historial al lado sale de un documento, de una exportación de gestor de contraseñas o de una ficha de herramienta de soporte.

Dónde nos señala esto a nosotros

Conviene decirlo con todas las letras: everyWAN es un proveedor de servicios gestionados, y la puerta por la que entró este actor es exactamente la nuestra. Tenemos registros de aplicación dentro de inquilinos de clientes —para copias, para monitorización, para automatización— igual que los tiene cualquiera que haga este trabajo. Una campaña que recorre proveedores para llegar a sus clientes nos pone en el lado del auditado.

Las recomendaciones que Todyl dirige específicamente a proveedores son tres y son incómodas en el buen sentido: revisar el acceso a Partner Center y las relaciones GDAP, auditar las aplicaciones que el proveedor tiene en inquilinos de clientes, y no guardar nunca secretos de aplicación de clientes en runbooks, en notas de la herramienta de soporte ni en documentación. Esa última es la que separa a un proveedor serio del resto, y no se comprueba con un certificado: se comprueba preguntando. Si un proveedor tuyo no te puede decir hoy qué registros de aplicación tiene en tu inquilino y con qué permisos, ya tienes la primera línea de tu auditoría. Y sí, tienes derecho a hacernos a nosotros la misma pregunta.

Hay una consecuencia legal que tampoco conviene esquivar. Todyl clasifica el acceso confirmado como un posible evento de exposición de datos que requiere involucrar a los responsables jurídicos y de privacidad. Buzones leídos y ficheros descargados en inquilinos de clientes es, en términos de cumplimiento y continuidad, material de notificación con plazos, no de informe interno. Quien tenga que decidir eso necesita saber antes qué se tocó y durante cuánto tiempo, y para eso hace falta el registro del punto siguiente.

Tres comprobaciones, con sus comandos

Esto se puede mirar hoy, sin comprar nada y sin ventana de parada. Son tres preguntas y las tres tienen respuesta con un número.

1. Cuántos secretos vivos tienes y cuándo caducan. Con el módulo de Microsoft Graph para PowerShell, en modo lectura:

Mira la columna Secretos contra la de Certificados antes que la fecha. Cada fila con secretos y sin certificado es una aplicación que está autenticándose con lo que Microsoft dice que no se use en producción. La lista completa suele ser más larga de lo que espera quien la pide, por la misma razón por la que el directorio acaba teniendo más fichas que empleados: nadie da de baja lo que nadie recuerda haber dado de alta.

2. Qué permisos de solo-aplicación tiene cada una. Un secreto robado vale lo que valgan los permisos de su aplicación. Los que se conceden a la aplicación entera, sin usuario detrás, son los que importan aquí:

Si alguna aplicación con secreto tiene Mail.Read, Files.Read.All o Directory.Read.All a nivel de aplicación, ya sabes qué se habría llevado el actor de este episodio en tu casa: buzones y ficheros, que es exactamente lo que se llevó en las ajenas.

3. El registro que no estás mirando. Los inicios de sesión de aplicación viven en otra pestaña del registro de inicios de sesión —«Inicios de sesión de principal de servicio», en Entra ID > Monitorización y estado— y en otra tabla de Log Analytics. Si exportas los registros de Entra:

Aquí viene la parte honesta: puede que no tengas ese histórico. En el portal, los registros de Entra se guardan 7 días en el plan gratuito y 30 días con P1 o P2, y el cambio no es retroactivo: la propia documentación avisa de que al pasar de Free a P1 o P2 solo recuperas lo que siga dentro de esos siete días. Todyl recomienda retroceder al menos hasta el 28 de octubre para buscar esta actividad. Esa fecha, hoy, ya está fuera de la ventana gratuita.

Lo que no haríamos esta semana

No compraríamos Workload ID Premium hoy. Una política necesita un sujeto, y a 3 dólares por identidad y mes lo primero que se paga sin el censo hecho es el inventario que no has hecho. El orden que nos parece defendible es otro: primero la lista del punto 1; después quitar aplicaciones que ya no usa nadie y credenciales caducadas; luego pasar a certificado o a credencial federada todo lo que el producto permita —que es más de lo que parece, porque muchas integraciones lo soportan y nadie lo cambió en su día—; y solo con lo que quede encima de la mesa decidir si justifica el SKU. Puede que sí. Pero entonces será una decisión con un número detrás.

Y no borraríamos secretos en bloque un viernes por la tarde. Un registro de aplicación sin credencial válida es una copia de seguridad que deja de ejecutarse o un conector que deja de sincronizar, y de eso te enteras el lunes. Cada secreto que se quita necesita saber antes qué proceso lo usaba. Esa frase, dicha así, parece de manual; lo que tiene de incómodo es que casi nunca hay quien pueda responderla sin abrir una herramienta.

Fuentes (verificadas el 08-11-2026): cronología (1 de noviembre 08:45 UTC, último intento bloqueado el 3 de noviembre 21:31 UTC), 412 intentos en siete días, 45 registros de aplicación en ~18 organizaciones, 33+ autenticaciones con éxito, 27 organizaciones alcanzadas, ~25 búsquedas en inquilinos, 81 ficheros, ~2.279 elementos de buzón, 95 % de clientes programados, ráfagas de 24 inicios en 10 s con reintentos de 11 s, orden ARM → Key Vault → Graph/Storage/Cognitive Services, los dos minutos y medio del conector, la frase sobre el MFA y el acceso condicional, el origen de los secretos (uso previo solo desde equipos del personal y pares vigente/caducado) y las recomendaciones para proveedores (Partner Center, GDAP, no guardar secretos de clientes en runbooks ni documentación) — informe de Todyl, 03-11-2026; inicios de sesión de servicio con éxito desde la misma IP ya el 28 de octubre, el marco ARTEX, las consultas a GitHub desde agosto de 2026 y la cita de los cinco minutos — Microsoft Threat Intelligence, 05-11-2026 y su continuación del 06-11-2026 sobre el sector financiero; cobertura independiente de la campaña y de su alcance en clientes de proveedores — Cybersecurity Dive, 04-11-2026; frases literales sobre los secretos de cliente («should not be used in production environments»), el techo de 24 meses y la recomendación de menos de 12 — Microsoft Learn, credenciales de aplicación; SKU independiente de Workload ID Premium a 3 $/identidad/mes, tabla de funciones Free vs Premium y la frase sobre aplicaciones de un solo inquilino — preguntas frecuentes de Microsoft Entra Workload ID. La retención de 7 días en el plan gratuito y 30 con P1/P2 es la documentada por Microsoft para los registros de Entra. La exclusión de aplicaciones multiinquilino y de identidades administradas, la frase sobre los tres rasgos de las identidades de carga de trabajo y la ruta del registro de inicios de sesión de principal de servicio — Microsoft Learn, acceso condicional para identidades de carga de trabajo. Los comandos de PowerShell y la consulta KQL son elaboración nuestra. Fotografía: «Key cabinet», de Thomas Quine, CC BY 2.0 vía Wikimedia Commons, recortada por nosotros.