Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Grupa FamousSparrow, wiązana z chińskim ekosystemem zagrożeń APT, została powiązana z ukierunkowaną kampanią cyberszpiegowską wymierzoną w firmę z sektora ropy i gazu w Azerbejdżanie. Sprawa ma szczególne znaczenie dla bezpieczeństwa infrastruktury krytycznej, ponieważ napastnicy wielokrotnie wracali do tej samej ścieżki dostępu, wykorzystując niezałatane środowisko Microsoft Exchange oraz zmieniając narzędzia po uzyskaniu przyczółka.
Opisany incydent pokazuje, że nawet dobrze znane podatności i techniki nadal pozostają skuteczne, jeśli organizacja nie domknie całego procesu remediacji. W praktyce oznacza to, że samo usunięcie malware nie wystarcza, gdy pierwotny wektor wejścia pozostaje aktywny.
W skrócie
- Kampania obejmowała co najmniej trzy fale aktywności od końca grudnia 2025 r. do końca lutego 2026 r.
- Początkowy dostęp miał być uzyskany przez podatny serwer Microsoft Exchange z użyciem łańcucha exploitów ProxyNotShell.
- Po wejściu do środowiska atakujący wdrażali m.in. web shelle, Deed RAT oraz próbowali uruchomić backdoora Terndoor.
- Napastnicy wykazali wysoką uporczywość, wracając do tej samej infrastruktury i modyfikując konfigurację narzędzi po wykryciu części aktywności.
- W kampanii odnotowano ruch boczny z użyciem poświadczeń uprzywilejowanych i technik przypominających zdalne wykonanie przez SMB.
Kontekst / historia
FamousSparrow jest znane z operacji cyberszpiegowskich prowadzonych przeciwko podmiotom o znaczeniu strategicznym. Najnowsza kampania wskazuje na rozszerzenie zainteresowania grupy na sektor energetyczny regionu Kaukazu Południowego, co wpisuje się w szerszy trend działań wymierzonych w organizacje mające znaczenie gospodarcze i geopolityczne.
Tłem incydentu jest dalsze wykorzystywanie podatności w serwerach Microsoft Exchange. ProxyNotShell, mimo że zostało publicznie opisane już wcześniej, nadal stanowi skuteczny wektor wejścia tam, gdzie proces zarządzania poprawkami jest opóźniony, niepełny albo nie został połączony z dokładnym dochodzeniem powłamaniowym.
W praktyce oznacza to, że organizacje mogą pozostawać narażone nie tylko na jednorazowe włamanie, ale również na powroty tego samego przeciwnika. Właśnie ten element wyróżnia opisywaną kampanię: napastnicy nie polegali wyłącznie na pojedynczym malware, lecz na trwałym modelu odzyskiwania dostępu.
Analiza techniczna
Pierwsza faza włamania rozpoczęła się 25 grudnia 2025 r. od wykorzystania podatnego serwera Microsoft Exchange. Po uzyskaniu dostępu operatorzy umieścili web shelle w publicznie dostępnych lokalizacjach, co umożliwiło im utrzymanie przyczółka i ponowne wejścia do środowiska w kolejnych tygodniach.
W pierwszej fali wdrożono Deed RAT, uznawany za następcę rodziny ShadowPad i kojarzony z chińskimi operacjami szpiegowskimi. Na uwagę zasługuje sposób uruchomienia ładunku przez DLL sideloading z wykorzystaniem legalnego komponentu LogMeIn Hamachi. Złośliwa biblioteka nie wykonywała całej logiki od razu, lecz rozdzielała ją na etapy związane z naturalnym przebiegiem startu legalnej aplikacji, co utrudnia analizę sandboxową i opóźnia ujawnienie właściwego zachowania próbki.
Łańcuch uruchomienia obejmował odszyfrowanie ukrytego ładunku, wykonanie shellcode’u, dynamiczne rozwiązywanie funkcji API oraz końcowe załadowanie modułu do pamięci. Deed RAT zachowywał architekturę modułową i oferował możliwości typowe dla zaawansowanego malware szpiegowskiego, w tym komunikację sieciową, konfigurację, obsługę proxy i mechanizmy wspierające wstrzykiwanie kodu.
Po ustanowieniu trwałości operatorzy przeszli do ruchu bocznego. Według dostępnego opisu wykorzystywali RDP z użyciem poświadczeń administratora domenowego, a następnie rozszerzali obecność w sieci narzędziami przypominającymi funkcjonalnie zestaw Impacket oraz zdalne wykonanie przez SMB. To wskazuje, że po początkowym wejściu stosunkowo szybko uzyskali wysoki poziom kontroli nad segmentami środowiska.
W drugiej fali, niemal miesiąc później, napastnicy ponownie wrócili przez ten sam serwer Exchange i próbowali wdrożyć backdoora Terndoor za pośrednictwem łańcucha loadera Mofu. Mechanizm dostarczenia ponownie wykorzystywał sideloading DLL z użyciem przemianowanego legalnego pliku wykonywalnego. Próba miała zostać zablokowana przez rozwiązanie ochronne, jednak pozostawione artefakty sugerowały próbę utworzenia usługi sterownika jądra oraz użycie technik zgodnych z wcześniej opisywanymi próbkami Terndoor.
Trzecia fala, z końca lutego 2026 r., po raz kolejny wykorzystywała tę samą ścieżkę wejścia, ale już z odświeżoną konfiguracją Deed RAT. Zmieniono między innymi nazwę usługi, muteks, cele wstrzykiwania kodu oraz lokalizację plików, przenosząc je do mniej oczywistego katalogu. Tego rodzaju modyfikacje sugerują świadome dostosowywanie narzędzi do warunków po częściowym wykryciu wcześniejszych artefaktów.
Konsekwencje / ryzyko
Najważniejszy wniosek z tej kampanii dotyczy trwałości dostępu. Jeżeli organizacja usuwa pojedyncze artefakty, ale nie eliminuje pierwotnej luki, nie resetuje poświadczeń i nie przeprowadza pełnego dochodzenia powłamaniowego, atakujący mogą wrócić tą samą drogą wielokrotnie.
Dla sektora energetycznego ryzyko jest wielowymiarowe. Obejmuje ono kradzież informacji operacyjnych, danych infrastrukturalnych oraz wiedzy o procesach biznesowych. Jednocześnie obecność przeciwnika w środowisku IT organizacji o znaczeniu strategicznym może stanowić etap przygotowawczy do dalszych działań, takich jak zakłócenie procesów, operacje wpływu lub nadużycia wymierzone w łańcuch dostaw.
Szczególnie niebezpieczny jest element związany z poświadczeniami uprzywilejowanymi. Wykorzystanie kont administratora domenowego podczas ruchu bocznego oznacza wysokie ryzyko pełnej kompromitacji środowiska korporacyjnego, a w niektórych scenariuszach także możliwość pośredniego oddziaływania na systemy krytyczne.
Dodatkowym utrudnieniem dla zespołów bezpieczeństwa jest używanie domen i nazw imitujących legalnych dostawców bezpieczeństwa. Tego typu maskowanie może wydłużać czas analizy i utrudniać szybkie odróżnienie ruchu legalnego od komunikacji C2.
Rekomendacje
Organizacje powinny potraktować ten incydent jako praktyczne przypomnienie, że bezpieczeństwo usług brzegowych wymaga nie tylko aktualizacji, ale również potwierdzenia skuteczności remediacji. Samo wdrożenie poprawek bez sprawdzenia śladów kompromitacji może okazać się niewystarczające.
- Natychmiast załatać publicznie dostępne serwery Exchange i inne systemy brzegowe.
- Zweryfikować, czy po aktualizacji nie pozostały web shelle, złośliwe usługi, zaplanowane zadania i inne artefakty persistence.
- Przeprowadzić pełny reset poświadczeń uprzywilejowanych, zwłaszcza kont administracji domenowej i kont serwisowych.
- Przeanalizować logi Exchange, IIS, RDP, SMB oraz EDR pod kątem wielokrotnych powrotów przez tę samą ścieżkę wejścia.
- Wdrożyć detekcję DLL sideloadingu, nietypowych bibliotek w katalogach aplikacji oraz uruchomień legalnych binarek z podejrzanymi zależnościami.
- Monitorować próby tworzenia sterowników i usług w niestandardowych lokalizacjach systemowych.
- Ograniczyć możliwości ruchu bocznego poprzez segmentację sieci i rozdzielenie systemów administracyjnych od krytycznych zasobów.
- Prowadzić threat hunting ukierunkowany na ładunki pamięciowe, niestandardowe mechanizmy deszyfracji oraz in-memory loading.
- Regularnie testować gotowość zespołów IR, aby potwierdzić zdolność nie tylko do wykrycia malware, ale też do usunięcia pierwotnej przyczyny kompromitacji.
W środowiskach infrastruktury krytycznej warto dodatkowo łączyć monitoring bezpieczeństwa IT z analizą ryzyka biznesowego i geopolitycznego. Kampanie APT coraz częściej podążają za realnym znaczeniem gospodarczym i strategicznym danego sektora.
Podsumowanie
Kampania przypisana FamousSparrow pokazuje dojrzały model działania APT: wykorzystanie znanej podatności do wejścia, utrzymanie dostępu przez web shelle, adaptację narzędzi po wykryciu części aktywności oraz konsekwentny powrót do tej samej organizacji. Z perspektywy obrony najważniejsza lekcja jest jasna: usunięcie malware nie wystarcza, jeśli nie została zamknięta pierwotna ścieżka dostępu i nie odcięto napastnika od możliwości ponownej infiltracji.
Dla operatorów infrastruktury krytycznej oznacza to konieczność równoczesnego działania na poziomie patch managementu, detekcji, response oraz ochrony tożsamości uprzywilejowanych. Tylko połączenie tych elementów pozwala skutecznie ograniczyć ryzyko powrotu przeciwnika po pozornie zakończonym incydencie.
Źródła
- Security Affairs – FamousSparrow targets Azerbaijani energy sector in multi-wave espionage campaign — https://securityaffairs.com/192113/apt/famoussparrow-targets-azerbaijani-energy-sector-in-multi-wave-espionage-campaign.html
- Bitdefender Labs – ProxyNotShell (background on Exchange exploitation) — https://www.bitdefender.com/en-us/blog/businessinsights/proxynotshell-exploited-in-the-wild/
- Microsoft Security Response Center – Customer guidance for reported vulnerabilities in Microsoft Exchange Server — https://msrc.microsoft.com/blog/2022/09/customer-guidance-for-reported-vulnerabilities-in-microsoft-exchange-server/
- CISA – Microsoft Exchange Server vulnerabilities mitigation and guidance — https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-257a
- MITRE ATT&CK – DLL Side-Loading — https://attack.mitre.org/techniques/T1574/002/