Tailscale i OpenSSH jako trwały backdoor po awarii C2: jak napastnik utrzymał dostęp do systemu

Wprowadzenie do problemu / definicja

Współczesne incydenty bezpieczeństwa coraz częściej pokazują, że wyłączenie infrastruktury command-and-control nie oznacza automatycznego usunięcia zagrożenia. W analizowanym przypadku napastnik wykorzystał legalne narzędzia administracyjne do zbudowania alternatywnego kanału dostępu, który pozostał aktywny nawet po zaniku głównej komunikacji z malware. To przykład nadużycia podejścia living-off-the-land oraz legalnych usług zdalnego dostępu do utrzymania persistence.

Szczególnie niebezpieczne jest to, że użyte komponenty nie muszą wyglądać jak klasyczne złośliwe oprogramowanie. Tailscale i OpenSSH są powszechnie stosowanymi narzędziami administracyjnymi, dlatego w słabiej monitorowanych środowiskach mogą funkcjonować długo bez wzbudzania podejrzeń.

W skrócie

• Badacze przeanalizowali 33 dni aktywności operatora prowadzącego atak przeciwko małej firmie z branży motoryzacyjnej i kilku osobom prywatnym.
• Napastnik korzystał z frameworka Havoc, wieloetapowego uruchamiania w pamięci, keyloggera w Pythonie oraz zaplanowanych zadań.
• Kluczowym elementem operacji była instalacja OpenSSH Server i Tailscale na systemie ofiary.
• Dzięki prywatnej sieci mesh i tunelowaniu SSH atakujący utrzymał dostęp nawet po wyłączeniu głównego C2.
• Po przywróceniu infrastruktury C2 implant wznowił komunikację bez potrzeby ponownej kompromitacji hosta.

Kontekst / historia

Analizowana operacja nie została opisana jako działalność zaawansowanej grupy APT, lecz raczej mniej doświadczonego operatora, który mimo popełnianych błędów skutecznie przejął kilka systemów. To ważna obserwacja dla obrońców: skuteczny incydent nie wymaga dziś zaawansowanego arsenalu malware. W praktyce wystarczą darmowe narzędzia, podstawowe usługi zdalnego dostępu i konsekwentne działania operacyjne.

Z opisu wynika, że głównym celem atakującego było pozyskiwanie danych uwierzytelniających, zwłaszcza do bankowości elektronicznej, poczty e-mail i portali administracyjnych. Nie odnotowano typowych oznak ransomware, szerokiego ruchu lateralnego ani masowej eksfiltracji dokumentów. Taki profil wskazuje raczej na kampanię nastawioną na przejęcie kont i bezpośrednią monetyzację skradzionych poświadczeń.

Analiza techniczna

Łańcuch ataku opierał się głównie na wykonaniu bezplikowym. W początkowej fazie użyto stagera VBScript z opóźnieniem, co miało utrudnić analizę w sandboxie. Następnie uruchamiany był loader PowerShell pobierający komponent .NET odpowiedzialny za załadowanie agenta Havoc Demon bez zapisywania właściwego implantu na dysku. Taki model ogranicza liczbę artefaktów plikowych i utrudnia wykrywanie metodami sygnaturowymi.

Do podniesienia uprawnień operator wykorzystywał mechanizm Start-Process z parametrem RunAs, czyli rozwiązanie zależne od interakcji użytkownika z oknem UAC. Nie był to cichy bypass, ale próba uzyskania zgody użytkownika w celu dalszej eskalacji. Po osiągnięciu wyższego poziomu uprawnień napastnik wdrożył kolejne mechanizmy utrzymania dostępu, w tym zadanie harmonogramu uruchamiane przy logowaniu z najwyższymi uprawnieniami, wstrzykiwanie shellcode do procesu Explorer.exe oraz zmodyfikowaną wersję RustDesk jako kanał zapasowy.

Do zbierania danych wykorzystano prosty keylogger napisany w Pythonie, zapisujący naciśnięcia klawiszy do lokalnego pliku. Co istotne, nie stosował on osobnego beaconingu ani automatycznej eksfiltracji. Operator pobierał dane ręcznie, logując się do systemu i odczytując zapisane keystroke’i. Dodatkowo używał narzędzia powercfg, aby zapobiec przechodzeniu stacji w stan uśpienia i wydłużyć czas aktywnego zbierania informacji.

Najważniejszy etap operacji nastąpił w chwili instalacji OpenSSH Server i Tailscale na stacji roboczej ofiary. Następnie host został dołączony do prywatnej sieci mesh kontrolowanej przez napastnika, skonfigurowano uwierzytelnianie kluczem SSH oraz uruchomiono tunel odwrotny. W praktyce oznaczało to zbudowanie niezależnego kanału administracyjnego działającego poza klasyczną infrastrukturą malware C2.

Taki dostęp nie wymagał wystawiania portów do Internetu i mógł działać przez zaufany, szyfrowany overlay sieciowy. Gdy serwer Havoc przestał odpowiadać, kanał oparty na Tailscale i OpenSSH nadal funkcjonował. Po późniejszym przywróceniu C2 implant wznowił komunikację bez konieczności ponownej infekcji, co pokazuje, że malware było tylko jednym z kilku równoległych sposobów kontroli nad hostem.

Konsekwencje / ryzyko

Największe ryzyko w tego rodzaju incydencie polega na błędnym założeniu, że zablokowanie beaconingu lub przejęcie serwera C2 kończy problem. Jeżeli napastnik wcześniej wdrożył legalne narzędzia zdalnego dostępu, może pozostać aktywny mimo pozornego sukcesu działań naprawczych. To otwiera drogę do ponownego wejścia, dalszego zbierania poświadczeń, rozszerzenia skali działań albo przygotowania kolejnych etapów ataku.

Dodatkowym wyzwaniem jest trudność detekcji. Tailscale i OpenSSH są legalnymi, podpisanymi narzędziami o uzasadnionych zastosowaniach administracyjnych. W organizacjach o słabej inwentaryzacji oprogramowania lub ograniczonym monitoringu endpointów ich obecność może nie wywołać żadnego alarmu. Jeśli obrona skupia się wyłącznie na złośliwych plikach, a nie na nietypowych zachowaniach systemu, taki kanał persistence może pozostać niewidoczny przez długi czas.

Dla małych i średnich firm szczególnie dotkliwe mogą być skutki finansowe wynikające z kradzieży poświadczeń do bankowości i poczty. Przejęcie skrzynek e-mail zwiększa ryzyko oszustw BEC, resetów haseł, podszywania się pod pracowników i manipulowania procesami płatniczymi. Nawet relatywnie prosty technicznie atak może więc przełożyć się na poważne straty operacyjne i reputacyjne.

Rekomendacje

Organizacje powinny traktować wykrycie komunikacji C2 jako początek pełnego polowania na persistence, a nie jako zakończenie incydentu. W praktyce oznacza to konieczność sprawdzenia wszystkich alternatywnych ścieżek dostępu, w tym usług mesh VPN, serwerów SSH, tuneli odwrotnych, narzędzi RMM oraz mechanizmów harmonogramu zadań.

W warstwie detekcyjnej warto wdrożyć alertowanie na instalację OpenSSH Server na stacjach roboczych Windows, o ile nie wynika to bezpośrednio z polityki administracyjnej. Należy również monitorować procesy i usługi powiązane z Tailscale na hostach, które standardowo nie korzystają z takiego oprogramowania. Cenne będą też reguły wykrywające użycie poleceń typu ssh -R, nietypowe uruchomienia wscript.exe z katalogów użytkownika, zadania harmonogramu uruchamiane z najwyższymi uprawnieniami oraz zmiany ustawień zasilania wykonywane przez powercfg.

Po stronie hardeningu warto ograniczyć możliwość instalacji nieautoryzowanego oprogramowania przez application control, zasadę least privilege i ścisłą kontrolę lokalnych administratorów. Dobrą praktyką pozostaje również segmentacja ruchu wychodzącego oraz blokowanie niezatwierdzonych usług, które mogą służyć do budowy trwałych tuneli do zewnętrznych sieci overlay.

W odpowiedzi na incydent należy zweryfikować co najmniej:

• listę zainstalowanych usług i funkcji systemowych,
• klucze SSH oraz pliki authorized_keys,
• zaplanowane zadania,
• narzędzia zdalnego dostępu i oprogramowanie RMM,
• aktywne interfejsy VPN i klientów mesh,
• artefakty keyloggerów oraz skryptów stagingowych,
• historię poleceń PowerShell, VBScript i procesów interpretera.

Kluczowe jest przyjęcie założenia, że legalne narzędzie administracyjne może pełnić rolę backdoora. Z tego powodu polityki bezpieczeństwa powinny oceniać przede wszystkim kontekst użycia, a nie wyłącznie reputację samej binarki.

Podsumowanie

Opisany incydent pokazuje wyraźną zmianę w praktyce operacyjnej cyberprzestępców: trwały dostęp do systemu nie musi już opierać się wyłącznie na klasycznym malware i dedykowanym serwerze C2. Połączenie legalnej sieci mesh VPN, serwera SSH i prostych mechanizmów persistence może wystarczyć do utrzymania kontroli nad hostem nawet po awarii lub przejęciu głównej infrastruktury atakującego.

Dla zespołów bezpieczeństwa najważniejszy wniosek jest prosty: remediacja nie może kończyć się na usunięciu implantu lub zablokowaniu komunikacji z C2. Konieczne jest aktywne poszukiwanie cichych, wtórnych kanałów dostępu, które wyglądają jak zwykłe narzędzia administracyjne, ale w praktyce pełnią funkcję trwałego backdoora.

Źródła

1. The Hacker News — https://thehackernews.com/2026/06/junior-hacker-used-tailscale-and.html
2. Cato CTRL Threat Research: Operation Poisson – Analyzing a Cybercriminal’s Entire Operation — https://www.catonetworks.com/blog/cato-ctrl-operation-poisson-analyzing-a-cybercriminals-entire-operation/