FrostyNeighbor i phishing z PDF-em

TL;DR

FrostyNeighbor, znany także jako Ghostwriter lub UNC1151, pokazuje, jak wygląda dojrzały spear phishing przeciw organizacjom w Europie Wschodniej. Atak nie polega na masowym wysłaniu jednego oczywistego linku. W kampanii opisanej przez ESET przynętą jest PDF, link w dokumencie prowadzi do infrastruktury atakujących, a serwer decyduje, czy ofiara ma dostać neutralny plik, czy kolejny etap infekcji.

Mechanizm jest ważny dla Polski, bo FrostyNeighbor nie jest aktorem oderwanym od naszego regionu. ESET wskazuje, że grupa skupia się na Ukrainie, Polsce i Litwie, a w polskiej telemetrii jej aktywność obejmowała między innymi credential phishing, malware oraz kampanie wymierzone w pocztę. Dla organizacji współpracujących z Ukrainą, administracji, sektora zdrowia, logistyki, przemysłu, uczelni i podmiotów objętych wymaganiami bezpieczeństwa to nie jest egzotyczny raport APT. To scenariusz, który dobrze pasuje do codziennej pracy z dokumentami zewnętrznymi.

Najważniejsza praktyczna zmiana jest konkretna: PDF z linkiem do kolejnego pliku nie powinien być traktowany jak zwykły dokument. Jeżeli użytkownik otwiera dokument, klika przycisk, pobiera archiwum i uruchamia skrypt, incydent trzeba analizować jako pełny łańcuch ataku, a nie jako pojedyncze kliknięcie.

PDF jako brama do kolejnego etapu

W tej kampanii PDF nie jest tylko nośnikiem treści. Jest elementem kwalifikacji ofiary. Według ESET dokument podszywał się pod komunikat związany z ukraińskim operatorem telekomunikacyjnym Ukrtelecom i zawierał przycisk pobierania prowadzący do serwera kontrolowanego przez atakujących. Użytkownik widział dokument, ale prawdziwa decyzja zapadała po stronie infrastruktury przeciwnika.

Jeżeli żądanie nie pasowało do oczekiwanego profilu, serwer mógł zwrócić neutralny PDF. Jeżeli ofiara łączyła się z ukraińskiego adresu IP, serwer dostarczał archiwum RAR z plikiem JavaScript. Ten plik wyświetlał przynętę w postaci dokumentu, a jednocześnie uruchamiał kolejny etap w tle.

To zmienia sposób myślenia o załącznikach. Sam fakt, że plik ma format PDF, nie zamyka analizy. Dokument może nie zawierać klasycznego złośliwego makra, a mimo to prowadzić do infekcji przez link, pobranie archiwum, uruchomienie skryptu i selektywne dostarczenie payloadu. W praktyce taki PDF działa jak kontrolowana bramka do procesu ataku.

Dla użytkownika problem jest trudny, bo dokument może wyglądać wiarygodnie i dotyczyć realnego kontekstu: telekomunikacji, administracji, pomocy dla Ukrainy, współpracy międzynarodowej, zamówienia, certyfikatu, komunikatu operatora albo dokumentacji technicznej. Atakujący nie potrzebuje perfekcyjnego oszustwa. Potrzebuje dokumentu, który daje odbiorcy wystarczający powód, aby kliknąć.

Geofencing utrudnia analizę SOC

Geofencing w phishingu oznacza, że infrastruktura atakującego pokazuje różne treści w zależności od cech ofiary. Może brać pod uwagę kraj, adres IP, user agent, język systemu, czas, typ przeglądarki, nagłówki żądania, reputację środowiska albo zachowanie wskazujące na sandbox. W kampanii FrostyNeighbor ESET opisał walidację po stronie serwera i dostarczanie właściwego etapu tylko wybranym ofiarom.

Dla SOC, czyli security operations center, to poważna komplikacja. Analityk może otworzyć link z innej lokalizacji, przez VPN, z izolowanego środowiska albo po kilku godzinach i zobaczyć zupełnie inną treść niż użytkownik, który kliknął wcześniej z firmowego komputera. Brak widocznego payloadu w momencie analizy nie oznacza, że użytkownik nie dostał go wcześniej.

Dlatego po zgłoszeniu nie wystarczy sprawdzić pierwszy adres URL. Trzeba odtworzyć ścieżkę po kliknięciu: czas dostarczenia wiadomości, czas otwarcia PDF-a, adres URL z dokumentu, żądania HTTP, logi proxy, logi DNS, aktywność endpointa, pobrania plików, uruchomione procesy, katalog pobrań i komunikację z domenami, które pojawiły się po kliknięciu.

W reakcji SOC na phishing po filtrze poczty taki szczegół ma duże znaczenie. Filtr poczty mógł przepuścić PDF, bo sam załącznik nie zachowywał się jak klasyczny malware. Złośliwy etap pojawił się dopiero po interakcji użytkownika i po walidacji po stronie serwera. Obrona musi więc patrzeć na sekwencję zdarzeń, nie tylko na reputację pliku w chwili dostarczenia.

PicassoLoader i ręczna kwalifikacja celu

ESET opisał w kampanii JavaScriptową wersję PicassoLoadera. To downloader kojarzony z aktywnością FrostyNeighbor, którego zadaniem jest zbieranie informacji o komputerze ofiary i komunikacja z infrastrukturą command and control, czyli C2. C2 to środowisko służące do sterowania przejętym systemem, odbierania danych i wydawania kolejnych poleceń.

PicassoLoader w tej kampanii zbierał między innymi informacje o użytkowniku, nazwie komputera, wersji systemu, czasie uruchomienia oraz procesach działających na urządzeniu. Następnie cyklicznie wysyłał fingerprint komputera do serwera atakującego. Operatorzy mogli ręcznie ocenić, czy dana ofiara jest warta dalszego etapu.

To ważny wniosek dla obrony. W atakach APT, czyli advanced persistent threat, kliknięcie nie zawsze oznacza natychmiastowe dostarczenie końcowego malware. Czasem kliknięcie rozpoczyna rozpoznanie. Atakujący sprawdza, czy trafił na właściwą organizację, właściwy dział, właściwego użytkownika i środowisko, które warto dalej eksploatować.

Jeżeli ofiara była interesująca, kolejnym etapem mógł być Cobalt Strike. Cobalt Strike to legalne narzędzie używane w testach bezpieczeństwa i red teamingu, ale często nadużywane przez grupy przestępcze i aktorów APT jako implant po kompromitacji. W tym przypadku ESET opisał dostarczenie Cobalt Strike Beacon po wcześniejszej walidacji ofiary.

Dlaczego to dotyczy Polski

Polski kontekst nie wynika wyłącznie z bliskości geograficznej. ESET wskazuje, że FrostyNeighbor koncentrował się na Ukrainie, Polsce i Litwie, a w przypadku Polski i Litwy zakres ofiar był szerszy niż tylko administracja. Wymieniane sektory obejmują między innymi przemysł i produkcję, zdrowie i farmację, logistykę oraz organizacje rządowe.

Dodatkowo CERT Polska opisywał kampanie UNC1151/Ghostwriter wymierzone w polskie podmioty. W 2025 roku zespół CERT Polska informował o wykorzystaniu podatności CVE-2024-42009 w Roundcube do kradzieży poświadczeń. Roundcube to webmail, czyli klient poczty działający w przeglądarce. W tym scenariuszu złośliwa wiadomość mogła wykonać kod JavaScript w momencie odczytania maila, bez klasycznego załącznika uruchamianego przez użytkownika.

To pokazuje, że grupa nie trzyma się jednej techniki. Raz może używać PDF-a z linkiem do archiwum, innym razem credential phishingu, podatności w webmailu, fałszywych stron logowania, dokumentów przynęt albo łańcuchów malware. Wspólny mianownik jest stały: rozpoznanie celu, dopasowanie przynęty i wykorzystanie zaufanych procesów komunikacji.

W Polsce taki scenariusz może dotyczyć wiadomości od partnera z Ukrainy, organizacji pomocowej, operatora telekomunikacyjnego, kancelarii, instytucji publicznej, uczelni, dostawcy, podmiotu logistycznego albo firmy obsługującej infrastrukturę. Treść nie musi być idealna językowo. Wystarczy, że pasuje do realnego procesu i trafia do osoby, która codziennie pracuje z dokumentami zewnętrznymi.

Jak użytkownik powinien traktować taki dokument

Użytkownik nie musi analizować PicassoLoadera ani rozumieć każdego etapu kampanii. Musi znać moment zatrzymania. Jeżeli dokument PDF od zewnętrznego nadawcy zawiera przycisk pobierania kolejnego pliku, link do archiwum, prośbę o uruchomienie skryptu, instrukcję otwarcia paczki RAR albo nietypowy sposób dostępu do dokumentu, proces powinien zostać przerwany i zgłoszony.

Szczególnie podejrzane jest połączenie kilku elementów: dokument zewnętrzny, presja zapoznania się z treścią, link zamiast załączonego pliku, archiwum do pobrania, plik JavaScript, komunikat o aktualizacji, dokument dotyczący administracji, sektora publicznego, telekomunikacji albo współpracy międzynarodowej. Każdy z tych elementów może być legalny. Razem tworzą ryzyko, którego nie powinno się rozstrzygać na własnym komputerze.

Dobrym nawykiem jest przekazanie wiadomości do właściwego kanału zgłoszeń bez dalszego klikania. Jeżeli organizacja nie ma takiego kanału, użytkownik powinien skontaktować się z helpdeskiem, IT albo przełożonym i jasno napisać, że chodzi o weryfikację podejrzanego dokumentu, a nie o wykonanie zadania z linku.

To istotne również wtedy, gdy dokument wygląda jak komunikacja od znanego partnera. W spear phishingu nadawca może być podszyty, konto może być przejęte, a temat może odnosić się do realnej współpracy. Wiarygodny kontekst nie jest dowodem bezpieczeństwa.

Co zrobić, jeśli to już się stało

Jeżeli użytkownik tylko otworzył PDF, ale nie kliknął linku ani nie pobrał kolejnego pliku, powinien zgłosić wiadomość i zachować ją do analizy. SOC lub IT powinien sprawdzić oryginalny załącznik, nagłówki wiadomości, linki w dokumencie, reputację domen oraz to, czy podobna wiadomość trafiła do innych osób.

Jeżeli użytkownik kliknął link z PDF-a, trzeba ustalić, co zobaczył i co pobrał. W scenariuszu z geofencingiem analityk może nie odtworzyć tej samej odpowiedzi z innego środowiska, dlatego ważny jest czas kliknięcia, adres IP użytkownika, logi proxy, DNS, przeglądarki i endpointa. Brak złośliwej treści w późniejszej analizie nie powinien kończyć sprawy.

Jeżeli pobrano archiwum RAR, ZIP albo inny plik, nie należy go otwierać ponownie ani przesyłać przypadkowymi kanałami. Plik powinien trafić do kontrolowanej analizy. Jeżeli użytkownik uruchomił plik JavaScript, skrypt, instalator albo dokument z instrukcją wykonania dodatkowych czynności, endpoint trzeba potraktować jako potencjalnie naruszony.

W takim przypadku zespół techniczny powinien sprawdzić procesy, zadania harmonogramu, wpisy autostartu, katalogi użytkownika, połączenia sieciowe, nowe pliki w AppData lub ProgramData, logi EDR, DNS, proxy i komunikację HTTP. Jeżeli pojawią się ślady downloadera, C2 lub Cobalt Strike, reakcja powinna obejmować izolację urządzenia, analizę artefaktów, unieważnienie sesji użytkownika i sprawdzenie, czy atak nie rozprzestrzenił się dalej.

Jeżeli organizacja korzysta z Microsoft 365, Google Workspace albo innych usług SaaS, warto równolegle sprawdzić logowania, aktywne sesje, reguły pocztowe, przekierowania, aplikacje z nadanymi zgodami oraz nietypowe operacje na plikach. Atak rozpoczęty od dokumentu może prowadzić do malware, ale może też skończyć się kradzieżą poświadczeń lub sesji.

Co powinien monitorować SOC

SOC powinien traktować PDF-y z linkami jako sygnał do korelacji, nie jako pojedynczy artefakt. W praktyce liczy się połączenie danych z poczty, endpointa, DNS, proxy, EDR, SIEM i usług chmurowych. SIEM, czyli security information and event management, pomaga łączyć zdarzenia z wielu źródeł i wykrywać wzorce, których nie widać w pojedynczym logu.

W tym scenariuszu ważne są zdarzenia takie jak otwarcie PDF-a z zewnętrznego źródła, kliknięcie linku z dokumentu, pobranie archiwum, uruchomienie wscript, cscript, mshta, powershell, rundll32 albo node z katalogu użytkownika, tworzenie zadań harmonogramu, nowe wpisy autostartu, nietypowe pliki w AppData lub ProgramData oraz cykliczne połączenia HTTP do nowych domen.

Warto też monitorować sytuacje, w których sandbox, proxy lub narzędzia reputacyjne widzą neutralną treść, ale endpoint użytkownika pobiera inny plik. To typowy problem przy walidacji ofiary po stronie serwera. Dobra detekcja nie powinna opierać się wyłącznie na jednorazowej analizie URL-a. Powinna obejmować zachowanie po kliknięciu.

Dla organizacji o wyższym profilu ryzyka, zwłaszcza administracji, sektora zdrowia, logistyki, przemysłu, energetyki, uczelni i podmiotów pracujących z Ukrainą, sensowne jest osobne traktowanie dokumentów przychodzących z regionu podwyższonego ryzyka. Nie chodzi o blokowanie współpracy. Chodzi o świadome sprawdzanie dokumentów, które uruchamiają kolejne pobrania albo wymagają wykonania plików poza standardowym procesem.

Jak ćwiczyć taki scenariusz w awareness

Kampania FrostyNeighbor dobrze nadaje się do ćwiczeń awareness, bo pokazuje różnicę między prostym phishingiem a atakiem ukierunkowanym. Użytkownik nie dostaje oczywistej fałszywej faktury. Dostaje dokument, który może pasować do jego pracy. Dopiero po kliknięciu linku pojawia się kolejny etap, a prawdziwa analiza wymaga danych z infrastruktury.

W testach phishingowych dla firm taki scenariusz można odtworzyć bez dostarczania złośliwego pliku. Wystarczy bezpieczny PDF z linkiem do kontrolowanego środowiska, które symuluje pobranie archiwum, prośbę o otwarcie pliku lub formularz weryfikacyjny. Celem nie jest przestraszenie użytkownika. Celem jest sprawdzenie, czy zatrzyma proces i zgłosi dokument przed uruchomieniem kolejnego etapu.

Warto mierzyć nie tylko kliknięcie. Znacznie ważniejsze są decyzje po drodze: czy użytkownik otworzył PDF, czy kliknął link, czy pobrał archiwum, czy próbował uruchomić plik, czy przekazał wiadomość dalej, czy zgłosił ją do IT, jak szybko to zrobił i czy helpdesk wiedział, jak eskalować takie zgłoszenie.

Taki test powinien obejmować również SOC lub IT. Jeżeli symulacja kończy się na raporcie kliknięć, organizacja traci najważniejszą lekcję. Należy sprawdzić, czy zespół techniczny potrafi odtworzyć ścieżkę po kliknięciu, powiązać zdarzenia z logów, ocenić ryzyko endpointa i przygotować komunikat dla innych użytkowników.

Wniosek

FrostyNeighbor pokazuje, że phishing w naszym regionie może być selektywny, cierpliwy i technicznie dopracowany. Atakujący nie muszą infekować każdego odbiorcy. Wystarczy, że rozpoznają właściwą osobę, właściwe środowisko i moment, w którym dokument wygląda jak normalna część pracy.

Dla polskich organizacji zasada jest konkretna: PDF z linkiem do kolejnego pliku nie jest zwykłym załącznikiem, tylko początkiem procesu do weryfikacji. Jeżeli obrona kończy się na filtrze poczty, taki atak może przejść niezauważony. Odporność zaczyna się dopiero wtedy, gdy użytkownik umie zatrzymać kliknięcie, a SOC potrafi odtworzyć, co wydarzyło się po otwarciu dokumentu.