Wprowadzenie do problemu / definicja
Botnet Sality to jedna z najdłużej działających i najbardziej odpornych infrastruktur złośliwego oprogramowania obserwowanych w cyberprzestrzeni. Przez lata sieć ta była wykorzystywana do prowadzenia kampanii spamowych, kradzieży danych uwierzytelniających, ataków DDoS oraz obsługi zainfekowanych hostów pełniących funkcję pośredników w dalszych operacjach przestępczych.
Najnowsza operacja wymierzona w Sality pokazuje, że skuteczne przeciwdziałanie takim zagrożeniom wymaga połączenia działań prawnych, technicznych i międzynarodowej współpracy między sektorem publicznym oraz prywatnym.
W skrócie
Sality był aktywny od 2003 roku i przez ponad dwie dekady utrzymywał zdolność do infekowania oraz kontrolowania dużej liczby urządzeń. W skoordynowanej operacji organy ścigania przejęły elementy infrastruktury powiązanej z botnetem, a partnerzy branżowi odcięli zainfekowane systemy od przestępczej sieci.
- przejęto domeny wykorzystywane przez infrastrukturę Sality,
- zakłócono komunikację między zainfekowanymi hostami,
- uruchomiono mechanizmy identyfikacji nadal zainfekowanych urządzeń,
- w działania zaangażowano podmioty z USA i Europy.
Kontekst / historia
Długowieczność Sality wynikała nie tylko z samej funkcjonalności malware, lecz przede wszystkim z odpornej architektury operacyjnej. Botnet przez lata ewoluował, dostosowując się do zmian w krajobrazie zagrożeń i sposobach monetyzacji aktywności cyberprzestępczej.
W początkowych fazach Sality kojarzono głównie z infekowaniem plików wykonywalnych i budowaniem szerokiej sieci zainfekowanych urządzeń. Z czasem infrastruktura była wykorzystywana do coraz szerszego katalogu działań, w tym do kradzieży poświadczeń, dystrybucji dodatkowych komponentów malware oraz wspierania ataków rozproszonych.
W późniejszych odsłonach obserwowano także mechanizmy związane z oszustwami finansowymi, w tym przechwytywanie operacji kopiowania adresów portfeli kryptowalutowych i ich podmianę na adresy kontrolowane przez napastników. To pokazuje, że operatorzy Sality konsekwentnie rozwijali model zarabiania na przejętych systemach.
Analiza techniczna
Największym wyzwaniem w neutralizacji Sality była jego architektura peer-to-peer. W odróżnieniu od klasycznych botnetów opartych na scentralizowanych serwerach command-and-control, Sality wykorzystywał rozproszoną komunikację pomiędzy zainfekowanymi hostami. Taki model znacząco utrudnia likwidację, ponieważ usunięcie pojedynczych punktów sterowania nie musi prowadzić do całkowitego przerwania działania sieci.
Dodatkowo malware potrafił osadzać się w plikach wykonywalnych obecnych na zainfekowanych systemach. Taki mechanizm zwiększał trwałość infekcji oraz ułatwiał dalsze rozprzestrzenianie się złośliwego kodu bez potrzeby ciągłego uruchamiania nowych kampanii dystrybucyjnych.
Operacja neutralizacji objęła zarówno działania procesowe, jak i techniczne. Przejęcie domen ograniczyło zdolność botnetu do komunikacji operacyjnej, natomiast przekierowanie ruchu zainfekowanych systemów do kontrolowanej infrastruktury umożliwiło ich bezpieczną identyfikację. Taki model sinkholingu pozwala rozpoznać aktywne ofiary i przekazać informacje odpowiednim podmiotom odpowiedzialnym za notyfikację oraz remediację.
Konsekwencje / ryzyko
Choć operacja znacząco osłabiła Sality, nie oznacza to automatycznego usunięcia malware ze wszystkich zainfekowanych urządzeń. Hosty, które wcześniej zostały skompromitowane, mogą nadal zawierać zmodyfikowane pliki wykonywalne, mechanizmy trwałości lub dodatkowe ładunki pobrane w trakcie aktywności botnetu.
Dla organizacji oznacza to kilka istotnych ryzyk. Po pierwsze, wcześniejsza infekcja mogła doprowadzić do ujawnienia poświadczeń lub innych wrażliwych danych. Po drugie, zainfekowane systemy mogły zostać wykorzystane jako element infrastruktury DDoS, sieci proxy albo platformy do dalszej dystrybucji złośliwego oprogramowania. Po trzecie, niepełne oczyszczenie środowiska może prowadzić do ponownej aktywacji szkodliwych mechanizmów lub przejęcia pozostawionych backdoorów przez innych aktorów zagrożeń.
Przypadek Sality potwierdza również, że botnety P2P pozostają szczególnie problematyczne dla przedsiębiorstw i instytucji publicznych. Nawet częściowe zakłócenie ich infrastruktury nie zawsze przekłada się na szybkie wyeliminowanie całego zagrożenia.
Rekomendacje
Informacje o neutralizacji Sality powinny skłonić organizacje do przeglądu środowiska pod kątem starszych i trudnych do wykrycia infekcji. W praktyce oznacza to potrzebę analizy telemetrii bezpieczeństwa, logów sieciowych oraz wskaźników kompromitacji związanych z nietypową komunikacją i zachowaniem procesów systemowych.
- przeskanować stacje robocze i serwery pod kątem modyfikacji plików binarnych,
- zweryfikować mechanizmy trwałości, wpisy autostartu i zadania harmonogramu,
- przeanalizować ruch wychodzący pod kątem anomalii i komunikacji rozproszonej,
- wymusić reset haseł dla kont używanych na zainfekowanych systemach,
- przeprowadzić rotację kluczy, tokenów i innych danych dostępowych,
- wzmocnić segmentację sieci, aby ograniczyć rozprzestrzenianie się infekcji,
- zablokować znane wskaźniki kompromitacji na poziomie DNS, proxy i zapór,
- zaktualizować reguły detekcyjne dla malware plikowego i zagrożeń P2P,
- w razie potwierdzonego naruszenia współpracować z CERT-em, operatorem telekomunikacyjnym lub partnerem MDR.
W przypadku wykrycia śladów infekcji nie należy ograniczać się wyłącznie do usunięcia próbki malware. Konieczne jest pełne dochodzenie obejmujące możliwość ruchu bocznego, kradzieży poświadczeń oraz obecność wtórnych komponentów dostarczonych przez botnet.
Podsumowanie
Sality pozostaje jednym z najbardziej charakterystycznych przykładów trwałego botnetu, którego skuteczność opierała się na połączeniu malware plikowego z odporną architekturą peer-to-peer. Skoordynowana operacja organów ścigania i partnerów prywatnych znacząco ograniczyła możliwości tej infrastruktury, ale pełne ograniczenie ryzyka zależy od wykrycia i oczyszczenia wszystkich zainfekowanych urządzeń.
Dla zespołów bezpieczeństwa to ważne przypomnienie, że zagrożenia obecne w środowisku przez wiele lat mogą nadal stanowić realny problem operacyjny, zwłaszcza jeśli wykorzystują zdecentralizowane modele komunikacji i mechanizmy utrwalania dostępu.