Tu unattend.xml lleva la contraseña del dominio en claro

Abre el fichero con el que instalas máquinas por red y busca la etiqueta Password. Lo que hay dentro es la cuenta con la que esos equipos se unen a tu dominio, escrita tal cual. Tu técnico no lo hizo mal. Es literalmente el ejemplo que publica Microsoft en su documentación.

Esto viene a cuento porque en septiembre circuló la noticia de que Microsoft deprecia Windows Deployment Services, y la deprecación es la parte menos urgente del asunto. Las dos cosas que ya te han pasado tienen fecha, y son del 13 de enero y del 14 de abril de 2026.

Dos contraseñas y dos maneras de no protegerlas

Un fichero de respuesta —el unattend.xml de toda la vida— automatiza la instalación para que nadie tenga que contestar las preguntas de Windows una por una. Para hacer eso necesita dos credenciales: la del administrador local del equipo recién instalado y la de la cuenta que lo mete en el dominio. Microsoft documenta las dos, y las trata distinto.

La del dominio no tiene ningún tratamiento. El ejemplo XML que publica la página oficial de Microsoft-Windows-UnattendedJoin es este —y la contraseña de la cuenta de máquina, dos líneas más abajo, va igual:

<Identification>
   <Credentials>
      <Domain>fabrikam.com</Domain>
      <Password>MyPassword</Password>
      <Username>MyUserName</Username>
   </Credentials>
   <JoinDomain>fabrikam.com</JoinDomain>
   <MachinePassword>ComputerPassword</MachinePassword>
</Identification>

La del administrador local sí tiene un adorno, y el adorno es lo interesante. Lleva un elemento hijo llamado PlainText que la documentación describe así: «Specifies whether the AdministratorPassword is hidden in the unattended installation answer file». Oculta. No cifrada. Con PlainText a false, el valor que publica Microsoft en su propio ejemplo es este:

<Value>cAB3AEEAZABtAGkAbgBpAHMAdAByAGEAdABvAHIAUABhAHMAcwB3AG8AcgBkAA==</Value>
<PlainText>false</PlainText>

$ echo 'cAB3AEEAZABt…' | base64 -d | iconv -f UTF-16LE
pwAdministratorPassword

Es base64 de UTF-16 con el nombre del ajuste pegado detrás. La contraseña del ejemplo es pw. Una orden, sin clave, sin nada. Quien vea el fichero ve la contraseña; lo único que hace el PlainText false es que no la veas de un vistazo, y eso en una auditoría cuenta exactamente cero. Hemos escrito antes sobre un campo de una ficha de usuario que resultó ser una credencial; esto es la misma categoría de problema, con la diferencia de que aquí el campo se llama Password y nadie puede alegar sorpresa.

Y hasta abril, ese fichero se servía sin autenticar

El 13 de enero de 2026 se publicó CVE-2026-0386. La descripción del NVD es de una sola línea: «Improper access control in Windows Deployment Services allows an unauthorized attacker to execute code over an adjacent network». CWE-284, control de acceso inadecuado, 7,5 sobre 10 en CVSS 3.1 con vector AV:A/AC:H/PR:N/UI:N y los tres impactos —confidencialidad, integridad y disponibilidad— en alto.

Las dos letras que importan de ese vector son AV:A: red adyacente. No se explota desde internet; se explota desde el mismo segmento. Es decir, desde la toma de red de la sala de reuniones, desde el portátil del becario o desde la VLAN plana donde conviven el PC de recepción y el servidor de despliegue. Y PR:N quiere decir que no hacen falta privilegios previos: basta con estar ahí. La guía de endurecimiento de Microsoft explica el mecanismo sin rodeos: «When an unattend.xml file is transmitted over an unauthenticated (insecure) RPC channel, it might expose sensitive data and create a potential risk for credential theft or remote code execution».

Un apunte de honestidad antes de seguir, porque el expediente lo dice y conviene no inflarlo: la complejidad de ataque está marcada como alta (AC:H), y la valoración SSVC que CISA registró el 14 de enero de 2026 anotaba explotación «none» y automatizable «no». Esto no es un gusano. Es una credencial de dominio en un canal sin autenticar, que es otra cosa y dura más.

El parche de enero no mitigaba nada

La corrección de este CVE no llegó como código. Llegó como una casilla, y en dos fases separadas por tres meses. La guía de Microsoft las enumera con sus fechas y con una redacción que merece leerse dos veces.

Entre esas dos filas hay tres meses en los que una empresa podía tener el Patch Tuesday de enero aplicado al día siguiente, el inventario en verde y el comportamiento vulnerable intacto. La fase 1 no apagó nada: añadió el interruptor y unas alertas en el visor de eventos. Hay que ir a buscarlo, y vive aquí:

HKLM\SYSTEM\CurrentControlSet\Services\WdsServer\Providers\WdsImgSrv\Unattend
    AllowHandsFreeFunctionality   0x00000000  bloquea el acceso sin autenticar
    AllowHandsFreeFunctionality   0x00000001  permite el despliegue inseguro

Lo escribimos hace poco a propósito de otra cosa: una política de parcheo que solo sabe decir «aplicado» o «pendiente» no tiene casilla para esto. «Actualizado» y «mitigado» son dos afirmaciones distintas, y en enero de 2026 solo una de las dos era cierta. Si tu respuesta a una auditoría es el informe del WSUS, en este caso el informe dice que sí y la máquina dice que no.

Esa misma fase 1 añadió dos avisos al visor de eventos, y son la prueba documental de en qué estado está cada servidor. Si el bloqueo está activo, el evento dice: «Warning: Unattend file request was made over an insecure connection. Windows Deployment Services has blocked the request to keep the system secure». Si alguien volvió a activar la función, el servidor escribe lo contrario: «Error: This system is using insecure settings for Windows Deployment Services». Es decir, la respuesta a «¿cómo estamos?» lleva meses escribiéndose sola en una máquina a la que casi nunca entra alguien. Con una salvedad que hay que decir para que el registro no dé falsa tranquilidad: esos avisos se escriben cuando hay una petición de fichero de respuesta, así que un registro vacío no demuestra que el servidor esté bien, solo que no se le ha pedido nada.

El síntoma llega meses después y no se parece a la causa

El 14 de abril el valor por defecto cambió en todas las plataformas soportadas. Y a partir de ahí pasa lo de siempre con los cambios de defecto: nadie lo nota el día que ocurre, porque nadie reinstala servidores un martes de parches por gusto. Se nota semanas o meses después, cuando a alguien le toca rehacer un equipo y el despliegue que iba solo deja de ir solo. Entre la causa y el síntoma pasa tanto tiempo que la relación se pierde, y el técnico se pone a buscar qué rompió él.

Hay un segundo síntoma, distinto de este y que conviene no mezclar, porque engaña todavía más. Si tu WDS corre sobre Windows Server 2025 y arrancas con el boot.wim del medio de instalación, la documentación avisa de que puede salir esto: «A media driver your computer needs is missing. This could be a DVD, USB or Hard disk driver». Y añade, con todas las letras, que «an error message is expected since using boot.wim on WDS running on Windows Server 2025 isn't supported». El mensaje habla de un controlador que falta. La causa es que ese flujo ya no está soportado. Si alguien se cree el mensaje, se puede pasar la tarde cargando controladores de red y de almacenamiento en una imagen que no iba a arrancar de ninguna manera.

Lo que dice el aviso de septiembre, y lo que no dice

La frase oficial, en la documentación actualizada el 18 de septiembre de 2026, es esta: «Windows Deployment Services (WDS) is deprecated beginning with the OS version following Windows Server 2025. This includes the inbox WDS role, WDS services, management tools and interfaces, and WDS-provided Preboot Execution Environment (PXE) boot functionality». Es una deprecación de futuro: empieza con la versión de sistema operativo posterior a Windows Server 2025. En Windows Server 2025 y anteriores, el rol sigue soportado según su ciclo de vida.

Nosotros lo leímos mal la primera mañana, así que conviene separar dos cosas que se mezclan. Esa frase incluye el arranque PXE de WDS, sí, pero habla de la versión siguiente de Windows Server. Hoy el PXE de WDS sigue funcionando, y la misma página lo dice del cambio actual en un apartado titulado «Not affected»: «This change doesn't affect WDS PXE boot. WDS can still be used to PXE boot devices with custom boot images». Lo que ya está bloqueado es usar el boot.wim del medio de instalación como imagen de arranque y lanzar el programa de instalación en modo WDS. Los flujos que usan una imagen propia —los que montan muchas empresas con MDT o con Configuration Manager— no están tocados por ese cambio concreto, aunque sí estén dentro del perímetro de la deprecación futura.

Donde sí duele es en el extremo nuevo del parque: para Windows 11, la tabla de la documentación marca «Not supported, blocked» con cualquier boot.wim de medio, incluido el del propio Windows 11, y el resumen remata que «an end to end deployment of Windows 11 using only WDS can't be performed». Para Windows Server 2022 el flujo sigue vivo con un aviso que se puede descartar; para Windows 10 y Windows Server 2019 no cambia nada. Es decir: el WDS de muchas pymes sigue instalando lo viejo y no instala lo nuevo, que es la peor forma de envejecer que tiene una herramienta, porque no se cae. Se queda a medias, y la fecha no la pone nunca.

Apagar la función no rota la contraseña

Esta es la parte que nos preocupa de verdad, y no la hemos encontrado ni en las coberturas que hemos leído estos días ni en la propia guía de Microsoft, que se detiene en apagar la función y planificar la migración a otras herramientas. Poner ese valor del registro a cero bloquea el acceso sin autenticar al unattend.xml. No borra el fichero, no lo mueve y, sobre todo, no cambia la contraseña que hay dentro. Si esa cuenta estuvo expuesta —y si tu WDS llevaba años sirviendo despliegues desatendidos en una red plana, la pregunta no es si fue accesible sino durante cuánto tiempo—, sigue siendo válida hoy, con los mismos permisos que tenía.

Y los permisos de esa cuenta son el segundo problema. Unir equipos a un dominio se puede delegar con un permiso muy concreto sobre una unidad organizativa. En los parques que nos encontramos cuando entramos a mantener una infraestructura, esa cuenta suele ser administrador del dominio, porque es lo que hace que el despliegue funcione a la primera el día que se monta y nadie vuelve a tocarlo. Un fichero legible y una cuenta sobredimensionada, juntos, hacen un camino.

Qué miraríamos esta semana

Sobre el cuarto punto conviene añadir un dato que acota la conversación: Microsoft señala Configuration Manager como alternativa recomendada, y en la guía de endurecimiento apunta además a soluciones en la nube como Autopilot. También aclara, y esto es importante para saber de qué estamos hablando, que «this vulnerability does not impact Microsoft Configuration Manager. The issue applies only to native Windows Deployment Services (WDS) scenarios where an Unattend.xml file is referenced». Dicho de otro modo: si ya tienes Configuration Manager, este agujero concreto no era tuyo. Si tienes un WDS pelado que arranca equipos con un unattend.xml, sí.

Si tu recuperación empieza por la red

Hay un sitio donde esto deja de ser una molestia y se convierte en un número: el plan de recuperación. Muchos procedimientos de vuelta a servicio empiezan con «arranca el equipo por red y reinstala». Si ese primer paso depende de un rol con fecha de caducidad anunciada y de un flujo que ya no vale para la mitad del parque, el tiempo de recuperación que tienes escrito no es el que vas a medir el día malo. Ya contamos cómo se calculan un RTO y un RPO sin humo; esta es exactamente la clase de dependencia que no aparece en la hoja de cálculo y sí aparece a las tres de la madrugada.

Y el conflicto de interés por delante, como siempre: everyWAN vive del mantenimiento informático y de los servicios gestionados, así que poner orden en esto lo facturamos nosotros. La parte comprobable de este post no: el valor del registro lo puede mirar cualquiera esta tarde, los ficheros de respuesta están en un recurso compartido de tu casa, y las frases que hemos citado están enlazadas al final para que las leas en la fuente y no en nuestra versión.

Fuentes (verificadas el 5 de octubre de 2026): descripción, fecha de publicación, CWE, puntuación y vector CVSS y valoración SSVC de CISA — NVD, CVE-2026-0386 (publicado el 13 de enero de 2026). Mecanismo del canal RPC sin autenticar, fases 1 y 2 con sus fechas, ruta y valores del registro, los dos avisos del visor de eventos, y las frases sobre Configuration Manager y Autopilot — guía de endurecimiento de Microsoft relacionada con CVE-2026-0386 (actualizada el 14 de abril de 2026). Frase de deprecación del rol, apartado «Not affected», tabla de escenarios soportados, mensaje de error del controlador que falta y la frase sobre abril de 2026 — documentación oficial de soporte de boot.wim en WDS (actualizada el 18 de septiembre de 2026). Ejemplos XML y descripción del elemento PlainText — páginas oficiales de AdministratorPassword y de UnattendedJoin / Credentials. La descodificación del valor de ejemplo es nuestra, hecha sobre el valor literal que publica esa página. Fotografía de portada: «A front-facing shot of a black wall-mounted network rack…», de Mohammed Kateregga, vía el directorio de fotos de WordPress y Openverse, dominio público (CC0).