Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Incydent związany z DigiCert pokazuje, że bezpieczeństwo procesu wydawania certyfikatów podpisu kodu jest równie istotne jak ochrona samych kluczy prywatnych. W tym przypadku atakujący nie przejęli bezpośrednio centralnej infrastruktury urzędu certyfikacji, lecz wykorzystali pośredni dostęp uzyskany po kompromitacji środowiska wsparcia technicznego.
Skutkiem było nieuprawnione pozyskanie certyfikatów EV Code Signing, które mogły następnie zostać użyte do podpisywania złośliwego oprogramowania. Taki scenariusz stanowi poważne zagrożenie dla łańcucha zaufania, ponieważ poprawny podpis cyfrowy bywa przez użytkowników i systemy ochronne traktowany jako sygnał wiarygodności pliku.
W skrócie
- Atakujący podszył się pod klienta i dostarczył złośliwy plik przez kanał wsparcia.
- Kompromitacji uległy dwa stanowiska analityków obsługi.
- Napastnik uzyskał dostęp do kodów inicjalizacyjnych powiązanych z zatwierdzonymi zamówieniami EV Code Signing.
- DigiCert unieważnił 60 certyfikatów, z czego 27 bezpośrednio powiązano z aktywnością sprawcy.
- Część certyfikatów miała zostać wykorzystana do podpisywania malware z rodziny Zhong Stealer.
Kontekst / historia
Do incydentu doszło na początku kwietnia 2026 roku. Atak rozpoczął się 2 kwietnia, gdy cyberprzestępca podszył się pod klienta i przesłał przez czat wsparcia archiwum ZIP, które miało wyglądać jak zwykły zrzut ekranu. W rzeczywistości paczka zawierała plik wykonywalny z ładunkiem malware.
Część prób dostarczenia złośliwego pliku została zablokowana przez zabezpieczenia, jednak jedna z nich zakończyła się infekcją stacji roboczej analityka. Początkowo uznano, że sytuacja została opanowana, lecz późniejsza analiza wykazała, że kolejny endpoint również został naruszony dzień później. Opóźnienie w pełnym wykryciu zdarzenia miało wynikać z nieprawidłowego działania ochrony na jednym z urządzeń.
W toku śledztwa ustalono, że napastnik wykorzystał dostęp do wewnętrznego portalu wsparcia, aby uzyskać dane pozwalające na pobranie wystawionych już certyfikatów. To przesunęło ciężar incydentu z klasycznego włamania do systemów CA na nadużycie funkcji operacyjnych i pomocniczych.
Analiza techniczna
Technicznie nie był to klasyczny atak na główny system urzędu certyfikacji, ale wykorzystanie funkcji pomocniczej dostępnej dla uwierzytelnionych pracowników supportu. Portal wsparcia umożliwiał analitykom wejście do kont klientów w ograniczonym trybie podglądu, co miało służyć realizacji zgłoszeń serwisowych.
Choć zakres tego dostępu nie obejmował zarządzania kontami, użytkownikami, kluczami API czy zamówieniami, nadal pozwalał na wgląd w kody inicjalizacyjne dla oczekujących zamówień na certyfikaty EV Code Signing. Ten element okazał się krytyczny, ponieważ w przypadku zatwierdzonego zamówienia sam kod inicjalizacyjny umożliwiał uzyskanie finalnego certyfikatu.
Napastnik, działając z przejętych stacji roboczych analityków, zebrał takie kody dla ograniczonej liczby zamówień i wykorzystał je do pobrania certyfikatów z różnych kont klientów oraz z kilku jednostek certyfikujących funkcjonujących w ekosystemie DigiCert. Łącznie cofnięto 60 certyfikatów. Spośród nich 27 zostało jednoznacznie przypisanych aktywności atakującego, a kolejne 33 unieważniono prewencyjnie ze względu na brak pełnej pewności co do integralności procesu pobrania.
Po incydencie wdrożono dodatkowe zabezpieczenia, obejmujące silniejsze uwierzytelnianie dla procesów administracyjnych, zablokowanie dostępu do kodów inicjalizacyjnych z poziomu sesji proxy używanych przez wsparcie, ograniczenie typów plików dopuszczanych w czacie i załącznikach oraz poprawę logowania zdarzeń.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją incydentu jest osłabienie zaufania do mechanizmu podpisu kodu. Certyfikat EV Code Signing może zwiększać wiarygodność binariów w oczach systemów operacyjnych, narzędzi bezpieczeństwa i użytkowników końcowych. Jeśli jednak zostanie użyty do podpisania malware, złośliwy plik może skuteczniej omijać mechanizmy reputacyjne i wzbudzać mniejsze podejrzenia.
Ryzyko dotyczy kilku grup jednocześnie. Zagrożone są organizacje, których certyfikaty mogły zostać pobrane bez autoryzacji, odbiorcy oprogramowania ufający ważnemu podpisowi cyfrowemu oraz sami dostawcy usług zaufania, dla których nawet ograniczone nadużycie procesu wydania certyfikatu oznacza konsekwencje reputacyjne, operacyjne i audytowe.
Incydent uwidacznia także problem architektury bezpieczeństwa: procesy pomocnicze wokół wydawania certyfikatów stają się atrakcyjnym celem ataków, jeśli mają dostęp do danych pozwalających dokończyć krytyczne operacje. To właśnie takie elementy często okazują się słabszym ogniwem całego modelu zaufania.
Rekomendacje
Organizacje korzystające z certyfikatów podpisu kodu powinny pilnie przeprowadzić przegląd aktywnych certyfikatów, historii ich użycia i logów związanych z procesem wydawania. Należy zweryfikować, czy nie doszło do pobrania certyfikatów z nietypowych adresów IP, poza standardowym procesem operacyjnym lub w nieoczekiwanym oknie czasowym.
Z perspektywy dostawców usług zaufania kluczowe jest stosowanie zasady najmniejszych uprawnień w narzędziach wsparcia technicznego. Funkcje proxy do kont klientów nie powinny ujawniać danych, które same w sobie pozwalają sfinalizować wydanie certyfikatu. Krytyczne sekrety, kody aktywacyjne i elementy finalizacji procesu powinny być ściśle odseparowane od środowisk supportowych.
W obszarze ochrony endpointów konieczne jest pełne objęcie stacji roboczych monitoringiem EDR lub XDR, kontrola poprawności działania agentów ochronnych oraz automatyczne alarmowanie o utracie telemetrii. Samo wdrożenie rozwiązania bezpieczeństwa nie gwarantuje skuteczności, jeśli jego działanie nie jest stale weryfikowane.
Warto również ograniczyć możliwość przesyłania archiwów i plików wykonywalnych przez kanały wsparcia, stosować izolację załączników, bezpieczne środowiska podglądu oraz dodatkowe mechanizmy wykrywania socjotechniki wymierzonej w helpdesk i support. Zespoły wsparcia regularnie pracują na plikach przesyłanych przez klientów, dlatego są szczególnie narażone na ataki oparte na zaufanej relacji.
Po stronie odbiorców oprogramowania i zespołów SOC podpis cyfrowy powinien być traktowany jako jeden z atrybutów zaufania, a nie ostateczny dowód bezpieczeństwa. Konieczne są korelacja z telemetrią zagrożeń, sprawdzanie statusu unieważnienia certyfikatów oraz szybka reakcja na pojawienie się nowych wskaźników kompromitacji.
Podsumowanie
Incydent DigiCert jest ważnym przykładem ataku na procesy okołocertyfikacyjne, a nie bezpośrednio na centralną infrastrukturę PKI. Napastnik wykorzystał socjotechnikę, kompromitację endpointów i zbyt szerokie możliwości funkcji wsparcia, aby uzyskać certyfikaty EV Code Signing.
Szybkie unieważnienie 60 certyfikatów ograniczyło skalę zagrożenia, ale zdarzenie dobitnie pokazuje, że bezpieczeństwo urzędu certyfikacji zależy nie tylko od kryptografii i ochrony kluczy, lecz także od odporności narzędzi pomocniczych, jakości monitoringu stacji roboczych i ścisłej kontroli każdego etapu procesu wydania.
Źródła
- SecurityWeek – DigiCert Revokes Certificates After Support Portal Hack
https://www.securityweek.com/digicert-revokes-certificates-after-support-portal-hack/ - Mozilla Bugzilla – DigiCert: Misissued code signing certificates
https://bugzilla.mozilla.org/show_bug.cgi?id=2033170