False positive w Microsoft Defender usuwa certyfikaty root DigiCert.

[Muchomorek]

Aktualizacja definicji Microsoft Defender z 30 kwietnia wprowadziła niemałe zamieszanie w systemach wielu organizacji. W wyniku błędu legalne certyfikaty firmy DigiCert zostały oznaczone jako złośliwe oprogramowanie, co w niektórych przypadkach doprowadziło do ich automatycznego usunięcia z systemu.

Tak poważny false positive stanowi realny problem, ponieważ uderza w fundamenty mechanizmów PKI, na których opiera się zaufanie do komunikacji, aplikacji i usług w każdym środowisku informatycznym.
Analiza problemu

DigiCert jest jednym z największych i najbardziej zaufanych urzędów certyfikacji (CA – Certificate Authority), którego certyfikaty domyślnie znajdują się w systemowych magazynach certyfikatów. Tym samym system operacyjny traktuje elementy podpisane certyfikatami wystawionymi przez DigiCert jako wiarygodne.

Błędna aktualizacja definicji Microsoft Defender wprowadziła detekcję o nazwie ,,Trojan:Win32/Cerdigent.A!dha", w wyniku której wpisy rejestru odpowiadające głównym certyfikatom DigiCert zostały niepoprawnie oznaczone jako zagrożenie. Mowa konkretnie o dwóch certyfikatach: DigiCert Trusted Root G4 oraz DigiCert Assured ID Root CA. Oba należą do kategorii root CA, czyli znajdują się na samym początku łańcucha zaufania i są przechowywane bezpośrednio w systemowym magazynie certyfikatów Windows. W praktyce oznacza to, że każdy certyfikat wydany przez DigiCert, który dziedziczy zaufanie z tych rootów, jest automatycznie uznawany za wiarygodny.

W systemach Windows wpisy te znajdują się w rejestrze pod ścieżką

Każdy certyfikat identyfikowany jest tam poprzez tzw. odcisk palca, czyli skrót kryptograficzny będący jego unikalnym identyfikatorem. W omawianym przypadku chodziło o:

    DigiCert Trusted Root G4
    Thumbprint: DDFB16CD4931C973A2037D3FC83A4D7D775D05E4
    DigiCert Assured ID Root CA
    Thumbprint: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43

Microsoft Defender objął te obiekty kwarantanną, co oznaczało ich usunięcie z magazynu zaufanych certyfikatów. Prowadziło to do poważnego ryzyka operacyjnego. Brak certyfikatów root w systemie uniemożliwia poprawną weryfikację połączeń SSL/TLS, co może skutkować błędami HTTPS, ostrzeżeniami w przeglądarkach oraz problemami z działaniem aplikacji. Dodatkowo zaburzona zostaje weryfikacja podpisów cyfrowych, co wpływa na możliwość uruchamiania legalnego oprogramowania. Usunięcie takich wpisów to w praktyce ,,odcięcie" całej gałęzi zaufania powiązanej z danym urzędem certyfikacji. Efekt jest prosty – wszystkie certyfikaty opierające się na tych rootach przestają być uznawane za wiarygodne.

Szczególnie narażone były organizacje korzystające z aplikacji podpisanych certyfikatami DigiCert lub opierające swoją infrastrukturę na usługach HTTPS opartych na tych certyfikatach.

Microsoft stosunkowo szybko zidentyfikował problem i opublikował poprawioną wersję definicji, jednak w wielu środowiskach skutki błędnej aktualizacji były już odczuwalne. Warto przy tym pamiętać, że nawet zaawansowane rozwiązania bezpieczeństwa, takie jak Microsoft Defender, nie są wolne od podatności i błędów. Niedawno pisaliśmy o aktywnie wykorzystywanych lukach w tym systemie bezpieczeństwa.
O incydencie bezpieczeństwa w DigiCert

Na odbiór całej sytuacji istotny wpływ miał również niedawny incydent bezpieczeństwa związany z firmą DigiCert, ujawniony na początku kwietnia 2026 roku.

Całość zaczęła się dość klasycznie, od phishingu wymierzonego w pracownika zespołu wsparcia. W wyniku ataku doszło do kompromitacji systemów, co pozwoliło atakującym uzyskać dostęp do ograniczonej liczby kodów inicjalizacyjnych wykorzystywanych w procesie wydawania certyfikatów typu code-signing. Dysponując takimi danymi, możliwe było wygenerowanie w pełni legalnych certyfikatów, które następnie zostały wykorzystane do podpisywania złośliwego oprogramowania. DigiCert poinformował o unieważnieniu łącznie 60 certyfikatów, z których część została powiązana z kampanią malware określaną jako Zhong Stealer. Sama kampania nie była szczególnie wyszukana i opierała się na znanych schematach, takich jak phishing, uruchomienie droppera i pobranie właściwego payloadu z zewnętrznych źródeł. Kluczową rolę odegrało jednak wykorzystanie prawidłowo podpisanych plików, które znacząco utrudniały ich wykrycie i zwiększały wiarygodność w oczach systemów oraz użytkowników.

Warto jednak podkreślić, że incydent ten nie był bezpośrednio powiązany z problemem Microsoft Defender. Certyfikaty oznaczone przez Defender jako złośliwe były certyfikatami root znajdującymi się w systemowym magazynie zaufania Windows i nie odpowiadały przejętym certyfikatom code-signing wykorzystanym w kampaniach malware.

Z perspektywy użytkowników i administratorów oba zdarzenia mogły jednak wyglądać bardzo podobnie, co dodatkowo utrudniało ocenę sytuacji, zwłaszcza że oba dotyczyły certyfikatów tej samej organizacji i pojawiły się w krótkim odstępie czasu.
Podsumowanie

Incydent ten dobrze pokazuje, że nawet narzędzia, którym ufamy najbardziej, mogą stać się źródłem problemów i wprowadzić sporo zamieszania w środowisku. Automatyczne systemy bezpieczeństwa są dziś niezbędne, jednak jak widać, nie zawsze działają tak, jak byśmy tego oczekiwali. W tym przypadku nie chodziło o zwykły false positive, lecz o ingerencję w jeden z kluczowych elementów każdego środowiska. Usunięcie certyfikatów root może generować szereg problemów – od HTTPS, przez weryfikację podpisów, aż po działanie aplikacji. Z perspektywy administratora to wyraźny sygnał, by aktualizacje w systemach bezpieczeństwa traktować z większą uwagą. Jak widać, nawet automatyczne aktualizacje definicji z zaufanych źródeł mogą wpływać na środowisko w nieoczekiwany sposób. Warto mieć nad tym kontrolę, rozumieć, co dokładnie dzieje się w tle i stosować bardziej świadome podejście do aktualizacji sygnatur oraz definicji w systemach bezpieczeństwa.


żródło Nie masz uprawnień do wyświetlania linków. Zarejestruj się lub Zaloguj

You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.
You cannot view this attachment.