PCPJack przejął 230 serwerów chmurowych i zbudował ukrytą sieć przekaźników SMTP

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

PCPJack to aktywność cyberprzestępcza związana z kompromitacją środowisk chmurowych i wykorzystywaniem przejętych zasobów do dalszych operacji. Najnowsze ustalenia pokazują, że atakujący wykorzystali serwery działające w AWS, Google Cloud i Microsoft Azure do budowy rozproszonej, ukrytej infrastruktury przekaźników SMTP.

Tego rodzaju sieć może służyć do wysyłki spamu, prowadzenia kampanii phishingowych, obchodzenia mechanizmów reputacyjnych i ukrywania prawdziwego źródła ruchu. Dla ofiar oznacza to nie tylko naruszenie bezpieczeństwa hostów, ale też ryzyko wykorzystania ich zasobów jako zaplecza do kolejnych ataków.

W skrócie

PCPJack miał przejąć około 230 serwerów biznesowych w różnych regionach świata.
Zainfekowane hosty zostały wykorzystane jako węzły ukrytej sieci relay SMTP.
Badacze odkryli na serwerze C2 otwarte katalogi z kodem źródłowym, binariami, logami wdrożeń i konfiguracją narzędzi.
Atakujący selekcjonowali tylko te hosty, które mogły realizować ruch wychodzący do usług SMTP.
Operacja miała charakter oportunistyczny i była aktywna w chwili wykrycia.

Kontekst / historia

PCPJack był wcześniej opisywany jako framework skupiony na kradzieży poświadczeń w środowiskach chmurowych. W poprzednich analizach zagrożenie łączono z aktywnością przypominającą robaka, wymierzoną w publicznie dostępne systemy, błędnie zabezpieczone usługi chmurowe, komponenty kontenerowe i środowiska deweloperskie.

W najnowszym incydencie widać jednak wyraźną zmianę profilu operacyjnego. Zamiast ograniczać się do pozyskiwania danych uwierzytelniających, operatorzy zaczęli wykorzystywać przejęte hosty jako praktyczną infrastrukturę do przekazywania poczty. To sugeruje przejście od etapu dostępu i eksfiltracji do etapu monetyzacji lub budowy zaplecza pod kolejne kampanie.

Analiza techniczna

Z ujawnionych artefaktów wynika, że operatorzy korzystali z zestawu wdrożeniowego opartego na frameworku Sliver oraz narzędziach tunelujących, takich jak Chisel. Na hostach ofiar złośliwy komponent był zapisywany jako ukryty plik pod ścieżką /var/tmp/.xs, a następnie utrzymywany w sposób zapewniający persystencję.

Skrypty wdrożeniowe ładowały konfigurację klienta C2 i filtrowały aktywne beacony systemów Linux, które zgłaszały się w określonym oknie czasowym. Każdemu beaconowi przypisywano port SOCKS5 na podstawie skrótu MD5 identyfikatora Sliver UUID, z mapowaniem do zakresu 10000–14999. Taki model upraszcza zarządzanie tunelami i pozwala uniknąć ręcznego utrzymywania rejestru portów.

Kluczowym etapem operacji była walidacja użyteczności przejętego hosta. Skrypty sprawdzały, czy system może realizować połączenia wychodzące do serwera SMTP na porcie 587. Tylko hosty spełniające ten warunek były kwalifikowane do dalszego wykorzystania jako element sieci relay.

Badacze opisali także skrypt diagnostyczny weryfikujący obecność binariów Chisel, aktywność procesu, dostępną przestrzeń dyskową, osiągalność portu 9000 na serwerze C2 oraz oznaki persystencji, takie jak wpisy cron i usługi systemd. Dodatkowy proces w Pythonie monitorował aktywne tunele, testował ich zdolność do obsługi SMTP i usuwał niesprawne kanały z puli. Zweryfikowane proxy były następnie rozszerzane o metadane, takie jak adres IP, kraj i ASN, po czym synchronizowane do kolejnego systemu co pięć minut.

Całość wskazuje na dojrzały model operacyjny: kompromitacja hosta, tunelowanie ruchu, test przydatności do relay SMTP, automatyczne usuwanie nieaktywnych węzłów i ciągła synchronizacja listy działających punktów wyjścia. Taka architektura zwiększa odporność infrastruktury przestępczej i utrudnia jej szybkie wyłączenie.

Konsekwencje / ryzyko

Przejęcie serwerów chmurowych do roli przekaźników SMTP generuje kilka równoległych zagrożeń. Organizacja może stać się nieświadomym uczestnikiem kampanii spamowych, phishingowych lub oszustw BEC, a ruch wychodzący z legalnych adresów IP dostawców chmurowych może przez pewien czas omijać część mechanizmów filtrujących.

Nie mniej istotne jest samo trwałe naruszenie bezpieczeństwa hosta. Obecność beaconów, tuneli i mechanizmów persystencji oznacza, że atakujący mogą utrzymać dostęp, rozszerzać zasięg kompromitacji lub pozyskiwać kolejne dane. Dodatkowo incydent może skutkować kosztami po stronie ofiary, blokadą reputacyjną adresów IP, zgłoszeniami nadużyć od partnerów oraz ograniczeniami narzuconymi przez dostawcę chmury.

Z perspektywy SOC i zespołów IR problem polega na tym, że ruch relay może wyglądać jak zwykła komunikacja wychodząca. Jeśli organizacja nie monitoruje anomalii w ruchu SMTP, połączeń SOCKS5 i nietypowych tuneli, wykrycie takiej aktywności może nastąpić z dużym opóźnieniem.

Rekomendacje

Organizacje korzystające z AWS, Google Cloud i Azure powinny potraktować ten przypadek jako sygnał do przeglądu zabezpieczeń hostów linuksowych i środowisk wystawionych do Internetu. Szczególnie ważne są zarówno kontrole host-based, jak i ograniczenia ruchu wychodzącego.

Ograniczyć ekspozycję usług administracyjnych i deweloperskich do Internetu oraz wymusić dostęp przez VPN, bastiony lub architekturę zero trust.
Monitorować procesy i pliki w katalogach tymczasowych, w tym ukryte pliki w /var/tmp, /tmp oraz katalogach użytkowników.
Wykrywać nietypowe połączenia wychodzące SMTP, SOCKS5 i tunele do nieautoryzowanych adresów.
Sprawdzać hosty pod kątem obecności narzędzi tunelujących, beaconów C2 i niestandardowych binariów wieloarchitekturowych.
Rotować poświadczenia przechowywane na systemach potencjalnie narażonych, w tym klucze SSH, sekrety aplikacyjne i tokeny chmurowe.
Wdrożyć egress filtering ograniczający możliwość realizacji nieautoryzowanych połączeń na porty pocztowe.
Wykorzystać EDR/XDR oraz telemetrię chmurową do wykrywania persystencji, anomalii procesowych i podejrzanej komunikacji z C2.
Przeanalizować logi systemowe, logi dostawcy chmury i konfigurację uruchamianych usług pod kątem śladów wcześniejszej kompromitacji.

W praktyce sama blokada pojedynczego binarium nie wystarczy. Jeżeli środowisko nadal pozwala na swobodne zestawianie tuneli i realizację ruchu SMTP na zewnątrz, atakujący mogą szybko odtworzyć infrastrukturę na innym hoście.

Podsumowanie

Incydent związany z PCPJack pokazuje, że przejęta infrastruktura chmurowa może zostać szybko przekształcona w wyspecjalizowane zaplecze operacyjne do dalszych ataków. Odkryta sieć około 230 węzłów relay SMTP wskazuje na wysoki poziom automatyzacji, skuteczną selekcję hostów i stałe utrzymywanie sprawności całej infrastruktury.

Dla obrońców to wyraźny sygnał, że bezpieczeństwo chmury nie kończy się na ochronie konsoli administracyjnej i zarządzaniu tożsamością. Równie ważne są kontrola ruchu wychodzącego, monitoring persystencji na hostach, detekcja tuneli oraz szybka reakcja po każdym podejrzeniu kompromitacji.