Malicious Go Crypto Module kradnie hasła i instaluje backdoora Rekoobe — groźny łańcuch supply chain w ekosystemie Go - Security Bez Tabu

Malicious Go Crypto Module kradnie hasła i instaluje backdoora Rekoobe — groźny łańcuch supply chain w ekosystemie Go

Wprowadzenie do problemu / definicja luki

Opisywana kampania to klasyczny atak na łańcuch dostaw (software supply chain attack) w wydaniu “look-alike dependency” — złośliwy moduł Go podszywa się pod jedną z najbardziej zaufanych bibliotek w ekosystemie: golang.org/x/crypto. Celem nie jest jedynie psucie buildów, ale kradzież sekretów w momencie ich wpisywania i szybkie przejście do trwałej kompromitacji Linuxa przez SSH oraz instalację backdoora Rekoobe.

Kluczowy element “sprytu” ataku: wykorzystanie tego, jak Go pobiera moduły (proxy/mirror) i jak łatwo w review zmian w go.mod przeoczyć, że “crypto” pochodzi z innego korzenia modułu niż oczekiwany.

W skrócie

  • Złośliwy moduł: github[.]com/xinfeisoft/crypto (podszycie pod golang.org/x/crypto).
  • Backdoor wstawiono do ssh/terminal/terminal.go i przechwytywano sekrety z ReadPassword() (hasła, passphrase, tokeny wpisywane w CLI).
  • Sekrety są zapisywane lokalnie (artefakt na dysku), następnie moduł pobiera wskaźnik konfiguracyjny z GitHub Raw i wykonuje treść jako polecenia shella.
  • Kolejny etap dodaje klucz SSH do authorized_keys, luzuje reguły iptables, pobiera payloady maskowane rozszerzeniem .mp5, w tym backdoora Rekoobe.
  • Go security team zablokował moduł na publicznym Go module proxy (zwracany błąd 403 SECURITY ERROR), ale repozytoria i ślady kompromitacji nadal mogą istnieć w środowiskach ofiar.

Kontekst / historia / powiązania

Namespace confusion i “zaufane” korzenie modułów

W Go to ścieżka modułu jest tożsamością zależności. W praktyce oznacza to, że github.com/xinfeisoft/crypto może wyglądać “normalnie” w grafie zależności, jeśli reviewer patrzy tylko na nazwę “crypto”, a nie na pełny import path i pochodzenie. Dodatkowo legalny golang.org/x/crypto ma publiczne mirrory (np. GitHub), co bywa nadużywane do tworzenia pozorów “rutynowego” importu.

Rekoobe: stary backdoor, wciąż użyteczny

Rekoobe to rodzina trojanów/backdoorów dla Linuxa obserwowana co najmniej od 2015 r., zdolna m.in. do wykonywania poleceń, przesyłania plików i pobierania kolejnych komponentów.
To, że łańcuch dostaw kończy się “znanym” backdoorem, jest typowe: atakujący inwestują w skuteczny “pierwszy krok” (zależność), a potem wdrażają sprawdzony implant.

Analiza techniczna / szczegóły luki

1) Backdoor w ReadPassword() — kradzież sekretów “na krawędzi”

Atakujący zmodyfikowali implementację ReadPassword() w ssh/terminal/terminal.go. To strategiczne miejsce, bo funkcja jest wywoływana dokładnie wtedy, gdy użytkownik wpisuje poufne dane w terminalu.

Z ustaleń Socket wynika, że moduł:

  • przechwytuje wpisany sekret,
  • zapisuje go do nietypowej ścieżki: /usr/share/nano/.lock,
  • pobiera “konfigurację” z GitHub Raw (update.html),
  • wysyła sekret HTTP POST pod adres zwrócony z tej konfiguracji,
  • pobiera kolejną treść i wykonuje ją przez /bin/sh.

2) GitHub Raw jako kanał sterowania (indirection)

Zamiast hardkodować endpoint C2, kampania używa pliku w repozytorium (GitHub Raw) jako “przełącznika” umożliwiającego rotację infrastruktury bez publikowania nowej wersji modułu.

3) Linux stager: SSH persistence + osłabienie zapory + payloady “.mp5”

Pobrany skrypt (stager):

  • dopisuje klucz atakującego do /home/ubuntu/.ssh/authorized_keys,
  • ustawia domyślne polityki iptables na ACCEPT,
  • pobiera kolejne payloady z domen związanych ze spoolsv[.]cc,
  • maskuje binarki jako pliki .mp5 (np. sss.mp5, 555.mp5).

Socket opisał też konkretne endpointy i wskaźniki sieciowe (m.in. 154[.]84[.]63[.]184, komunikacja po TCP/443).

4) Dystrybucja przez ekosystem Go (proxy/mirror)

Ważna obserwacja operacyjna: nawet jeśli moduł widnieje w katalogach, kluczowa jest ścieżka pobierania. Go domyślnie korzysta z proxy (np. proxy.golang.org) w mechanizmie rozwiązywania wersji i pobierania modułów — i to właśnie tam moduł został zablokowany po zgłoszeniu, zwracając 403 SECURITY ERROR.

Praktyczne konsekwencje / ryzyko

Kogo to boli najbardziej:

  • zespoły DevOps/infra używające narzędzi CLI w Go (bastiony, jump hosty, admin boxy),
  • CI/CD na Linuxie (runner-y budujące obrazy, narzędzia deploy),
  • narzędzia, które proszą o hasła do SSH, baz danych, API lub KMS w trybie interaktywnym.

Dlaczego to groźne:

  • sekret jest kradziony przed jakimkolwiek hashowaniem/encryption po stronie aplikacji (bo to moment wejścia),
  • persistence przez authorized_keys oznacza łatwy, “cichy” powrót,
  • zmiana polityk iptables może ułatwić dalsze ruchy lateralne i ściąganie narzędzi,
  • Rekoobe zapewnia trwały kanał zdalnych poleceń i pobierania kolejnych payloadów.

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowa higiena zależności (Go)

  • Przeskanuj repozytoria pod kątem importów i wpisów w go.mod / go.sum zawierających: github.com/xinfeisoft/crypto.
  • Traktuj każdą zmianę w go.mod jako zmianę bezpieczeństwa: review “pełnej ścieżki modułu”, nie tylko nazwy pakietu.
  • W CI dodaj reguły deny-list dla znanych złych modułów i alerty na “podejrzane utility deps” umożliwiające shell/HTTP w kryptografii (w tej kampanii dołączono m.in. bibliotekę ułatwiającą pipeline’y i sieć).

2) Wykrywanie na endpointach (Linux)

Ustaw detekcje/alerty na:

  • zapis do /usr/share/nano/.lock,
  • pobranie raw.githubusercontent[.]com/.../update[.]html i następujący po nim dynamiczny POST/GET,
  • wykonania /bin/sh -c <treść z sieci> lub wzorce “curl | sh”,
  • modyfikacje /home/ubuntu/.ssh/authorized_keys,
  • zmiany domyślnych polityk iptables na ACCEPT.

3) Blokady sieciowe i IOC (minimum)

Jeśli to pasuje do Twojego modelu blokowania (np. egress filtering), rozważ blokadę:

  • domen/hostów: img.spoolsv[.]cc, img.spoolsv[.]net, spoolsv[.]cc, spoolsv[.]net,
  • IP: 154[.]84[.]63[.]184 (TCP/443),
  • hash’y payloadów (SHA256):
    • sss.mp5: 4afdb3f5914beb0ebe3b086db5a83cef1d3c3c4312d18eff672dd0f6be2146bc
    • 555.mp5: 8b0ec8d0318347874e117f1aed1b619892a7547308e437a20e02090e5f3d2da6

4) Reakcja na incydent (jeśli podejrzewasz infekcję)

  • Potraktuj host jako skompromitowany: rotuj hasła/passphrase wpisywane na tym systemie (SSH, DB, API, itp.).
  • Sprawdź authorized_keys (szczególnie użytkownika ubuntu) oraz historię zmian reguł iptables.
  • Zidentyfikuj procesy/połączenia do 154[.]84[.]63[.]184:443 i artefakty .mp5 pobierane z img.spoolsv[.]cc.

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

W porównaniu do typowych typosquatów (literówki w nazwie), tutaj kluczowa jest wiarygodność “kultowej” biblioteki oraz atak na “credential edge” (miejsce, gdzie sekret pojawia się jawnie). To z reguły daje:

  • mniej szumu (payload uruchamia się dopiero przy realnym użyciu ReadPassword()),
  • większą wartość zdobytych danych (prawdziwe loginy, passphrase, tokeny),
  • łatwiejsze wejście w persistence (SSH key).

Dodatkowo użycie GitHub Raw jako “przekaźnika” upraszcza rotację infrastruktury i utrudnia blokady oparte wyłącznie o statyczne IoC w kodzie.

Podsumowanie / kluczowe wnioski

  • To nie jest “kolejny złośliwy pakiet” — to celowanie w fundament ekosystemu Go i kradzież sekretów w najbardziej krytycznym momencie: przy wpisywaniu w terminalu.
  • Łańcuch ataku jest prosty i skuteczny: backdoor w ReadPassword() → GitHub Raw jako indirection → sh stager → SSH persistence → Rekoobe.
  • Blokada na Go proxy (403 SECURITY ERROR) ogranicza ryzyko “dla nowych ofiar” w domyślnej ścieżce pobierania, ale nie usuwa skutków dla środowisk, które już pobrały moduł lub używają niestandardowych źródeł.
  • Największy “wins” obrony: twarde review go.mod, skan zależności w PR, oraz detekcje na konkretne zachowania (artefakty plikowe, GitHub Raw fetch + shell exec, modyfikacja authorized_keys).

Źródła / bibliografia

  1. The Hacker News — “Malicious Go Crypto Module Steals Passwords, Deploys Rekoobe Backdoor” (27 lutego 2026). (The Hacker News)
  2. Socket Research — “Malicious Go ‘crypto’ Module Steals Passwords and Deploys Rekoobe Backdoor” (26 lutego 2026). (Socket)
  3. Go.dev — Go Modules Reference (mechanika pobierania modułów i proxy). (go.dev)
  4. Doctor Web — “Rekoobe Trojan threatens Linux users” (3 grudnia 2015). (Dr.Web)
  5. Intezer — “Linux Rekoobe Operating with New, Undetected Malware Samples” (20 stycznia 2020). (Intezer)