En abril de 2026 alguien entró en un despacho de abogados, y no lo hizo por el correo ni por la VPN. Entró por el programa con el que ese despacho apunta las horas que factura. El motivo: la clave con la que ese programa firma lo que recibe venía escrita en el código, igual para todas las instalaciones. Lo cuenta CrowdStrike en un informe publicado ayer, y lo que lo hace nuevo no es el fallo: es que, según el informe, fue «the first observed targeting of legal sector-specific software». La primera vez que se observa a alguien ir a por el software propio de un gremio. Y no trae CVE: lo hemos buscado y no hay ficha pública.
Los abogados son la anécdota. Lo que describe el informe es una categoría, y tú tienes una: el software que solo usa tu sector. El programa de gestión de la clínica, el de la asesoría, el que lleva las rutas de la flota, el que controla el laboratorio, el que emite los albaranes de la cooperativa. Lleva quince años en producción, lo mantiene una empresa pequeña, nadie lo ha metido nunca en el alcance de una auditoría y suele correr en el servidor donde está todo lo demás.
Lo que es una clave de máquina, en treinta segundos
Las aplicaciones web clásicas de Windows guardan parte de su estado en el propio navegador del usuario y se lo reenvían al servidor en cada clic. Para que nadie manipule ese paquete por el camino, el servidor lo firma con una clave —la machineKey— y comprueba la firma al recibirlo. Microsoft lo explica sin rodeos en un aviso de febrero de 2025: con la clave en la mano, un atacante puede «craft a malicious ViewState using the stolen keys and send it to the website via a POST request», y entonces el servidor lo descifra, comprueba la firma, la da por buena y «the malicious code is then loaded into the worker process memory and executed».
No es una contraseña que te roban: es el sello con el que tu servidor reconoce lo que viene de su propio lado. Y en los cuatro casos que vienen luego esa clave no estaba escondida en ningún binario, estaba en texto plano en el web.config que instala el producto. Lo tienen todos los clientes, y cualquiera que haya pegado su fichero de configuración en un foro pidiendo ayuda. El mismo aviso de Microsoft dice que identificaron más de 3.000 claves divulgadas públicamente utilizables para este tipo de ataque. No hay que adivinar nada: hay que buscar.
El mismo error, cuatro productos, seis años
Esta tabla la hemos hecho buscando «hardcoded machineKey» en la base de vulnerabilidades del NIST. No son fallos parecidos: es el mismo, repetido. Los dos primeros son del mismo fabricante, así que hablamos de tres casas distintas y cuatro productos.
Ninguno es de Microsoft, de Oracle ni de SAP. Son productos que resuelven un problema concreto para un público concreto, que alguien eligió bien en su momento y que nadie ha vuelto a mirar. El de Gladinet acabó en el catálogo de vulnerabilidades explotadas de CISA cinco días después de publicarse, con plazo federal al 29 de abril de 2025; la ficha del NIST dice «as exploited in the wild in March 2025», o sea que se usó antes de que hubiera aviso. Los otros tres no están en ese catálogo, lo que no significa que nadie los haya usado: significa que nadie lo ha observado y contado.
Una acotación honesta, porque la tabla invita a una conclusión más cómoda de la que aguantan los datos: el error no es exclusivo del software de nicho. La misma familia —deserialización con inyección de código— alcanzó en 2025 a Sitecore Experience Manager y Experience Platform hasta la 9.0, y eso no es un producto de gremio: es CVE-2025-53690, en el catálogo de explotados el 4 de septiembre de 2025 con plazo al 25. Así que la tesis no es «el software pequeño está peor hecho». Es otra, y va en la sección siguiente: lo que cambia entre un producto y otro no es el error, es cuánta gente hay mirando.
Nadie va a encontrar ese fallo por ti
Del caso de abril, CrowdStrike dice que el grupo «exploited a hardcoded IIS machine key vulnerability in Intapp Time Server», software de registro de horas que usan casi en exclusiva los despachos. Buscamos su CVE antes de escribir esto, en el NIST y en el catálogo de CISA, y no lo encontramos. Sobre lo que pasa en esa ventana ya escribimos hace seis días, cuando seis fallos del kernel de Linux salieron a la luz sin CVE y sin parche: el hueco en el que no hay identificador deja ciega a toda la cadena de herramientas que cuenta CVE. No lo repetimos aquí.
Lo que sí es distinto en el software de tu sector es la causa de esa ventana, y es incómoda: no hay nadie buscando. El software que usa todo el mundo lo miran investigadores, equipos de bug bounty y competidores, porque publicar un fallo ahí da nombre. En un programa que usan unos cientos de empresas de un solo gremio, ese incentivo no existe. No es que el fallo tarde en salir: es que, si nadie te ataca, no sale nunca, y el día que alguien te ataca el primero en enterarse es el atacante. Eso es exactamente lo que acaba de pasar en abril, y por eso el informe lo llama la primera vez observada.
Y mientras, el ruido de fondo
Hay en el informe un número que puedes ir a mirar hoy en tu consola de identidad. En un solo despacho registraron «nearly 500 distinct failed login attempts to as many accounts from approximately 300 distinct IP addresses in a 30-day period». Casi quinientos intentos fallidos contra casi quinientas cuentas distintas, desde unas trescientas direcciones, en un mes. Una cuenta, un intento: es el patrón diseñado para no disparar ningún bloqueo por intentos repetidos.
Formaba parte de la campaña de prueba masiva de contraseñas que el informe llama ORB28 y que afectó a «more than 340 primarily U.S.-based entities across numerous sectors». En tu consola de identidad eso es una línea gris con el contador de inicios fallidos a uno. No pasa el umbral de nadie, y no lo pasa por diseño. Solo se ve agrupando por dirección de origen en vez de por cuenta, que es una consulta que nadie hace hasta que tiene un motivo.
La otra puerta sigue siendo el teléfono
Lo apuntamos porque conviene no salir de aquí pensando que esto es solo cosa de software viejo. El grupo que el informe señala como amenaza dominante en el sector trabaja «impersonating IT staff to establish remote access sessions and exfiltrate sensitive data within minutes»: se hace pasar por el departamento de IT, abre una sesión de asistencia remota y saca datos en minutos. Y en noviembre de 2025, según el mismo documento, llegó a contratar a una persona para entrar físicamente en un despacho haciéndose pasar por empleado interno de IT. Sobre eso ya escribimos: quién verifica que eres tú cuando llamas al servicio de soporte es la pregunta que casi nadie tiene contestada por procedimiento. Y el mismo razonamiento vale para el agente que tu proveedor de IT instala en todas tus máquinas.
No vas a auditar el código de tu proveedor
No te vamos a decir que audites el código de tu proveedor, porque no vas a hacerlo y nosotros tampoco podemos: ese software es cerrado y el contrato no te da derecho a mirarlo. Tampoco te vamos a decir que lo cambies. El programa que lleva veinte años encajando con cómo trabaja tu gremio no se sustituye por una noticia, y quien te diga lo contrario no ha migrado nunca uno de estos. Y no, no es un problema que se resuelva comprando otra herramienta de escaneo: el escáner que tienes no ve esto porque no hay nada que ver, no porque sea malo.
Lo que sí se puede hacer es más aburrido y funciona: tratar ese software como lo que es, un componente de confianza alta y mantenimiento ajeno, y rodearlo. Preguntar por escrito al proveedor, porque el que no contesta ya te ha contestado. Y vigilar el comportamiento del servidor donde vive, que es lo único que queda cuando no hay firma que buscar: un proceso de IIS que lanza cmd.exe no necesita CVE para ser una mala noticia.
Y hay una cosa que puedes mirar tú, hoy, sin esperar a nadie. En el servidor donde corre esa aplicación, abre su web.config y busca si hay un bloque <machineKey> con los valores escritos ahí, en texto plano. Si está, esa es la clave de la que habla todo este post. La ficha del NIST del caso de Gladinet llega a decirlo como remedio —«a CentreStack admin can manually delete the machineKey defined in portal\web.config»—, pero no lo hagas a ciegas en producción: tocar esa clave invalida las sesiones y las cookies de autenticación en marcha, y en algunas aplicaciones es el propio proveedor quien debe regenerarla. Mirar no rompe nada; cambiarla, sí, y toca avisar antes.
El correo que mandaríamos esta mañana
Cuatro preguntas, al proveedor, por escrito. Por escrito importa: lo que se dice por teléfono no sirve de nada en diciembre, cuando hay que decidir si se renueva el contrato.
- 1. «¿La clave de firma de la aplicación se genera en mi instalación o viene en el instalador?» Si la respuesta es «no sé a qué te refieres», apunta la fecha de la conversación. Si es «viene configurada», ya tienes el hallazgo del mes y una conversación concreta que tener con ellos.
- 2. «¿Dónde publicáis los avisos de seguridad, y pedís CVE?» Un proveedor pequeño puede hacerlo muy bien sin tener un portal: basta con una lista de correo y el compromiso de avisar. Lo que no vale es «lo ponemos en las notas de la versión», porque nadie lee las notas de una versión que instala el propio proveedor.
- 3. «¿Qué registra, y adónde?» Si los registros de la aplicación mueren en el disco del propio servidor, la respuesta a «¿qué hizo el atacante?» va a ser un encogimiento de hombros. Que salgan a donde van los demás; no es un proyecto, es una línea de configuración.
- 4. «Si mañana aparece un fallo grave, ¿en cuánto tiempo tengo parche y quién me llama?» No busques un número en un contrato: busca si existe una persona. En software de nicho, el tiempo de parche real depende de que haya alguien con nombre al otro lado, y eso se sabe preguntando antes y no durante.
Y dos que no hace falta preguntar porque las contestas tú, mirando. La primera: con qué cuenta corre ese servicio y qué permisos tiene en el dominio. Es la que decide si un fallo en ese programa significa «un servidor» o «el dominio entero», y la respuesta histórica suele ser una cuenta de administrador de dominio que alguien puso en 2014 porque así funcionaba a la primera. La segunda: si de verdad hace falta que esté publicado en internet. Muchos de estos programas se publicaron en 2020 para que alguien trabajara desde casa y nadie lo revisó después; si hoy se llega por VPN, el formulario que acepta el paquete firmado deja de estar al alcance de cualquiera.
Dónde encaja esto en lo que hacemos
Un fallo sin CVE no se detecta por firma: se detecta por conducta. Ahí es donde sirve un EDR y MDR gestionado, y no por el folleto: en el servidor donde vive tu aplicación sectorial no hay una lista de versiones malas que comparar, hay un proceso que de pronto hace algo que nunca hacía y alguien de guardia que lo mira a las tres de la mañana. La otra mitad es revisión de la postura, y es casi todo preguntas aburridas: con qué cuenta corre cada cosa, qué está publicado sin que haga falta, qué registra y adónde va. No lo resolvemos con un cuestionario; lo resolvemos entrando a mirar la máquina. Si te sirve, hablamos: lo que sale es una lista de aplicaciones que corren con más permisos de los que necesitan y otra de proveedores que no tienen a quién llamar.
En corto
El mismo error —una clave de firma igual para todos los clientes— ha salido cuatro veces en seis años, con notas de 9,1 a 9,8, y el caso de abril ni siquiera tiene ficha. La diferencia entre el software que usa todo el mundo y el que usa solo tu gremio no es la calidad del código: es que en el primero hay gente buscando. En el segundo, el que busca es el que entra. Abrir el web.config cuesta cinco minutos y mandar el correo, diez.
Fuentes (verificadas el 29 de octubre de 2026): CrowdStrike, «Inside the CrowdStrike 2026 Legal Threat Landscape Report», 28-10-2026 — de ahí salen, citadas literalmente, la frase «the first observed targeting of legal sector-specific software», el caso de abril de 2026 («exploited a hardcoded IIS machine key vulnerability in Intapp Time Server»), los casi 500 intentos fallidos contra otras tantas cuentas desde unas 300 direcciones en 30 días, las «more than 340 primarily U.S.-based entities» de la campaña de prueba masiva de contraseñas ORB28, el «impersonating IT staff… within minutes» y el episodio de noviembre de 2025 en el que se contrató a una persona para acceder físicamente a un despacho haciéndose pasar por empleado de IT; el informe también cifra en el 82 % la actividad de motivación económica sobre el sector y en 455 las entidades legales nombradas en sitios de filtración, un 39 % más que el año anterior. Mecánica de la clave de máquina: Microsoft Security Blog, «Code injection attacks using publicly disclosed ASP.NET machine keys», 06-02-2025, con las dos citas sobre el ViewState fabricado y las «over 3,000 publicly disclosed keys». La tabla de los cuatro productos sale de consultas a la base de vulnerabilidades del NIST (CVE-2020-13166, 9,8, 19-05-2020, myLittleAdmin 3.8; CVE-2021-39392, 9,8, 15-09-2021, myLittleBackup ≤1.7; CVE-2025-30406, 9,8 en la ficha primaria del NIST y 9,0 en la del fabricante, 03-04-2025, con la nota «as exploited in the wild in March 2025» y el remedio manual «a CentreStack admin can manually delete the machineKey defined in portal\web.config», Gladinet CentreStack ≤16.1.10296.56315; CVE-2026-5426, 9,1 de quien lo publicó y pendiente de análisis en el NIST, 16-04-2026, KnowledgeDeliver anterior al 24-02-2026; y, para la acotación de que el error no es exclusivo del nicho, CVE-2025-53690 en Sitecore Experience Manager y Experience Platform hasta 9.0, en el catálogo de explotados el 04-09-2025 con plazo 25-09-2025) y del catálogo de vulnerabilidades explotadas de CISA (versión 2026.10.28, 1.762 entradas, descargada y leída por nosotros: CVE-2025-30406 figura con alta el 08-04-2025 y plazo 29-04-2025; los otros tres no figuran). La ausencia de CVE público para el caso de Intapp Time Server es resultado de nuestra propia búsqueda en esas dos fuentes el 29-10-2026 y puede cambiar. La lectura sobre el software sectorial, el proceso basado en CVE y las seis preguntas es nuestra.
¿Con qué cuenta corre el programa de tu sector?
Si la respuesta tarda más de un minuto, esa es la tarea. Repasamos tus aplicaciones de nicho una por una: en qué servidor viven, con qué permisos, publicadas o no, y qué registran. Sale una lista corta de cosas que arreglar, y te decimos cuáles no merecen que las toques.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN