CVE-2026-47301: de una simple elevación de privilegios en SCCM a ejecución como SYSTEM
Hay vulnerabilidades que, vistas únicamente desde la descripción del CVE, parecen bastante menos interesantes de lo que realmente son.
Es el caso de CVE-2026-47301, una vulnerabilidad de improper access control en Microsoft Configuration Manager, el producto que muchos seguimos llamando por su antiguo nombre: SCCM. Microsoft la publicó el 14 de julio de 2026 con una puntuación CVSS 3.1 de 8.8, describiéndola como una elevación de privilegios que puede ser explotada por un atacante autorizado a través de la red.
Hasta aquí, nada especialmente revolucionario. El problema aparece cuando alguien se pone a mirar qué hay realmente detrás de ese «elevation of privilege». Y eso es precisamente lo interesante del trabajo publicado por Omri Baso, que ha desarrollado un PoC que encadena varios fallos de seguridad hasta convertir la vulnerabilidad en algo bastante más serio: ejecución de código con privilegios SYSTEM en el servidor primario de SCCM.
** Antes de entrar en materia conviene hacer una distinción. CVE-2026-47301 no está catalogada por Microsoft como una Remote Code Execution. La descripción oficial habla de una vulnerabilidad de control de acceso que permite a un atacante autorizado elevar privilegios sobre la red. Su vector CVSS es: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Es decir: explotación remota, baja complejidad, privilegios bajos y sin interacción del usuario, con impacto alto en confidencialidad, integridad y disponibilidad.
Pero una cosa es la clasificación del CVE y otra muy distinta lo que puede construirse alrededor de él.
El PoC publicado en GitHub demuestra precisamente esto: la primitiva proporcionada por la vulnerabilidad puede encadenarse con otras debilidades de Configuration Manager para terminar ejecutando código en el contexto de SYSTEM.
SCCM: un objetivo especialmente interesante
.png)
Configuration Manager es una pieza de infraestructura especialmente atractiva desde el punto de vista ofensivo.
En una organización grande puede tener acceso privilegiado a prácticamente todos los endpoints gestionados. El servidor primario, los Management Points, Distribution Points y demás componentes forman una infraestructura con una relación de confianza muy potente respecto a los equipos administrados.
Por eso comprometer el Primary Site Server no es simplemente comprometer «otro Windows Server». Es conseguir una posición desde la que potencialmente se puede influir sobre una infraestructura diseñada precisamente para administrar cientos o miles de máquinas.
Y ahí está una de las razones por las que este CVE merece más atención de la que podría sugerir inicialmente su etiqueta de EoP.
La cadena de explotación
El trabajo de Baso resulta interesante porque no depende de una única vulnerabilidad mágica.
La cadena combina varias piezas:
Broken access control → subida de CAB → path traversal → escritura arbitraria → bypass de validación de certificados → DLL hijacking → SYSTEM
Es decir, el CVE proporciona una primitiva inicial que posteriormente puede combinarse con el comportamiento de varios componentes de Configuration Manager.
El repositorio lo describe explícitamente como una cadena que combina:
- acceso incorrectamente protegido;
- extracción de archivos CAB con posibilidad de path traversal;
- escritura arbitraria de archivos;
- bypass de la verificación de certificados;
- DLL hijacking;
- y finalmente ejecución como SYSTEM.
Esto es precisamente el tipo de explotación que muchas veces se pierde cuando miramos únicamente el número CVE.
1. El punto de entrada: AdminService
Uno de los elementos centrales del PoC es AdminService, una API de Configuration Manager.
El código del exploit interactúa con endpoints relacionados con la subida de extensiones de consola, concretamente operaciones como UploadExtensionInChunks y UploadExtension.
Lo interesante es que el PoC diferencia dos caminos.
Uno de ellos requiere el control de acceso basado en RBAC, mientras que el investigador identifica una ruta de subida en chunks que puede utilizarse sin ese mismo requisito de RBAC.
En otras palabras, el problema no es simplemente «existe un endpoint». El problema es qué garantías de autorización se aplican realmente a cada camino que termina procesando el mismo tipo de contenido.
Este es un patrón que aparece constantemente en aplicaciones empresariales complejas: una función está correctamente protegida, pero existe otra ruta que termina llegando al mismo código con unas comprobaciones diferentes. Para un atacante, esas diferencias son oro.
2. El CAB como primitiva de escritura
La segunda pieza es especialmente interesante. El mecanismo acepta un archivo CAB que posteriormente es procesado por Configuration Manager.
El problema aparece cuando el nombre o la ruta de los archivos contenidos en ese CAB pueden utilizarse para escapar del directorio previsto durante la extracción.
En términos conceptuales:
Directorio esperado
│
▼
extracción CAB
│
├── archivo legítimo
│
└── ../.. / ../.. / archivo controlado
│
▼
ubicación inesperadaEso convierte una funcionalidad aparentemente inocua —subir una extensión— en una primitiva de escritura arbitraria de archivos.
El .cab del exploit habilita la cuenta de Administrador con RID 500 si está deshabilitada, la renombra como omrispy y establece la contraseña Xm#Poc-2026!Adm1n$Ok. Además, registra los cambios realizados por el exploit y el nombre que tenía anteriormente la cuenta de Administrador con RID 500, de modo que sea posible revertir todos los cambios y dejar el sistema como estaba.
Los registros se guardan en C:POC.txt, en el Primary Site Server afectado.
La carga de la DLL se produce cada 5 minutos, por lo que puede existir cierto retraso entre la ejecución del exploit y el momento en que se observan sus efectos. Este comportamiento fue observado utilizando Procmon64.exe.
3. De escribir un archivo a ejecutar código
Aquí entra el clásico, pero todavía extremadamente efectivo, DLL hijacking.
El PoC utiliza una pareja de DLLs relacionada con adsource: adsource.dll y adsource_original.dll.
La segunda actúa como proxy para permitir que la DLL maliciosa intercepte la carga sin provocar el fallo del proceso original. El propio autor explica que esta técnica permite mantener operativo el servicio SMS_EXECUTIVE.
Esto es importante porque un DLL hijacking útil en un servidor no consiste simplemente en conseguir que Windows cargue «mi DLL».
Hay que conseguir que:
- el proceso privilegiado encuentre nuestra DLL;
- la cargue;
- el proceso continúe funcionando;
- y nuestro código se ejecute dentro de ese contexto.
En este caso, el contexto buscado es SYSTEM.
Y es aquí donde una simple vulnerabilidad de EoP empieza a parecerse bastante más a una RCE desde la perspectiva de un atacante.
4. Encontrar el Primary Site Server
Hay otro detalle interesante desde el punto de vista de Red Team. El PoC no depende de conocer previamente una ruta de instalación concreta de SCCM. El propio investigador indica que la técnica funciona independientemente de dónde esté instalado Configuration Manager, utilizando rutas relativas para alcanzar el directorio correspondiente.
El problema que queda es localizar el Primary Site Server. Y aquí entra Active Directory.
El repositorio explica que el nombre del servidor no tiene por qué estar publicado directamente en AD, pero que puede inferirse examinando los permisos sobre:
CN=System Management,CN=System
La idea es buscar cuentas de máquina con permisos elevados sobre ese contenedor y utilizar esa información para identificar los servidores de sitio.
La PoC propone utilizar PowerShell para consultar las identidades que disponen de permisos GenericAll o FullControl sobre dicho contenedor:
$root = [ADSI]"LDAP://RootDSE"
$configDN = "CN=System Management,CN=System," + $root.defaultNamingContext
$container = [ADSI]"LDAP://$configDN"
$container.ObjectSecurity.Access |
Where-Object { $_.ActiveDirectoryRights -match "GenericAll|FullControl" } |
Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType |
Format-Table -AutoSizeEl resultado muestra las entidades que tienen esos permisos sobre el contenedor. Según el autor, las identidades que terminan en $ corresponden normalmente a cuentas de máquina de los Site Servers.
Es un detalle pequeño, pero bastante interesante desde la perspectiva de Red Team: no estamos descubriendo SCCM mediante un atributo explícito, sino deduciendo la infraestructura a partir de los permisos que Configuration Manager ha establecido en Active Directory.
Una vez tenemos el hostname del Primary Site Server, podemos ejecutar el exploit:
.C1_AFW.exe write SCCM-CM01.basoss.local 'pwn.cab' .evil.cab --verboseLa cadena completa
Podemos resumir conceptualmente el ataque de esta manera:
Lo interesante no es tanto cada técnica individual como la composición. Ninguna de las piezas necesita ser espectacular. El resultado final sí lo es.
Imaginemos un Red Team que ya dispone de una cuenta corporativa normal. No estamos hablando necesariamente de Domain Admin. No estamos hablando de una vulnerabilidad pre-auth. Tenemos simplemente:
credenciales válidas + conectividad hacia la infraestructura SCCM + una instancia vulnerable.
El CVE está definido precisamente con privilegios requeridos bajos (PR:L) y vector de red (AV:N).
A partir de ahí, el atacante puede intentar convertir esa posición inicial en control sobre el servidor de Configuration Manager.
Y éste es un escenario especialmente peligroso porque SCCM representa una frontera de privilegios muy interesante.
Contramedidas
Microsoft ha publicado actualizaciones para las versiones afectadas.
La información disponible apunta a KB37864969 para Configuration Manager 2509 y KB38232642 para las ramas 2503/2603; Microsoft documenta específicamente KB38232642 como una actualización de seguridad que mejora la seguridad de Configuration Manager en el proceso de importación de extensiones de consola.
Además, Microsoft indica que para Configuration Manager 2509 la corrección está integrada en el segundo paquete acumulativo de actualizaciones, por lo que no es necesario instalar una revisión independiente fuera de banda.
Por tanto, la primera recomendación es bastante poco sexy, pero absolutamente necesaria: parchear SCCM.
Y no solamente el sistema operativo. Hay que comprobar específicamente la versión de Configuration Manager y el nivel de actualización aplicado al sitio.
Además, yo añadiría varias comprobaciones.
Primero, identificar todos los Primary Site Servers y comprobar su versión y nivel de parche.
Segundo, revisar quién tiene conectividad hacia los endpoints de AdminService y limitarla en la medida de lo posible.
Tercero, revisar las ACLs de los objetos de Configuration Manager en Active Directory, especialmente el contenedor System Management.
Cuarto, monitorizar cambios inesperados en los directorios de instalación de Configuration Manager y cargas anómalas de DLL.
Y quinto, investigar especialmente cualquier combinación de:
CAB upload
+
unexpected file creation
+
DLL load
+
SMS_EXECUTIVENo es necesario esperar a encontrar un exploit completo en un EDR para detectar que algo raro está ocurriendo.
Referencias:
Powered by WPeMatico
