Configura Credential Guard al Windows pas a pas

Credential Guard s'ha convertit en una peça clau per reforçar la seguretat de credencials en entorns Windows moderns, especialment en organitzacions on un atac de robatori de credencials pot suposar un problema seriós. En lloc de deixar els secrets d'autenticació exposats a la memòria del sistema, aquesta característica els aïlla mitjançant seguretat basada en virtualització, reduint moltíssim la superfície d'atac.

En les següents línies veureu com configurar Credential Guard amb diferents mètodes (Intune/MDM, Directiva de grup i Registre), quins requisits ha de complir l'equip, quines limitacions introdueix, com validar que realment està actiu i també com deshabilitar-ho en escenaris on calgui, incloent màquines virtuals i equips amb bloqueig UEFI. Tot explicat amb detall, però amb un llenguatge proper perquè puguis aplicar-ho sense complicar-te la vida.

Què és Credential Guard i com protegeix les credencials

Credential Guard és una característica de seguretat de Windows que utilitza la seguretat basada en virtualització (VBS) per aïllar credencials i altres secrets relacionats amb l'autenticació. En lloc que tot s'emmagatzemi directament en el procés de l'autoritat de seguretat local (lsass.exe), les dades sensibles es guarden en un component aïllat anomenat LSA aïllat o isolated LSA.

Aquest LSA aïllat s'executa en un entorn protegit, separat del sistema operatiu principal mitjançant l'hipervisor (manera segura virtual o VSM). Només un conjunt molt reduït de binaris, signats amb certificats de confiança, es poden carregar en aquest entorn. La comunicació amb la resta del sistema es fa mitjançant RPC, cosa que impedeix que el el malware que corre al sistema, per molt privilegiat que sigui, pugui llegir directament els secrets protegits.

Credential Guard protegeix específicament tres tipus de credencials: els hashes de contrasenyes NTLM, els tiquets de concessió de tiquets de Kerberos (TGT) i les credencials emmagatzemades per les aplicacions com a credencials de domini. D'aquesta manera es mitiguen atacs clàssics com passa-el-hash o pass-the-ticket, molt habituals en moviments laterals dins de xarxes corporatives.

És important tenir clar que Credential Guard no ho protegeix tot: no cobreix, per exemple, credencials manejades per programari de tercers fora dels mecanismes estàndard de Windows, comptes locals i de Microsoft, ni protegeix davant d'atacs físics o registradors de pulsacions de tecles. Tot i així, redueix enormement el risc relacionat amb credencials de domini.

Habilitació predeterminada de Credential Guard

Des de Windows 11 22H2 i Windows Server 2025, la seguretat basada en virtualització (VBS) i Credential Guard s'activen per defecte en dispositius que compleixen els requisits de maquinari, microprogramari i programari definits per Microsoft. Això vol dir que, en molts equips moderns, ja ve preparat i actiu sense que l'administrador hagi de fer res.

L'habilitació predeterminada es realitza en mode “sense bloqueig UEFI”, és a dir, sense el cadenat que impedeix desactivar-lo remotament. Aquest enfocament facilita que els administradors puguin deshabilitar Credential Guard mitjançant polítiques o configuració remota si alguna aplicació crítica no és compatible o es detecten problemes de rendiment.

Quan Credential Guard s'activa per defecte, la pròpia VBS també s'habilita automàticament. No cal configurar VBS a part perquè Credential Guard funcioni, encara que sí que hi ha paràmetres addicionals per reforçar el nivell de protecció de la plataforma (per exemple, exigir protecció DMA a més del arrencada segur).

Hi ha un matís important en equips actualitzats: si un dispositiu tenia Credential Guard deshabilitat explícitament abans d'actualitzar a una versió de Windows on s'activi per defecte, continuarà deshabilitat després de l'actualització. En altres paraules, la configuració explícita de l'administrador té prioritat sobre el comportament per defecte.

Requisits de sistema, maquinari, firmware i llicenciament

Perquè Credential Guard aporti protecció real, el dispositiu ha de complir una sèrie de requisits mínims de maquinari, microprogramari i programari. Aquells equips que superen aquests mínims i disposen de funcionalitats addicionals, com ara IOMMU o TPM 2.0, poden aprofitar nivells de seguretat superiors davant d'atacs DMA i amenaces avançades.

Requisits de maquinari i microprogramari

Els principals requisits de maquinari per a Credential Guard inclouen una CPU de 64 bits amb extensions de virtualització (Intel VT-x o AMD-V) i suport de traducció d'adreces de segon nivell (SLAT, també conegudes com a Extended Page Tables). Sense aquestes capacitats de virtualització, VBS i el mode segur virtual no podran aïllar la memòria de manera adequada.

A nivell de firmware és obligatori disposar de UEFI en versió 2.3.1 o superior amb suport d'arrencada segura (Secure Boot) i un procés d'actualització de microprogramari segur. A més, es recomanen característiques com MOR (Memory Overwrite Request) implementat de forma segura, protecció de la configuració d'arrencada i capacitat d'actualització de microprogramari a través de Windows Update.

L'ús d'una unitat de gestió de memòria d'entrada/sortida (IOMMU), com Intel VT-d o AMD-Vi, és molt recomanable, ja que permet habilitar protecció DMA en conjunció amb VBS. Aquesta protecció evita que dispositius maliciosos connectats al bus puguin accedir directament a la memòria i extreure'n secrets.

El mòdul de plataforma segura (TPM) és un altre component clau, preferentment en versió TPM 2.0, encara que també s'admet TPM 1.2. El TPM proporciona un ancoratge de seguretat en maquinari per protegir la clau mestra de VSM i assegurar que només es pugui accedir a les dades protegides per Credential Guard en un entorn de confiança.

Proteccions de VSM i paper del TPM

Els secrets protegits per Credential Guard s'aïllen en memòria mitjançant el mode segur virtual (VSM). En maquinari recent amb TPM 2.0, les dades persistents de l'entorn VSM es xifren amb una clau mestra de VSM protegida pel propi TPM i pels mecanismes d'arrencada segura del dispositiu.

Tot i que NTLM i els TGT de Kerberos es regeneren a cada inici de sessió i no se solen conservar entre reinicis, l'existència de la clau mestra VSM permet protegir aquelles dades que sí que es puguin mantenir en el temps. El TPM garanteix que no es pugui extreure aquesta clau fora del dispositiu ni accedir als secrets protegits fora d'un entorn validat.

Requisits d'edició de Windows i llicències

Credential Guard no està disponible a totes les edicions de Windows. En sistemes client, s'admet a Windows Enterprise ia Windows Education, però no a Windows Pro ni a Windows Pro Education/SE. És a dir, un equip amb Windows Pro necessitaria una actualització a Enterprise per poder fer servir aquesta funcionalitat.

Els drets d'ús de Credential Guard es concedeixen mitjançant llicències com Windows Enterprise E3 i E5 o bé les llicències educatives A3 i A5. En entorns empresarials, això sol obtenir-se mitjançant acords de llicència per volum, mentre que els OEM normalment lliuren Windows Pro i el client realitza després l'actualització a Enterprise.

Credential Guard en màquines virtuals Hyper-V

Credential Guard també pot protegir secrets dins de màquines virtuals executades a Hyper-V, de forma similar al que fa en equips físics. Els requisits principals són que el host de Hyper-V disposi de IOMMU i que les màquines virtuals siguin de generació 2.

És important entendre la frontera de protecció en aquests escenaris: Credential Guard protegeix davant d'atacs que s'originen dins de la pròpia màquina virtual, però no davant d'amenaces que procedeixen del host amb privilegis elevats. Si l'amfitrió està compromès, podeu continuar tenint accés a les màquines convidades.

Requisits d'aplicacions i compatibilitat

En activar Credential Guard es bloquegen certes funcionalitats d'autenticació, de manera que algunes aplicacions poden deixar de funcionar si depenen de mètodes antics o insegurs. Abans de desplegar-lo massivament, convé provar les aplicacions crítiques per comprovar que segueixen operatives.

Les aplicacions que requereixen xifrat DES per a Kerberos, delegació de Kerberos sense restriccions, extracció de TGT o ús de NTLMv1 es veuran interrompudes perquè aquestes opcions queden directament deshabilitades quan Credential Guard està actiu. És una mesura de seguretat estricta, però necessària per evitar vulnerabilitats greus.

Altres funcionalitats, com l'autenticació implícita, la delegació de credencials, MS-CHAPv2 o CredSSP, exposen les credencials a riscos addicionals fins i tot quan Credential Guard està actiu. Les aplicacions que insisteixen a fer-les servir poden seguir funcionant, però deixen les credencials més exposades, per la qual cosa també es recomana revisar-les.

Hi pot haver també impactes de rendiment si certes aplicacions intenten interactuar directament amb el procés aïllat LsaIso.exe. En general, els serveis que utilitzen Kerberos de forma estàndard (per exemple, recursos compartits de fitxers o escriptori remot) continuen funcionant normalment sense notar canvis.

Com habilitar Credential Guard correctament

La recomanació general de Microsoft és habilitar Credential Guard abans que el dispositiu s'uneixi a un domini o abans que un usuari de domini iniciï sessió per primera vegada. Si s'activa més tard, és possible que els secrets d'usuari o de l'ordinador ja hagin estat exposats a la memòria sense protecció.

Hi ha tres mètodes principals per configurar aquesta característica: mitjançant Microsoft Intune/MDM, usant Directiva de grup ia través del Registre de Windows. L'elecció depèn del tipus d'entorn, les eines de gestió disponibles i el grau d'automatització desitjat.

Habilita Credential Guard mitjançant Microsoft Intune / MDM

En entorns gestionats amb Intune o altres solucions MDM, es pot habilitar Credential Guard creant una directiva de configuració de dispositiu que activi primer la seguretat basada en virtualització i, després, defineixi el comportament específic de Credential Guard.

Usant el CSP de DeviceGuard es poden crear directives personalitzades amb els següents paràmetres OMA-URI clau:

• Activar VBS: OMA-URI ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurity, tipus de dades int, valor 1 per habilitar la seguretat basada en virtualització.
• Configura Credential Guard: OMA-URI ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlags, escriviu int, valor 1 per habilitar amb bloqueig UEFI o 2 per habilitar sense bloqueig.

Un cop creada la directiva, s'assigna al grup de dispositius o usuaris que es vol protegir. Després de l'aplicació de la política, cal reiniciar el dispositiu perquè Credential Guard entri en funcionament.

Configura Credential Guard amb Directiva de grup (GPO)

En dominis Active Directory, el mètode més còmode sol ser la GPO. Podeu utilitzar l'Editor de directiva de grup local per a un únic equip o crear un objecte de directiva de grup vinculat a dominis o unitats organitzatives per incloure molts dispositius.

La ruta concreta de la política de grup és: Configuració de l'equip → Plantilles administratives → Sistema → Device Guard. Dins d'aquesta secció hi ha una configuració anomenada «Activar la seguretat basada en virtualització».

En habilitar aquesta directiva, cal triar l'opció de Credential Guard a la llista desplegable de «Configuració de Credential Guard»:

• Habilitat amb bloqueig UEFI: impedeix deshabilitar remotament Credential Guard; només es pot canviar mitjançant accés físic al microprogramari/BIOS.
• Habilitat sense bloqueig: permet desactivar Credential Guard posteriorment mitjançant GPO o configuració remota.

Les GPO es poden filtrar mitjançant grups de seguretat o filtres WMI, permetent aplicar aquesta protecció només a certs tipus dequips o perfils. Després de l'aplicació de la política, també cal reiniciar perquè els canvis tinguin efecte.

Configura Credential Guard mitjançant el Registre de Windows

Quan es necessita un control més granular o un script personalitzat, es pot habilitar Credential Guard directament a través del Registre. Aquest mètode sol fer-se servir en escenaris avançats o automatitzacions on no es disposa de GPO o MDM.

Per activar la seguretat basada en virtualització (VBS), cal configurar les claus següents:

• Ruta de clau: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
  Nom: EnableVirtualizationBasedSecurity, escriviu REG_DWORD, valor 1.
• Ruta de clau: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
  Nom: RequirePlatformSecurityFeatures, escriviu REG_DWORD, valor 1 per a arrencada segura o 3 per a arrencada segura amb protecció DMA.

Per a la configuració específica de Credential Guard s'usa la clau:

• Ruta de clau: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  Nom: LsaCfgFlags, escriviu REG_DWORD, valors possibles:
  0 per deshabilitar Credential Guard,
  1 per habilitar-lo amb bloqueig UEFI,
  2 per habilitar-lo sense bloqueig.

Després d'ajustar aquestes claus al Registre, cal reiniciar l'equip perquè VBS i Credential Guard s'inicialitzin correctament i comencin a protegir credencials.

Comprovar si Credential Guard està habilitat

Encara que pugui semblar temptador mirar si el procés LsaIso.exe està en execució des de l' Administrador de tasques, Microsoft no recomana aquest mètode com a comprovació fiable. Al seu lloc, es proposen tres mecanismes principals: Informació del sistema, PowerShell i Visor d´esdeveniments.

Verificació amb Informació del sistema (msinfo32)

La forma més senzilla per a molts administradors és utilitzar l'eina «Informació del sistema» de Windows:

1. Selecciona Inici i escriu msinfo32.exe, després obriu l'aplicació «Informació del sistema».
2. Al panell esquerre, accedeix a Resum de sistema.
3. Al panell dret, cerca l'apartat «Serveis de seguretat basats en virtualització en execució» i comprova que aparegui Credential Guard entre els serveis llistats.

Si Credential Guard figura com a servei en execució en aquesta secció, significa que està correctament habilitat i actiu a l'equip.

Verificació mitjançant PowerShell

En entorns administrats resulta molt pràctic fer servir PowerShell per comprovar massivament l'estat de Credential Guard. Des d'una consola de PowerShell amb privilegis elevats, podeu executar:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

Aquesta ordre retorna un conjunt de valors numèrics que indiquen quins serveis de seguretat basats en virtualització estan actius. En el cas concret de Credential Guard, s'interpreten així:

• 0: Credential Guard deshabilitat (no està en execució).
• 1: Credential Guard habilitat (en execució).

A més d'aquesta consulta genèrica, Microsoft ofereix l'script DG_Readiness_Tool (per exemple, DG_Readiness_Tool_v2.0.ps1), amb què es pot comprovar si el sistema és capaç d'executar Credential Guard, habilitar-lo, deshabilitar-lo i validar el seu estat mitjançant opcions com -Capable, -Enable, -Disable y -Ready.

Ús del visualitzador d'esdeveniments

Una altra via de comprovació més orientada a auditoria és utilitzar el visualitzador d'esdeveniments. Des de eventvwr.exe es pot accedir a «Registres de Windows» → «Sistema» i filtrar els esdeveniments l'origen del qual sigui WinInit.

Entre aquests esdeveniments apareixen entrades relacionades amb l'arrencada dels serveis de seguretat basats en virtualització, incloent-hi aquells que indiquen si Credential Guard s'ha inicialitzat correctament durant el procés d'inici.

Deshabilitar Credential Guard i gestió del bloqueig UEFI

Encara que el més normal és voler mantenir Credential Guard habilitat, hi ha escenaris on pot ser necessari desactivar-ho: incompatibilitats d'aplicacions, proves de laboratori, canvis d'arquitectura de seguretat, etc. El procediment per deshabilitar-lo dependrà de com es va activar i de si es va utilitzar el bloqueig UEFI.

En termes generals, deshabilitar Credential Guard implica revertir la configuració aplicada mitjançant Intune/MDM, Directiva de grup o Registre, i posteriorment reiniciar lequip. No obstant això, quan es va activar amb bloqueig UEFI, hi ha passos addicionals perquè part de la configuració queda emmagatzemada a variables EFI del microprogramari.

Deshabilitació de Credential Guard amb bloqueig UEFI

Si Credential Guard es va habilitar amb bloqueig UEFI, no n'hi ha prou amb canviar la GPO o el Registre. Cal eliminar també les variables EFI associades a la configuració de LSA aïllat utilitzant bcdedit i un petit procés d'arrencada especial.

des d'un símbol de sistema amb privilegis elevats s'executa una seqüència de ordres per:

1. Muntar una unitat EFI temporal amb mountvol i copiar SecConfig.efi a la ruta d'arrencada de Microsoft.
2. Crear una entrada de carregador de sistema amb bcdedit /create apuntant a aquest SecConfig.efi.
3. Configura el bootsequence del gestor d'arrencada perquè arrenqui una vegada amb aquest carregador especial.
4. Afegir l'opció de càrrega DISABLE-LSA-ISO per deshabilitar la configuració de LSA aïllat emmagatzemada a UEFI.
5. Desmuntar de nou la unitat EFI temporal.

Després de fer aquests passos es reinicia el dispositiu. Abans que arrenqueu el sistema operatiu, apareixerà un missatge indicant que s'ha modificat la configuració UEFI i es demanarà confirmació. És imprescindible acceptar aquest missatge perquè els canvis de desactivació siguin persistents.

Deshabilita Credential Guard en màquines virtuals

En el cas de màquines virtuals connectades a un host Hyper-V, es pot fer que la VM no utilitzi VBS i Credential Guard fins i tot si el sistema operatiu convidat estaria preparat per fer-ho.

Des del host, amb PowerShell, es pot executar la següent ordre perquè una màquina virtual quedi exclosa de la seguretat basada en virtualització:

Set-VMSecurity -VMName <VMName> -VirtualizationBasedSecurityOptOut $true

En activar aquesta opció d'exclusió, la VM s'executarà sense les proteccions de VBS i, per extensió, sense Credential Guard, cosa que pot resultar útil en entorns de test o quan s'executen sistemes heretats dins de màquines virtuals.

Integració de Credential Guard a AWS Nitro i altres escenaris

Credential Guard també està disponible en entorns de núvol com a Amazon EC2, aprofitant l'arquitectura segura del sistema AWS Nitro. En aquest context, VBS i Credential Guard es recolzen a Nitro per evitar que les credencials d'inici de sessió de Windows s'extreguin de la memòria del sistema operatiu convidat.

Per utilitzar Credential Guard en una instància de Windows a EC2, cal llançar una instància compatible, seleccionant un tipus d'instància admès i una AMI de Windows preconfigurada que inclogui TPM virtual i suport de VBS. Això es pot fer des de la consola d'Amazon EC2, des d'AWS CLI usant run-instances o amb PowerShell mitjançant New-EC2Instance, especificant, per exemple, una imatge de l'estil TPM-Windows_Server-2022-English-Full-Base.

En alguns escenaris caldrà desactivar la integritat de memòria (HVCI) abans d'activar Credential Guard, ajustant polítiques de grup relacionades amb “Protecció basada en la virtualització de la integritat del codi”. Un cop realitzats aquests ajustaments i reiniciada la instància, es pot habilitar Credential Guard i validar-lo, com en qualsevol altre equip Windows, amb msinfo32.exe.

Límits de protecció i aspectes que Credential Guard no cobreix

Encara que Credential Guard fa un salt enorme en protecció de credencials, no és una bala de plata que ho resolgui tot. Hi ha casos concrets que queden fora del seu àmbit, i cal tenir-los clars per no caure en una falsa sensació de seguretat.

Alguns exemples del que no protegeix són:

• Programari de tercers que gestiona credencials fora dels mecanismes estàndard de Windows.
• comptes locals i comptes de Microsoft configurats al propi equip.
• Base de dades d'Active Directory en controladors de domini Windows Server.
• Canals d'entrada de credencials com a servidors de porta d'enllaç d'Escriptori remot.
• Registradors de pulsacions de tecles i atacs físics directes a lequip.

Tampoc impedeix que un atacant amb codi maliciós a l'equip feu ús dels privilegis ja concedits a una credencial activa. És a dir, si un usuari amb permisos elevats es connecta a un sistema compromès, l'atacant pot aprofitar aquests permisos mentre duri la sessió encara que no pugui robar el hash des de la memòria protegida.

En entorns amb usuaris o comptes d'alt valor (administradors de domini, personal de TI amb accés a recursos crítics, etc.), continua sent recomanable utilitzar equips dedicats i altres capes addicionals de seguretat, com a autenticació multifactor, segmentació de xarxa i mesures anti-keylogger.

Device Guard, VBS i relació amb Credential Guard

Device Guard i Credential Guard solen esmentar-se junts perquè tots dos aprofiten la seguretat basada en virtualització per reforçar la protecció del sistema, encara que resolen problemes diferents.

Credential Guard se centra a protegir credencials (NTLM, Kerberos, Credential Manager) aïllant-les al LSA protegit. No depèn de Device Guard, encara que tots dos comparteixen l'ús de l'hipervisor i de característiques de maquinari com TPM, arrencada segura i IOMMU.

Device Guard, per la seva banda, és un conjunt de característiques maquinari i programari que permeten bloquejar el dispositiu perquè només pugui executar aplicacions de confiança definides en polítiques d'integritat de codi. Canvia el model tradicional (tot s'executa llevat que el bloquegi un antivirus) per un altre en què només s'executa allò explícitament autoritzat.

Totes dues funcions formen part de l'arsenal de Windows Enterprise per protegir davant d'amenaces avançades. Device Guard depèn de VBS i requereix que els controladors siguin compatibles amb HVCI, mentre que Credential Guard es recolza en VBS per aïllar els secrets d'autenticació. Juntes, ofereixen una combinació potent: codi més fiable i credencials més ben protegides.

Tenir Credential Guard ben configurat suposa blindar un dels punts més delicats de qualsevol entorn Windows: les credencials dusuaris i equips. Entendre els seus requisits, saber com activar-lo amb Intune, GPO o Registre, conèixer els seus límits i disposar de procediments clars per verificar-ne l'estat i deshabilitar-lo en casos excepcionals permet aprofitar al màxim aquesta tecnologia sense emportar-se sorpreses en producció.