Ny utnyttelseskode skal gi SYSTEM-tilgang gjennom Microsoft Defender

Sikkerhetsforskeren som kaller seg Nightmare Eclipse publiserte 12. august 2026 en utnyttelseskode kalt ShieldBreak, kort tid etter at Microsoft ga ut augustoppdateringene. Koden skal gi SYSTEM-rettigheter gjennom Microsoft Defender, og forskeren omtaler den som en fullstendig omgåelse av rettelsen Microsoft ga for sårbarheten RoguePlanet, CVE-2026-50656, i juli. Ifølge forskeren er koden prøvd på Windows 11 25H2, på Canary-utgaven og på Windows Server 2025, og skal ha virket hver gang. Will Dormann, sårbarhetsanalytiker i Tharros, bekreftet 11. august at koden virker, og oppgir at Defender må være slått på for at rettighetene skal kunne heves. BleepingComputer opplyser at de har bedt Microsoft om en kommentar.

Hva som skjer teknisk

Kevin Beaumont, som også har publisert søk for å oppdage bruken av ShieldBreak i Microsoft Defender for Endpoint, beskriver at de to sårbarhetene virker på helt forskjellige måter. RoguePlanet var en race condition mot filsystemet, altså en feil som oppstår når to operasjoner kappes om den samme filen, der virtuelle disker og filoperasjoner på et lavt nivå fikk karanteneprosessen i Defender til å skrive over systemfiler. ShieldBreak går en annen vei: den henger seg på en rutine i brukermodus som Windows kaller under skanningen, og endrer innholdet i filen mens Defender skanner den gjennom Cloud Filter API, altså grensesnittet som brukes når en fil som ligger i skyen hentes ned til maskinen ved behov.

Mekanismen er verdt å forstå prinsipielt, uavhengig av denne ene feilen. Et antivirusprogram må lese filen for å vurdere den, og det gjør det med systemets høyeste rettigheter. Filer som synkroniseres fra skyen finnes i tillegg i to tilstander, som en plassholder og som en fullstendig fil, og overgangen mellom dem skjer i det øyeblikket noe leser filen. Klarer en angriper å bytte innholdet i akkurat det tidsrommet, er det den privilegerte prosessen som behandler det nye innholdet. Sikkerhetsproduktet blir da veien inn, ikke fordi det gjør noe galt, men fordi det har rettighetene angriperen mangler.

Det er samtidig grenser for hva som er bekreftet. Påstanden om at koden virker på alle oppdaterte maskiner, og at den lykkes hver gang, kommer fra forskeren selv. Dormann har bekreftet at den virker, med det forbeholdet at Defender må være aktivert. Windows 10 er ifølge forskeren ikke støttet av koden, men skal likevel være sårbar. Saken har også en bakgrunn som er verdt å kjenne til: dette er en pågående uenighet mellom Microsoft og forskeren om selskapets praksis for varsling og dusører, og forskeren har siden april 2026 publisert en rekke utnyttelseskoder mot Defender, BitLocker og andre deler av Windows. Noen av de underliggende feilene er rettet, andre venter fortsatt på en oppdatering.

Hva det betyr for deg som drifter Windows-klientene

Dette er ikke en sak der du kan oppdatere deg ut av problemet i dag, for det finnes ingen rettelse ennå. Det du kan gjøre, er å flytte oppmerksomheten dit den hører hjemme. En rettighetseskalering krever at noen allerede kjører kode som en vanlig bruker på maskinen. Da er det første trinnet, altså phishing, en ondsinnet installasjon eller en kapret økt, fortsatt det avgjørende leddet i kjeden. Klarer du å gjøre det trinnet vanskeligere, betyr det mindre at det siste trinnet er lett.

Berigos vurdering er at du bør skaffe deg deteksjon framfor å vente. Beaumont har publisert søk for Defender for Endpoint, og de kan legges inn nå. Samtidig er dette en påminnelse om at sikkerhetsproduktet er en del av angrepsflaten din, ikke bare et forsvar. Etter NIS2 artikkel 21 hører dette hjemme både i sårbarhetshåndteringen og i overvåkingen, og et kompenserende tiltak er et gyldig svar så lenge det er dokumentert og tidsbegrenset. Vi vil legge til at en påstand fra en forsker ikke er det samme som en bekreftet sårbarhet fra leverandøren, og at en styresak bør si tydelig hva som er hvilket.

Berigo anbefaler

• Legg inn deteksjonssøkene som er publisert for Defender for Endpoint, og se etter treff bakover i tid.
• Prioriter tiltak mot første trinn i kjeden, altså kjøring av kode som vanlig bruker, siden det ikke finnes en rettelse ennå.
• Følg med på Microsofts sikkerhetsvarsler for en oppdatering, og planlegg utrullingen før den kommer.
• Se på sikkerhetsproduktene som en del av angrepsflaten i risikovurderingen, ikke bare som kontroller.
• Skill tydelig mellom forskerens påstander og det leverandøren har bekreftet når saken løftes til ledelsen.