Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Kompromitacja infrastruktury związanej z wydawaniem certyfikatów do podpisywania kodu to jeden z najpoważniejszych scenariuszy w obszarze zaufania cyfrowego. Certyfikaty code signing potwierdzają autentyczność oprogramowania i integralność plików wykonywalnych, dlatego ich przejęcie przez cyberprzestępców może umożliwić podpisywanie złośliwego kodu w sposób zwiększający jego wiarygodność oraz utrudniający wykrycie.
W opisywanym przypadku aktywność powiązano z klastrem CylindricalCanine, łączonym z podgrupą GoldenEyeDog. Incydent pokazuje, że zagrożenie nie musi wynikać bezpośrednio z przejęcia kluczy kryptograficznych — wystarczy naruszenie procesów operacyjnych i funkcji wsparcia, które pośrednio wpływają na wydawanie certyfikatów.
W skrócie
Według opublikowanych ustaleń atakujący mieli uzyskać dostęp do stacji roboczych pracowników wsparcia technicznego i wykorzystać funkcje portalu serwisowego do pozyskania danych niezbędnych do wydania certyfikatów EV Code Signing. W efekcie część certyfikatów została przejęta lub wydana bez udziału prawowitych odbiorców.
Następnie certyfikaty miały zostać użyte do podpisywania złośliwego oprogramowania, w tym wariantów łączonych z Golden Gh0st RAT i Zhong Stealer. Skala incydentu doprowadziła do odwołania dziesiątek certyfikatów i unaoczniła, jak pozornie pomocnicze funkcje wsparcia mogą stać się krytycznym elementem łańcucha ataku.
Kontekst / historia
GoldenEyeDog jest śledzony od lat i był wcześniej wiązany z kampaniami wymierzonymi w organizacje z sektorów gier, hazardu i finansów, szczególnie w regionie Azji i Pacyfiku. Grupa zasłynęła z wykorzystywania fałszywych stron, instalatorów podszywających się pod legalne aplikacje oraz wieloetapowych łańcuchów infekcji kończących się wdrożeniem trojanów zdalnego dostępu.
W poprzednich operacjach sprawcy stosowali zmodyfikowane warianty Gh0st RAT, dostarczane przez loadery i osadzane w plikach imitujących legalne oprogramowanie. Z czasem ich taktyki rozszerzyły się o działania socjotechniczne skierowane do zespołów wsparcia klienta, co wskazuje na rosnącą dojrzałość operacyjną i lepsze rozumienie procesów biznesowych ofiar.
Analiza techniczna
Atak miał rozpocząć się od kontaktu z kanałem wsparcia klienta. Napastnik przesłał archiwum ZIP podszywające się pod zrzut ekranu związany ze zgłoszeniem. W rzeczywistości plik zawierał komponent wykonywalny, którego uruchomienie doprowadziło do kompromitacji dwóch stacji roboczych analityków wsparcia.
Po uzyskaniu dostępu sprawcy wykorzystali funkcję portalu pozwalającą pracownikom supportu wejść w perspektywę klienta. Ta funkcjonalność, zaprojektowana do obsługi zgłoszeń i działań serwisowych, miała umożliwić odczyt kodów inicjalizacyjnych związanych z zatwierdzonymi, lecz jeszcze niedostarczonymi zamówieniami na certyfikaty EV Code Signing.
Połączenie takich danych z wcześniej zaakceptowanym procesem zamówienia mogło pozwolić na wydanie certyfikatu bez udziału właściciela zamówienia. W następstwie incydentu odwołano 60 certyfikatów wydanych w ramach tego ekosystemu, a część z nich została powiązana z podpisywaniem złośliwego oprogramowania.
Badacze połączyli tę aktywność z rodziną Golden Gh0st RAT. Typowy łańcuch infekcji obejmował phishing lub zgłoszenia do systemów wsparcia z plikami udającymi zrzuty ekranów. Po uruchomieniu następował etap DLL side-loading, w którym legalny plik wykonywalny ładował złośliwą bibliotekę DLL, a ofierze mógł zostać pokazany fałszywy dokument lub ekran błędu w celu odwrócenia uwagi.
Końcowy ładunek zapewniał napastnikom szeroki zestaw możliwości operacyjnych:
- utrwalanie obecności w systemie,
- kradzież danych z przeglądarek i komunikatorów,
- keylogging i wykonywanie zrzutów ekranu,
- uruchamianie poleceń powłoki,
- tunelowanie ruchu przez SOCKS proxy,
- dostarczanie dodatkowych komponentów,
- czyszczenie logów zdarzeń Windows.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem incydentu jest podważenie zaufania do mechanizmów podpisu cyfrowego. Jeśli malware zostaje podpisany ważnym certyfikatem, rośnie szansa na skuteczne dostarczenie go do środowisk korporacyjnych, a część zabezpieczeń opartych na reputacji plików lub wydawców może działać mniej efektywnie.
Incydent uwidacznia również rosnące znaczenie ataków na zespoły wsparcia klienta. Organizacje często koncentrują ochronę na administratorach, programistach i działach IT, tymczasem pracownicy supportu mają dostęp do procesów pośrednich, które mogą zostać wykorzystane do eskalacji wpływu na krytyczne usługi.
Dla klientów skutki obejmują konieczność odwołania i ponownego wydania certyfikatów, ryzyko zakłóceń w pipeline’ach wydawniczych, potrzebę przeglądu wcześniej podpisanych artefaktów oraz weryfikację, czy legalne procesy build i release nie zostały naruszone.
Rekomendacje
Organizacje obsługujące procesy wydawania certyfikatów powinny ponownie ocenić modele zagrożeń dla portali wsparcia, funkcji impersonacji oraz wszystkich mechanizmów pośredniego dostępu do danych klienta. Funkcje historycznie uznawane za pomocnicze należy traktować jak elementy krytyczne z perspektywy bezpieczeństwa.
Kluczowe działania ochronne obejmują:
- wdrożenie zasady minimalnych uprawnień,
- segmentację funkcjonalną między supportem a procesem wydania certyfikatu,
- maskowanie kodów inicjalizacyjnych, tokenów i innych wrażliwych danych,
- silny audyt dostępu do zamówień oczekujących na realizację,
- dodatkowe mechanizmy zatwierdzania wydania i odbioru certyfikatu.
Zespoły SOC i IR powinny rozszerzyć monitoring o nietypowe uruchamianie plików dostarczonych przez systemy ticketowe, podejrzane użycie funkcji „view as customer”, nagłe wydanie lub odwołanie wielu certyfikatów oraz przypadki podpisywania nowych binariów przez świeżo wystawione certyfikaty EV.
W obszarze endpoint security warto blokować uruchamianie plików SCR, monitorować techniki DLL side-loading i stosować kontrolę aplikacji opartą nie tylko na ważności podpisu, ale również na analizie behawioralnej. Istotne pozostają także szkolenia pracowników wsparcia z rozpoznawania socjotechniki w czatach, zgłoszeniach i załącznikach podszywających się pod obrazy lub zrzuty ekranu.
Podsumowanie
Sprawa powiązana z GoldenEyeDog i incydentem DigiCert pokazuje, że bezpieczeństwo procesu code signing zależy nie tylko od ochrony materiału kryptograficznego, ale również od całego otoczenia operacyjnego: narzędzi wsparcia, logiki portali klienta, separacji obowiązków i kontroli dostępu.
Napastnicy wykorzystali połączenie socjotechniki, kompromitacji endpointów i słabości w modelu zagrożeń, aby przejąć zasoby o wyjątkowo wysokiej wartości. To kolejny sygnał dla branży, że infrastruktura zaufania cyfrowego musi być chroniona warstwowo, a zaufanie do podpisu cyfrowego nie może opierać się wyłącznie na samym certyfikacie.
Źródła
- https://thehackernews.com/2026/07/goldeneyedog-subgroup-linked-to.html
- https://expel.com/blog/
- https://bugzilla.mozilla.org/
- https://knowledge.digicert.com/
- https://www.elastic.co/security-labs