Por: Taesoo Kim, vicepresidente, Agentic Security, Microsoft.
Hoy Microsoft ha anunciado un gran avance en la defensa cibernética impulsada por IA: nuestro nuevo sistema de seguridad agéntica ayudó a los investigadores a encontrar 16 nuevas vulnerabilidades en la pila de redes y autenticación de Windows, incluidos cuatro fallos críticos en la ejecución remota de código en componentes como la pila TCP/IP del núcleo de Windows y el servicio IKEv2. Utilizaron el nuevo arnés de escaneo agéntico multimodelo de Microsoft Security (nombre en clave MDASH), que fue desarrollado por el equipo de Seguridad de Código Autónomo de Microsoft. A diferencia de los enfoques de modelo único, el arnés orquesta más de 100 agentes de IA especializados a través de un conjunto de modelos fronterizos y destilados para descubrir, debatir y demostrar fallos explotables de principio a fin.
Conozcan más y regístrense para unirse a la vista previa privada
Los resultados hablan por sí mismos: 21 de 21 vulnerabilidades plantadas encontradas con cero falsos positivos en un piloto de pruebas privado; el 96% de la llamada de registro frente a cinco años de casos confirmados del Microsoft Security Response Center (MSRC) en clfs.sys y del 100% en tcpip.sys; y una puntuación líder del sector del 88,45% en el índice público CyberGym de 1.507 vulnerabilidades del mundo real—la puntuación más alta en la clasificación, alrededor de cinco puntos por delante de la siguiente entrada.
La implicación estratégica es clara: el descubrimiento de vulnerabilidades en IA ha pasado de la curiosidad investigadora a la defensa de calidad de producción a escala empresarial, y la ventaja duradera reside en el sistema agéntico alrededor del modelo y no en un modelo individual. El nombre en clave MDASH es utilizado por equipos de ingeniería de seguridad de Microsoft y probado por un pequeño grupo de clientes como parte de una vista previa privada limitada.
Esta publicación explica cómo funciona el nombre en clave MDASH, qué hemos lanzado, qué hemos aprendido en el camino y cómo pueden inscribirse en la vista previa privada.
Descubrimiento de vulnerabilidades impulsado por IA a hiperescala
El equipo de Microsoft Autonomous Code Security (ACS) se formó para llevar la investigación de vulnerabilidades impulsada por IA de una curiosidad investigadora a la ingeniería de producción a escala empresarial. Varios miembros de este equipo llegaron a Microsoft desde Team Atlanta, el equipo que ganó el Desafío Cibernético de IA de DARPA de 29,5 millones de dólares al construir un sistema autónomo de razonamiento cibernético que detectaba y parceaba errores reales en proyectos complejos de código abierto. Las lecciones de ese trabajo, en especial el nivel de ingeniería necesario para que los modelos de lenguaje de vanguardia realicen auditorías de seguridad a nivel profesional, son en torno a lo que se basa nuestro nuevo arnés de escaneo agente multimodelo (nombre en clave MDASH).
La base de código de Microsoft es un reto para auditorías de seguridad por varias razones:
- Superficie propietaria enorme. Windows, Hyper-V, Azure y los ecosistemas de controladores de dispositivo y servicios que los rodean son bases de código privadas de Microsoft—no forman parte del corpus de entrenamiento de ningún modelo de lenguaje convencional, y en verdad difíciles de razonar: las convenciones de llamada al kernel, los invariantes IRP y bloqueos, los límites de confianza del IPC y los modismos internos de componentes no ceden ante la coincidencia de patrones. En esta superficie, un modelo tiene que razonar realmente.
- DevSecOps a gran escala. Cada hallazgo tiene un dueño real, un proceso de triaje y un martes de parches para aterrizar. No hay un cajón silencioso para hallazgos especulativos; si una herramienta produce ruido, el ruido es problema de todos.
- Objetivos de alto valor. Windows, Hyper-V, Xbox y Azure sirven a miles de millones de usuarios. La recompensa por encontrar un único error duro es, de manera inusual, alta, y también lo es el coste de un falso positivo en un componente de primer nivel.
Los hallazgos de esta publicación son el resultado de una estrecha colaboración entre ACS, Microsoft Offensive Research & Security Engineering (MORSE) y Microsoft Windows Attack Research and Protection (WARP). WARP y MORSE son los dueños de la parte profunda y dura de la investigación ofensiva de Windows; ACS aporta la cadena de descubrimiento y validación impulsada por IA. Juntos, los equipos han colaborado para construir un arnés maduro.
Nombre en clave: MDASH—El nuevo arnés de escaneo agéntico multimodelo de Microsoft Security
El nombre en clave MDASH es, en esencia, un sistema agéntico de detección y remediación de vulnerabilidades. El modelo es una entrada. El sistema es el producto.
Un modelo mental útil es pensarlo como una tubería estructurada que toma una base de código y emite hallazgos validados y probados:
- Etapa de preparación: Ingiere el objetivo original, construye índices conscientes del idioma y luego dibuja la superficie de ataque y los modelos de amenaza analizando los compromisos anteriores.
- Etapa de escaneo: Ejecuta agentes auditores especializados sobre rutas de código candidato, para emitir hallazgos candidatos con hipótesis y pruebas.
- Etapa de validación: Ejecuta una segunda cohorte de agentes—debatientes—que argumentan a favor y en contra de la alcance y explotabilidad de cada hallazgo.
- Etapa de deduplicación: Colapsa hallazgos equivalentes a nivel semántico (por ejemplo, agrupación basada en parches).
- Etapa de prueba: Construye y ejecuta entradas activadoras donde la clase de error las admite. La etapa de demostración valida de manera dinámica la precondición y formula las entradas que activan el error para demostrar la existencia de vulnerabilidad (por ejemplo, ASan en C/C++).
Tres entidades hacen que esto funcione en la práctica:
- Un conjunto de modelos diversos que se gestionan de manera eficaz bajo el nombre en clave MDASH. Ningún modelo es el mejor en todas las etapas. El arnés de escaneo agéntico multimodelo ejecuta un panel configurable de modelos. Eso incluye los modelos SOTA como razonador pesado, los modelos destilados como debatiente rentable para pases de alto volumen, y un segundo modelo SOTA separado como contrapunto independiente. El desacuerdo entre modelos es en sí mismo una señal: cuando un auditor señala algo como sospechoso y el debatiente no puede refutarlo, la credibilidad posterior de ese hallazgo aumenta.
- Agentes especializados. Un auditor no razona como un debatiente, que no razona como un proveedor. Cada etapa del oleoducto tiene su propio papel, régimen de puntuación, herramientas y criterios de parada. No esperamos que un solo prompt lo haga todo; no esperamos que un solo agente reconozca, valide y explote un error en una sola pasada. El nombre calve MDASH cuenta con más de 100 agentes especializados, construidos mediante una investigación profunda con vulnerabilidades y exposiciones comunes (CVEs, por sus siglas en inglés) pasadas y sus parches, para trabajar de manera independiente para descubrir los errores, y sus resultados de auditoría se recopilarán en un solo informe.
- Pipeline de extremo a extremo con plugins extensibles. El oleoducto es opinativo, pero no está cerrado. Los plugins permiten a expertos en el dominio inyectar contextos que los modelos fundacionales no pueden ver por sí solos: convenciones de llamada al kernel, reglas IRP, invariantes de bloqueo, límites de confianza IPC, máquinas de estados de códecs. El plugin de demostración CLFS que describimos a continuación es un ejemplo de ello: un plugin de dominio que sabe cómo construir un archivo de registro de disparo dado un hallazgo candidato. Por ejemplo, también se puede aprovechar el razonamiento extendido por equipos de Windows con base de datos de análisis de código personalizado, o la base de datos CodeQL.
La ventaja de esta arquitectura es la portabilidad entre generaciones de modelos. Las etapas de segmentación, validación, deduplicación y demostración de la tubería son agnósticas al modelo por construcción, lo que permite que el harness obtenga lo mejor de lo que cualquier modelo pueda ofrecer. Cuando un modelo nuevo aterriza, probarlo A/B contra el panel actual es un cambio de configuración. Cuando un modelo mejora, la inversión previa del cliente —archivos de alcance, plugins, configuraciones, calibraciones— se mantiene, lo que permite a los clientes navegar por la frontera del valor de seguridad.
Uso del nombre en clave MDASH para investigación en seguridad
Para evaluar las capacidades de detección de errores del arnés de escaneo agéntico multimodelo, primero necesitan conectar con código que nunca ha sido visto por un modelo. Esto elimina la posibilidad de que un modelo «haya aprendido las respuestas del examen.» Escaneamos StorageDrive, un controlador de dispositivo de muestra utilizado en entrevistas de Microsoft para investigadores de seguridad ofensiva. El controlador contiene 21 vulnerabilidades inyectadas de manera deliberada, incluido el uso de los usuarios posteriores (UAF, por sus siglas en inglés) del kernel, problemas de gestión de enteros, lagunas en la validación de IOCTL y errores de bloqueo. Como StorageDrive es una base de código privada que nunca se ha publicado, podemos asumir con seguridad que no se incluyó en los datos de entrenamiento de los modelos de lenguaje modernos.
Ejecutamos el arnés en StorageDrive a través de su configuración predeterminada. Los resultados fueron llamativos: las 21 vulnerabilidades de la verdad en el terreno fueron identificadas correctamente, sin ningún falso positivo en esta ejecución.
Esta sencilla prueba muestra que las capacidades de razonamiento y detección de vulnerabilidades de un nombre en clave MDASH pueden aproximarse a las de investigadores ofensivos profesionales.
Luego usamos el arnés para realizar auditorías de seguridad de la parte más crítica de Windows, es decir, la pila de red TCP/IP.
La cohorte del Patch Tuesday del 12.5.2026
En toda la pila de red de Windows y servicios adyacentes, el Patch Tuesday de hoy incluye 16 CVEs que nuestros equipos de ingeniería encontraron usando el nombre en clave MDASH.
| Componente | Descripción | CVE | Gravedad | Tipo |
| tcpip.sys | Paquetes SSRR IPv4 sin autenticación remota que causan UAF | CVE-2026-33827 | Crítica | Ejecución remota de código |
| tcpip.sys | Deref NULL mediante cabeceras de extensión IPv6 diseñadas | CVE-2026-40413 | Importante | Denegación de Servicio (DoS) |
| tcpip.sys | DoS del núcleo mediante el subflujo de refcount ESP SA | CVE-2026-40405 | Importante | Denegación de Servicio |
| ikeext.dll | Disparadores IKEv2 SA_INIT doble libre LocalSystem RCE | CVE-2026-33824 | Crítica | Ejecución remota de código |
| tcpip.sys | Uso después de la liberación en Ipv4pReassembleDatagram que conduce a la divulgación | CVE-2026-40406 | Importante | Divulgación de información |
| tcpip.sys | Empalme de fragmentos cruzados IPsec mediante reensamblaje | CVE-2026-35422 | Importante | Bypass de características de seguridad |
| tcpip.sys | El RPC local no autenticado de la Plataforma de Filtrado de Windows (WFP) desactiva la caché de nombres | CVE-2026-32209 | Importante | Bypass de características de seguridad |
| ikeext.dll | Fuga de memoria | CVE-2026-35424 | Importante | Denegación de Servicio |
| telnet.exe | Lectura de Out-of-bounds (OOB) en FProcessSB mediante TO_AUTH malformada | CVE-2026-35423 | Importante | Divulgación de información |
| tcpip.sys | El paquete MDL-split IPv6+TCP activa NULL deref | CVE-2026-40414 | Importante | Denegación de Servicio |
| tcpip.sys | El paquete ICMPv6 activa NdisGetDataBuffer NULL deref | CVE-2026-40401 | Importante | Denegación de Servicio |
| tcpip.sys | UAF remoto pre-autenticación mediante doble decremento SA | CVE-2026-40415 | Importante | Ejecución remota de código |
| http.sys | Lectura OOB de flujo de control QUIC remoto sin autenticación | CVE-2026-33096 | Importante | Denegación de Servicio |
| tcpip.sys | Desbordamiento de búfer de pila del kernel mediante blob RPC | CVE-2026-40399 | Importante | Elevación del privilegio |
| netlogon.dll | Usuario CLDAP no autenticado= desbordamiento de pila de filtros | CVE-2026-41089 | Crítica | Ejecución remota de código |
| dnsapi.dll | Respuesta DNS UDP elaborada activa la OOB del heap | CVE-2026-41096 | Crítica | Ejecución remota de código |
Estas vulnerabilidades son 10 en modo kernel / 6 en modo usuario. La mayoría son accesibles desde un puesto en la red sin credenciales. Vamos a echar un vistazo más de cerca.
Dos inmersiones profundas
Los dos hallazgos a continuación son característicos de lo que puede hacer la nueva pipeline de arnés de escaneo agéntico multimodelo de Microsoft Security que un arnés de un solo modelo no puede. El primero es un uso después de la condición de raza del núcleo que requiere razonar sobre la vida útil del objeto a través de un flujo de control no trivial y tres caminos libres concurrentes independientes. El segundo es un aliasing doble-libre que abarca seis archivos fuente y solo es visible frente al contraste de un sitio gestionado de manera correcta en otra parte de la misma base de código.
CVE-2026-33827—UAF remoto no autenticado en tcpip.sys vía SSRR
La vulnerabilidad surge en la ruta de recepción IPv4 de Windows debido a una gestión inadecuada de la vida útil de un objeto de Path contado por referencias dentro de Ipv4pReceiveRoutingHeader. Tras invocar una consulta de enrutamiento, la función pierde su única referencia propia al Path mediante una operación de desreferencia, pero más tarde reutiliza el mismo puntero al manejar el procesamiento de Ruta Estricta de Fuente y Registro (SSRR, por sus siglas en inglés). Como el recuento de referencia del objeto puede llegar a cero en el punto de lanzamiento anterior, la memoria subyacente puede devolverse a un asignador de reubicación por procesador y reutilizarse posteriormente, convirtiendo el acceso posterior en un clásico uso después de liberar en el contexto del kernel.
Esto ocurre en una ruta activable por red que procesa metadatos de paquetes controlados por el atacante, lo que los hace accesibles a IRQL elevado dentro de la pila de red. El problema central se agrava por el modelo de concurrencia de la caché de rutas y las rutinas de limpieza asociadas. Una vez que el llamante renuncia a la propiedad, la vivacidad del objeto Path depende por completo de referencias externas que poseen las estructuras de datos compartidas. Múltiples subsistemas independientes —incluido el rastreador de caché de rutas, rutinas explícitas de vaciado y la recolección de basura basada en estado de la interfaz— pueden eliminar de manera simultánea el objeto y eliminar la referencia final. Estas operaciones no están sincronizadas con la ventana de ejecución del lado receptor en esta función, y no se tiene bloqueo para serializar el acceso. Como resultado, en sistemas SMP el objeto liberado puede ser recuperado y sobrescrito antes de la posterior desreferencia, lo que convierte un simple error de ordenación en un uso después de la carrera con viabilidad real de ejecución.
Desde el punto de vista de la explotación, la vulnerabilidad es accesible mediante un atacante remoto y no autenticado mediante paquetes IPv4 elaborados que contienen la opción SSRR y que superan las comprobaciones estándar de validación. La desreferencia del puntero obsoleto puede desencadenar una cadena de acceso a través de la memoria liberada, lo que puede llevar a lecturas controladas y a una primitiva de corrupción más fuerte si la asignación recuperada está influenciada por el atacante. Aunque la explotación requiere ganar una ventana de temporización estrecha y moldear la reutilización de asignadores, la combinación de accesibilidad remota, contexto de ejecución del núcleo y el potencial de manipulación controlada de la memoria eleva el problema a severidad crítica.
Por qué los sistemas de modelo único pasaron por alto este error
Un único arnés de modelo tiende a pasar por alto este error porque la violación de por vida no es visible a nivel local ni siquiera dentro de la misma función. La liberación de la referencia de Path y su posterior reutilización están separadas por un flujo de control no trivial—una rama alternativa, múltiples comprobaciones de validación y varias condiciones de caída temprana—que rompen el patrón sencillo de «soltar y luego usar» en el que confían la mayoría de los detectores. Sin rastrear la propiedad de referencia a través de estos estados intermedios, el modelo ve dos operaciones independientes en lugar de una dependencia temporal. Como resultado, la desreferencia no parece sospechosa de manera aislada, aunque la semántica del conteo de referencia garantiza que el puntero ya podría ser inválido.
La señal decisiva también vive fuera del contexto inmediato. La misma operación lógica aparece en otros lugares con el orden correcto; todos los datos necesarios se derivan del objeto antes de eliminar la referencia. Esto convierte este sitio de llamadas en una inconsistencia en lugar de un uso indebido evidente.
Detectar eso requiere razonamiento entre archivos: identificar patrones análogos, alinear su intención y notar la desviación. Además, la accesibilidad depende de componer múltiples condiciones: una entrada que establezca la bandera SSRR, la configuración por defecto que permite la ruta y subsistemas concurrentes que puedan recuperar el objeto durante la ventana expuesta. Un análisis de disparo único colapsa estos pasos y pierde la interacción entre ellos, mientras que un enfoque escalonado puede conectar la violación de la propiedad, el modelo de concurrencia y el disparador controlado a nivel externo en un camino de explotación coherente.
Divulgación. CVE-2026-33827, actualizado en abril del Patch Tuesday.
CVE-2026-33824: SA_INIT IKEv2 no autenticado + fragmentación → doble libre → RCE LocalSystem
La vulnerabilidad residía en el servicio IKEEXT, el componente de Windows responsable de la claves IKE y AuthIP para IPsec, y era accesible mediante un atacante remoto y no autenticado a través de UDP/500 en cualquier host configurado como respondedor IKEv2 (RRAS VPN, DirectAccess, infraestructura Always-On VPN o cualquier máquina con una regla de seguridad de conexión entrante). Al enviar un IKE_SA_INIT elaborado que lleve la carga útil de identificador del proveedor «IPsec Security Realm Id» de Microsoft, seguido de un único fragmento IKEv2 (RFC 7383 SKF) que se reensamble de inmediato, un atacante podría desencadenar una asignación determinista de 16 bytes de heap libre de 16 bytes dentro del servicio.
Como IKEEXT se ejecuta como LocalSystem dentro de svchost.exe, esto representa una ruta remota de ejecución de código pre-autenticación hacia uno de los contextos de mayor privilegio del sistema. La causa raíz es un error típico de la propiedad. Cuando IKEEXT reinyecta un fragmento reensamblado a través de su pipeline de recepción, duplica el contexto de recepción del paquete con un memcpy plano. Esta es una copia superficial: clona los bytes del struct pero no las asignaciones del heap a las que apunta. Una de esas asignaciones es el identificador de reino de seguridad proporcionado por el atacante, y tras la copia, tanto el contexto en cola como el SA en Modo Principal en vivo contienen el mismo puntero, y ambos creen ser propietarios.
En el desmontaje, cada uno lo libera, lo que resulta en un doble libre. La secuencia de disparo es de dos paquetes UDP, sin carrera, sin sincronización especial. El servicio IKEEXT funciona como LocalSystem en svchost.exe. Un doble libre de un fragmento de heap de tamaño fijo es una primitiva de corrupción bien entendida en Windows moderno; no publicamos más detalles sobre explotación. La accesibilidad requiere que el host tenga una política de respuesta IKEv2 que acepte las transformaciones propuestas: el error es accesible en RRAS VPN, DirectAccess, Always-On VPN y las reglas de seguridad de conexión IPsec en sus configuraciones típicas, pero un IKEEXT de inicio de servicio sin política de respuesta no es vulnerable. El servicio IKEEXT es DEMAND_START por defecto; cuando existe una política de respondedor, BFE la iniciará en el primer paquete IKE entrante, por lo que el atacante no necesita que IKEEXT ya esté en ejecución.
Por qué los sistemas de modelo único pasaron por alto este error
El error es un error del ciclo de vida de aliasing que abarca seis archivos: ike_A.c (el memcpy defectuoso), ike_B.c (el origen del alias y la primera copia local de la pila), ike_C.c (el free incorrecto), ike_D.c (tanto el patrón correcto como el segundo free), ike_E.c (donde el buffer se llena remotamente) y ike_F.c (el despachador IKEv2 y el sitio de lectura UAF que precede al segundo free). Ningún análisis en un solo archivo lo detecta. La prueba más sólida de que el error es real es la versión correcta del mismo patrón, en la misma base de código, en ike_D.c—inmediatamente después del memcpy del selector. Para detectarlo es necesario que el auditor reconozca el paso que falta en un lugar por referencia al paso actual en otro. Nuestros agentes auditores especializados están diseñados para mostrar justo estas comparaciones; el escenario del debate les obliga a levantarse bajo el contrainterrogatorio.
Divulgación. CVE-2026-33824, actualizado en el martes de parche de abril.
¿Qué capacidad tiene el nombre en clave MDASH?
La cohorte Patch Tuesday y StorageDrive son señales de futuro. Dos benchmarks retrospectivos nos muestran cómo funciona el sistema en comparación con la verdad real en código real y bien valorado.
Retirada de casos históricos del MSRC. Volvimos a ejecutar el nombre en clave MDASH al comparar instantáneas previas al parche de dos componentes de Windows muy revisados y medimos si los errores históricos confirmados por MSRC habrían sido (re)descubiertos:
- clfs.sys: 96% de recuerdos en 28 casos del MSRC en un periodo de cinco años.
- tcpip.sys: Recordación del 100% de 7 casos del MSRC en un periodo de cinco años.
Estos son los datos internos más sólidos que publicamos, y son significativos por una razón específica: la base de datos de casos del MSRC es la verdad sobre lo que explotaron los atacantes reales, qué requirió un Patch Tuesday y a qué tuvieron que reaccionar los defensores. Un sistema que recupera el 96% de un atraso de cinco años de MSRC en un componente del núcleo muy revisado no encuentra debilidades teóricas; lo que importaba era encontrar los errores.
Somos deliberados sobre lo que dicen y no afirman estos números. Son benchmarks retrospectivos de recuerdo en código interno con un recuento de casos finito. Nos dicen que el sistema habría sido útil si hubiera existido en ese momento. No predicen, por sí solos, que los próximos 38 bugs en CLFS se encuentren al mismo ritmo. La señal de futuro es la propia cohorte del Patch Tuesday.
La extensión de prueba de CLFS como ejemplo práctico. El número de retirada del 96% del CLFS es en parte una historia sobre la fase de prueba. Muchos hallazgos de CLFS parecen interesantes hasta que intentas construir un archivo de registro que desencadene; un hallazgo candidato sin una prueba es, en la práctica, una entrada en un retraso en el triaje. El plugin de demostración específico de CLFS que escribimos sabe cómo construir registros de disparo dado un hallazgo candidato: entiende el diseño del contenedor en disco, la secuencia de validación de bloques y la máquina de estados en memoria lo suficiente como para guiar un camino candidato hacia su sumidero. Para esto es justo para lo que sirve la extensibilidad de plugins: los modelos de fundación no internalicen ni deberían internalizar invariantes específicos del sistema de archivos de Microsoft. El plugin los incrusta, el modelo los usa y el resultado son errores que sobreviven a ser demostrados, no errores que se archivan y olvidan.
CyberGym. En el benchmark público de CyberGym —un corpus de 1.507 tareas reales de reproducción de vulnerabilidades extraídas de 188 proyectos OSS-Fuzz— el arnés de escaneo agéntico multimodelo de Microsoft Security alcanza una tasa de éxito del 88,45%, la puntuación más alta en la clasificación publicada por CyberGym en el momento de escribir esto y cerca de cinco puntos por encima de la siguiente entrada, 83,1%. Este resultado se obtuvo a través de la utilización de modelos disponibles en general. Los sólidos resultados sugieren que el sistema agente circundante contribuye de manera sustancial al rendimiento de extremo a extremo, más allá de la capacidad pura del modelo. Para evaluar, utilizamos la configuración predeterminada de CyberGym (nivel 1), que proporciona el código fuente vulnerable y una descripción de vulnerabilidad a alto nivel. Para integrar el protocolo de evaluación de CyberGym, ampliamos la fase de prueba de los arneses para enviar de forma autónoma entradas de prueba de concepto (PoC, por sus siglas en inglés) y recuperar las banderas.
Nuestro análisis de fallos del 12% restante revela dos patrones estructurales notables: entre los hallazgos que se dirigieron al área de código incorrecta, el 82% procedió de tareas con descripciones vagas que también carecían de identificadores de función o archivo, lo que sugiere que la calidad de las descripciones es un factor clave en la precisión del escaneo. También encontramos casos en los que el agente construyó entradas al estilo libFuzzer, pero la tarea de benchmark en realidad requería entradas en formato honggfuzz, lo que llevó a que las reproducciones de otro modo funcionaran en mal estado por desajuste entre el formato del arnés.
Qué significa todo esto
Estamos en un momento de la industria en el que el descubrimiento de vulnerabilidades impulsado por IA deja de ser especulativo y empieza a ser un problema de ingeniería. Los hallazgos de este Patch Tuesday y la revisión retrospectiva de cinco años de casos de CLFS MSRC son evidencia de que los hallazgos de vulnerabilidad a la IA pueden escalar.
Lo que hemos aprendido al construir MDASH y usándolo en Microsoft es más portátil: el arnés hace el trabajo y el modelo es una entrada.
Esto importa de tres maneras concretas.
Primero, el descubrimiento requiere una composición que ningún prompt individual puede lograr. Los bugs de esta publicación —la raza tcpip.sys, la cadena de alias ikeext.dll— no son visibles para un modelo que recibe una sola función. Son visibles para un sistema que puede secuenciar la comparación de patrones entre archivos, el análisis de alcance en varios pasos, el debate entre agentes especializados y la construcción de pruebas de extremo a extremo. Los arneses monomodelo ofrecían menos de lo que los modelos pueden hacer; Agentes individuales demasiado confiables superan lo que los modelos pueden hacer de forma fiable. El arte es el arnés alrededor del modelo, y el arnés es la mayor parte de la ingeniería.
Segundo, la validación es la diferencia entre un hallazgo y una solución. Un escáner que detecta errores candidatos es un escáner que genera un retraso en el triaje. La cohorte del Patch Tuesday es lo que es porque el sistema que la produjo no se queda en el candidato: debate, dedula y demuestra. La validación no es una casilla para verificar; es su propio pipeline de agentes y plugins, y es donde termina la mayor parte de la ingeniería diaria.
Tercero, el sistema absorbe las mejoras del modelo, lo que lo hace duradero. Cuando un nuevo modelo funciona, las etapas de apuntado, debate, deduplicación y demostración no necesitan ser reescritas; cambiamos una configuración y volvemos a hacer una prueba A/B. La inversión del cliente—contexto por proyecto, plugins de escaneo, agentes de demostración—se traslada. Esta es la propiedad arquitectónica que más importa a largo plazo, porque la lotería del modelo va a seguir repitiéndose, y cualquier sistema cuyo valor esté limitado en un modelo concreto es un sistema que hay que reconstruir cada seis meses.
Para los defensores —a cualquier escala, en cualquier código que posean— la implicación es la misma. La pregunta correcta que hay que hacerle a una herramienta de vulnerabilidad de IA no es qué modelo utiliza. Pero, ¿qué hace con el modelo y qué sobrevive cuando llega el siguiente?
Conclusión
El arnés de escaneo agéntico multimodelo de Microsoft Security (nombre en clave MDASH) ayuda a nuestros equipos de ingeniería a mejorar de manera significativa los resultados de seguridad a través del a utilización de modelos de IA disponibles en general—hoy en día. También es probado por los clientes como parte de nuestra limitada vista previa privada. Para unirse a la vista previa privada, por favor suscríbanse aquí.
Muchas gracias a los equipos de Microsoft que trabajan para mejorar la seguridad de nuestros clientes, incluido el equipo de Seguridad de Código Autónomo, la Ingeniería de Investigación y Seguridad Ofensiva de Microsoft (MORSE, por sus siglas en inglés) y la Investigación y Protección contra Ataques de Microsoft Windows (WARP, por sus siglas en inglés), cuyo trabajo llevó a los hallazgos de esta publicación.
Esperamos compartir más novedades con los clientes y la industria mientras trabajamos para hacer del mundo un lugar más seguro para todos.