Basisherding

Bakgrunn

Det er mulig å delegere rettigheter til objekter på OU nivå i Active Directory. Delegering kan også skje helt øverst på domenenavnet, på det som man kaller Root i Active Directory. Dersom man f.eks gir "Domain Users" rettigheten "Full Control" på Root, så har man gjort samtlige brukere i domenet til "Domain Admins", siden alle brukere da har rettighet til å endre passord på Domain Admins og tilgang til å legge seg selv og andre inn i gruppen "Domain Admins". Det er altså viktig å ha kontrol på rettighetene i AD.

Risiko hvis man ikke fikser: Høy

Angripere vil alltid utnytte rettigheter som gir dem Domain Admin, og de finner disse automatisk med verktøy.

Kan det ha negative konsekvenser å fikse: Muligens

Dersom rettighetene er gitt for å enkelt gi tilgang til en applikasjon, for å slippe å finne ut nøyaktig hvilke rettigheter applikasjonen trenger, så kan det å fjerne rettighetene føre til at applikasjonen ikke lengre virker.

Kompleksitet på endringen: Høy (ADUC)

Hvordan utføre endringen:
Rettigheter på OUer er komplisert å få oversikt over, men dessverre helt nødvendig. Det vil være unikt fra AD til AD hvilke rettigheter som må fjernes hvor, så dette er manuelt arbeid hvor man må sette seg inn i hver enkelt sak. Vi anbefaler å starte med å rette opp det som Ping Castle rapporterer direkte om, for så å kjøre Ping Castle på nytt for å fjerne sårbarhetene som blir rapportert, fram til alle er fikset.

Etter innføring av Tiermodellen vil normalt mange flere slike sårbarheter bli oppdaget og man må gjøre ytterligere runder med dette arbeidet.

Eksempel

Nedenfor følger et eksempel fra et testmiljø.

Først har vi åpnet ADUC og høyreklikket på Root (helse.lab) og valgt Properties. Velger så Advanced og ser at "Domain Users" er gitt "Full Control". Den siste pilen viser at rettigheten arves til "...all descendant..".

Dette gir altså alle brukere rettigheter til alle objekter, som direkte gir alle brukere Domain Admin i domenet, og dermed har kortsluttet all sikkerhet i AD.

Reset AdminCount

Bakgrunn

Når en konto blir Domain Admin så blir attributtet AdminCount satt til 1. Dette for å vise at denne kontoen har, eller har hatt, Domain Admin. Attributtet må resettes manuelt dersom kontoen ikke lengre er Domain Admin.

Risiko hvis man ikke fikser: Middels

Angripere kan ikke utnytte AdminCount attributtet direkte, men de tar ut en liste over alle kontoer som har AdminCount=1. Dette vet de er kontoer som enten har Domain Admin tilgang, eller har hatt det tidligere. Dersom en konto ikke lengre er Domain Admin, så kan det være at brukeren f.eks er tatt ut av Protected Users og andre spesielle sikringer som gjelder for Domain Admins. Hvis kontoen fortsatt har andre privileges enn Domain Admin så vil kontoen være et angreps mål.

Kan det ha negative konsekvense å fikse: Usannsynlig

Dersom en konto ikke lenger skal være Domain Admin skal den heller ikke trenge dette attributtet lenger.

Kompleksitet på endringen: Lav (Powershell, ADUC)

Teknisk beskrivelse
For å få ut alle objekter

Get-ADObject -LDAPFilter "(adminCount=1)"

Gå igjennom alle kontoer i listen og sett AdminCount til 0 for de vanlige Administratorer som ikke lengre skal være Domain Admins:

Åpne ADUC og Properties for den relevante kontoen, velg Attribute Editor og Edit på adminCount. Velg Clear.

NB: Dersom tabben for "Attribute Editor" ikke vises, velg View > Advanced Features

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/reducing-the-active-directory-attack-surface#protected-accounts-and-groups-in-active-directory

Internet artikkel: https://blog.netwrix.com/2022/09/30/admincount_attribute/

Disable Delegation for alle Admin Accounts

Bakgrunn

Kerberos delegation tillater en service å benytte en bruker til å få tilganger på vegne av brukeren. Det er en nyttig funksjon for tjenester, men skal aldri være mulig for administratorkontoer. Protected Users-gruppen vil også sikre denne innstillingen, men det er uansett anbefalt å også sette den på hvert enkelt objekt.

Risiko hvis man ikke fikser: Middels

Dersom en angriper har fått kontrol på en service, og en administrator så authentisere til denne servicen, så kan angriperen benytte denne kontoen til å kontakte andre servere og tjenester på vegne av administratorkontoen. Angriper kan altså operere som angriper har fått full kontrol på administratorkontoen, uten at angriper har kontrol på den, siden angriper kan operere på vegne av administratoren.

Kan det ha negative konseksvenser å fikse: Usannsynlig

Kompleksitet på endringen: Lav (ADUC)

Hvordan utføre endringen:
Start ADUC (Active Directory Users and Computers) og åpne en og en admin konto. For hver av dem:
Velg Accounts og sett på krysset for: Account is sensitive and cannot be delegated

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/ensure-privileged-accounts-with-sensitive-flag

Reset password on AzureADSSOACC

Bakgrunn

Kontoen AZUREADSSOACC gir SSO (Single Sign On) med Azure AD.

Passordet på AZUREADSSOACC bør skiftes regelmessig.

Risiko hvis man ikke fikser: Lav

Angripere vil alltid prøve å knekke passordet på AZUREADSSOACC, da det gir dem Domain Admin relativt raskt.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Dette er bare et passordbytte på en spesiell servicekonto, så det skal ikke påvirke brukerne på noen måte.

Kompleksitet på endringen: Lav (Powershell)

Hvordan utføre endringen:

NB: Prosedyren nedenfor forutsetter 1 Forest med 1 Domain. For andre konfigurasjoner se artikkel nedenfor.

Åpne Powershell og kjør kommandoene:

cd $env:programfiles"\Microsoft Azure Active Directory Connect"

Import-Module .\AzureADSSO.psd1

$creds = Get-Credential
NB: Brukernavnet må være en Domain Admin og må skrives inn på formen: contoso\johndoe

Update-AzureADSSOForest -OnPremCredentials $creds

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/change-password-microsoft-entra-seamless-single-sign-on#why-might-the-microsoft-entra-seamless-sso-computer-account-old-password-be-a-risk
Microsoft Change AzureADSSOAcc passord: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso-faq#how-can-i-roll-over-the-kerberos-decryption-key-of-the--azureadsso--computer-account-

Reset krbtgt password

Bakgrunn

Passordet på kontoen krbtgt (Kerberos Ticket Granting Ticket) benyttes som secret for å signere alle Kerberos tickets.

Risiko hvis man ikke fikser: Høy

Angripere forsøker alltid å få tak i passordet på denne kontoen. Med dette passordet får de tilgang til hele domenet og det er veldig komplisert å oppdage et slikt angrep.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Kompleksitet på endringen: Middels (ADUC)

Hvordan utføre endringen:

VIKTIG: Passordet må skiftes to ganger, og det MÅ være minst 10 timer og bør helst være 1 uke mellom passordbyttene. Årsaken til denne kritiske ventetiden er at Kerberos ticket etter det første passordbyttet må ha løpt ut før det neste passordbyttet skjer, ellers kan DCer miste tilgang til domenet!

Verifiser at alle DCer replikerer korrekt før passordet byttes. Åpne Command Prompt og kjør følgende to kommandoer:

repadmin /showrepl

-Repadmin skal gi svar "Last attempt .... was successful" for alle.

dcdiag /e /test:connectivity

-DcDiag skal gi "servername passed test Connectivity" for alle.

Åpne ADUC > domene > Users > krbtgt
Høyreklikk og velg Reset Password

Fjern krysset for "User must change password at next logon"

Det er ikke viktig hvilket passord man setter, så lenge det er godkjent av passordpolicy.
ADUC vil automatisk erstatte passordet man skriver inn med en lang random string.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/change-password-krbtgt-account

Microsot Doc: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-reset-the-krbtgt-password

Fjern passord i Group Policy Preferences

Bakgrunn

Group Policy Preferences (GPP) utvider Group Policy med flere opsjoner.
GPP kom med Windows 2008, og gjorde det mulig å lagre passord i Group Policy med AES 32-kryptering. Det er for kort med kun 32 bits AES-kryptering, og Microsoft publiserte også AES krypteringsnøkkelen for GPP i 2012, slik at hackere etter det lett kan dekrypterere alle passord i GPP.

Microsoft kom med en patch til GPP i 2014 (MS14-025), men patchen hindrer deg kun i legge inn nye passord i GPOer, den fjerner ikke passordene som allerede er lagt inn. Man må derfor manuelt fjerne alle passord fra GPOene.

Risiko hvis man ikke fikser: Høy

Angripere henter raskt ut alle passord i GPOer og får direkte tilgang til å logge inn som disse brukerne. De vil også prøve GPO passordene på alle andre brukere for å sjekke om passordene er gjenbrukt.

Kan det ha negative konsekvenser å fikse: Muligens

Dersom bruker/passordet benyttes aktivt må man finne andre måter å få utført denne funksjonen på først, ellers vil brukerne bli påvirket. Normalt er ikke bruker/passordet i bruk lengre og kan bare slettes.

Kompleksitet på endringen: Middels (CMD,Powershell,GPMC, PingCastle)
Man må først ta ut de aktuelle GUID fra kommandolinje, finne navnet på GPOene med powershell, og deretter endre dem i GPMC

Hvordan utføre endringen:

For å finne passord i GPP kjører man følgende kommando i et CMD vindu:

findstr /S /I cpassword \\<FQDN>\sysvol\<FQDN>\policies\*.xml

Kommandoen vil ikke liste ut passordene, men vil vise om man har noen policies med passord.

Kommandoen vil finne GUID for policyen som inneholder password. Man kan bruke Get-GPO med GUID som input for å få ut navnet på GPOen.
PingCastle viser en oversikt over kontoene som har passord lagret i hvilke GPOer og hvilket passord som er satt.

Fjerning av passordet:
Åpne Group Policy Management Console (GPMC)

Editer den aktuelle GPOen og åpne Computer > Preferences eller User > Preferences
Let deg fram til hvor brukernavn/passordet er satt.

Her kan man slette hele settingen, disable den eller gå inn i settingen og slette selve brukernavnet/passordet.

Hva man velger å gjøre avhenger om dette er i bruk eller hvordan det benyttes.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-preferences

Microsoft GPP Patch: https://support.microsoft.com/nb-no/topic/ms14-025-sikkerhetsproblem-i-gruppepolicyinnstillingene-kan-tillate-heving-av-tilgangsniv%C3%A5-13-mai-2014-60734e15-af79-26ca-ea53-8cd617073c30

Internet artikkel 1: https://adsecurity.org/?p=384
Internet artikkel 2: https://adsecurity.org/?p=2288

Internet artikkel 3: https://thalpius.com/2025/01/26/microsoft-defender-for-identity-recommended-actions-reversible-passwords-found-in-gpos/

Disable Inactive Computers

Bakgrunn

Inactive computere er PCer eller servere som ikke har tatt kontakt med en DC på mer enn 180 dager. Et domene vil automatisk sperre ute computere/servere som ikke har kontaktet domenet på 180 (default verdi) dager, og slike vil måtte kontakte IT drift for å få hjelp til å fungere igjen. Inactive computer/servere bør derfor disables.

Risiko hvis man ikke fikser: Middels

Angripere utnytter inaktive PCer/servere som bakdører for å få tilgang til systemer.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Utstyr som ikke har vært brukt på 180 dager vil uansett ikke fungere lengre, så ingen brukere burde få ekstra problemer av at objektet disables.

Kompleksitet på endringen: Lav (Powershell, ADUC)

Hvordan utføre endringen:
Powershell kommando som viser de som er eldre enn 180 dager, med de eldste først:

Search-ADAccount –AccountInActive –ComputersOnly –TimeSpan 180:00:00:00 –ResultPageSize 2000 –ResultSetSize $null | ?{$_.Enabled –eq $True} | Sort LastLogonDate | Select-Object Name, SamAccountName, DistinguishedName, LastLogonDate

Åpne ADUC og disable alle objektene dere mener kan disables. Husk å starte med noen få av de som har vært inaktiv lengst og så øke på.

Disable Inactive Admins

Bakgrunn

Inactive admins er administratorer som ikke har logget inn på mer enn 180 dager.
Det er spesielt ille med brukere som aldri har logget på, da disse ikke har satt MFA ennå.

Risiko hvis man ikke fikser: Middels

Angripere utnytter inaktive admins som bakdører for å få tilgang til systemer. Dette gjelder spesielt admins som aldri har logget inn, siden disse ikke har aktivert MFA ennå. Hvis angriper får aktivert MFA på vanlig måte vil det være veldig vanskelig å oppdage at kontoen er overtatt av en angriper.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Dersom admins som ikke har vært pålogget på lenge kommer tilbake, så vil kontoen være disablet og de må få en annen admin til å enable kontoen.

Kompleksitet på endringen: Lav (Powershell, ADUC)

Hvordan utføre endringen:
Powershell kommando som viser alle kontoer som er eldre enn 180 dager, med de eldste først:

Search-ADAccount –AccountInActive –UsersOnly –TimeSpan 180:00:00:00 –ResultPageSize 2000 –ResultSetSize $null | ?{$_.Enabled –eq $True} | Sort LastLogonDate | Select-Object Name, SamAccountName, DistinguishedName, LastLogonDate

Gå igjennom listen over alle inaktive bruker og lag en ny liste med kun Administrator kontoer.

Åpne ADUC og disable alle administrator kontoer som ikke er i bruk.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/services-hub/unified/health/remediation-steps-ad/regularly-check-for-and-remove-inactive-user-accounts-in-active-directory

Disable LLMNR protokollen

Bakgrunn

LLMNR erstattet i 2007 NetBios og er en failovermetode for navneoppslag når DNS ikke virker. I dagens IT miljøer må alltid DNS virke, så det er ikke noe behov for failover for DNS. LLMNR er Legacy fra 2022.

Risiko hvis man ikke fikser: Høy

Angripere kan utnytte LLMNR med grunnleggende gratis-verktøy

Kan det ha negative konsekvenser å fikse: Usannsynlig

Dersom dere har noe som benytter kun LLMNR vil det slutte å virke når LLMNR Disables. Siden LLMNR er så gammelt vurderer vi det som usannsynlig. Det er dessverre ingen enkel måte å proaktivt finne ut om noe vil slutte å virke. Dersom dere ønsker å lytte på nettet for å forsøke å finne ut av om LLMNR er I bruk så har vi inkludert en link til informasjon om hvordan benytte Wireshark for dette.

Kompleksitet på endringen: Lav (GPO)

Hvordan utføre endringen:
Anbefaler å benytte GPO som er opprettet for herding, og å benytte Pilot GPO på økende mengder av klienter først og så samme på servere før DCene tas til slutt.
Settes for Klienter, Servere og DC.

Naviger til : Computer Configuration\Policies\Admin Templates\Network\DNS Client
Sett "Turn Off Multicast name Resolution" = Enabled

For å verifisere at innstillingen er satt, kjør gpupdate og deretter følgende kommando:
reg query "HKLM\Software\Policies\Microsoft\Windows NT\DNSClient" | findstr "EnableMulticast"

NB: Denne GPO innstillingen tatoveres, så dersom dere endrer ""Turn Off Multicast name Resolution" til "Not Configured" så vil det som sist ble satt fortsatt ligge inne som aktiv verdi.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-llmnrp/6806998e-034d-4c39-8398-5af8bfd52d7e

Internet artikkel: https://woshub.com/how-to-disable-netbios-over-tcpip-and-llmnr-using-gpo/

Wireshark: https://en.wikiversity.org/wiki/Wireshark/LLMNR

Disable LM og NLTMv1

Bakgrunn

LM, NTLM og NTLMv2 er autentiseringsprotokoller som brukes når Kerberos-autentisering ikke er tilgjengelig.

LM kom i 1987, NTLM kom i 1993, NTLMv2 kom i 1998. LM og NTLM har altså vært legacy i over 25 år.

Risiko hvis man ikke fikser: Høy

Angripere kan utnytte LM og NTLMv1 med grunnleggende gratis-verktøy

Kan det ha negative konsekvenser å fikse: Muligens

Dersom dere har utstyr eller tjenester som er avhengig av NTLMv1 vil dette slutte å virke når man skrur av NTLMv1. Typiske eksempler er printere/scannere og veldig gamle Windows-servere som må omkonfigureres til å være kompatible med bedre autentisering. For å kjøre innføringen mer kontrollert bør man aktivere GPOen for klienter/servere i batcher først, og starte med å sette dem på nivå 3 (Se internet artikkel nedenfor). Når alle klienter har kjørt på nivå 3 en stund setter man DCene på nivå 3. Til slutt setter man så DCene på nivå 5.

NB: Denne settingen tatoveres i Windows, så man kan ikke slette GPOen for å fjerne settingen på klienter/servere. Dersom noe feiler må man manuelt slette innstillingen fra klienter/servere.

Kompleksitet på endringen: Middels (Tatovert GPO)

Hvordan utføre endringen:
Anbefaler å benytte GPO som er opprettet for herding, og å benytte Pilot GPO på økende mengder av klienter først og så samme på servere før DCene tas til slutt.
Settes for Klienter, Servere og DC.

Naviger til : Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options
Sett "Network security: LAN Manager authentication level" = "Send NTLMv2 response only. Refuse LM & NTLM"

For å verifisere at innstillingen er satt, kjør gpupdate og deretter følgende kommando:
reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa" | findstr "lmcompatibilitylevel"

Verdien skal være 0x5.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/windows/win32/secauthn/microsoft-ntlm

NTLM beskrivelse: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-1-%E2%80%93-disabling-ntlmv1/3934787

Disable NetBios protokollen

Bakgrunn

NetBios gjør hovedsakelig navneoppslag, slik som DNS gjør idag.

NetBios kom i 1983 og ble vanlig fra 1987 med NBT (Netbios over TCP/IP). Den er dessverre usikker By Design, og ble legacy fra Windows 2000, da DNS tok over alt av navneoppslag.

Risiko hvis man ikke fikser: Høy

Angripere kan utnytte NetBios med grunnleggende gratis-verktøy.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Dersom dere har noe som benytter kun NetBios vil det slutte å virke når NetBios Disables. Siden NetBios er så gammelt vurderer vi det som usannsynlig. Det er dessverre ingen enkel måte å proaktivt finne ut om noe vil slutte å virke. Dersom dere ønsker å lytte på nettet for å forsøke å finne ut av dette så har vi inkludert en link til Wireshark.

Kompleksitet på endringen: Lav (GPO)

Hvordan utføre endringen:
Anbefaler å benytte GPO som er opprettet for herding, og å benytte Pilot GPO på økende mengder av klienter først og så samme på servere før DCene tas til slutt.
Settes for Klienter, Servere og DC.

Naviger til:
Computer Configuration\Policies\Windows Settings\Scripts\Startup

Gå til "Powershell Scripts"-fanen, og velg "Show Files".

Opprett filen DisableNETBIOS.ps1 med følgende innhold:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\netbt\Parameters\interfaces\tcpip_*' -name NetBiosOptions -value 2 –Verbose

Velg: Add > ScriptName: DisableNETBIOS.ps1
Script Parameters: [la denne være blank]

Det kreves restart før settingen kommer inn.

For å sjekke at herdingen er ok, kjør følgende kommando:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\netbt\Parameters\interfaces\tcpip_*' | findstr "NetbiosOptions"

For alle linjer skal NetbiosOptions = 2

Artikler

Microsoft dokumentasjon: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/1430ebe9-2ad0-4763-b14f-c720338e0482

Internettartikkel: https://woshub.com/how-to-disable-netbios-over-tcpip-and-llmnr-using-gpo/

Wireshark: https://medium.com/@4ghora/wireshark-traffic-analysis-d934fde9a6d2

Disable Password not required

Bakgrunn

Det er mulig å tillate kontoer å ha tomt passord med å sette PasswordNotRequired på objektet.

Risiko hvis man ikke fikser: Middles

Passordpolicy overstyrer innstillingen på objektet når passord byttes, så normalt er det ikke kritisk å fikse denne feilen. Det er imidlertid anbefalte å rette opp i feilen, da den både påvirker sikkerhetsovervåkning og også gir mulighet for framtidige feil som kan utnyttes av en angriper. Dersom man en gang tidligere hadde en passordpolicy og noen brukere den gang satte tomt passord på kontoen sin, så kan de fortsatt ha tomt passord selv om passordpolicyen nå ikke tillater det.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Brukere må uansett oppfylle sikkerhetskravene i passordpolicyen, så de skal ikke merke noe. Endringen vil også bare være aktiv ved neste passordbyttet.

Kompleksitet på endringen: Lav (Powershell)

Hvordan utføre endringen:
Kjør følgende powershell-kommando for å finne alle kontoer som tillater tomme passord:

Get-ADUser -Filter {PasswordNotRequired -eq $true} | ft name, UserPrincipalName

Disable muligheten for blankt passord ved neste passordbytte ved å kjøre følgende kommando for hver av brukerne over:

Set-ADUser -Identity [user] -PasswordNotRequired $false

NB: Dersom dere har Trust satt opp vil det komme opp en konto for hvert Trust som har navn på trustet og så slutter på $: trustnavn$
Ikke endre noe på disse spesielle Trust kontoene.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/useraccountcontrol-manipulate-account-properties

Internet artikkel: https://blog.icewolf.ch/archive/2022/01/06/understand-and-remove-passwd_notreqd-flag-from-useraccountcontrol/

Remove Service accounts from Domain Admin

Bakgrunn

Kontoer som er satt til "Password never expires" er normalt service kontoer. Det bør ikke ligge service kontoer i Domain Admins gruppen.

NB: Dersom man har satt en sikker passordpolicy og byttet alle passord og deretter endret alle brukere til å aldri mere bytte passord i henhold til de nye passordanbefalingene, så kan man se bort fra hele dette punktet.

Risiko hvis man ikke fikser: Lav

Angripere som ser service kontoer i Domain Admins vil forsøke å finne ut hvor disse servicekontoene er benyttet og så angripe servicen der de kjører. Hvis de klarer å komme inn på server eller applikasjonen hvor servicekonto er benyttet så har de fått Domain Admin tilgang.

Kan det ha negative konsekvenser å fikse: Muligens

Service kontoer skal normalt aldri trenge Domain Admin, men kun ha den tilgangen som er nødvendig for tjenesten. Imidlertid er det dessverre normalt å gi servicekontoer Domain Admin tilgang, for det er raskere å bare gi tilgang til alt enn å gi den tilgangen som faktisk er nødvendig. Dersom man har en servicekonto som i dag har Domain Admin fordi den krever visse tilganger, vil den slutte å funke om man fjerner Domain Admin.

Kompleksitet på endringen: Lav (ADUC)

Hvordan utføre endringen:
NB: Dersom man har satt en sikker passordpolicy og byttet alle passord og deretter endret alle brukere til å aldri mere bytte passord, så kan man se bort fra hele dette punktet.

Dersom man har grupper i Domain Admins eller Administrators vil kommandoene nedenfor feile på gruppene, så de må da sjekkes manuelt.

Kjør powershell kommando for liste over service kontoer i Domain Admins:

Get-ADGroupMember -Identity "Domain admins" | Get-ADUser -Properties PasswordNeverExpires, LastLogonDate | Sort -Descending -Property PasswordNeverExpires | Select-Object Name, SAMAccountname, LastLogonDate, Enabled, PasswordNeverExpires | ft -autosize

Kjør powershell kommando for liste over service kontoer i Administrators:

Get-ADGroupMember -Identity "Administrators" | Get-ADUser -Properties PasswordNeverExpires, LastLogonDate | Sort -Descending -Property PasswordNeverExpires | Select-Object Name, SAMAccountname, LastLogonDate, Enabled, PasswordNeverExpires | ft -autosize

Gå igjennom Domain Admins/Administrators gruppen og finn ut hvilke kontoer som er satt til "Password never expires".
Dersom kontoene er servicekontoer, gi kontoene korrekt tilgang og ta dem deretter ut av Domain Admins.
Hvis de må ligge Domain Admins/Administrators: sett opp en prosedyre for å passordbytte og fjern krysset for "Password never expires".

Artikler

Internet artikkel: https://idefixwiki.no/find-domain-admins-with-password-never-expires/

Enforce riktig Primary group

Bakgrunn

Active Directory har en attributt som heter "primarygroupid". Verdien på denne skal være "Domain Users" (513) for alle brukere, "Domain Computers" (515) for alle computere og "Domain Controllers" (516) for alle domenekontrollere.

Risiko hvis man ikke fikser: Lav

Angripere endrer ofte Primary group for å unngå å bli oppdaget. Dersom man har objekter med feil Primary group fra før, så vil ikke deteksjonsverktøy fungere optimalt.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Det er ingen kjente konsekvenser med å sette riktig Primary group.

Kompleksitet på endringen: Lav (ADUC)

Hvordan utføre endringen:
Kjør følgende to Powershell kommandoer for å liste ut alle objekter med feil Primary group:

$DomainUsersSid = New-Object System.Security.Principal.SecurityIdentifier ([System.Security.Principal.WellKnownSidType]::AccountDomainUsersSid,(Get-ADDomain).DomainSID)

Get-ADUser -Filter * -Properties PrimaryGroup | Where-Object { $_.PrimaryGroup -ne (Get-ADGroup -Filter {SID -eq $DomainUsersSid} ).DistinguishedName } | Select-Object UserPrincipalName,PrimaryGroup

Merk at kommandoen vil liste ut Guest kontoen, som har Primary Group satt til "Domain Guests". Dette er riktig, og er det eneste som vil dukke opp dersom alle primary groups er satt riktig i domenet.

Åpne hvert objekt med feil Primary Group i ADUC (Active Directory Users and Computers) og endre atributtet primarygroup til riktig verdi.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/accounts-with-non-default-pgid

Mitigate ADCS ESC1

Bakgrunn

Normale brukerkontoer kan be om et sertifikat for en Domain Admin, og dermed enkelt bli Domain Admin.

SpecterOps rapporterte ESC1-8 i 2021 og beskriver også løsninger.
ESC1 består av en rekke feilkonfigureringer som til sammen gjør at en normal User kan bli Domain Admin.

Risiko hvis man ikke fikser: Høy

Angriper kan få tak i sertifikat til Domain Administrator med grunnleggende gratisverktøy.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Man må vurdere hva hver enkelt Certificate mal benyttes til før man endrer, så man er sikker på at fiksene ikke bryter med funksjonen.

Vanligvis skal det ikke være noe problem å fikse feilene. Internet artikkelen nedenfor beskriver også hvordan man kan sjekke om noen forsøker å utnytte ESC1 svakheten.

Liste over konfigurasjoner som må endres:
Bytte Subject Name fra "Supply in the request" til "Build from this Active Directory information"
Fjerne Enrollment Rights fra Domain Users, og gi dem Read Only

Microsoft anbefaler også å aktivere "Issuance Requirements > CA certificate manager approval". Dette gir veldig stor trygghet, men det gjør at alle sertifikatforespørsler må godkjennes manuelt i Certificate Authority verktøyet under "Pending Requests". Dersom man har kapasitet til dette så er det sikkerhetsmessig anbefalt, men hvis man fikser de to andre svakhetene vil man ha utbedret ESC1 trusselen.

Kompleksitet på endringen: Lav (ADSC innstilling)

Hvordan utføre endringen:
Åpne Certificate Authority > Høyre-klikk Certificate Templates og velg Manage

For alle Templates, verifiser at Properties > Subject Name er satt til "Build from this Active Directory information"

For alle Templates, verifiser at Properties > Security > Domain Users kun har Read og ikke har Enroll. Legg til evt grupper som trenger Enroll.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/security-assessment-prevent-users-request-certificate

Internet artikkel: https://www.beyondtrust.com/blog/entry/esc1-attacks

ESC originale beskrivelser: https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf

Slett delegations til SID

Bakgrunn

Hvis man setter opp Delegation (Constrained eller unconstrained) til en konto som senere slettes, så vil delegeringen fortsatt eksistere etter slettingen, og delegeringen vil vises som en SID. Angripere kan utnytte dette. Se også artikkelen vår om "Unconstrained Delegation".

Delegering til andre domener vil også vises som en SID, men man bør ikke delegere på tvers av domener, så slike delegeringer bør også slettes.

Risiko hvis man ikke fikser: Lav

Angripere kan utnytte delegering til slettede objekter til å få flere tilganger.

Kan det ha negative konsekvenser å fikse: Usannsynlig
Kontoen det var delegert til er allerede slettet, så det vil ikke gi noen konsekvenser å slette selve delegeringen.

Kompleksitet på endringen: Lav (Powershell, ADUC)

Hvordan utføre endringen:
Powershell kommando for å se alle kontoer som har delegation:

Get-ADComputer -Filter {(TrustedForDelegation -eq $True) -AND (PrimaryGroupID -eq 515)} -Properties TrustedForDelegation,TrustedToAuthForDelegation,servicePrincipalName,Description

For å verifisere at alle tilhører det relevante domenet:

Get-ADDomain | select DomainSID

De tre bolkene etter "S-1-5-21-" utgjør SID til Domenet. Alle objekter i samme domene vil ha de samme tallene i disse tre bolkene. Så kommer en fjerde bolk som er unik for hvert enkelt objekt.

Dersom man finner delegeringer til andre domener bør man ta en nøye vurdering om slik delegering er nødvendig, for normalt skal man aldri ha slike.

Slett alle delegeringer til SID:

Start ADUC (Active Directory Users and Computers) og åpne de relevante kontoene. For hver av dem:
Velg Delegations og endre til: Do not trust this account for delegation

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/security-assessment-unconstrained-kerberos

Internet artikkel: https://www.sentinelone.com/blog/detecting-unconstrained-delegation-exposures-in-ad-environment/

Microsoft info: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers

Disable Kerberos DES

Bakgrunn

Kerberos DES er en krypteringsmetode for passord/tickets, som i dag lett kan dekrypteres og må dermed ikke benyttes. Keberos Armoring disabler DES på alle enheter, men det er viktig å også disable DES på selve brukerobjektene.

DES-kryptering ble legacy i 2008.

Risiko hvis man ikke fikser: Høy

Angripere dekrypterer DES tickets raskt.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Kerberos AES kom allerede i 2008, så det er usannsynlig at noe fortsatt krever DES. Vi har imidlertid opplevd i noen få tilfeller at spesielle servicekontoer har gitt applikasjonstrøbbel for eldre applikasjoner etter endringen, så det er viktig å fange opp feilmeldinger i etterkant av denne endringen. Isåfall er det bare sette innstillingen tilbake til opprinnelig verdi.

Kompleksitet på endringen: Lav (ADUC)

Hvordan utføre endringen:
Kjør følgende Powershell kommando for å liste ut alle objekter som benytter DES kryptering:
Get-ADObject -Filter {UserAccountControl -band 0x200000 -or msDs-supportedEncryptionTypes -band 3}

Åpne de relevante objektene i ADUC, åpne Attribute Editor. Noter verdien til attributten msDS-SupportedEncryptionTypes og endre den så til verdi 24

Alternativt åpne objektene i ADUC, åpne tab Account, se under Account Options og kryss av for:

This account support Keberos AES 128bit encryptions
This account support Keberos AES 256bit encryptions

Fjern krysset for: Use only DES encryption types for this account

Artikler

Microsoft Doc: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/decrypting-the-selection-of-supported-kerberos-encryption-types/1628797

Enable Secure DNS Zones

Bakgrunn

Domain Name System (DNS) er tjenesten som konverterer mellom IP nummer og navn.

Det er veldig tungvint å oppdatere IP nummer og navn manuelt, så i 1997 kom DNS med Dynamic Updates (DDNS) og i 2000 kom DDNS med Secure Update.

Risiko hvis man ikke fikser: Høy

Angripere kan opprette og endre DNS registereringer uten å logge inn på domenet.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Brukere oppdaterer normalt aldri DNS registreringer manuelt. Automatiske oppdateringer gjøres enten av DHCP serveren eller av PCen og begge disse er Secure. Det er mulig at Linux servere ikke lengre får oppdatert DNS, og konfigurasjon på dem må da endres.

Kompleksitet på endringen: Lav (Powershell, DNS Manager)

Hvordan utføre endringen:
Kjør følgende powershell kommando for å liste ut alle utrygge soner:

Get-DnsServerZone | where{$_.DynamicUpdate -ne "Secure" -AND $_.IsAutoCreated -eq $False -AND $_.ZoneName -ne "TrustAnchors"} | select ZoneName, DynamicUpdate, IsReverseLookupZone

For alle med IsReverseLookupZone=False

Åpne DNS Manager > DCName > Forward Lookup Zones >
For hver av Zonene som rapporteres, åpne Properties for sonen og sett "Dynamic Updates"= Secure only

For alle med IsReverseLookupZone=True

Åpne DNS Manager > DCName > Reverse Lookup Zones >
For hver av Zonene som rapporteres, åpne Properties for sonen og sett "Dynamic Updates"= Secure only

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/windows-server/networking/dns/dynamic-update

Internet artikkel: https://eitca.org/cybersecurity/eitc-is-wsa-windows-server-administration/configuring-dhcp-and-dns-zones-in-windows-server/creating-a-dns-zone/examination-review-creating-a-dns-zone/why-is-it-recommended-to-select-secure-dynamic-updates-when-configuring-a-dns-zone-and-what-are-the-risks-associated-with-non-secure-updates/

Enable password change

Bakgrunn

Alle Computer objekter bytter automatisk passord hver 30 dag. Det er mulig å disable passordbyttet, men det bør man ikke gjøre, da det er en sikkerhetsrisiko. Angripere disabler ofte passordbyttet så snart de får kontroll på en PC, så derfor vil mange sikkerhetsverktøy gi alarm om angrep dersom passordbyttet er disablet.

Risiko hvis man ikke fikser: Lav

Angripere disabler ofte dette passordbyttet, så derfor bør man ikke ha Computer objekter uten automatisk passordbytte.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Såfremt man ikke har en helt spesiell årsak til å slå av passordbyttet, så skal ikke dette gi noen konsekvens for brukerne.

Kompleksitet på endringen: Lav

Hvordan utføre endringen:
Start registry editor (regedit.exe) og endre følgende på objektet Ping Castle rapporterer:

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange = 0 (OK om Value mangler)

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\MaximumPasswordAge = 30 (Decimal)

Artikler

Microsoft Doc: https://support.microsoft.com/en-us/help/154501/how-to-disable-automatic-machine-account-password-changes

Tøm Enterprise og Schema Admins

Bakgrunn

Enterprise Admins gruppen gir tilgang til alle domener i skogen og Schema Admins gruppen gir tilgang til selve AD skjema som bygger opp domenene. Begge disse gruppene bør som regel være tomme, og brukere kun legges inn når de skal utføre oppgaver som krever rollene.

Risiko hvis man ikke fikser: Lav

Det er ingen direkte risiko med å ha kontoer som allerede ligger i Domain Admins i disse gruppene i tillegg, men det er anbefalt å beholde disse gruppene tomme for å minske angrepsflaten. Når gruppene er tomme bør man sette opp alarm dersom noen blir medlem av dem, slik at man får alarm om en angriper legger seg inn.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Dette har ingen konsekvens for sluttbruker, kun for administratorer.

Kompleksitet på endringen: Lav (ADUC)

Hvordan utføre endringen:
Åpne Active Directory Users and Computer (ADUC) og tøm gruppene Enterprise Admins og Schema Admins.

Artikler

Microsoft Doc Schema: https://learn.microsoft.com/en-us/services-hub/unified/health/remediation-steps-ad/review-and-reduce-the-number-of-accounts-in-highly-privileged-administrative-groups

Microsoft Doc Enterprise: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-e--securing-enterprise-admins-groups-in-active-directory

Disable Print Spooler service

Bakgrunn

Det har dessverre vært mange sikkerhetsproblemer med Print tjenesten, og spesielt når den kjører på DCer.

For at print tjenesten skal fungere, så må alle Authenticated Users kunne kople seg til den og be om en oppdatering og angripere kan be om at oppdateringen skjer med Unconstrained Delegation. Siden print servicen er eid av System, så betyr det at System blir eksponert ut til angriper. For å unngå alle sikkerhetsproblemer med Print tjenesten, så bør den alltid være disablet på DCer.

Risiko hvis man ikke fikser: Lav

Selv om det akkurat nå ikke er noen kjente sikkerhets hull i Print Spooler service, så vil angripere teste om de kan om de kan komme inn via Print Spooler. Hvis man f.eks ikke har patchet, så vil de kunne komme inn via tidligere sikkerhetsfeil. Derfor anbefales det å disable servicen.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Ingen skal printe igjennom printservicen på DCen.

Kompleksitet på endringen: Lav (services.msc)
Disable Print Spooler Service i service manager.

Hvordan utføre endringen:
Print Spooler service kan enkelt stoppes på hver enkelt DC slik: Åpne Services og åpne "Print Spooler" og sett Startup Type = Disabled

Anbefaler å benytte GPO som er opprettet for herding, da denne også vil gjelde for nye DCer framover. Settes kun for DCer.

Naviger til : Computer Configuration\Policies\Windows Settings\Security Settings\System Services\Print Spooler

Huk av "Define this policy setting", og sett "Select service startup mode" til Disabled.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/security-assessment-print-spooler

Internet artikkel: https://www.alitajran.com/disable-print-spooler-domain-controller/

Enable Auditing

Bakgrunn

Auditing er en vanskelig balansegang mellom for mye og for lite data. Microsoft sin artikkel nedenfor anbefaler å slå på en lang rekke logger. Det er bra å få slått på alle loggene som anbefales, men det kan gi uventede mengde med data i noen miljøer. Vi anbefaler derfor at man ihvertfall slår på de loggene som vi har listet nedenfor.

Vi har en mere omfattende anbefaling rundt logging på våre nettsider, men her fokuserer vi på det aller viktigste.

Risiko hvis man ikke fikser: Lav

Manglende logging gir ikke angripere noen tilganger, men det gjør det vanskelig å oppdage angrep.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Dette er kun logging, så det skal ikke ha noe innvirkning på noe annet. Dersom en domenekontroller har helt full disk og sliter ytelsesmessig kan det å skru på auditing potensielt skape flere problemer, men dette skal ikke være normalt.

Kompleksitet på endringen: Lav (GPMC)

Hvordan utføre endringen:
Anbefaler å benytte GPO som er opprettet for herding, og å benytte Pilot GPO på økende mengder av klienter først og så samme på servere før DCene tas til slutt.
Settes for DCer.

Naviger til : Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuratio\Audit Policies
Sett:
Detailed Tracking > Audit DPAPI Activity = Success
Account Logon > Audit Kerberos Service Ticket Operations = Success
Privilege Use > Audit Sensitive Privilege Use = Success

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations?tabs=winserver

Internet artikkel: https://adsecurity.org/?p=3377

Disable at brukere kan joine PCer til domenet

Bakgrunn

Med Windows 2000 fikk alle brukere tillatelse til å opprette 10 PCer i domenet. Tilgang til å opprette Computer objekter i et domene bør begrenses til administratorer eller kjente grupper med brukere.

Risiko hvis man ikke fikser: Middels

Default tilgangen til å opprette 10 computer objects åpner opp for flere kjente angrepsteknikker og tilgangen bør derfor fjernes

Kan det ha negative konsekvenser å fikse: Muligens

Normalt skal ikke brukere noen gang opprette PCer i domenet, men avhengig av hvordan dere setter opp PCer så kan det være at dere er avhengig av at brukerne skal kunne ha tilgang til dette. Dersom det er tilfellet bør dere gå over til å benytte grupper istedet og delegere tilgangen på de relevante OUene.

Kompleksitet på endringen: Lav (Powershell, GPMC)

Hvordan utføre endringen:
Kjør følgende Powershell kommandoer:

Hent ut opprinnelig verdi: Get-ADObject ((Get-ADDomain).distinguishedname) -Properties ms-DS-MachineAccountQuota

Disable funksjonen: Set-ADDomain (Get-ADDomain).distinguishedname -Replace @{"ms-ds-MachineAccountQuota"="0"}

Gi tilgangen til en gruppe:
Åpne Group Policy Management Console (GPMC) > Domain Controllers > Default Domain Controllers Policy : Edit
Gå til Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment

Velg Add workstations to domain > Properties
Fjern Authenticated Users og legg til gruppen dere ønsker å gi tilgang til.

Artikler

Microsoft Doc: https://learn.microsoft.com/nb-no/troubleshoot/windows-server/active-directory/default-workstation-numbers-join-domain

Microsoft Group Join: https://learn.microsoft.com/en-us/archive/technet-wiki/5446.active-directory-how-to-prevent-authenticated-users-from-joining-workstations-to-a-domain#2-by-default-domain-controllers-policy

Internet artikkel: https://sid-500.com/2017/09/09/securing-active-directory-who-can-add-computers-to-the-domain-only-the-domain-admin-are-you-sure/

Disable Inactive Users

Bakgrunn

Inactive users er brukere som ikke har logget inn på mer enn 180 dager.
Det er spesielt ille med brukere som aldri har logget på, da disse ikke har satt MFA ennå.

Risiko hvis man ikke fikser: Middels

Angripere utnytter inaktive brukere som bakdører for å få tilgang til systemer. Dette gjelder spesielt brukere som aldri har logget inn, siden disse ikke har aktivert MFA ennå. Hvis angriper får aktivert MFA på vanlig måte vil det være veldig vanskelig å oppdage at kontoen er overtatt av en angriper.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Dersom brukere som ikke har vært pålogget på lenge kommer tilbake, så vil kontoen være disablet. Det er normalt helt akseptabelt at brukere som har vært borte så lenge må ta kontakt med IT avdelingen når de kommer tilbake igjen.

Kompleksitet på endringen: Lav (Powershell, ADUC)

Hvordan utføre endringen:
Powershell kommando som viser de som er eldre enn 180 dager, med de eldste først:

Search-ADAccount –AccountInActive –UsersOnly –TimeSpan 180:00:00:00 –ResultPageSize 2000 –ResultSetSize $null | ?{$_.Enabled –eq $True} | Sort LastLogonDate | Select-Object Name, SamAccountName, DistinguishedName, LastLogonDate

Åpne ADUC og disable alle objektene dere mener kan disables. Husk å starte med noen få av de som har vært inaktiv lengst og så øke på.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/services-hub/unified/health/remediation-steps-ad/regularly-check-for-and-remove-inactive-user-accounts-in-active-directory

Enforce password change for Admins

Bakgrunn

Admin kontoer bør ikke ha passord som er eldre enn 3 år.

NB: Dersom man har satt en sikker passordpolicy og byttet alle passord og deretter endret alle brukere til å aldri mere bytte passord i henhold til de nye passordanbefalingene, så kan man se bort fra hele dette punktet.

Risiko hvis man ikke fikser: Lav

Gamle passord kan være enklere å knekke enn nye.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Kompleksitet på endringen: Lav (ADUC)

Hvordan utføre endringen:
NB: Dersom man har satt en sikker passordpolicy og byttet alle passord og deretter endret alle brukere til å aldri mere bytte passord, så kan man se bort fra hele dette punktet.

Kjør powershell kommando for en liste over når alle kontoer sist byttet passord:

Get-ADUser -Filter * -Properties PwdLastSet, lastlogondate | Sort -Descending -Property PwdLastSet | Select-Object Name, Samaccountname, lastlogondate, Enabled, @{name ="pwdLastSet";expression={[datetime]::FromFileTime($_.pwdLastSet)}} | ft -autosize

Gå igjennom listen og finn ut hvilke kontoer som er administratorer.
Be dem bytte passord, eller bytt passord for dem.

Mitigate ADCS ESC8

Bakgrunn

Sertifikatutsending over HTTP kan benyttes i NTLM relay angrep.

SpecterOps rapporterte ESC1-8 i 2021 og beskriver også løsninger.
ESC8 består av to konfigureringer som til sammen utgjør en trussel.

Risiko hvis man ikke fikser: Høy

Kan det ha negative konsekvenser å fikse: Usannsynlig

Man må vurdere hva hver enkelt sertifikatmal benyttes til før man utfører endringer, slik at man er sikker på at endringene ikke bryter med nåværende funksjonalitet. Vanligvis skal det ikke være noe problem å fikse feilkonfigurasjoner.

Internett-artikkelen nedenfor beskriver også hvordan man kan sjekke om noen forsøker å utnytte ESC1 svakheten.

Liste over konfigurasjoner som må endres:
Verifisere at alle AD CS Web grensesnitt kun benytter HTTPS.
Fjerne Enrollment Rights fra Domain Users, og gi dem Read Only (Forhåpentligvis allerede fikset under ESC1)

Kompleksitet på endringen: Middels (IIS Manager)

Hvordan utføre endringen:
Åpne Internet Information Services (IIS) Manager > Servername > Sites > Default Web Site

Velg Bindings i Actions menyen på høyre side. Sikre at https finnes.

Åpne Internet Information Services (IIS) Manager > Servername > Sites > Default Web Site > CertSrv > SSL Settings

Kryss av for "Require SSL"

Dersom man ikke har HTTPS Binding fra før må det opprettes, se link nedenfor.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/security-assessment-insecure-adcs-certificate-enrollment

Internett-artikkel: https://www.beyondtrust.com/blog/entry/esc1-attacks

ESC originale beskrivelser: https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf

Opprette https Binding: https://learn.microsoft.com/en-us/system-center/scom/configure-https-binding-windows-server-ca?view=sc-om-2025#configure-an-https-binding

Enable Extended Protection for Authentication (EPA)

Bakgrunn

Utnytter NTLM videresending på sertifikatservere.

Sårbarheten ble oppdaget i 2009 og Microsoft kom da med beskrivelse på hvordan sikre sertifikatserverne.

Risiko hvis man ikke fikser: Middels

Kan det ha negative konsekvenser å fikse: Usannsynlig

Vi har ikke hørt om noen som får problemer etter aktivering av EPA.

Kompleksitet på endringen: Lav (IIS Manager)

Hvordan utføre endringen
Åpne Internet Information Services (IIS) Manager > Servername > Sites > Default Web Site > CertSrv > Authentication > Windows Authentication

Velg Advanced Settings og aktiver Extended Protection.

Vi anbefaler å først sette Accept og se at alt fungerer ok. Hvis alt fungerer ok i en periode setter man Required.

Når Certsrv er ok utfører man det samme for Certificate Enrollement Web Service.

Det siste punktet for å sikre seg med EPA er å disable HTTP, og det er beskrevet under artikkelen vår for ESC8.

Artikler

Microsoft Doc: https://support.microsoft.com/en-gb/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429

Internet artikkel: https://msrc.microsoft.com/blog/2009/12/extended-protection-for-authentication/

Disable Enable Enforce

Bakgrunn

Utnytter NTLM videresending på sertifikatservere med Web Enrollment

Sårbarheten ble oppdaget i 2021 og Microsoft kom det med beskrivelse på hvordan sikre sertifikatserverne.

Denne sårbarheten blir fjernet ved å fjerne andre sårbarheter, så vi henviser her til disse. Vi har tatt det med som et eget punkt da det ofte blir rapportert som en egen sak.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Feilen utbedres ved å slå på Extended Protection og disable HTTP. Se egne artikler for Extended Protection og ECS8 for disabling HTTP.

Kompleksitet på endringen: Lav

Hvordan utføre endringen:
Se egne artikler for Extended Protection og ESC8.

Artikler

Microsoft Doc: https://support.microsoft.com/en-gb/topic/kb5005413-mitigating-ntlm-relay-attacks-on-active-directory-certificate-services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429

Internet artikkel: https://www.truesec.com/hub/blog/from-stranger-to-da-using-petitpotam-to-ntlm-relay-to-active-directory

Enforce Privileged group on RODCs

Bakgrunn

Read Only Domain Controllers (RODC) er domenekontrollere som bare replikerer et lite subsett av kontoer, slik at det ikke er full krise om disse kommer på avveie. Et attributt som heter msDS-NeverRevealGroup sikrer at ingen Privileged Groups skal replikeres.

Risiko hvis man ikke fikser: Lav

Hvis gruppen msDS-NeverRevealGroup er feil, så vil det bli replikert grupper som ikke skal være på en RODC.

Kan det ha negative konsekvenser å fikse : Usannsynlig

Dette skal bare påvirke administratorer, og disse gruppene skulle uansett ikke vært på en RODC.

Kompleksitet på endringen: Lav

Hvordan utføre endringen:
Åpne ADUC (Active Directory Users and Computers > Domain Controllers >
Åpne alle RODC objekter og sikre at msDS-NeverRevealGroup attributten er satt til:

Administrators
Server Operators
Account Operators
Backup Operators
Denied RODC Password Replication Group

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust?tabs=intune#microsoft-entra-kerberos-and-cloud-kerberos-trust-authentication

Internet artikkel: https://techcommunity.microsoft.com/blog/itopstalkblog/deep-dive-how-azure-ad-kerberos-works/3070889

Hvordan sette opp AzureADKerberos kontoen: https://msendpointmgr.com/2023/03/04/cloud-kerberos-trust-part-2/

Enforce LDAP Signing

Bakgrunn

LDAP Signing gjør at pakker er signerte og derfor ikke kan endres på veien.

LDAP signing kom i 2003, og i 2019 ble hacking av usignerte pakker inkludert i hackerverktøyene.

Risisko om man ikke fikser: Høy

Angripere utnytter manglende LDAP Signing med grunnleggende gratis-verktøy

Kan det ha negative konsekvenser å fikse: Usannsynlig
Siden LDAP signing er støttet siden 2003, så er det er usannsynlig at noe skal få problemer med at pakkene blir signert. Microsoft har en artikkel for hvordan man kan verifisere om noe vil bli påvirket av endringen.

Kompleksitet på endringen: Lav (GPO)

Hvordan utføre endringen:
Anbefaler å benytte GPO som er opprettet for herding, og å benytte Pilot GPO på økende mengder av klienter først og så samme på servere før DCene tas til slutt.
Det er forskjellige GPO settinger for DCer og for servere/klienter.

For klienter og servere

Naviger til : Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options >
Sett: "Network security: LDAP client signing requirements" = Require Signing

For DC

Naviger til : Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options >
Sett "Domain Controller: LDAP server signing requirements" = Require Signing

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server

Internet artikkel: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-3-%E2%80%93-enforcing-ldap-signing/4066233

Verify support for LDAP Signing: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server#how-to-discover-clients-that-do-not-use-the-require-signing-option

Enforce Channel Binding

Bakgrunn

LDAP Channel Binding sikrer LDAP kommunikasjon, selv om en kommunikasjonskanalen blir brutt og restartet.

LDAP Channel Binding kom i RFC5056 i 2007, men ble ikke støttet av Microsoft før i 2020. Støtte ble da inkludert i Windows Update slik at alt som ikke er End Of Life fikk støtte for det.

Risiko om man ikke fikser: Høy

Angripere utnytter manglende LDAP Channel Binding med grunnleggende gratis-verktøy

Kan det ha negative konsekvenser å fikse: Usannsynlig

LDAP Channel Binding er støttet på Windows7, Windows Server 2008 R2 og alt nyere. Eldre systemer enn disse vil ikke klare å kommunisere med AD lengre etter at LDAP Channel Binding er aktivert. Internet artikkelen nedenfor forklarer hvordan man kan sjekke proaktivt om noe utstyr vil få problemer med Channel Binding.

Kompleksitet på endringen: Lav (GPO)

Hvordan utføre endringen:
Anbefaler å benytte GPO som er opprettet for herding.
Settes for kun for DCer.

Naviger til : Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options >

Sett "Domain controller: LDAP server channel binding token requirements" = Always

Artikler

Microsoft Doc: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-5-%E2%80%93-enforcing-ldap-channel-binding/4235497

Microsoft KB: https://support.microsoft.com/en-us/topic/2020-2023-and-2024-ldap-channel-binding-and-ldap-signing-requirements-for-windows-kb4520412-ef185fb8-00f7-167d-744c-f299a66fc00a

Internet artikkel: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-5-%E2%80%93-enforcing-ldap-channel-binding/4235497

Disable Unconstrained Delegation

Bakgrunn

Kerberos Delegation betyr at en applikasjon kan få tilganger på vegne av en annen konto. Unconstrained Delegation betyr at disse tilgangene er gitt generelt til alt, og de er ikke spesifisert til bestemte ting.

Risiko hvis man ikke fikser: Høy

Dersom en angriper har fått tilgang til en applikasjon som benytter et objekt som er satt opp med Unconstrained Delegation, og en Domain Admin benytter applikasjonen, så har angriper automatisk Domain Admin tilgang. Dersom en applikasjon må benytte delegation, så er det viktig å ikke sette den opp med unconstrained delegation, men å delegere kun til nøyaktig hva applikasjonen trenger.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Å endre fra Unconstrained Delegation til Constrained Delegation skal ikke påvirke brukerne, så lenge man får lagt inn alle constraints applikasjonen trenger tilgang til.

Kompleksitet på endringen: Middels (Powershell,ADUC)

(Active Directory Users og Computers (ADUC) har en egen liste over tilganger som er enkel å oppdatere, men det kan være vanskelig å vite hva som skal legges inn.

Hvordan utføre endringen:

Powershell kommando for å se alle Computer objekter som har delegation:

Get-ADComputer -Filter {((TrustedForDelegation -eq $True) -OR (TrustedToAuthForDelegation -eq $true)) -AND (PrimaryGroupID -eq 515)} -Properties TrustedForDelegation,TrustedToAuthForDelegation,servicePrincipalName,Description

Hvis TrustedForDelegation = True, så er det Unconstrained Delegation
Hvis TrustedToAuthForDelegation = False, så er det Constrained Delegation

Microsoft anbefaler å ikke benytte Delegation hvis det er mulig å unngå det. Vurder om det er mulig å slå av Delegation for objektet. Hvis det ikke er mulig, endre til Constrained Delegation slik:

Start ADUC, åpne det relevante objektet og endre fra "Trust this computer for delegation to any service (Kerberos only)" til "Trust this computer for delegation to specified services only"

Velg "Use Kerberos only"
Legg inn de servicene som kontoen skal kunne delegere til.
Viktig å huske at en angriper vil få tilgang til alle servicene man legger inn i listen, dersom angriper får tilgang til den opprinnelige applikasjonen.

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/security-assessment-unconstrained-kerberos

Internet artikkel: https://www.sentinelone.com/blog/detecting-unconstrained-delegation-exposures-in-ad-environment/

Disable Enable Enforce

Bakgrunn

Microsoft utbedret i 2015 en svakhet som gav angripere tilgang til å gjøre GPO endringer via SYSVOL og NETLOGON sharene. Noen slo manuelt av denne fiksen når den kom, for å være sikker på å unngå noen problemer med utbedringen til Microsoft.

Risiko hvis man ikke fikser: Høy

Angripere kan utnytte Hardened Path med grunnleggende gratis-verktøy.

Kan det ha negative konsekvenser å fikse: Muligens

Normalt skal det ikke være noen konsekvenser med dette, men det kan være at årsaken til at utbedringen ble avslått når Microsoft fikset dette i 2015, var fordi noe sluttet å virke den gang.

Kompleksitet på endringen: Lav (GPMC)

Hvordan utføre endringen:
Anbefaler å benytte GPO som er opprettet for herding, og å benytte Pilot GPO på økende mengder av klienter først og så samme på servere før DCene tas til slutt.
Settes for Klienter, Servere og DC.

Naviger til : Computer Configuration\Policies\Administrative Templates\Network\Network Provider\

Sett "Hardened UNC Paths" til Enabled

Under Options, gå ned til "Show" knappen og legg inn følgende to paths:

Value Name Value
\\*\NETLOGON RequireMutualAuthentication=1,RequiredIntegrity=1

\\*\SYSVOL RequireMutualAuthentication=1,RequiredIntegrity=1

Artikler

Microsoft Doc: https://support.microsoft.com/en-us/topic/ms15-011-vulnerability-in-group-policy-could-allow-remote-code-execution-february-10-2015-91b4bda2-945d-455b-ebbb-01d1ec191328

Internet artikkel 1: https://woshub.com/cant-access-domain-sysvol-netlogon-folders/

Internet artikkel 2: https://labs.withsecure.com/publications/how-to-own-any-windows-network-with-group-policy-hijacking-attacks
Internet artikkel 3: https://calcomsoftware.com/enable-hardened-unc-paths-what-why-and-how/

Disable HTTP for WSUS

Bakgrunn

WSUS benyttes hovedsakelig for å oppdatere computere. WSUS skal automatisk benytte HTTPS, men det er mulig å aktivere HTTP for test.

I 2020 ble det publisert hvordan man kan gjøre et angrep mot HTTP, og HTTP bør derfor ikke benyttes.

Risiko hvis man ikke fikser: Høy

Angripere utnytter bruk av HTTP med kjente verktøy for å ta kontroll på enhetene som oppdateres.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Det er usannsynlig at brukere opplever noen problemer, da dette kun gjelder oppdateringer.

Kompleksitet på endringen: Lav

Hvordan utføre endringen:
NB: Endringene nedenfor bør utføres av noen med kompetanse på WSUS og Configuration Manager.

Først må man skaffe et sertifikat for WSUS, hvis man ikke har det fra før. Se Microsoft Cert nedenfor for detaljer.

Logg inn på WSUS-serveren med en domenekonto som ligger i local Administrators.

Åpne Internet Information Services (IIS) Manager > Servername > Sites > WSUS Administration

Endre KUN følgende WSUS web tjenster med å sette "SSL Settings" til "Require SSL Options" og "Client Certificates" til Ignore:

SimpleAuthWebService
DSSAuthWebService
ServerSyncWebService
APIremoting30
ClientWebService

WSUS må så oppdateres for å få inn endringene ovenfor. Åpne en commandprompt som Administrator.

Gå til WSUS folderen, antakeligvis: cd "c:\Program Files\Update Services\Tools"

Kjør: WsusUtil.exe configuressl FQDN_ServerName

Verifiser endringene over med å starte WSUS console > Action > Connect to Server
Skriv inn FQDN til server. Når man velger portnummer skal man se at krysset for SSL automatisk slås på.
Verifiser at oppkopling til server fungerer.

Til slutt må man konfigurere WSUS oppdateringspunktene til å benytte HTTPS.

Åpne Configuration Manager og kople til din Central Administration Site.

Gå til Administration > Overview > Site Configuration > Servers and Site System Roles
Velg Site System serveren hvor WSUS er installert og velg Software Update Point Site og velg Properties

Sett kryss for "Require SSL communication to the WSUS server"

Verifiser endringene med å starte Configuration Manager til top-level site.

Gå til Software Library > Overview > Software Updates > All Software Updates

Velg Synchronize Software Updates
Velg Yes på å initiere Site-Wide synkronisering.

Åpne wsyncmgr.log for siten.

Verifiser at logfilen viser at Full Sync er startet og fullført med "Done synchronizing…"

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/intune/configmgr/sum/get-started/software-update-point-ssl#bkmk_webserv

Microsoft Cert: https://learn.microsoft.com/en-us/windows-server/administration/windows-server-update-services/deploy/2-configure-wsus#23-secure-wsus-with-the-tls-protocol

Internet artikkel: https://gosecure.ai/blog/2021/11/22/gosecure-investigates-abusing-windows-server-update-services-wsus-to-enable-ntlm-relaying-attacks/

Disable Enable Enforce

Bakgrunn

Når Microsoft lanserte Active Directory i 2000, så var det bekymret for at alle Windows NT serverne ikke skulle få den nødvendige tilgangen til AD. De opprettet derfor gruppen "Pre-Windows 2000 Compatible Access". I tidligere versjoner av Windows ble Everyone og Anonymous lagt inn i denne gruppen. Det er nå sterkt anbefalt å fjerne alle andre objekter enn Authenticated Users fra gruppen. For best sikkerhet bør også Authenticated Users fjernes, men det gir erfaringsmessig problemer for endel eldre applikasjoner/prosesser, så det er normalt å la Authenticated Users ligge igjen som eneste objekt i gruppen.

Risiko hvis man ikke fikser: Lav

Angripere utnytter lesetilgangen til å finne interresante objekter i AD som de så kan angripe.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Alle brukere er Authenticated Users, så det er veldig usannsynlig at det gir noen problemer å kun ha Authenticated Users i gruppen. Dersom man også fjerner Authenticated Users så er det dessverre normalt at gamle systemer/prosesser får problemer.

Kompleksitet på endringen: Lav (ADUC)

Hvordan utføre endringen:
Åpne ADUC > Builtin > Pre-Windows 2000 Compatible Access > Members

Kun Authenticated Users skal ligge i gruppen, så fjern alle andre objekter.

Info rundt sertifikatservere

Det er helt normalt at Sertifikat/PKI/CA servere ligger i gruppen, da installasjonsprogrammet for sertifikatservere legger disse inn automatisk. Det er imidlertid kun i veldig spesielle tilfeller at disse serverne trenger medlemskapet, så normalt vil det være helt trygt å fjerne dem. (Dersom man benytter "restricted certificate manager feature" må sertifikat serverne ligge i "Pre-Windows 2000 Compatible Access", men hvis man benytter denne funksjonen så bryter man med Tiermodellen som sier at kun Domain Admins skal ha tilgang til sertifikatservere.)

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/7a76a403-ed8d-4c39-adb7-a3255cab82c5

Internet artikkel: https://www.semperis.com/blog/security-risks-pre-windows-2000-compatibility-windows-2022/

Internet artikkel om sertifikat servere: https://www.gradenegger.eu/en/why-active-directory-integrated-certification-authorities-are-members-of-pre-windows-2000-compatible-access/

Enforce AES på Kerberos Trusts

Bakgrunn

Kerberos er en autentiseringsprotokoll i Windows Active Directory. Trusts benytter som default DES og RC4. Begge disse kan nå dekrypteres. Man bør derfor konfigurere Trusts til å benytte kun Kerberos AES.

Risiko om man ikke fikser: Høy

Angripere utnytter DES og RC4 kryptering til å kjøre standard Kerberoasting angrep da disse protokollene kan dekrypteres raskt.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Før man endrer et Trust til å kun benytte AES sikrer man begge domenene/skogene ved å utføre alle de tidligere herdingspunktene. Man har da allerede avviklet DES og RC4 i begge domenene som utgjør Trustet. Siden det da allerede er kun AES trafikk igjennom Trustet vil det ikke være noe konsekvenser ved å kreve dette også på Trustet.

Kompleksitet på endringen: Lav (AD Domains and Trusts)

Hvordan utføre endring:
Sikre at begge domenene som er på hver side av Trustet allerede er herdet.

Åpne Active Directory Domains and Trusts
Velg domenet, høyreklikk og velg Trusts. Velg Trustet.

Huk av for "The other domain supports Kerberos AES Encryption"

Artikler

Internet artikkel: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-4-%E2%80%93-enforcing-aes-for-kerberos/4114965

Kerberos Encryption Types explained: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/decrypting-the-selection-of-supported-kerberos-encryption-types/1628797

Bakgrunn

Sertifikater med mindre enn 2048 bits er mulig for en angriper å dekryptere.

Risiko hvis man ikke fikser: Lav

Angripere kan dekryptere sertifikater med mindre enn 2048 bits RSA nøkkel.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Bytte av sertifikat er en vanlig driftsoperasjon, så dette skal det allerede være prosedyrer på.

Kompleksitet på endringen: Lav (Certification Manager)

Hvordan utføre endring:
Bytt sertifikatet som Ping Castle rapporterer på vanlig måte. Det er veldig forskjellig hva sertifikater benyttes til, så undersøk hvordan tidligere sertifikatbytter ble utført for å se hvilke systemer som må oppdateres etter byttet.

Bakgrunn

SMB Signing gjør at pakker er signerte og derfor ikke kan endres på veien.

SMB Signing kom i 1996, og har vært anbefalt å benytte siden da.

Risiko om man ikke fikser: Høy

Angripere utnytter manglende SMB Signing til å utføre et standard NTLM Replay angrep.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Siden SMB Signing er støttet siden 1996, så er det er usannsynlig at noe skal få problemer med at pakkene blir signert. For å sjekke om man har noe som ikke støtter SMB Signing må man først oppgradere alle DCer til 2025. Se beskrivelse i Internet artikkelen nedenfor.

Kompleksitet på endringen: Lav (GPO)

Hvordan utføre endringen:
Anbefaler å benytte GPO som er opprettet for herding, og å benytte Pilot GPO på økende mengder av klienter først og så samme på servere før DCene tas til slutt.
Det er forskjellige GPO settinger for DCer og for servere/klienter.

På DCene skal den allerede være satt til Enabled

Velg Default Domain Controller Policy

Naviger til : Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options

Verifiser at "Microsoft network server: Digitally sign communications (always)" = Enabled

NB: Hvis den ikke står til Enabled, forsøk å finn ut hvorfor.

På servere og klienter

Naviger til : Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options

Sett "Microsoft network server: Digitally sign communications (always)" = Enabled

Sett "Microsoft network client: Digitally sign communications (always)"=Enabled

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/overview-server-message-block-signing

Internet artikkel: https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/active-directory-hardening-series---part-6-%E2%80%93-enforcing-smb-signing/4272168

Internet artikkel: https://techcommunity.microsoft.com/blog/filecab/configure-smb-signing-with-confidence/2418102

Enforce Kerberos armoring

Bakgrunn

Kerberos Armoring krypterer Kerberos trafikken, og uten den så går trafikken ukryptert.

Kerberos Armoring kom i 2012, og har vært anbefalt å benytte siden da.

Risiko om man ikke fikser: Høy

Angripere utnytter manglende Kerberos Armoring for å utføre standard Kerberoasting angrep.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Dersom det er noe som ikke støtter Kerberos Armoring, så vil det slutte å virke når det slås på. Siden Kerberos Armoring kom med Windows Server 2012, så er det usannsynlig at det blir noen problemer. Det er nødvendig å starte med klientene, for å sikre at de har Kerberos Armoring, før man så krever det på DCene. Det vil logges hvis noe feiler fordi det ikke støtter Kerberos Armoring, se internet-artikkelen nedenfor.

Kompleksitet på endringen: Lav (GPO)

Teknisk beskrivelse av GPO
Anbefaler å benytte GPOer som er opprettet for herding, og å rulle ut armored requests på klienter og servere forsiktig. Merk at man må først skru på at DC støtter armoring før man ruller ut til klienter og servere.

Det er forskjellige GPO-settinger for DCer og andre servere/klienter

For DC – skru på støtte for armored requests

Naviger til : Computer Configuration\Policies\Administrative Templates\System\KDC

Sett "KDC support for claims, compound authentication, and Kerberos armoring" = Supported

For klienter og servere – skru på armored requests

Naviger til : Computer Configuration\Policies\Administrative Templates\System\Kerberos
Sett "Kerberos client support for claims, compound authentication and Kerberos armoring" = Enabled

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831747(v=ws.11)#support-for-claims-compound-authentication-and-kerberos-armoring

Internet artikkel: https://www.hub.trimarcsecurity.com/post/securing-the-chink-in-kerberos-armor-fast-understanding-the-need-for-kerberos-armoring

Mitigate ADCS ESC15

Bakgrunn

Sertifikatutsending over HTTP kan benyttes i NTLM relay angrep.

Oppdaget i 8 oktober 2024 og patchet gjennom Windows Update av Microsoft med CVE-2024-49019 i 12 november 2024.

ESC15 består av to konfigurasjoner som til sammen utgjør en trussel.

Kan det ha negative konsekvenser å fikse: Usannsynlig

Kompleksitet på endringen: Lav (ADSC innstilling)

Teknisk beskrivelse
Utfør ESC1 utbedringene, disse vil også fikse ESC15

Patch server med Windows Update

Artikler

Microsoft Doc: https://learn.microsoft.com/en-us/defender-for-identity/prevent-certificate-enrollment-esc15

Microsoft general tips for securing PKI: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn786426%28v=ws.11%29#securing-certificate-templates

Internet artikkel: https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc

Internet artikkel: https://www.ravenswoodtechnology.com/esc15-vulnerability/