AnySign4PC: watering hole infekował bez kliknięcia

30 lipca 2026 roku koreańskie instytucje i cztery firmy bezpieczeństwa ujawniły kampanię określoną jako Operation Double Barrel. Napastnicy przejmowali legalne strony internetowe, a następnie wykorzystywali lokalnie zainstalowane oprogramowanie bezpieczeństwa finansowego. W przypadku podatnego AnySign4PC sama wizyta na zmodyfikowanej stronie mogła doprowadzić do wykonania kodu i instalacji backdoora — bez osobnego pobrania pliku i bez dodatkowego kliknięcia.

To szczególnie ważny przypadek „odwróconego zaufania”. Program instalowany w celu obsługi podpisu elektronicznego i bezpiecznych usług finansowych stał się mostem między stroną internetową a systemem operacyjnym. Legalna witryna dostarczyła JavaScript, lokalny komponent przyjął komunikację przez WebSocket, a luka pamięciowa pozwoliła przejść z kontekstu przeglądarki do wykonania shellcode.

Co zostało potwierdzone

Korea Internet & Security Agency, National Intelligence Service, National Police Agency i Financial Security Institute wydały wspólny komunikat na podstawie analiz AhnLab, S2W, ENKI Whitehat i Plainbit. Źródła zebrane w publikacji z 30 lipca wskazują:

• podatne są AnySign4PC 1.1.4.4–1.1.4.6;
• poprawiona wersja to 1.1.5.0;
• KISA rekomenduje usunięcie podatnych instalacji;
• napastnicy wykorzystywali spear phishing i przejęte strony typu watering hole;
• złośliwy kod kontaktował się z lokalnym programem po WebSocket;
• łańcuch prowadził do backdoorów SIGNBT albo COPPERHEDGE;
• AhnLab znalazł ślady powiązanej aktywności w 72 organizacjach i 15 przejętych witrynach;
• źródła nie przypisują całej kampanii formalnie Lazarusowi;
• nie ma publicznego CVE przypisanego konkretnie do tej nowej luki AnySign4PC.

Liczba 72 nie jest prostą liczbą pełnych włamań. Publiczny raport nie opisuje jednolitego kryterium zaliczenia organizacji do zbioru. Może obejmować różne poziomy obserwacji: próbę wejścia, artefakt, wykonanie części łańcucha albo potwierdzoną obecność malware. Nie należy jej przedstawiać jako 72 organizacji z kompletnie przejętą siecią.

Watering hole zamiast bezpośredniego ataku na ofiarę

W ataku watering hole napastnik wybiera witrynę, którą regularnie odwiedza docelowa grupa. Zamiast wysyłać każdej osobie osobny plik, kompromituje serwis informacyjny, medyczny, edukacyjny, branżowy albo należący do mniejszego dostawcy.

W tej kampanii zmodyfikowane strony zawierały skrypt uruchamiający łańcuch tylko wtedy, gdy na komputerze znajdował się odpowiedni komponent. Dla większości odwiedzających witryna mogła wyglądać i działać normalnie. Takie filtrowanie ogranicza liczbę widocznych błędów i utrudnia administratorowi strony zauważenie nadużycia.

Spear phishing używał przynęt związanych z CV, rekrutacją, inwestycjami i ankietami branżowymi. Wiadomość nie musiała bezpośrednio przenosić malware. Jej rolą było skierowanie właściwej osoby na legalną, lecz przejętą stronę.

Techniczny łańcuch AnySign4PC

Raport AhnLab „Operation Double Barrel” opisuje użycie czterech obrazów PNG. Nie były one zwykłymi elementami graficznymi. Poszczególne etapy służyły do wymiany kluczy, sprawdzenia wersji lokalnego oprogramowania, dostarczenia dopasowanego exploita i przekazania wyniku wykonania.

Schemat wyglądał następująco:

1. użytkownik otwierał zmodyfikowaną stronę;
2. JavaScript wykrywał lokalny komponent bezpieczeństwa;
3. strona komunikowała się z AnySign4PC przez WebSocket;
4. wersja programu decydowała o wariancie kodu;
5. przepełnienie bufora prowadziło do wykonania shellcode;
6. payload był wstrzykiwany do legalnego procesu Windows;
7. uruchamiany był SIGNBT/Struggle albo COPPERHEDGE/Brandoor;
8. backdoor pobierał kolejne zadania i narzędzia.

Plainbit zrekonstruował jeden incydent, w którym napastnicy najpierw rozpoznali publiczne systemy organizacji, przejęli witrynę, umieścili webshell i dopisali JavaScript do legalnej strony z wiadomością. Po wizycie podatny komponent utworzył złośliwą bibliotekę DLL bez dialogu pobierania.

To nie jest typowy drive-by download oparty wyłącznie na błędzie przeglądarki. Krytycznym elementem był lokalny program udostępniający interfejs osiągalny z treści WWW.

SIGNBT i COPPERHEDGE po wejściu

Końcowe implanty zapewniały zdalne wykonywanie poleceń, kradzież plików, rozpoznanie sieci, wstrzykiwanie procesów i pobieranie kolejnych modułów. Poszczególne klastry używały DLL side-loadingu, zaszyfrowanych danych w rejestrze oraz ładowania plików PE w pamięci.

W jednym wariancie konfiguracja C2 była przechowywana w rejestrze. Malware wstrzykiwał kod do svchost.exe, co utrudniało prostą ocenę po nazwie procesu. Inny łańcuch tworzył zadanie RuntimeBroker, które uruchamiało task.vbs, a następnie przemianowanego klienta SSH działającego jako SearchHost.exe w celu zestawienia tunelu zwrotnego.

Nazwy przypominające komponenty Windows są sygnałem, nie dowodem. Legalny RuntimeBroker.exe i SearchHost.exe istnieją. Detekcja musi uwzględniać ścieżkę, podpis, proces nadrzędny, argumenty i połączenia, a nie samą nazwę.

Dlaczego hash pliku szybko traci wartość

ENKI opisał tryby samoochrony, w których backdoor usuwał konfigurację rejestru, loader i własne pliki po skopiowaniu ich do pamięci. Przy prawidłowym zamknięciu zapisywał loader ponownie, lecz z innym hashem.

To oznacza, że pojedynczy SHA-256 może wykryć próbkę z raportu, ale nie całą klasę. Większą wartość mają:

• nietypowa komunikacja strony WWW z lokalnym WebSocket;
• biblioteka DLL ładowana przez nieoczekiwany legalny program;
• wykonanie PE bez odpowiadającego pliku na dysku;
• nowe usługi i zadania harmonogramu;
• zaszyfrowane wartości w kluczach usług;
• wstrzyknięcie do SyncHost.exe albo svchost.exe;
• wychodzący tunel SSH z procesu o nazwie systemowej;
• czyszczenie artefaktów przez SDelete lub CCleaner po aktywności malware.

Zespół powinien zachować pamięć procesu, command line, zdarzenia ładowania DLL, rejestr i ruch sieciowy przed zakończeniem procesu. Zbyt szybkie „sprzątanie” może usunąć najcenniejszy materiał.

Związek z Gunra ransomware bez nadmiernej atrybucji

AhnLab znalazł techniczne nakładanie się kampanii szpiegowskiej z incydentem Gunra ransomware z marca 2026 roku. Wspólne elementy obejmowały podatność w jednym z anonimowo opisanych produktów, nazwy net.tmp i inet.tmp, format argumentów, fingerprint klucza SSH, adres tunelu oraz domenę dystrybucyjną.

Nie dowodzi to jednego operatora. Możliwe wyjaśnienia to:

• współpraca ograniczona do dostępu początkowego;
• wspólne narzędzia lub infrastruktura;
• ten sam broker dostępu;
• wykorzystanie wspólnego zasobu operacyjnego;
• ponowne użycie ujawnionych elementów przez inną grupę.

Co więcej, AhnLab nie ujawnił nazw dwóch pozostałych podatnych produktów, oznaczonych jako software A i I. Raport nie ustala, że produkt użyty w incydencie Gunra był właśnie AnySign4PC.

Czy to Lazarus?

Oddzielny raport AhnLab z kwietnia przypisywał wcześniejszy watering hole wykorzystujący AnySign4PC grupie Lazarus. Kaspersky wcześniej opisał Operation SyncHole z użyciem koreańskiego oprogramowania bezpieczeństwa, SIGNBT i COPPERHEDGE.

Te podobieństwa są istotnym kontekstem. Obecny wspólny komunikat i Operation Double Barrel określają jednak operatora tylko jako grupę sponsorowaną przez państwo. Nie przypisują całej kampanii Lazarusowi, a tym bardziej nie łączą tej grupy z Gunra. W raporcie wewnętrznym atrybucję należy oznaczyć jako niepotwierdzoną hipotezę, nie fakt.

Kogo dotyczy ryzyko

Bezpośrednio zagrożone są urządzenia z wersjami AnySign4PC 1.1.4.4–1.1.4.6, szczególnie w Korei Południowej, gdzie program jest używany do podpisu certyfikatowego. Organizacje spoza Korei powinny potraktować incydent jako wzorzec dla wszystkich lokalnych „helperów” instalowanych przez banki, administrację, podpis elektroniczny i starsze portale B2B.

Warto zinwentaryzować:

• rozszerzenia i usługi nasłuchujące na localhost;
• komponenty komunikujące się z dowolną stroną przez WebSocket;
• programy instalowane kiedyś na potrzeby jednego portalu;
• automatyczne aktualizatory o niejasnym właścicielu;
• podpisane, lecz niewspierane biblioteki;
• lokalne aplikacje mające prawa wyższe niż przeglądarka.

Program nieużywany biznesowo powinien zostać usunięty. Aktualizacja niepotrzebnego komponentu nadal pozostawia dodatkową powierzchnię.

Plan reakcji

1. wyszukaj wersje AnySign4PC w inwentarzu oprogramowania;
2. usuń wydania 1.1.4.4–1.1.4.6 albo zaktualizuj zgodnie z instrukcją KISA do 1.1.5.0;
3. sprawdź, czy urządzenia odwiedzały witryny i infrastrukturę z raportów;
4. zbierz telemetrię pamięci, DLL, zadań, usług, rejestru i tuneli;
5. odizoluj systemy z kombinacją sygnałów;
6. sprawdź konta, RDP i ruch boczny po pierwszym podejrzanym czasie;
7. wymień poświadczenia użyte na zainfekowanym hoście;
8. zweryfikuj integralność własnych witryn i dostawców zarządzających stronami.

Jeśli host wykazuje obecność backdoora, sama aktualizacja AnySign4PC nie usuwa implantu ani dostępu uzyskanego później. Potrzebne jest pełne reagowanie na incydent i analizowanie zasięgu.

Detekcja dla SOC

Zespół może przekształcić raport w kilka hipotez:

• przeglądarka nawiązuje lokalny WebSocket, po czym proces podpisu tworzy DLL;
• podpisany program ładuje bibliotekę z katalogu użytkownika lub tymczasowego;
• SyncHost.exe albo svchost.exe otwiera połączenie niewynikające z roli hosta;
• zadanie o systemowej nazwie uruchamia VBS i klienta SSH;
• proces bezpieczeństwa finansowego zapisuje lub wykonuje niepodpisany kod;
• po wejściu na znaną stronę następuje użycie Mimikatz, RDP lub NLBrute.

Podejście do budowy i testowania takich korelacji opisujemy w materiale o detection engineering z Sigma i SIEM. Kontekst kampanii i poziomy pewności atrybucji warto prowadzić zgodnie z cyklem Cyber Threat Intelligence.

Walidacja po aktualizacji

Samo odczytanie numeru 1.1.5.0 w panelu inwentarza nie zamyka ryzyka. Zespół powinien potwierdzić, że stare pliki wykonywalne i biblioteki nie pozostały w katalogach użytkownika, pamięci podręcznej instalatora, złotych obrazach ani pakietach dystrybucyjnych. Warto również sprawdzić, czy lokalny WebSocket jest dostępny wyłącznie dla oczekiwanych originów i czy przeglądarka nie może wywołać uprzywilejowanej operacji bez uwierzytelnionego kontekstu.

Po stronie SOC kryterium zamknięcia powinno obejmować brak artefaktów SIGNBT i COPPERHEDGE, brak nieautoryzowanych zadań, usług, tuneli oraz aktywności kont po najwcześniejszym czasie ekspozycji. Po stronie właściciela witryny potrzebne są porównanie plików z zaufanym wydaniem, przegląd kont administracyjnych, logów publikacji i mechanizmu zarządzania treścią. Kampania była łańcuchem dwóch granic zaufania: przejętego serwisu i podatnego komponentu lokalnego. Naprawienie tylko jednej pozostawia niepełny obraz.

Dobry test regresji jest nieszkodliwy: z kontrolowanej domeny próbuje wykonać niedestrukcyjne żądanie do lokalnego helpera i potwierdza jego odrzucenie. Publicznego PoC wykorzystującego przepełnienie bufora nie należy uruchamiać na stacji użytkownika.

Źródła a wnioski Breachroad

Wersje, poprawka, komunikacja WebSocket, exploit pamięciowy, rodziny malware i obserwowane zachowania pochodzą z komunikatów KISA oraz raportów AhnLab, ENKI, Plainbit i S2W. Źródła potwierdzają techniczne nakładanie z Gunra, ale nie jednego operatora. Nie potwierdzają także pełnej atrybucji Double Barrel do Lazarusa.

Wnioski dotyczące lokalnych helperów, inwentarza WebSocket, priorytetów detekcji i kolejności reakcji są analizą Breachroad. Organizacje mogą sprawdzić podobne granice podczas audytu bezpieczeństwa IT i testów aplikacji webowych oraz API.

Najważniejsza lekcja jest uniwersalna: zaufana strona i podpisany lokalny program nie tworzą automatycznie bezpiecznego łańcucha. Szkolenia cyberbezpieczeństwa dla zespołów powinny obejmować także sytuacje, w których użytkownik nie pobiera pliku, a zagrożenie wynika z przejętego zaufanego serwisu.