Autor: Wojciech Ciemski

Wprowadzenie do problemu / definicja

Na początku maja 2026 roku część środowisk Windows zaczęła rejestrować fałszywe alarmy generowane przez Microsoft Defender. Legalne certyfikaty DigiCert były klasyfikowane jako zagrożenie o nazwie Trojan:Win32/Cerdigent.A!dha, mimo że nie stanowiły złośliwego oprogramowania. Problem miał istotne znaczenie operacyjne, ponieważ w części przypadków nie kończył się na samym alercie, lecz prowadził także do usuwania wpisów certyfikatów z magazynu zaufania systemu Windows.

To klasyczny przykład false positive, który w środowisku firmowym może wywołać skutki wykraczające poza sam szum alertowy. Jeśli narzędzie ochronne błędnie ingeruje w łańcuch zaufania PKI, konsekwencją mogą być problemy z walidacją podpisów cyfrowych, działaniem aplikacji i komunikacją z usługami wykorzystującymi certyfikaty.

W skrócie

• Microsoft Defender błędnie oznaczał wybrane certyfikaty root DigiCert jako malware.
• Problem został szeroko zauważony 3 maja 2026 roku, po wcześniejszej aktualizacji sygnatur pod koniec kwietnia.
• W części systemów wpisy certyfikatów były usuwane z magazynu AuthRoot w Windows.
• Microsoft skorygował detekcję w aktualizacji Security Intelligence 1.449.430.0 i nowszych.
• Dostępne informacje wskazują, że poprawka mogła również przywracać wcześniej usunięte certyfikaty.
• Incydent był powiązany czasowo z wcześniejszym naruszeniem po stronie DigiCert, ale błędnie oflagowane obiekty nie odpowiadały bezpośrednio cofniętym certyfikatom code-signing.

Kontekst / historia

Tłem zdarzenia był wcześniej ujawniony incydent bezpieczeństwa po stronie DigiCert. Z opublikowanych informacji wynikało, że napastnicy uzyskali dostęp do ograniczonego zestawu danych inicjalizacyjnych związanych z zatwierdzonymi, ale jeszcze niedostarczonymi zamówieniami na certyfikaty EV Code Signing. W praktyce umożliwiło to wygenerowanie ważnych certyfikatów, które następnie wykorzystano do podpisywania złośliwego oprogramowania.

Według opisu incydentu wektor wejścia obejmował socjotechnikę skierowaną do pracownika wsparcia technicznego. Atakujący mieli wykorzystać złośliwe archiwum podszywające się pod zrzut ekranu, a po kompromitacji uzyskać dostęp do środowiska wsparcia i funkcji pozwalających podglądać konta klientów z ich perspektywy. To właśnie tam miały znajdować się dane umożliwiające uzyskanie części certyfikatów.

W reakcji na ten kontekst Microsoft wdrożył mechanizmy detekcyjne mające chronić klientów przed skutkami nadużywanych certyfikatów. Problem polegał jednak na tym, że logika wykrywania objęła również legalne certyfikaty root obecne w systemowym łańcuchu zaufania. W efekcie działania ochronne okazały się zbyt szerokie i doprowadziły do false positive o realnym wpływie operacyjnym.

Analiza techniczna

Incydent nie dotyczył klasycznej infekcji malware, lecz błędnej klasyfikacji elementów infrastruktury PKI. Microsoft Defender przypisywał legalnym certyfikatom nazwę detekcji Trojan:Win32/Cerdigent.A!dha, przez co system traktował składniki zaufanego łańcucha certyfikacji jak obiekty złośliwe.

Kluczowe znaczenie ma rozróżnienie między certyfikatami root a certyfikatami code-signing. Certyfikat root pełni funkcję punktu zaufania dla walidacji całego łańcucha certyfikatów i znajduje się w magazynie zaufanych głównych urzędów certyfikacji. Z kolei certyfikat code-signing służy do podpisywania plików wykonywalnych i potwierdzania ich pochodzenia. Dostępne dane wskazują, że błędnie oznaczone zostały wpisy root DigiCert w magazynie AuthRoot, a nie same cofnięte certyfikaty używane do podpisywania kodu.

Na dotkniętych systemach wpisy miały być usuwane z lokalizacji rejestru odpowiadającej magazynowi zaufania systemowego. Taka zmiana może bezpośrednio wpływać na walidację łańcuchów certyfikatów, podpisów cyfrowych, połączeń TLS oraz procesów zależnych od zaufanych urzędów certyfikacji. W środowiskach korporacyjnych może to oznaczać błędy przy uruchamianiu oprogramowania, problemach z weryfikacją podpisów, instalacją agentów czy komunikacją z zewnętrznymi usługami.

Microsoft poinformował, że problem wynikał z detekcji związanych z kompromitacją certyfikatów po incydencie dotyczącym DigiCert. Producent skorygował logikę alertowania i wskazał, że środowiska powinny korzystać z wersji sygnatur Security Intelligence 1.449.430.0 lub nowszej. Z opublikowanych informacji wynika również, że aktualizacja mogła nie tylko zatrzymać dalsze false positive, ale także odtworzyć wcześniej usunięte certyfikaty.

Konsekwencje / ryzyko

Najbardziej oczywistą konsekwencją był wzrost szumu operacyjnego. Alert wskazujący na trojana w obszarze certyfikatów mógł sugerować pełną kompromitację hosta, co prowadziło do niepotrzebnych eskalacji, czasochłonnych analiz, a w skrajnych przypadkach nawet do ponownej instalacji systemów.

Drugim poziomem ryzyka były skutki techniczne wynikające z ingerencji w magazyn zaufania. Nawet jeśli false positive nie oznaczało realnej infekcji, usunięcie certyfikatu root mogło powodować awarie procesów zależnych od PKI. W organizacjach o wysokim stopniu automatyzacji taki efekt uboczny może przełożyć się na problemy z dostępnością usług, błędy zgodności i przerwy w działaniu aplikacji.

Trzecim obszarem ryzyka pozostaje zaufanie do mechanizmów detekcyjnych. Gdy system EDR lub antywirus błędnie klasyfikuje krytyczne elementy łańcucha zaufania, zespoły bezpieczeństwa muszą równoważyć szybkie reagowanie z minimalizacją szkód wynikających z automatycznej remediacji. Ten incydent pokazuje, że nawet uzasadniona reakcja na realne nadużycia certyfikatów może generować wtórne ryzyko, jeśli klasyfikacja nie jest dostatecznie precyzyjna.

Rekomendacje

W pierwszej kolejności organizacje powinny upewnić się, że Microsoft Defender korzysta z aktualnych sygnatur Security Intelligence w wersji 1.449.430.0 lub nowszej. W środowiskach zarządzanych centralnie warto potwierdzić rzeczywistą wersję sygnatur na stacjach roboczych i serwerach, zamiast polegać wyłącznie na deklarowanym stanie w konsoli zarządzającej.

Kolejnym krokiem powinna być kontrola integralności magazynu certyfikatów systemowych. Zespoły administracyjne powinny zweryfikować, czy w magazynie AuthRoot nie brakuje oczekiwanych wpisów oraz czy aplikacje biznesowe nie zgłaszają błędów walidacji certyfikatów lub podpisów cyfrowych. W środowiskach krytycznych warto porównać stan magazynu z hostem referencyjnym albo wzorcem konfiguracyjnym.

Ważna jest także rewizja polityk automatycznej remediacji. Jeżeli rozwiązania ochronne mają możliwość automatycznego usuwania obiektów związanych z zaufaniem systemowym, należy rozważyć dodatkowe zabezpieczenia proceduralne. Dotyczy to zwłaszcza działań obejmujących magazyny certyfikatów, komponenty PKI oraz kluczowe elementy systemu operacyjnego.

Dobrym rozwiązaniem jest również przygotowanie playbooka na wypadek false positive dotyczącego infrastruktury zaufania. Taki scenariusz powinien obejmować:

• weryfikację wersji sygnatur i zakresu alertów,
• ustalenie, które obiekty zostały usunięte lub zmodyfikowane,
• ocenę wpływu na procesy biznesowe i aplikacje,
• odtworzenie magazynu certyfikatów, jeśli to konieczne,
• komunikację do użytkowników końcowych w celu ograniczenia niepotrzebnych działań naprawczych.

Na poziomie strategicznym incydent potwierdza potrzebę ścisłego monitorowania zależności pomiędzy naruszeniami po stronie dostawców usług zaufania, kampaniami malware i reakcjami dostawców zabezpieczeń. Gdy dochodzi do kompromitacji certyfikatów code-signing, organizacje powinny zakładać możliwość zarówno realnych nadużyć, jak i zakłóceń wynikających z nadmiernie agresywnych mechanizmów ochronnych.

Podsumowanie

Fałszywe alarmy Microsoft Defendera dotyczące certyfikatów DigiCert pokazują, jak wrażliwym obszarem pozostaje automatyczna ochrona wokół PKI i łańcucha zaufania. Nie był to klasyczny przypadek infekcji endpointów, lecz błąd detekcyjny o istotnych skutkach operacyjnych. Bezpośrednim problemem okazało się błędne oznaczanie legalnych certyfikatów root i ich usuwanie z magazynu zaufania Windows.

Choć źródłowym kontekstem była wcześniejsza kompromitacja danych użytych do uzyskania części certyfikatów code-signing, zakres false positive wyraźnie wykraczał poza rzeczywiście cofnięte certyfikaty. Dla zespołów bezpieczeństwa najważniejsza lekcja jest jasna: incydenty związane z certyfikatami wymagają jednocześnie szybkiej reakcji i bardzo precyzyjnej walidacji technicznej, aby narzędzia ochronne same nie stały się źródłem dodatkowego ryzyka.

Źródła

1. BleepingComputer — Microsoft Defender wrongly flags DigiCert certs as Trojan:Win32/Cerdigent.A!dha — https://www.bleepingcomputer.com/news/security/microsoft-defender-wrongly-flags-digicert-certs-as-trojan-win32-cerdigentadha/
2. Microsoft Security Intelligence — Change logs for security intelligence update version 1.449.430.0 — https://www.microsoft.com/en-us/wdsi/definitions/antimalware-definition-release-notes?requestVersion=1.449.430.0
3. DigiCert Knowledge Base — Code Signing Certificate FAQs — https://knowledge.digicert.com/general-information/code-signing-certificate-faqs
4. DigiCert Docs — Download a code signing certificate — https://docs.digicert.com/en/certcentral/manage-certificates/code-signing-certificates/download-a-code-signing-certificate.html
5. DigiCert Knowledge Base — Set Up Your DigiCert Provided eToken — https://knowledge.digicert.com/solution/set-up-your-digicert-provided-etoken