OctLurk i SilkLurk: modułowe backdoory w Azji Centralnej

Kaspersky opisał długotrwałą kampanię szpiegowską wymierzoną głównie w instytucje rządowe i publiczne Azji Centralnej. Operator używa trzech nowych narzędzi: backdoorów OctLurk i SilkLurk oraz serwera pośredniczącego LurkProxy. Aktywność jest obserwowana co najmniej od stycznia 2025 r. i objęła organizacje w Afganistanie, Kirgistanie, Tadżykistanie, Uzbekistanie, Kazachstanie oraz Syrii.

Badacze widzą językowe i infrastrukturalne ślady wskazujące na operatora chińskojęzycznego, ale kampania nie została przypisana do znanej grupy. To ważne: podobne narzędzia lub serwery są wskazówką analityczną, nie dowodem tożsamości sprawcy.

Trzy elementy jednego zestawu

Pełna analiza Securelist pokazuje architekturę nastawioną na ciche rozszerzanie możliwości po wejściu do sieci.

OctLurk jest wstrzykiwany do pamięci przez loader. Zbiera informacje o systemie, szyfruje je i wysyła do zakodowanego serwera C2. Następnie może odbierać wtyczki wykonywane bezpośrednio w pamięci. Operator nie musi wdrażać pełnego zestawu od razu — może dobrać funkcje do wartości konkretnej stacji.

SilkLurk uruchamia się przez DLL side-loading: legalny program ładuje bibliotekę kontrolowaną przez napastnika. Backdoor łączy się z C2 po TCP, odbiera konfigurację i wstrzykuje kolejne moduły do pamięci. W analizowanych przypadkach służył także do etapowania dokumentów, archiwizacji i wdrażania PlugX.

LurkProxy działa jako reverse proxy w trybie SOCKS5 albo transparentnym. Dzięki temu przejęty host może stać się punktem wejścia do usług wewnętrznych i źródłem ruchu wyglądającego jak komunikacja z sieci ofiary.

Dlaczego dekodowanie zależne od hosta ma znaczenie

OctLurk wiąże dekodowanie ładunku m.in. z numerem seryjnym dysku, a SilkLurk z nazwą komputera. Próbka przeniesiona na inne stanowisko badawcze może nie odsłonić poprawnego kodu. To nie jest tylko zaciemnianie: artefakt zostaje „dopasowany” do celu i gorzej zachowuje się w przypadkowej piaskownicy.

Dla obrońcy oznacza to, że statyczne kopiowanie jednego pliku do laboratorium może dać fałszywe poczucie bezpieczeństwa. Warto zachować kontekst hosta, pamięć procesu, drzewo uruchomień i parametry środowiska. Analiza pamięci oraz telemetria EDR stają się ważniejsze od samego hasha pliku.

Co robi operator po uzyskaniu dostępu

Moduły opisane przez Kaspersky obsługują wykonywanie poleceń, operacje na plikach, schowek, zrzuty ekranu, syntetyczne zdarzenia myszy i klawiatury oraz rozpoznanie sieci. W obserwowanych incydentach napastnicy:

• eksportowali zdarzenia udanych logowań zdalnych;
• używali Impacket secretsdump.py do pozyskiwania hashy z kontrolerów domeny;
• uruchamiali keylogger podszywający się pod AnyDesk;
• wyciągali hasła z Chrome i Firefoksa;
• wdrażali Pandora RC do zdalnego dostępu;
• skanowali sieci narzędziem Fscan i próbowali logować się do SSH oraz MySQL;
• łączyli się z serwerami poczty, aby zbierać lub modyfikować wiadomości;
• pakowali dokumenty przez WinRAR lub 7-Zip i etapowali je na udziałach sieciowych.

To ciąg od stacji roboczej do domeny, poczty i dokumentów. Dlatego detekcja pojedynczego loadera nie zamyka incydentu. Potrzebne jest ustalenie, które tożsamości przejęto i dokąd ruch był tunelowany.

Priorytety detekcji

Nie warto budować całej obrony na domenach i adresach IP z jednego raportu. Infrastruktura się zmieni, a zachowania pozostaną użyteczne dłużej. SOC powinien korelować:

1. Nietypowe pary legalny EXE + DLL ładowana z katalogu użytkownika lub archiwum.
2. Procesy wykonujące wstrzykiwanie pamięci i długotrwałe połączenia TCP bez typowego protokołu aplikacyjnego.
3. Uruchamianie secretsdump, dostęp do danych przeglądarek, zrzuty LSASS i eksport logów logowania.
4. Nowe archiwa powstające tuż przed transferem oraz masowy odczyt dokumentów z udziałów.
5. SOCKS5 lub ruch tunelowany z hosta, który nie pełni funkcji proxy.
6. Program „AnyDesk” uruchomiony z nietypowej ścieżki albo niezgodny podpisem i hashem z zatwierdzonym pakietem.

Jeśli wykryto podobne zachowanie, izolacja jednej stacji nie wystarczy. Należy zachować pamięć i artefakty, unieważnić dotknięte poświadczenia z czystego systemu, sprawdzić kontrolery domeny, serwery pocztowe i hosty dostępne przez tunel, a następnie szukać etapowanych archiwów.

Kto jest narażony

Raport wymienia administrację, ministerstwa spraw zagranicznych, ochronę zdrowia, badania, logistykę, organy ścigania, planowanie miejskie, zarządzanie obiektami i edukację. Nie oznacza to jednak, że prywatne firmy spoza regionu są „odporne”. Narzędzia są przenośne, a łańcuch post-exploitation odpowiada celom, które mają katalog domenowy, pocztę i wartościowe dokumenty.

Organizacje współpracujące z instytucjami publicznymi w regionie powinny przejrzeć telemetryczne ślady, dostęp dostawców i konta zdalne. Przydatne są tu procesy opisane w cyklu Cyber Threat Intelligence i planie reagowania na incydenty.

Fakty źródłowe a wnioski Breachroad

Nazwy malware’u, opis modułów, lista sektorów i obserwowane działania pochodzą z telemetrii i analizy Kaspersky. Początkowy wektor dostępu pozostaje nieznany, a aktywność nie została przypisana do konkretnej znanej grupy. Powiązania infrastruktury z innymi klastrami nie rozstrzygają autorstwa.

Wnioskiem Breachroad jest priorytet dla detekcji zachowań, analizy pamięci i pełnego przeglądu tożsamości po wykryciu tunelu lub credential dumpingu. Szkolenia cyberbezpieczeństwa dla zespołów technicznych uczą łączyć artefakty w historię ataku, a audyt bezpieczeństwa IT może sprawdzić segmentację, EDR, kontrolery domeny i gotowość reakcji.