Microsofts signerade rootkit-skadlig programvara som kan dekryptera all krypterad kommunikation

I juni 2021 upptäckte en säkerhetsforskare att Microsoft hade digitalt signerat ett kernel-mode rootkit. Drivrutinen, kallad "Netfilter", passerade genom Microsofts egen pipeline för hårdvarucertifiering, omdirigerade sedan nätverkstrafik och placerade ett falskt betrott rotcertifikat på infekterade maskiner, den typ av certifikat som ligger till grund för förtroendet i krypterad kommunikation . Den här artikeln beskriver exakt vad Netfilter gjorde, vad det inte gjorde och vad incidenten fortfarande lär säkerhets- och PKI-team om förtroende för drivrutinssignering idag.

Publicerad: september 2022. Uppdaterad: augusti 2026. Granskad av Encryption Consultings PKI- och kodsigneringsrådgivningsteam.

Vad hände i Netfilter Rootkit-incidenten?

Karsten Hahn, en forskare inom skadlig kod på säkerhetsföretaget G Data, upptäckte en drivrutin som flaggats av hans företags detekteringssystem och som innehöll en giltig digital signatur från Microsoft. Den första instinkten var att behandla varningen som ett falskt positivt resultat, eftersom Microsoft hade signerat filen under sitt Windows Hardware Compatibility Program (WHCP). Hahn fortsatte att gräva ändå. Det äldsta kända exemplet av drivrutinen dateras tillbaka till mars 2021, och vidare analys visade att den betedde sig som ett rootkit snarare än ett legitimt nätverksfilter. Hahn delade sina resultat offentligt och kontaktade Microsoft direkt.

Den 25 juni 2021 bekräftade Microsofts Security Response Center rapporten. En tredjepartsutvecklare hade skickat in drivrutinen, med namnet "Netfilter", för certifiering via WHCP, och Microsofts signeringsprocess hade godkänt den. BleepingComputer och Ars Technica publicerade båda bekräftelsen samma vecka, och deras rapportering, tillsammans med G Datas ursprungliga analys, är den primära faktagrunden för denna artikel.

Vad Netfilter faktiskt gjorde, baserat på G Datas reverse engineering och uppföljningsrapportering, var mer begränsat än vad incidentens rykte antyder:

• Omdirigerade specificerad nätverkstrafik till angriparkontrollerade IP-adresser, inklusive en kommando-och-kontrollvärd (C2) som observerades vid 110.42.4.180:2081, med omdirigerad trafik dirigerad mot 45.248.10.244:3000.
• Skrev ett nytt certifikat i Windows-registersökvägen för betrodda rotcertifikat, vilket i praktiken lade till en obehörig certifikatutfärdare (CA) i maskinens betrodda arkiv.
• Kunde ställa in en ny systemproxy och ändra lokala internetinställningar utan användarens medgivande.
• Hade självuppdateringslogik, checkade in med sin C2-server och ersatte sin egen binärfil när en nyare version fanns tillgänglig.

C2-infrastrukturen exponerade en liten uppsättning URL-sökvägar, var och en med ett distinkt jobb:

• /p, associerad med proxyinställningar
• /s, kodade omdirigerings-IP-adresser
• /h?, används för att ta fingeravtryck av CPU-ID
• /c, levererade det oseriösa rotcertifikatet
• /v?, hanterade skadlig programvaras självuppdateringsfunktion

Flera kanaler rapporterade att aktörens troliga mål var att rikta in sig på spelare, främst i Kina, så att de kunde förfalska sin geolokalisering och kringgå regionala begränsningar eller spela på servrar de inte var auktoriserade för. En del rapporter beskrev också keylogging-beteende kopplat till kontokompromettering. Varken G Datas ursprungliga analys eller den efterföljande pressbevakningen dokumenterade en storskalig, verifierad förmåga att fånga upp eller dekryptera "all" krypterad trafik på en infekterad maskin, än mindre över internet.

Hur missbrukade Netfilter Microsofts förtroendemodell för drivrutinssignering?

Windows kräver att kärnlägesdrivrutiner har en giltig Microsoft-signatur innan de laddas på moderna 64-bitarssystem. Det kravet finns just för att förhindra att osignerad eller manipulerad kod körs med högsta möjliga förtroendenivå för operativsystemet. WHCP är den certifieringsväg som hårdvaru- och drivrutinsleverantörer använder för att få den signaturen: en partner skickar in en drivrutin, Microsofts pipeline testar och signerar den, och den resulterande Microsoft-signaturen informerar varje Windows-maskin om att drivrutinen är säker att ladda.

Netfilter utnyttjade inte en brist i Microsofts kryptografi eller stal en privat nyckel. Angriparen använde ett registrerat WHCP-partnerkonto, skickade in en drivrutin som klarade automatiserade tester och fick en legitim signatur för skadlig kod. Microsofts egen undersökning, som beskrevs i deras uttalande vid den tidpunkten, fann inga bevis för att deras signeringscertifikat eller WHCP-signeringsinfrastruktur hade komprometterats. Företaget stängde av det inskickande kontot, granskade andra inskickade filer från samma partner för ytterligare skadlig kod, lade till Netfilter-detektering i Microsoft Defender och delade indikatorer med andra antivirusleverantörer.

Detta är den viktigaste lärdomen för kodsigneringsprogram av alla slag, inte bara Microsofts: en signeringspipeline är ett förtroendebeslut om inskickaren, inte en skanning efter illvilliga avsikter. Om granskningen av vem som kan skicka in kod och vilka tester den koden går igenom har en lucka, kan en giltig signatur hamna på skadligt innehåll utan att någon bryter den underliggande kryptografin. Ingen CVE tilldelades någonsin till denna incident, eftersom det inte var en sårbarhet i Windows-kod. Det var ett process- och identitetsgranskningsfel i en leveranskedja som Windows är beroende av för förtroende.

Kan Netfilter verkligen "dekryptera all krypterad kommunikation"?

Detta är påståendet i titeln, och det förtjänar ett precist svar: nej, inte som en bokstavlig, demonstrerad förmåga. Det som offentliga register stöder är snävare och fortfarande värt att ta på allvar.

Netfilters bekräftade förmåga var att installera ett falskt rotcertifikat i Windows betrodda rotarkiv. Det är viktigt eftersom Windows och de flesta webbläsare avgör om en TLS-anslutning är pålitlig genom att kontrollera om certifikatet som presenteras av en server är kopplat till en certifikatutfärdare i det betrodda arkivet. Om en angripare kan lägga till sin egen certifikatutfärdare i arkivet kan de utfärda certifikat för vilken domän som helst, och operativsystemet kommer att acceptera dem som giltiga. Kombinerat med Netfilters trafikomdirigering och proxyinställningar ger det en angripare de delar som behövs för att köra en man-in-the-middle (MITM)-attack, som avlyssnar och omkrypterar TLS-skyddad trafik som angriparen faktiskt dirigerar genom sin egen infrastruktur.

Det skiljer sig markant från ett påstående att skadlig programvara skulle kunna dekryptera all krypterad kommunikation, var som helst, utan att först omdirigera den. Rapporter från G Data, BleepingComputer och TheHackerNews beskriver hur Netfilter omdirigerar specifik trafik, kopplad till spel och geolokaliseringsförfalskning, och inte tyst dekrypterar godtyckliga krypterade sessioner över internet. Det oseriösa rotcertifikatet är den mekanism som i princip möjliggör bredare TLS-avlyssning; det är inte i sig bevis på att angriparen använde det på det sättet i stor skala.

Läs den här titeln som en beskrivning av en attackmekanism, ett falskt betrott rotcertifikat som kan möjliggöra TLS-avlyssning av omdirigerad trafik, snarare än en beprövad, obegränsad dekrypteringsfunktion. Den distinktionen är viktig för korrekt incidentrespons och för alla som citerar detta fall som referenspunkt.

Vad är ett rootkit, och varför är rotcertifikatet viktigt?

En rootkit är skadlig kod som är byggd för att dölja sin egen närvaro från operativsystemet, från fillistor, aktivitetshanterare och standardverktyg för detektering, vanligtvis genom att köras på en behörighetsnivå, som kernelläge, där den kan fånga upp och förfalska vad resten av systemet ser. Netfilter kvalificerade sig som en rootkit eftersom den kördes som en signerad kernellägesdrivrutin, vilket gav den samma förtroendenivå som legitima hårdvarudrivrutiner.

Ett rotcertifikat tillhör, i normal drift, en certifikatutfärdare som en webbläsare eller operativsystemleverantör har granskat och litar på att endast utfärda certifikat till verifierade domänägare. Det är detta förtroende som låter TLS bekräfta både att trafiken är krypterad under överföring och att servern i andra änden är den den utger sig för att vara. När Netfilter skrev sitt eget certifikat till samma betrodda arkiv, infogade det en okontrollerad certifikatutfärdare i ett system som var utformat kring antagandet att allt i det arkivet har genomgått en riktig valideringsprocess.

Vilken är hotmodellen bakom attacker i leveranskedjan med drivrutinssignering?

Netfilter är ett exempel på ett bredare mönster: en angripare behöver inte bryta en kodsigneringsalgoritm när de kan få en legitim signatur applicerad på skadligt innehåll genom processen runt det. Den realistiska hotmodellen för alla organisationer som förlitar sig på kodsignering, oavsett om det gäller kärndrivrutiner, firmware eller programvaruversioner, inkluderar:

1. Identitetsmissbruk vid inlämning. En angripare registrerar, köper eller komprometterar ett legitimt signeringskonto och skickar in skadlig kod som om det vore rutinmässigt.
2. Otillräcklig validering för signering. Automatiserad testning kontrollerar stabilitet och kompatibilitet, inte ont uppsåt, så kod som beter sig "normalt" under testning kan fortfarande vara skadlig i produktion.
3. Stöld av privat nyckel. Om själva signeringsnyckeln exponeras kan en angripare signera godtycklig kod utan att gå igenom den legitima inlämningsprocessen alls, ett distinkt och allvarligare felläge än Netfilters.
4. Förgiftning av förtroendebutik. När skadlig kod körs med systembehörigheter kan den lägga till otillåtna certifikat, inaktivera skydd eller öppna ytterligare persistensvägar.
5. Nedströms förökning. Signerade skadliga drivrutiner eller binärfiler sprids via normala programvarudistributions- och uppdateringskanaler, eftersom själva signaturen undertrycker de flesta säkerhetsvarningar.

Encryption Consulting har behandlat den allvarligare versionen av denna hotmodell i en separat fallstudie om MSI:s kodsigneringsnyckelstöld 2023 , där en faktisk signeringsnyckel stals snarare än missbrukades genom inlämning. Båda incidenterna pekar på samma underliggande krav: säkerheten för ett kodsigneringsprogram beror på hur nycklarna och inlämningsprocessen styrs, inte bara på styrkan hos den kryptografiska algoritmen.

Hur bör organisationer välja kodsigneringsalgoritmer och protokoll för att förhindra detta?

Val av algoritm är nödvändigt men inte tillräckligt i sig självt; Netfilter signerades med en giltig, okomprometterad nyckel, så felet låg fortfarande kvar under processen, inte under kryptografin. Att få den kryptografiska baslinjen rätt stänger dock av intilliggande attackvägar:

• Använd RSA-3072 eller ECDSA P-384 eller starkare för kodsigneringsnycklar, som matchar nuvarande CA/Browser Forum-baskrav för offentligt betrodda kodsigneringscertifikat och helt undviker äldre SHA-1-signering. Se Encryption Consultings Bästa praxis för kodsignering i SDLC för en fullständig genomgång av kontroller på pipeline-nivå.
• Kräv hårdvarubaserad lagring av privata nycklar. Sedan juni 2023 har CA/Browser Forum Code Signing Baseline Requirements krävt att privata nycklar för offentligt betrodda kodsigneringscertifikat genereras och lagras på FIPS 140-2 Level 2 (eller motsvarande Common Criteria EAL 4+) hårdvara, såsom en HSM eller en hårdvarutoken, just så att en nyckel inte kan exporteras eller kopieras från den enhet som skyddar den.
• Föredra EV-kodsigneringscertifikat för inlämningar i kernelläge. Microsofts nuvarande instrumentpanel för Hardware Dev Center kräver ett EV-certifikat (eller, som en alternativ sökväg, ett registrerat Authenticode-certifikat) för att skicka binärfiler för attesteringssignering eller WHCP-certifiering, vilket höjer ribban för identitetsverifiering för vem som kan skicka in en drivrutin från första början.
• Lägg till RFC 3161-tidsstämpling till varje signatur Så en signatur förblir verifierbar, och varje återkallelse efter signering ogiltigförklarar fortfarande bedrägligt utfärdad kod, även efter att själva signeringscertifikatet har löpt ut.
• Använd Windows Defender Application Control (WDAC) eller en lista över tillåtna drivrutiner utöver signaturkontroller, så en giltig Microsoft-signatur är nödvändig men inte automatiskt tillräcklig för att köras i din miljö.

Vilka är nackdelarna med prestanda och interoperabilitet med strängare policyer för förarsignering?

Att skärpa kontrollerna för drivrutinssignering och kodsignering är inte gratis, och säkerhetsteam bör planera för dessa avvägningar snarare än att upptäcka dem efter utrullningen:

• HSM-baserad signering lägger till latens i releasepipelinen. Varje signeringsåtgärd blir ett nätverks- eller hårdvaruanrop istället för en lokal filåtgärd, vilket kan lägga till sekunder per build i en CI/CD-pipeline som signerar många artefakter per dag; batch- och cachlagring av signeringssessioner minskar det mesta av detta.
• WDAC och strikt tillåtelselistning ökar supportkostnaderna. Legitima men olistade drivrutiner, vanliga med nischhårdvara eller äldre kringutrustning, kommer att blockeras tills de uttryckligen godkänns, vilket flyttar det verkliga arbetet över till IT- och helpdesk-team under utrullningen.
• Utfärdandet av elcertifikat är långsammare och mer dokumenttungt än standardutfärdande av kodsigneringscertifikat, eftersom det kräver granskning av organisationsidentitet, vilket kan försena en tidslinje för inlämning av drivrutiner med dagar om det begärs i sista minuten.
• Striktare övervakning av förändringar i trust-store kan generera falska positiva resultat från legitim företagsprogramvara, som VPN-klienter eller endpoint-agenter, som också installerar rot- eller mellanliggande certifikat av giltiga skäl, så det är viktigt att fastställa vad som är normalt i din miljö innan du tillämpar blockeringsregler.

Inga av dessa avvägningar talar emot kontrollerna. De argumenterar för att införa dem med en övervakningsfas först innan man går över till verkställighet, så att driftskostnaden är synlig och hanterbar snarare än ett oväntat avbrott.

Vilka är nyckelhanteringsberoendena för att skydda kodsigneringsnycklar?

Netfilters specifika felläge involverade inte en stulen nyckel, men den bredare klassen av kodsigneringsincidenter, inklusive MSI-fallet som refereras till ovan, gör det oftast. Ett kodsigneringsprograms nyckelhanteringsställning är ett beroende som resten av förtroendemodellen vilar på:

• Förvaring av hårdvara. Signeringsnycklar bör genereras inuti, och aldrig exporteras från, en FIPS 140-validerad HSM. En nyckel som endast existerar som ett exportmål är en nyckel som så småningom kan lämna byggnaden, vilket Encryption Consulting tar upp i sin guide till exponering av privat nyckel.
• Rollseparation och dubbel kontroll. Ingen enskild ingenjör ska kunna både begära och godkänna en signeringsoperation för produktionsbunden kod; nyckelceremonier för rot- eller värdefulla signeringsnycklar ska kräva flera auktoriserade deltagare.
• Åtkomstloggning kopplad till identitet, inte delade autentiseringsuppgifter. Varje signeringsåtgärd bör kunna hänföras till en specifik autentiserad användare eller automatiserad pipeline-identitet, så att en avvikande signeringsbegäran kan spåras.
• Omfattande, kortlivade signeringscertifikat för CI/CD-pipelines. En pipeline-identitet som kan signera vad som helst, på obestämd tid, har en större explosionsradie än en som är begränsad till en specifik artefakttyp och uppdateras enligt ett definierat schema.
• En dokumenterad återkallelse- och rotationsplan. Om en signeringsnyckel eller ett partnerkonto någonsin misstänks vara komprometterat eller missbrukat behöver organisationen en testad väg för att snabbt återkalla, rotera och omsignera berörda artefakter, inte en som utformats under press under en incident.

Hur härdar man en kodsigneringspipeline mot den här typen av attack?

Använd detta som en fungerande checklista för att granska eller bygga ett kodsigneringsprogram eller drivrutinssigneringsprogram:

1. Inventera alla signeringsnycklar, certifikat och partnerkonton som för närvarande är auktoriserade att skapa betrodda signaturer i din miljö, inklusive tredjeparts byggpipelines.
2. Flytta alla signeringsnycklar som fortfarande är lagrade i programvara, en byggserver eller en utvecklararbetsstation till en HSM och inaktivera exportfunktionen på den nya hårdvarubaserade nyckeln.
3. Kräv EV-validering, eller ett motsvarande verifierat identitetscertifikat, för alla konton som är behöriga att skicka drivrutiner i kernelläge eller på systemnivå.
4. Lägg till obligatoriskt godkännande med dubbel kontroll för signeringsåtgärder kopplade till kernelläge, firmware eller andra kodvägar med hög behörighet.
5. Aktivera tidsstämpling på varje signatur så att återkallelsen förblir giltig även efter att certifikatet har löpt ut.
6. Distribuera WDAC eller en motsvarande godkännandelista så att en giltig signatur är ett nödvändigt, inte tillräckligt, villkor för att köras i din miljö.
7. Lägg till kontinuerlig övervakning för oväntade ändringar i det betrodda rotcertifikatarkivet över slutpunkter.
8. Kör en testad spelbok för återkallelse och omsignering minst en gång per år, så att teamet inte utformar den processen för första gången under en live-incident.

Hur ser verkliga, härdade implementeringar ut?

Tre distributionsmönster täcker de flesta organisationer som producerar signerad kod, drivrutiner eller firmware:

• Leverantör av företagsprogramvara, CI/CD-integrerad signering. Byggpipelinen begär en signatur från en HSM-baserad signeringstjänst via ett autentiserat API-anrop, begränsat till en specifik byggidentitet och artefakttyp, med varje begäran loggad och varje signatur tidsstämplad, så att en komprometterad byggagent inte kan signera godtyckliga framtida versioner.
• Hårdvaru- eller drivrutinsleverantör, inlämning i WHCP-stil. Drivrutinsbinärfiler signeras internt med en HSM-skyddad nyckel innan de skickas in, inlämningskonton kräver EV-validerad identitet och godkännande från flera personer för kernellägesversioner, och övervakning efter signering övervakar alla drivrutiner som signerats under organisationens identitet och som inte var en del av en godkänd version.
• Reglerat företag, intern ansökningssignering. Interna applikationer signeras via en centraliserad tjänst med rollbaserad åtkomst, dubbel kontroll för alla signeringsomfång som är bredare än ett enda program och automatiska aviseringar om ett nytt rot- eller mellancertifikat visas i en slutpunkts förtroendearkiv utanför ett ändringsfönster.

Attackvektor, försvar och den EC-tjänst som hanterar den

Attack vektor	Försvar	Relaterad EC-tjänst
Missbrukat eller okontrollerat konto för drivrutin/kodsignering	EV-validerad partneridentitet, godkännande av dubbel kontroll före signering	CodeSign Secure
Signeringsnyckeln lagras i programvaran och kan exporteras	Hårdvarubaserad nyckelförvaring, ingen exportfunktion	HSM-som-en-tjänst
Oseriöst rotcertifikat tillagt i förtroendearkivet	Kontinuerlig övervakning av trust-store, slutpunktstillståndslistor (WDAC)	Krypteringsrådgivning, PKI-tjänster
Ingen insyn i vilka nycklar, algoritmer och certifikat som finns i miljön	Kontinuerlig kryptografisk upptäckt och inventering	CBOM-säkerhet
Långsam eller improviserad återkallelse efter misstänkt kompromettering	Testad spelbok för återkallelse, rotation och omsignering	PKI-tjänster, krypteringsrådgivning

Begränsningar

Flera detaljer om Netfilter-incidenten offentliggjordes aldrig helt. Microsoft avslöjade inte den exakta interna processluckan som tillät inlämningen att certifieras, och de namngav inte tredjepartsinlämningen utöver att bekräfta att kontot var avstängt. G Datas ursprungliga tekniska rapport dokumenterade omdirigerings-, proxy- och rotcertifikatbeteendet i detalj, men publicerade inte självt ett bekräftat fynd av aktiv SSL/TLS-avlyssning i det fria. Den specifika karakteriseringen kan spåras tillbaka till kommentarer från en oberoende reverse engineer vid den tiden, inte en formell, bekräftad teknisk rapport. En tidigare version av minst en samtida rapport namngav också ett specifikt inlämnande företag som ett "kommunistiskt kinesiskt militärt" företag enligt en lista från det amerikanska försvarsdepartementet. BleepingComputer rapporterade senare att de inte kunde verifiera det företaget på den relevanta försvarsdepartementets lista, och påståendet drogs tillbaka från den källa det kom ifrån. Denna artikel behandlar den specifika tillskrivningen som obekräftad.

Vad skulle krypteringskonsulter rekommendera?

Behandla den här incidenten som en processläxa, inte en kryptografiläxa. Lösningen för ett Netfilter-liknande fel är inte en starkare algoritm; RSA- och ECDSA-signering har aldrig brutits här. Lösningen är att täppa till luckorna kring vem som kan begära en signatur, vilken hårdvara som skyddar nyckeln som producerar den och hur snabbt du kan återkalla och signera på nytt om något ändå kommer igenom. I praktiken innebär det att flytta varje kodsignerings- och drivrutinssigneringsnycklar till HSM-baserad förvaring med HSM-as-a-Service , tillämpa identitetsverifierade signeringsarbetsflöden med dubbel kontroll med CodeSign Secure och upprätthålla en live-inventering av varje nyckel, certifikat och algoritm som används i din miljö med CBOM Secure , så att en oväntad förändring av signeringskonto, certifikat eller algoritm dyker upp omedelbart istället för under ett offentligt avslöjande. Prata med vårt rådgivande team för kodsignering för att granska din nuvarande signeringspipeline mot denna checklista.

Slutsats

Netfilter var ett verkligt, väldokumenterat misslyckande: Microsoft signerade ett rootkit, och det rootkitet planterade ett falskt, betrott rotcertifikat som kunde möjliggöra TLS-avlyssning på omdirigerad trafik. Baserat på verifierade offentliga register var det inte ett demonstrerat massdekrypteringsvapen mot all krypterad kommunikation. Microsofts egen redogörelse för händelsen pekar på den faktiska bristen: en certifieringsprocess som verifierade stabilitet, inte avsikt, och ett inlämningskonto som borde ha granskats mer innan det någonsin nådde signeringspipelinen. Varje organisation som förlitar sig på kodsignering, för drivrutiner, firmware eller programvaruversioner, bör läsa detta som en påminnelse om att en giltig signatur bara är så pålitlig som processen och nyckelhanteringen bakom den.

Vanliga frågor om partihandel med mat och dryck

Dekrypterade Netfilter-rootkit faktiskt all krypterad trafik över hela internet?
Nej. Verifierad rapportering från G Data, BleepingComputer och Ars Technica beskriver hur Netfilter omdirigerar specifik nätverkstrafik och installerar ett otillåtet rotcertifikat, en mekanism som kan möjliggöra avlyssning av omdirigerad TLS-trafik. Ingen offentlig rapport dokumenterar en påvisad förmåga att dekryptera all krypterad kommunikation över internet.

Blev Microsofts kodsigneringsinfrastruktur hackad?
Microsoft uppgav att de inte funnit några bevis för att deras signeringscertifikat eller signeringsinfrastruktur för Windows Hardware Compatibility Program (WHCP) hade komprometterats. Den skadliga drivrutinen nådde signeringen via ett legitimt, men missbrukat, partnerkonto.

Varför är en kernellägesdrivrutin farligare än vanlig skadlig kod?
En kärnlägesdrivrutin körs på samma behörighetsnivå som kärndelar av operativsystemet, vilket ger den möjlighet att fånga upp trafik, modifiera förtroendelager och dölja sin egen närvaro från standarddetekteringsverktyg, vilket är det som gör ett signerat rootkit som Netfilter särskilt svårt att upptäcka.

Fick den här incidenten en CVE?
Nej. En CVE tilldelas en specifik sårbarhet i programvara. Netfilter utnyttjade en lucka i Microsofts process för drivrutinsinlämning och granskning snarare än en brist i Windows-kod, så ingen CVE-identifierare gäller för incidenten.

Hur låter ett oseriöst rotcertifikat en angripare avlyssna HTTPS-trafik?
Operativsystem och webbläsare litar på en TLS-anslutning när serverns certifikat är kopplat till en certifikatutfärdare som redan finns i enhetens förtroendearkiv. Om skadlig kod lägger till sin egen, okontrollerade certifikatutfärdare i det arkivet kan den utfärda certifikat för vilken domän som helst som enheten accepterar som giltig, vilket möjliggör en man-in-the-middle-attack mot trafik som faktiskt dirigeras genom angriparens infrastruktur.

Referensprojekt

• G Data: Microsoft signerade ett skadligt Netfilter-rootkit
• BleepingComputer: Microsoft erkänner att de signerat rootkit-skadlig programvara i leveranskedjefiasko
• Ars Technica: Microsoft signerar digitalt skadlig rootkit-drivrutin
• Hackernyheterna: Hackare lurar Microsoft att signera Netfilter rootkit-skadlig programvara
• Microsoft Learn: Krav på kodsignering av drivrutiner
• DigiCert: Nytt krav på lagring av privata nycklar för kodsigneringscertifikat