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.

Przykładowe certyfikaty DigiCert w magazynie Trusted Root Certification Authorities

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ą:

HKLM:\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\

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.

Komunikat Microsoft Defender o akcji podjętej na detekcję Trojan:Win32/Cerdigent.A!dha
Źródło: Microsoft

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.