NTLM svakheter og responsmuligheter

Windows-miljøer fortsetter å være sårbare for en rekke svakheter knyttet til NTLM. NTLM er en vanlig autentiseringsfunksjon i Windows systemer. Denne artikkelen gir et overblikk hvordan nylige sårbarheter utnyttes, hvorfor de er så alvorlige, og hvordan man bør respondere.  

Jeg skal forklarer hva som gjør disse svakhetene så attraktive for angripere, hvordan angrepene gjennomføres, og hvilke tiltak og loggmekanismer som er nødvendige for å beskytte virksomheten. 

Hva er felles for de siste NTLM sårbarhetene? 

CVE-2025-24054, CVE-2025-21377, CVE-2025-21308, CVE-2024-43451, CVE-2024-21320 

Disse krever minimal eller ingen bestemt handling fra brukeren av et system for å utnyttes.  

Det som trengs for å aktivere disse sårbarhetene er å få Windows maskinen til å se på filens innhold eller metadata. Da trenger brukeren kun å se at filen eksisterer i File Explorer. 

Siden det nesten ikke krever noen handling fra brukere så er det attraktive svakheter for angripere. Noen av svakhetene ligger inn i databasen CISA KEV (Known Exploited Vulnerabilities).  

Windows håndterer NTLM-autentisering uavhengig av sonedefinisjoner (Intranet/Trusted/Public). Den skiller heller ikke på om IP’en er innenfor eller utenfor de private IP-nettene (RFC1918).  

Angrepsvektor 

Dette fungerer også når angriperen er utenfor det private nettverket. Så lenge SMB trafikk kommer fram til angriperens system så er det mulighet for å utnytte dette. 

Angriperen kan også bruke et "internt" kompromittert system med en SMB tjeneste som tar imot NTLM-hash fra en bruker. Som angriper ønsker man da en bruker med flere rettigheter og tilganger. 

For at systemet skal bruke NTLM som autentiseringsmetode så må tilkoblingslenken inneholde en IP-adresse. Hvis tilkoblingslenken har en FQDN (for eksempel FIL-SERVER.BEDRIFT.NO) så vil systemet bruke Kerberos som autentiseringsmetode. 

Bildet ovenfor viser et verktøy som kan bli brukt for å motta SMB tilkobling og deretter uthente NTLM-hash. 

Responsmuligheter 

• Deaktiver NTLM autentisering på systemer som ikke har direkte behov for den autentiseringsmetoden. Dette kan gjøres via Group Policy (GPO).

• Begrense SMB trafikk mot server grupper som Domenekontrollere, Fil-servere og Print-servere. Disse tjeneste kan bruke Kerberos som autentiseringsmetode, så det eksistere en mulighet å begrense NTLM autentisering mot disse tjenestene.

• Verifisere at SMB-signing er påskrudd. Dette kan gjøres via Group Policy (GPO).

• Oppdater systemene fortløpende i tråd med rutine. 

Logging 

• Aktiver NTLM-audit. I standard-oppsett så er dette ikke påskrudd. Grunnen til at dette bør skrus på er fordi autentiseringslogger (Event ID: 4624) – der NTLM er autentiseringsmetoden – ikke inneholder informasjon om klienten som kobler seg til systemet. 

Network security Restrict NTLM Audit NTLM authentication in this domain - Windows 10 | Microsoft Learn 

• Verifiser at NTLM logger blir innhentet til SIEM eller av SOC-tjenesten. Viktig Event ID er 8004, og loggene befinner seg i: Applications and Services Logs >> Microsoft >> Windows >> NTLM >> Operational  

Siden NTLM logg-hendelser ikke eksisterer i sikkerhetsloggen så må man ofte gjøre ekstra konfigurasjon for å samle inn disse loggdataene. 

Les mer om våre tjenester innen sikkerhetsovervåking og hendelseshåndtering (SOC) her >