Hva er Credential Guard, og hvordan sjekker man om det er aktivert?

Å beskytte påloggingsinformasjon i Windows har blitt en kritisk oppgave for ethvert selskap som tar cybersikkerhet på alvor. Hver gang en bruker logger seg inn, genereres og lagres påloggingsinformasjon. ekstremt verdifulle autentiseringshemmeligheter (hasher, billetter, tokens osv.) som, hvis de faller i hendene på en angriper, lar dem bevege seg rundt i nettverket som om de var en legitim bruker. Det er nettopp her Credential Guard kommer inn i bildet.

Windows Defender Credential Guard er en sikkerhetsfunksjon som utnytter Virtualiseringsbasert sikkerhet (VBS) å isolere disse hemmelighetene og forhindre at det «normale» operativsystemet eller skadelig programvare med utvidede rettigheter får tilgang til dem. Selv om det ikke er en mirror current og ikke dekker alle typer legitimasjonsinformasjon eller alle angrepsvektorer, reduserer det drastisk effektiviteten til klassiske teknikker som Pass-the-Hash og Pass-the-Ticketsamt verktøy som Mimikatz i mange scenarier.

Hva er egentlig Windows Defender Credential Guard?

Credential Guard er en Windows-funksjon som er utviklet for å Beskytt domenelegitimasjon og andre autentiseringshemmeligheter Denne teknologien beskytter mot angrep som prøver å lese dem direkte fra systemminnet. Den dukket først opp i Windows 10 Enterprise og Windows Server 2016, og er fortsatt tilstede i senere versjoner av Windows 11 og Windows Server.

Generelt sett er Credential Guard avhengig av VBS for å utføre deler av sikkerhetsprosessen i en miljø isolert av hypervisoren, separat fra hovedoperativsystemet. I stedet for hemmelighetene som ligger direkte i minnet til den tradisjonelle lokale sikkerhetsmyndigheten (LSA)-prosessen (lsass.exe), lagres i en beskyttet og uavhengig prosess, vanligvis administrert av LsaIso.exe, som bare kan nås med den mest privilegerte og pålitelige koden.

Denne separasjonen har som mål å forhindre at skadelig programvare som har fått administratorrettigheter, bare dump LSASS-minnet å trekke ut NTLM-hasher, Kerberos-billetter eller legitimasjonsinformasjon lagret i Credential Manager. Tilnærmingen er ikke å endre autentiseringsprotokollene, men å for å sikre hvor og hvordan legitimasjon lagres i minnet.

Hemmeligheter og tjenester beskyttet av Credential Guard

Funksjonen beskytter ulike typer legitimasjon som tradisjonelt har vært et hovedmål for angripere. Blant hemmelighetene som Credential Guard beskytter, er først og fremst de som er relatert til:

• NTLMNTLM-passord-hasher brukt til autentisering.
• KerberosMer spesifikt, Ticket Granting Ticket (TGT) som lar deg be om andre tjenestebilletter.
• Legitimasjonsansvarligdomenelegitimasjon lagret av applikasjoner og tjenester.
• Lokale og eksterne pålogginger som avhenger av domenelegitimasjon.

I tidligere versjoner av Windows lå disse hemmelighetene i prosessminnet. LSASS på en tilgjengelig måte for en angriper med utvidede rettigheter. Med Credential Guard aktivert kjøres en isolert LSA-prosess som ikke direkte eksponerer disse hemmelighetene for verktøy som prøver å lese standard operativsystemets minne.

Hvordan virtualiseringsbasert sikkerhet (VBS) og virtuell sikker modus (VSM) fungerer

Nøkkelen til Credential Guard er VBS, en teknologi som bruker Windows-hypervisoren til å opprette isolerte utførelsesmiljøer innenfor den samme fysiske maskinen. Innenfor dette miljøet, ofte kalt Virtual Secure Mode (VSM), kjører sikkerhetstjenester som administrerer autentiseringshemmeligheter.

Når Credential Guard er aktiv, lagres hemmeligheter i minnet i VSM og ikke i vanlig minneplass i operativsystemetHypervisoren sørger for at bare svært privilegert og verifisert kode har tilgang til dem. På denne måten, selv om en angriper klarer å kompromittere operativsystemet med administratorrettigheter, reduseres sjansene deres for å lese disse hemmelighetene direkte betraktelig.

På moderne maskinvare som inkluderer en kompatibel TPM 2.0, kan VSM-persistente data krypteres med en VSM-hovednøkkelDenne nøkkelen lagres og beskyttes av TPM og dens rotmekanismer for tillit på fastvarenivå. Som et resultat, selv om noen prøver å tukle med oppstartsprosessen eller klone en disk, Du vil ikke kunne få tilgang til beskyttede hemmeligheter utenfor et bekreftet miljø..

Det er også viktig å merke seg at Credential Guard vanligvis ikke lagrer data som følgende på disk: NTLM-hash eller TGTDisse genereres på nytt ved hver pålogging og går tapt mellom omstarter, slik at de ikke er direkte avhengige av VSM-hovednøkkelen eller TPM-en for å forbli sikre etter en avslutning.

Grenser og legitimasjon som Credential Guard ikke beskytter

Til tross for fordelene har Credential Guard klare begrensninger som må forstås For å unngå overdreven selvtillit. Det finnes legitimasjons- og autentiseringsflyter som faller utenfor beskyttelsesområdet, eller som rett og slett ikke fungerer på samme måte når funksjonen er aktiv.

På den ene siden, når Credential Guard er aktivert, vil visse eldre protokoller, som f.eks. NTLMv1, MS-CHAPv2, Digest og CredSSP De kan ikke bruke påloggingsinformasjon fra en allerede pålogget økt. Dette betyr at enkel pålogging (SSO) med disse protokollene slutter å fungere. Programmer som er avhengige av dem, må kanskje be om brukernavn og passord på nytt eller bruke påloggingsinformasjon lagret i Windows-lageret. som i disse tilfellene ikke er beskyttet av Credential Guard.

Videre finnes det metoder for legitimasjonshåndtering som faller helt utenfor omfanget av denne funksjonen, for eksempel:

• Tredjepartsprogramvare som lagrer passord eller tokener utenfor standard Windows-infrastruktur.
• Lokale kontoer og Microsoft-kontoer, som ikke har samme type isolasjon som domenelegitimasjon.
• Active Directory-databaser lagres på Windows Server-domenekontrollere. Credential Guard beskytter ikke Active Directory-databasen eller inngående pipelines for legitimasjon direkte i tjenester som Remote Desktop Gateway.
• Tasteloggere og andre enheter for inndataopptak: Hvis angriperen registrerer tastetrykk, kan de stjele passordet før det i det hele tatt er lagret i LSASS eller sandkassen.
• Fysiske angrep til utstyret (for eksempel tilgang til aktivt minne eller disklesing ved hjelp av avanserte teknikker).

Det bør også bemerkes at Credential Guard ikke hindrer en angriper som allerede har skadelig programvare på maskinen i å få tilgang. Bruk rettighetene til gyldig legitimasjon som ble innhentet på alternative måter. Hvis for eksempel en administrator logger seg på en allerede kompromittert maskin, kan angriperen utnytte den aktive økten til å utføre handlinger med sine tillatelser, selv om de ikke klarer å trekke ut NTLM-hashen fra sandkassemiljøet.

På den annen side, den bufret påloggingsinformasjon Windows-pålogginger (ofte kalt «bufrede pålogginger») faller heller ikke inn under kategorien gjenbrukbar legitimasjon på andre datamaskiner. De lagres i det lokale registeret og brukes bare til å validere pålogginger når domenet ikke er tilgjengelig. Disse administreres av sikkerhetspolicyen «Interaktiv pålogging: Antall tidligere pålogginger som skal bufres» og De er ikke spesifikt beskyttet av Credential Guard.

Til slutt, den Kerberos-tjenestekuponger De er ikke beskyttet av Credential Guard, selv om TGT er det. Og når Credential Guard er aktiv, vil ikke Kerberos tillate ubegrenset delegering eller DES-kryptering, verken for initierte legitimasjonsopplysninger eller forespurte eller lagrede legitimasjonsopplysninger.

Fordeler mot angrep på legitimasjonstyveri

Hovedmålet med Credential Guard er å stoppe angrep mot «tyveri og gjenbruk» av legitimasjon, spesielt:

• Pass-the-HashGjenbruk av stjålne NTLM-hasher for autentisering på andre systemer.
• Pass-the-Ticketmisbruk av Kerberos-billetter (TGT eller tjeneste) hentet fra en kompromittert maskin.

Ved å isolere hemmeligheter i VSM og begrense hvem som har tilgang til dem, blokkeres mange av teknikkene som utnytter verktøy som Mimikatz. dump LSASS-minnetI et miljø uten Credential Guard kan Mimikatz trekke ut NTLM-hasher og Kerberos-billetter uten store problemer når angriperen har administratorrettigheter. Med Credential Guard aktivert forhindrer den isolerte LSA-prosessen at disse hemmelighetene er tilgjengelige i minnet som er tilgjengelig fra standard operativsystem.

Likevel er det viktig å forstå at Credential Guard ikke er usårbar. Mimikatz og lignende verktøy kan fortsatt, for eksempel, fange opp legitimasjon mens den legges innHvis systemet allerede er kompromittert og den privilegerte brukeren logger seg inn etterpå, har Mimikatz' forfatter advart om at hvis angriperen får kontroll over endepunktet før administratoren oppgir legitimasjonen deres, finnes det fortsatt måter å stjele den på. Videre beskytter ikke Credential Guard mot ondsinnet bruk av legitimasjon av... legitime interne brukereHvis noen har autorisert tilgang til en ressurs, vil ikke denne teknologien hindre dem i å kopiere sensitive data.

Aktivert som standard i Windows 11 og Windows Server

I nyere versjoner av systemet har Microsoft gått et skritt videre og muliggjort kombinasjonen av VBS og Credential Guard på visse enheter. Fra og med Windows 11, versjon 22H2 og Windows Server 2025, aktiveres disse funksjonene automatisk på datamaskiner som oppfyller minimumskravene.

Fabrikkinnstillingen gjøres vanligvis uten UEFI-låsDette betyr at administratorer kan deaktivere Credential Guard eksternt hvis de anser det som nødvendig, for eksempel på grunn av kritisk inkompatibilitet med et eldre program. Når Credential Guard er aktivert, aktiveres også VBS automatisk.

Det er viktig å vite at hvis et team allerede hadde Credential Guard eksplisitt deaktivert Før oppgradering til en versjon av Windows der funksjonen er aktivert som standard, opprettholdes statusen «deaktivert» etter oppgraderingen. Den eksplisitte policyen prioriteres alltid over standardvirkemåten etter en omstart.

Krav til maskinvare, fastvare og programvare

For at Credential Guard skal tilby effektiv beskyttelse, må enheten overholde Minimumskrav til maskinvare, fastvare og operativsystemJo mer moderne og komplett maskinvaren er, desto høyere beskyttelsesnivå kan oppnås.

Viktige krav inkluderer:

• 64-bits CPU, med støtte for maskinvarevirtualisering.
• Virtualiseringsbasert sikkerhet aktivert (VBS).
• Sikker oppstart aktivert og konfigurert.

I tillegg, selv om det ikke alltid er obligatorisk, anbefales det sterkt å ha:

• TPM (Trusted Platform Module) versjon 1.2 eller 2.0, enten separat eller fastvare, for å koble beskyttelse til maskinvare og lagre hovednøkler sikkert.
• UEFI-låssom hindrer en angriper i å deaktivere Credential Guard ganske enkelt ved å endre registeroppføringer eller endringer i lavnivåkonfigurasjonen.

Lag som oppfyller disse grunnleggende kravene kan være kvalifisert til ytterligere sikkerhetsvurderinger og høyere beskyttelsesnivåer mot trusler som prøver å utnytte oppstartskjeden eller direkte minnetilgang.

Bruke Credential Guard på virtuelle Hyper-V-maskiner

Credential Guard kan også beskytte hemmeligheter i virtuelle maskiner som kjører på Hyper-V, omtrent som det gjør på fysisk maskinvare. Når det er aktivert i en VM, isoleres hemmeligheter fra angrep som stammer fra innenfor den samme virtuelle maskinen.

Det finnes imidlertid viktige nyanser: Credential Guard gir ikke beskyttelse mot angrep med forhøyede rettigheter lansert fra vert som den virtuelle maskinen kjører. Det vil si at vertsadministratoren eller en angriper som kontrollerer det underliggende fysiske systemet fortsatt kan ha manipulasjonsalternativer.

For at Credential Guard skal fungere på en virtuell Hyper-V-maskin, kreves minst følgende:

• En Hyper-V-vert med IOMMU (inndata/utdata-minnehåndteringsenhet) kompatibel.
• En virtuell maskin av Generasjon 2, som støtter sikker UEFI-oppstart og nødvendige utvidelser.

Fra verten er det til og med mulig å deaktivere Credential Guard for en bestemt VM ved hjelp av PowerShell, med en kommando som ligner på Set-VMSecurity-VirtualizationBasedSecurityOptOut $true, som peker på navnet på den virtuelle maskinen.

Kompatible Windows-lisenser og -utgaver

Credential Guard er ikke tilgjengelig i alle utgaver av Windows. Microsoft har reservert det for de mer forretnings- og utdanningsorienterte versjonene, og utelatt visse standard profesjonelle utgaver.

Når det gjelder kompatibilitet mellom Windows-utgaver, gjelder i hovedsak følgende:

• Windows Enterprise- Støtter Credential Guard.
• Windows Education: kompatibel.
• Windows Pro og Windows Pro Education/SE: inkluderer ikke direkte støtte for Credential Guard.

Når det gjelder lisensrettigheter, er funksjonaliteten knyttet til abonnementer på bedrifts- og utdanningsnivå. Blant lisensene som Ja, de gir bruksrettigheter Legitimasjonsvakt inkluderer:

• Windows Enterprise E3
• Windows Enterprise E5
• Windows Education A3
• Windows Education A5

Andre lisenser, som Windows Pro eller Pro Education Standard, inkluderer ikke disse rettighetene som standard. For mer detaljert informasjon om hva hver lisens inkluderer og hvilke scenarioer den dekker, anbefales det å se gjennom den offisielle dokumentasjonen. Windows-lisensiering.

Innvirkning på autentiseringsapplikasjoner og -protokoller

Aktivering av Credential Guard har direkte konsekvenser i noen tilfeller eldre autentiseringsprotokoller og visse funksjoner av Kerberos og NTLM, som mange eldre applikasjoner fortsatt bruker. Før en masseutrulling er det avgjørende å identifisere krav og teste kompatibilitet.

Applikasjonene vil slutte å fungere som de skal hvis de krever noen av følgende funksjoner:

• Støtte for DES-kryptering i Kerberos.
• Kerberos-delegering uten begrensninger.
• Utvinning av Kerberos TGT fra systemet.
• Bruk av NTLMv1 som en autentiseringsprotokoll.

Andre scenarier ødelegger ikke nødvendigvis applikasjonen, men de gjør det. øke risikoen for eksponering av legitimasjonsinformasjon hvis den fortsatt brukes:

• Implisitt autentisering som fanger opp eller gjenbruker klartekstlegitimasjon.
• Delegering av legitimasjon uten tilstrekkelige sikkerhetstiltak.
• Protokoller som MS-CHAPv2 y KredittSSPsom kan tvinge brukeren til å oppgi påloggingsinformasjon som deretter lagres på en mindre sikker måte.

Noen tjenester eller applikasjoner som prøver koble den isolerte prosessen direkte LSAIso.exe De kan forårsake ytelsesproblemer eller funksjonsfeil hvis de ikke er utviklet for å fungere med denne nye modellen. Omvendt kan tjenester som er avhengige av Kerberos som standard, for eksempel SMB-delinger eller godt konfigurerte tilkoblinger til eksternt skrivebord, De bør fortsette å fungere normalt når Credential Guard er aktivert.

Slik aktiverer du Credential Guard i bedriftsmiljøer

Sikkerhetsanbefalingen er å aktivere Credential Guard. før du kobler en enhet til domenet eller før en domenebruker logger seg på for første gang, slik at hemmeligheter aldri lagres uten forbedret beskyttelse. Hvis den aktiveres etter at maskinen har vært i bruk en stund, kan det hende at noen påloggingsinformasjon allerede er kompromittert.

Det finnes flere hovedmetoder for å aktivere Credential Guard på en rekke Windows-enheter:

• Microsoft Intune / MDM.
• Gruppepolicyordre (GPO).
• Direkte registerkonfigurasjon.

Konfigurasjon ved hjelp av Microsoft Intune og MDM-policyer

I et Intune-administrert miljø kan konfigurasjoner distribueres via sikkerhetsprofiler eller tilpassede policyer. Den typiske arbeidsflyten innebærer å opprette en kontobeskyttelsespolicy eller tilsvarende og angi parameterne for Aktiver VBS og definer konfigurasjonen av Credential Guard.

Når du bruker en CSP (konfigurasjonstjenesteleverandør) som DeviceGuard, inkluderer de relevante nøklene:

• Konfigurasjonsnavn: «Aktiver virtualiseringsbasert sikkerhet». OMA-URI: ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurityDatatype: heltall. Verdi: 1 å aktivere.
• Konfigurasjonsnavn: «Credential Guard-konfigurasjon». OMA-URI: ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlagsDatatype: heltall. Typiske verdier:
  • 1: aktivert med UEFI-lås.
  • 2: aktivert uten blokkering.

Når policyen er brukt på den ønskede gruppen av enheter eller brukere, er det nødvendig start datamaskinen på nytt slik at hypervisoren og VSM-miljøet initialiseres riktig og Credential Guard blir operativt.

Aktivering ved hjelp av gruppepolicy (GPO)

I Active Directory-baserte domener er den klassiske måten å konfigurere Credential Guard på via GruppepolicyredigererDen kan konfigureres både i redigeringsprogrammet for lokale policyer på hver datamaskin og i gruppepolicyobjekter som er koblet til OU-er eller hele domenet.

Standard konfigurasjonsstien er:

Enhetskonfigurasjon → Administrative maler → System → Enhetsbeskyttelse

Innenfor den banen må du redigere policyen «Aktiver virtualiseringsbasert sikkerhet» og sette statusen til AktivertI rullegardinmenyen «Innstillinger for Credential Guard» kan du velge mellom «Aktivert med UEFI-lås» eller «Aktivert uten lås», avhengig av ønsket begrensningsnivå. Etter policyoppdateringen og en omstart vil beskyttelsen være aktiv.

Avansert konfigurasjon via registeret

For spesifikke scenarier eller automatiseringer er det også mulig å konfigurere Credential Guard ved å manipulere direkte Windows-registeretDe mest relevante nøklene er:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
  nøkkel: EnableVirtualizationBasedSecurity (REG_DWORD). Verdi: 1 for å aktivere VBS.
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
  nøkkel: RequirePlatformSecurityFeatures (REG_DWORD). Typiske verdier:
  • 1 kun til bruk i sikker oppstart.
  • 3 å bruke sikker oppstart og DMA-beskyttelse.
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  nøkkel: LsaCfgFlags (REG_DWORD). Verdier:
  • 1Aktiver Credential Guard med UEFI-lås.
  • 2Aktiver Credential Guard uten å låse.

Etter at du har implementert disse endringene, må du start maskinen på nytt for at den nye konfigurasjonen skal tre i kraft og det beskyttede miljøet skal starte.

Slik sjekker du om Credential Guard faktisk kjører

En vanlig feil er å fokusere utelukkende på om prosessen LsaIso.exe Den vises i Oppgavebehandling, noe som tyder på at Credential Guard er aktiv. Microsoft anbefaler ikke denne metoden som en definitiv kontroll, da den kan gjenspeiler ikke nøyaktig den faktiske beskyttelsestilstanden.

I stedet finnes det tre mer pålitelige metoder for å sjekke statusen til Credential Guard:

• Verktøy Systeminformasjon (msinfo32.exe).
• Kommandoer av PowerShell.
• Gjennomgang av hendelser i Hendelsesvisning.

Med Systeminformasjon, bare kjør msinfo32.exeVelg «Systemsammendrag» og merk av i feltet «Kjører virtualiseringsbaserte sikkerhetstjenester». Hvis «Credential Guard» er oppført blant de aktive tjenestene, betyr det at Funksjonen fungerer faktisk..

Via PowerShell kan du kjøre kommandoen:

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

Den returnerte verdien vil indikere utførelsesstatusen:

• 0Credential Guard deaktivert (kjører ikke).
• 1Credential Guard aktivert og operativ.

I tillegg kan relaterte hendelser gjennomgås i hendelsesvisningen, filtrert etter Windows Logs\System på grunn av hendelsenes opprinnelse WinInitPeriodisk analyse av disse hendelsene, kombinert med WMI-spørringer eller sikkerhetsrevisjoner, bidrar til å bekrefte implementeringens tilstand og status på tvers av hele flåten.

Alternativer for å deaktivere Credential Guard

Selv om det ikke er ideelt fra et sikkerhetssynspunkt, er det noen ganger nødvendig Deaktiver Credential Guard på grunn av kompatibilitetsproblemer med kritiske applikasjoner eller eldre protokoller som ikke kan erstattes på kort sikt.

Fremgangsmåten for å deaktivere funksjonen varierer avhengig av hvordan den opprinnelig ble aktivert. Generelt sett bør du:

• Tilbakestill konfigurasjonen som ble brukt av Intune, GPO eller Registry, og returner VBS- og LsaCfgFlags-verdiene til deaktivert tilstand.
• Start enheten på nytt for å stoppe lasting av virtualiseringsbaserte sikkerhetskomponenter.

Hvis Credential Guard ble konfigurert med UEFI-låsTing blir litt mer komplisert fordi deler av tilstanden er lagret i EFI-variabler i fastvaren. I dette tilfellet er det, i tillegg til å angre konfigurasjonen i Windows, nødvendig å kjøre en rekke kommandoer med bcdedit fra en forhøyet ledetekst for å laste inn et spesielt konfigurasjonsverktøy (SecConfig.efi) under oppstart.

Flyten er vanligvis noe slikt:

• Monter en midlertidig EFI-partisjon ved hjelp av mountvol og kopier den SecConfig.efi.
• Opprett en systemladeroppføring med bcdedit /createpeker på SecConfig.efi.
• Konfigurer en midlertidig oppstartssekvens for å kjøre den oppføringen ved neste omstart og gi den alternativet DEAKTIVER-LSA-ISO.
• Start maskinen på nytt, og når meldingen før oppstart vises, Bekreft endringen i UEFI-konfigurasjonen slik at deaktiveringen vedvarer.

Uten denne bekreftelsen vil ikke fastvaren registrere endringen, og Credential Guard vil forbli låst på UEFI-nivå, selv om konfigurasjonen er endret i operativsystemet.

I virtuelle maskiner kan Hyper-V-verten deaktivere bruken av VBS og Credential Guard for en bestemt virtuell maskin ved hjelp av PowerShell-kommandoen. Set-VMSecurity med det tilhørende ekskluderingsalternativet.

I noen miljøer har det blitt observert at datamaskiner som brukte eksternt skrivebordsautentisering med SSO eller eldre metoder, begynner å vise meldinger etter visse Windows-oppdateringer. legitimasjonene er ikke lenger gyldigeI mange av disse tilfellene har den midlertidige løsningen som har blitt brukt vært å deaktivere Credential Guard fra den lokale gruppepolicyen (GPEDIT.msc), navigere til Datamaskinkonfigurasjon → Administrative maler → System → Enhetsbeskyttelse → «Slå på virtualiseringsbasert sikkerhet» og merke konfigurasjonsalternativet Credential Guard som «Deaktivert».

Credential Guard har etablert seg som en nøkkelkomponent i identitetsbeskyttelsesstrategier i Windows, spesielt i miljøer med omfattende Active Directory og svært sensitive privilegerte kontoer. VBS-, TPM- og minneisoleringDenne teknologien gjør livet mye vanskeligere for angripere som prøver å bevege seg sidelengs ved å stjele legitimasjon fra minnet til endepunkter og servere, forutsatt at den suppleres av god praksis, overvåkingsverktøy og rimelig administrasjon av eldre applikasjoner og protokoller.