Tornar al Blog

El teu unattend.xml porta la contrasenya del domini en clar

El teu unattend.xml porta la contrasenya del domini en clar

Obre el fitxer amb què instal·les màquines per xarxa i busca l'etiqueta Password. El que hi ha dins és el compte amb què aquells equips s'uneixen al teu domini, escrit tal qual. El teu tècnic no ho va fer malament. És literalment l'exemple que publica Microsoft a la seva documentació.

Això ve a tomb perquè al setembre va circular la notícia que Microsoft deprecia Windows Deployment Services, i la deprecació és la part menys urgent de l'assumpte. Les dues coses que ja t'han passat tenen data, i són del 13 de gener i del 14 d'abril del 2026.

Dues contrasenyes i dues maneres de no protegir-les

Un fitxer de resposta —l'unattend.xml de tota la vida— automatitza la instal·lació perquè ningú hagi de contestar les preguntes de Windows una per una. Per fer-ho necessita dues credencials: la de l'administrador local de l'equip acabat d'instal·lar i la del compte que el posa al domini. Microsoft documenta totes dues, i les tracta diferent.

La del domini no té cap tractament. L'exemple XML que publica la pàgina oficial de Microsoft-Windows-UnattendedJoin és aquest —i la contrasenya del compte de màquina, dues línies més avall, va igual:

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

La de l'administrador local sí que té un ornament, i l'ornament és l'interessant. Porta un element fill anomenat PlainText que la documentació descriu així: «Specifies whether the AdministratorPassword is hidden in the unattended installation answer file». Amagada. No xifrada. Amb PlainText a false, el valor que publica Microsoft al seu propi exemple és aquest:

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

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

És base64 d'UTF-16 amb el nom de l'ajust enganxat al darrere. La contrasenya de l'exemple és pw. Una ordre, sense clau, sense res. Qui vegi el fitxer veu la contrasenya; l'únic que fa el PlainText false és que no la vegis d'un cop d'ull, i això en una auditoria compta exactament zero. Hem escrit abans sobre un camp d'una fitxa d'usuari que va resultar ser una credencial; això és la mateixa categoria de problema, amb la diferència que aquí el camp es diu Password i ningú no pot al·legar sorpresa.

I fins a l'abril, aquell fitxer se servia sense autenticar

El 13 de gener del 2026 es va publicar CVE-2026-0386. La descripció del NVD és d'una sola línia: «Improper access control in Windows Deployment Services allows an unauthorized attacker to execute code over an adjacent network». CWE-284, control d'accés inadequat, 7,5 sobre 10 en CVSS 3.1 amb vector AV:A/AC:H/PR:N/UI:N i els tres impactes —confidencialitat, integritat i disponibilitat— en alt.

Les dues lletres que importen d'aquell vector són AV:A: xarxa adjacent. No s'explota des d'internet; s'explota des del mateix segment. És a dir, des de la presa de xarxa de la sala de reunions, des del portàtil del becari o des de la VLAN plana on conviuen el PC de recepció i el servidor de desplegament. I PR:N vol dir que no calen privilegis previs: n'hi ha prou de ser-hi. La guia d'enduriment de Microsoft explica el mecanisme sense giragonses: «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 apunt d'honestedat abans de continuar, perquè l'expedient ho diu i convé no inflar-ho: la complexitat d'atac està marcada com a alta (AC:H), i la valoració SSVC que CISA va registrar el 14 de gener del 2026 anotava explotació «none» i automatitzable «no». Això no és un cuc. És una credencial de domini en un canal sense autenticar, que és una altra cosa i dura més.

El pedaç del gener no mitigava res

La correcció d'aquest CVE no va arribar com a codi. Va arribar com una casella, i en dues fases separades per tres mesos. La guia de Microsoft les enumera amb les seves dates i amb una redacció que val la pena llegir dues vegades.

Data Fase Què fa Et protegeix sola?
13-01-2026Fase 1«Hands-free deployment continues to be supported and can be explicitly disabled to enhance security»No
14-04-2026Fase 2«Hands-free deployment is disabled by default but can be re-enabled, if necessary, with an understanding of the associated security risks»Sí, llevat que algú la reactivi

Entre aquestes dues files hi ha tres mesos en què una empresa podia tenir el Patch Tuesday del gener aplicat l'endemà, l'inventari en verd i el comportament vulnerable intacte. La fase 1 no va apagar res: va afegir l'interruptor i unes alertes al visor d'esdeveniments. Cal anar a buscar-lo, i viu aquí:

HKLM\SYSTEM\CurrentControlSet\Services\WdsServer\Providers\WdsImgSrv\Unattend
    AllowHandsFreeFunctionality   0x00000000  bloqueja l'accés sense autenticar
    AllowHandsFreeFunctionality   0x00000001  permet el desplegament insegur

Ho vam escriure fa poc a propòsit d'una altra cosa: una política de pedaços que només sap dir «aplicat» o «pendent» no té casella per a això. «Actualitzat» i «mitigat» són dues afirmacions diferents, i al gener del 2026 només una de les dues era certa. Si la teva resposta a una auditoria és l'informe del WSUS, en aquest cas l'informe diu que sí i la màquina diu que no.

Aquella mateixa fase 1 va afegir dos avisos al visor d'esdeveniments, i són la prova documental de l'estat en què es troba cada servidor. Si el bloqueig és actiu, l'esdeveniment diu: «Warning: Unattend file request was made over an insecure connection. Windows Deployment Services has blocked the request to keep the system secure». Si algú va tornar a activar la funció, el servidor escriu el contrari: «Error: This system is using insecure settings for Windows Deployment Services». És a dir, la resposta a «com estem?» fa mesos que s'escriu sola en una màquina on gairebé mai no hi entra algú. Amb una excepció que cal dir perquè el registre no doni falsa tranquil·litat: aquells avisos s'escriuen quan hi ha una petició de fitxer de resposta, de manera que un registre buit no demostra que el servidor estigui bé, només que no se li ha demanat res.

El símptoma arriba mesos després i no s'assembla a la causa

El 14 d'abril el valor per defecte va canviar a totes les plataformes suportades. I a partir d'aquí passa el de sempre amb els canvis de defecte: ningú no ho nota el dia que passa, perquè ningú no reinstal·la servidors un dimarts de pedaços per gust. Es nota setmanes o mesos després, quan a algú li toca refer un equip i el desplegament que anava sol deixa d'anar sol. Entre la causa i el símptoma passa tant de temps que la relació es perd, i el tècnic es posa a buscar què va trencar ell.

Hi ha un segon símptoma, diferent d'aquest i que convé no barrejar, perquè enganya encara més. Si el teu WDS corre sobre Windows Server 2025 i arrenques amb el boot.wim del mitjà d'instal·lació, la documentació avisa que pot sortir això: «A media driver your computer needs is missing. This could be a DVD, USB or Hard disk driver». I afegeix, amb totes les lletres, que «an error message is expected since using boot.wim on WDS running on Windows Server 2025 isn't supported». El missatge parla d'un controlador que falta. La causa és que aquell flux ja no està suportat. Si algú es creu el missatge, es pot passar la tarda carregant controladors de xarxa i d'emmagatzematge en una imatge que no arrencaria de cap manera.

Què diu l'avís del setembre, i què no diu

La frase oficial, a la documentació actualitzada el 18 de setembre del 2026, és aquesta: «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». És una deprecació de futur: comença amb la versió de sistema operatiu posterior a Windows Server 2025. A Windows Server 2025 i anteriors, el rol continua suportat segons el seu cicle de vida.

Nosaltres ho vam llegir malament el primer matí, així que convé separar dues coses que es barregen. Aquella frase inclou l'arrencada PXE de WDS, sí, però parla de la versió següent de Windows Server. Avui el PXE de WDS continua funcionant, i la mateixa pàgina ho diu del canvi actual en un apartat titulat «Not affected»: «This change doesn't affect WDS PXE boot. WDS can still be used to PXE boot devices with custom boot images». El que ja està bloquejat és fer servir el boot.wim del mitjà d'instal·lació com a imatge d'arrencada i llançar el programa d'instal·lació en mode WDS. Els fluxos que fan servir una imatge pròpia —els que munten moltes empreses amb MDT o amb Configuration Manager— no estan tocats per aquell canvi concret, tot i que sí que són dins del perímetre de la deprecació futura.

On sí que fa mal és a l'extrem nou del parc: per a Windows 11, la taula de la documentació marca «Not supported, blocked» amb qualsevol boot.wim de mitjà, inclòs el del mateix Windows 11, i el resum remata que «an end to end deployment of Windows 11 using only WDS can't be performed». Per a Windows Server 2022 el flux continua viu amb un avís que es pot descartar; per a Windows 10 i Windows Server 2019 no canvia res. És a dir: el WDS de moltes pimes continua instal·lant el vell i no instal·la el nou, que és la pitjor manera d'envellir que té una eina, perquè no cau. Es queda a mitges, i la data no se li posa mai.

Apagar la funció no rota la contrasenya

Aquesta és la part que ens preocupa de debò, i no l'hem trobada ni a les cobertures que hem llegit aquests dies ni a la mateixa guia de Microsoft, que es queda en apagar la funció i planificar la migració a altres eines. Posar aquell valor del registre a zero bloqueja l'accés sense autenticar a l'unattend.xml. No esborra el fitxer, no el mou i, sobretot, no canvia la contrasenya que hi ha a dins. Si aquell compte va estar exposat —i si el teu WDS portava anys servint desplegaments desatesos en una xarxa plana, la pregunta no és si va ser accessible sinó durant quant de temps—, continua sent vàlid avui, amb els mateixos permisos que tenia.

I els permisos d'aquell compte són el segon problema. Unir equips a un domini es pot delegar amb un permís molt concret sobre una unitat organitzativa. Als parcs que ens trobem quan entrem a mantenir una infraestructura, aquell compte sol ser administrador del domini, perquè és el que fa que el desplegament funcioni a la primera el dia que es munta i ningú no hi torna. Un fitxer llegible i un compte sobredimensionat, junts, fan un camí.

Què miraríem aquesta setmana

  • 1.El valor del registre i el visor d'esdeveniments, servidor per servidor. Si el valor està a 1 i el servidor escriu l'error d'ajustos insegurs, algú el va reactivar després de l'abril i hi ha una conversa pendent sobre per què.
  • 2.Quins fitxers de resposta hi ha sota el recurs RemoteInstall i qui els pot llegir. No el permís que et penses: el que surt en mirar-ho.
  • 3.Quins comptes hi apareixen, i què poden fer. Rotar la contrasenya i abaixar els permisos al que és imprescindible és feina d'un matí i no depèn de Microsoft.
  • 4.Quina versió de Windows instal·les amb aquell servidor. Si ja hi ha Windows 11 al parc, el camí de WDS amb el boot.wim del mitjà no existeix i cal decidir el següent, no improvisar-lo el dia que calgui.

Sobre el quart punt convé afegir una dada que acota la conversa: Microsoft assenyala Configuration Manager com a alternativa recomanada, i a la guia d'enduriment apunta a més a solucions al núvol com Autopilot. També aclareix, i això és important per saber de què parlem, 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». Dit d'una altra manera: si ja tens Configuration Manager, aquest forat concret no era teu. Si tens un WDS pelat que arrenca equips amb un unattend.xml, sí.

Si la teva recuperació comença per la xarxa

Hi ha un lloc on això deixa de ser una molèstia i es converteix en un número: el pla de recuperació. Molts procediments de tornada a servei comencen amb «arrenca l'equip per xarxa i reinstal·la». Si aquell primer pas depèn d'un rol amb data de caducitat anunciada i d'un flux que ja no val per a la meitat del parc, el temps de recuperació que tens escrit no és el que mesuraràs el dia dolent. Ja vam explicar com es calculen un RTO i un RPO sense fum; aquesta és exactament la mena de dependència que no apareix al full de càlcul i sí que apareix a les tres de la matinada.

I el conflicte d'interès al davant, com sempre: everyWAN viu del manteniment informàtic i dels serveis gestionats, així que posar ordre en això ho facturem nosaltres. La part comprovable d'aquest post no: el valor del registre el pot mirar qualsevol aquesta tarda, els fitxers de resposta estan en un recurs compartit de casa teva, i les frases que hem citat estan enllaçades al final perquè les llegeixis a la font i no en la nostra versió.

Fonts (verificades el 5 d'octubre del 2026): descripció, data de publicació, CWE, puntuació i vector CVSS i valoració SSVC de CISA — NVD, CVE-2026-0386 (publicat el 13 de gener del 2026). Mecanisme del canal RPC sense autenticar, fases 1 i 2 amb les seves dates, ruta i valors del registre, els dos avisos del visor d'esdeveniments, i les frases sobre Configuration Manager i Autopilot — guia d'enduriment de Microsoft relacionada amb CVE-2026-0386 (actualitzada el 14 d'abril del 2026). Frase de deprecació del rol, apartat «Not affected», taula d'escenaris suportats, missatge d'error del controlador que falta i la frase sobre l'abril del 2026 — documentació oficial de suport de boot.wim a WDS (actualitzada el 18 de setembre del 2026). Exemples XML i descripció de l'element PlainText — pàgines oficials d'AdministratorPassword i d'UnattendedJoin / Credentials. La descodificació del valor d'exemple és nostra, feta sobre el valor literal que publica aquella pàgina. Fotografia de portada: «A front-facing shot of a black wall-mounted network rack…», de Mohammed Kateregga, via el directori de fotos de WordPress i Openverse, domini públic (CC0).

Qui sap quins comptes hi ha dins dels teus fitxers de desplegament?

No quants servidors tens: quines credencials viuen als llocs que ningú no mira. Revisem el servidor de desplegament i els comptes que fa servir dins del manteniment informàtic, abaixem permisos i segmentem amb criteri de ciberseguretat, i deixem escrit com es reinstal·la una màquina el dia que toca, que és mitja pàgina del teu pla de disaster recovery.

Parlar amb everyWAN

Etiquetes:

Compartir:

Subscriu-te al nostre butlletí

Per rebre històries del món IT, novetats d'everyWAN i ofertes exclusives per a subscriptors, dona't d'alta a la nostra llista de correu

everyWAN
everyWAN