Rządowe i przemysłowe serwery na celowniku kampanii „PassiveNeuron” powiązanej z Chinami

Wprowadzenie do problemu / definicja luki

Kaspersky ujawnił aktywną kampanię cyberszpiegowską „PassiveNeuron”, która od grudnia 2024 r. do co najmniej sierpnia 2025 r. celowała w serwery Windows Server w organizacjach rządowych, przemysłowych i finansowych na rynkach Azji, Afryki i Ameryki Łacińskiej. Atakujący uzyskiwali zdalne wykonanie kodu (RCE), instalowali web-shelle i wdrażali niestandardowe implanty do eksfiltracji danych oraz dalszej penetracji środowisk. Atrybucja jest ostrożnie przypisana do aktora chińskojęzycznego (niska pewność). Źródła branżowe (SecurityWeek, Dark Reading) potwierdzają wyniki Kaspersky.

W skrócie

• Wektor: serwery Windows (często z komponentem Microsoft SQL Server), potem web-shell i łańcuch loaderów DLL.
• Implanty: dwa nieznane wcześniej – Neursite (modularny backdoor C++) i NeuralExecutor (.NET loader) – oraz Cobalt Strike.
• C2: w nowszych próbkach wykorzystanie techniki „dead drop resolver” z GitHub do pozyskania adresów C2.
• Kamuflaż: nadmuchane pliki DLL (>100 MB) umieszczane w System32 dla trwałości i uniknięcia detekcji.
• Zasięg i czas: fala 12.2024–08.2025; wcześniejsze próby z czerwca 2024 r., pauza ~6 mies. i powrót.
• Atrybucja: przesłanki TTP wskazują na chińskojęzycznego aktora (niska pewność).

Kontekst / historia / powiązania

„PassiveNeuron” po raz pierwszy opisano zwięźle w 2024 r. jako kampanię na rządowe serwery z użyciem nieznanych implantów. Po zatrzymaniu rozprzestrzeniania w połowie 2024 r. aktywność zniknęła, by powrócić w grudniu 2024 r. i trwać do sierpnia 2025 r. Media branżowe odnotowują wzmiankę o celowaniu w serwery (w tym SQL) i sektorach wrażliwych. Wskazówki atrybucyjne z 2025 r. (m.in. dead drop na GitHub z charakterystycznymi delimitrami) korelują ze wzorcami obserwowanymi wcześniej u grup chińskojęzycznych (np. kampania EastWind).

Analiza techniczna / szczegóły kampanii

Początkowy dostęp i RCE

• W co najmniej jednym incydencie uzyskano RCE poprzez komponenty Microsoft SQL Server na serwerze Windows. Dokładny mechanizm bywa niejasny; Kaspersky wymienia typowe ścieżki: exploity w samym serwerze, SQL injection w aplikacjach korzystających z bazy lub brute-force/kradzież poświadczeń DBA. Próba szybkiego ugruntowania przyczółka to wdrożenie ASPX web-shella.

Łańcuch loaderów i trwałość

• Gdy web-shell zawiódł, operatorzy wdrażali zaawansowane implanty poprzez łańcuch loaderów DLL umieszczanych w C:\Windows\System32. Pliki były sztucznie „napompowane” (ponad 100 MB), co utrudniało analizę i detekcję sygnaturową. Loader uruchamiał się automatycznie przy starcie systemu.

Neursite (C++ modular backdoor)

• Obsługa wielu protokołów C2: TCP/SSL/HTTP/HTTPS, łączenie do serwera C2 bezpośrednio lub przez host pośredniczący; możliwość proxy ruchu przez inne zainfekowane maszyny (ułatwienie ruchu lateralnego), zbieranie informacji o systemie, zarządzanie procesami, ładowanie pluginów (shell, operacje na FS, gniazda TCP).

NeuralExecutor (.NET)

• Loader .NET, obfuskowany ConfuserEx, wielokanałowa komunikacja (TCP/HTTP/HTTPS/named pipes/WebSockets), główna funkcja: doładowywanie i wykonywanie kolejnych ładunków .NET. W wydaniu z 2025 r. pobierał konfigurację/C2 z pliku na GitHub (dead drop resolver) – struny wydzielone specyficznymi delimiterami, dekodowane Base64 i odszyfrowywane AES.

Cobalt Strike

• Stosowany jako komponent do post-exploitation i manewrów wewnątrz sieci.

Atrybucja i „false flags”

• W próbkach z 2024 r. widoczne były ciągi w cyrylicy („Супер обфускатор”) – najpewniej fałszywy trop wprowadzony podczas obfuskacji. Sygnatura PDB powiązana wcześniej przez Cisco Talos z działaniami APT41 pojawiła się w jednej z bibliotek (imjp14k.dll), ale kontekst nie jest rozstrzygający. Kaspersky wskazuje niski poziom pewności atrybucji do aktora chińskojęzycznego, opierając się przede wszystkim na TTP.

Praktyczne konsekwencje / ryzyko

• Ryzyko eksfiltracji danych i długotrwałego utrzymania w sieci (implantly + Cobalt Strike).
• Ryzyko pivotu z serwerów do krytycznych zasobów (proxy w Neursite, lateral movement).
• Uderzenie w organizacje o wysokiej wartości (rządy, przemysł, finanse), także z infrastrukturą OT po stronie serwerowej (np. ERP/SCADA back-ends), co wpisuje się w szersze trendy aktywności aktorów powiązanych z ChRL.

Rekomendacje operacyjne / co zrobić teraz

Twarde kontrolki na warstwie serwerów i SQL

1. Ogranicz ekspozycję serwerów Windows/SQL do Internetu; wymuś MFA i sieciowe listy kontroli dostępu (NACL) / VPN z silnym uwierzytelnianiem dla administracji.
2. Patching & hardening: aktualizacje Windows Server/SQL; wyłącz zbędne usługi; egzekwuj TLS i szyfrowanie w tranzycie; polityki haseł DBA (długość, rotacja, brak domyślnych). (Najlepsze praktyki wynikają pośrednio z analizy Kaspersky dot. typowych wektorów.)
3. WAF + bezpieczeństwo aplikacji: testy pod kątem SQLi, reguły blokujące nietypowe kwerendy administracyjne z warstwy aplikacyjnej.

Detekcja i reagowanie
4. Monitoruj artefakty:

• Nieoczekiwane ASPX web-shelle, pliki DLL w System32 o rozmiarach >100 MB.
• Ruch wychodzący do GitHub/Gist pobierający konfiguracje (anomalia proxy/IDS).
• Wskaźniki z najnowszego zestawu IoC opublikowanego przez Kaspersky (hash’e loaderów, imjp14k.dll).

5. EDR/XDR z regułami na: uruchamianie rundll32/regsvr32 z nietypowymi parametrami, ładowanie .NET assemblies z pamięci, zachowania Cobalt Strike (beaconing, named pipes). (Wnioski z TTP zawartych w raportach.)
6. Segmentacja i egress filtering: zablokuj nieużywane protokoły, kontroluj HTTP/HTTPS z serwerów bazodanowych, wprowadzaj „deny-by-default” dla wyjść sieciowych. (Wnioski operacyjne na podstawie sposobu komunikacji implantów.)
7. Hunting: reguły YARA/Sigma oparte na descriptorach Neursite/NeuralExecutor; korelacje logów SQL (np. xp_cmdshell, nieautoryzowane sp_configure, nietypowe EXEC). (Oparte na opisie RCE przez SQL i ładunków .NET.)

Gotowość incydentowa
8. Plany izolacji serwerów, kopie zapasowe offline, ćwiczenia tabletop dla scenariusza „serwer centralny (SQL) jako patient zero”.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

• Dead drop resolver na GitHub był wcześniej widoczny w kampaniach przypisywanych aktorom chińskojęzycznym (np. EastWind), co odróżnia PassiveNeuron od wielu operacji, które korzystają z jednoznacznych, własnych serwerów C2.
• Skupienie na serwerach (zwłaszcza SQL) i nadmuchane DLL-e w System32 to wyróżniki TTP tej kampanii względem typowych łańcuchów opartych na spear-phishingu czy złośliwych sterownikach.

Podsumowanie / najważniejsze wnioski

„PassiveNeuron” to konsekwentnie prowadzona, ukierunkowana kampania na serwery Windows, korzystająca z dwóch niestandardowych implantów i technik utrudniających detekcję (dead drop na GitHub, ogromne DLL-e, łańcuch loaderów). choćby przy niskiej pewności atrybucji, zbieżność TTP z wcześniejszymi operacjami chińskojęzycznymi powinna skłonić SOC do podwyższonej czujności, szczególnie w organizacjach z krytyczną infrastrukturą i systemami bazodanowymi eksponowanymi do sieci.

Źródła / bibliografia

1. SecurityWeek — „Government, Industrial Servers Targeted in China-Linked ‘PassiveNeuron’ Campaign”, 21 października 2025. (SecurityWeek)
2. Kaspersky Securelist — „PassiveNeuron: a sophisticated campaign targeting servers of high-profile organizations”, 21 października 2025 (GReAT). Zawiera IoC i szczegóły TTP. (securelist.com)
3. Kaspersky (komunikat prasowy) — „Kaspersky identifies PassiveNeuron cyberespionage campaign…”, 21 października 2025. (Kaspersky)
4. Dark Reading — „‘PassiveNeuron’ Cyber Spies Target Orgs With Custom Malware”, 21 października 2025. (Dark Reading)
5. The Hacker News — „Researchers Identify PassiveNeuron APT Using Neursite and NeuralExecutor…”, 22 października 2025. (The Hacker News)