PCPJack przejmuje serwery w chmurze, by zbudować ukrytą sieć przekaźników SMTP

Zaobserwowano, że aktor zagrożeń znany jako PCPJack przejmuje serwery w chmurze Amazon Web Services, Google Cloud i Microsoft Azure, aby stworzyć ukrytą sieć przekaźników SMTP.

Według Hunt.io skompromitowane serwery firmowe w Stanach Zjednoczonych, Europie i Azji zostały po cichu przekształcone w proxy SMTP. Hosty te były weryfikowane pod kątem możliwości wychodzącego przekazywania poczty, a następnie synchronizowane z odbiorcą docelowym co pięć minut.

Operacja wydawała się aktywna w chwili, gdy badacze ją odkryli, co pokazuje, że infrastruktura nie była teoretyczna ani uśpiona. Działała, była zorganizowana i zaprojektowana do obsługi dostarczania poczty na dużą skalę.

Co odkryto?

Hunt.io odkryło operację po znalezieniu dwóch otwartych katalogów na serwerze dowodzenia i kontroli (C2) pod adresem:

213.136.80[.]73

Katalogi były wystawione bez uwierzytelniania i zawierały znaczną ilość materiałów operacyjnych.

Badacze znaleźli:

kod źródłowy
skompilowane pliki binarne
logi wdrożeń
skanery internetu
narzędzia do eksploatacji
konfigurację Sliver C2
narzędzia do wdrażania proxy SMTP
pliki binarne do tunelowania Chisel
skrypty do automatyzacji wdrażania w skompromitowanych systemach Linux

Te ujawnione dane dały badaczom rzadki wgląd w to, jak atakujący przekształcali skompromitowane serwery w chmurze w infrastrukturę przekaźnikową.

Kim jest PCPJack?

PCPJack został po raz pierwszy opisany przez SentinelOne w kwietniu 2026 r.

Wówczas grupę powiązano z frameworkiem do kradzieży poświadczeń wymierzonym w usługi chmurowe. Framework wydawał się też kończyć i usuwać procesy lub artefakty powiązane z TeamPCP, inną grupą hakerską znaną z ataków na łańcuch dostaw oprogramowania.

Relacja między PCPJack a TeamPCP pozostaje niejasna, ale to nakładanie się jest godne uwagi. Sugeruje rywalizację, porządki lub konflikt w szerszym ekosystemie cyberprzestępczym.

Najnowsza aktywność pokazuje, że PCPJack wychodzi poza kradzież poświadczeń i przechodzi do nadużywania infrastruktury, wykorzystując skompromitowane serwery do budowy opartej na chmurze sieci przekaźników.

Zamiana serwerów w chmurze w proxy SMTP

Odzyskane pliki pokazują, że PCPJack używał skompromitowanych serwerów Linux jako węzłów proxy.

Atakujący korzystali z Sliver, frameworka dowodzenia i kontroli, do zarządzania zainfekowanymi hostami. Użyli też Chisel, narzędzia do tunelowania, aby stworzyć funkcjonalność proxy SOCKS5 w skompromitowanych systemach.

Na maszynach ofiar plik binarny Chisel był zrzucany jako ukryty plik z kropką na początku nazwy i utrwalany w lokalizacji:

/var/tmp/.xs

Taka nazwa i lokalizacja mają sprawić, że plik będzie mniej widoczny podczas pobieżnej kontroli.

Skrypty wdrażające łączyły się z lokalnym Sliver C2, wyświetlały listę aktywnych beaconów Linux, które niedawno się zgłosiły, przesyłały do nich pliki binarne Chisel i instalowały Chisel jako trwałą usługę.

Krótko mówiąc, skrypty automatyzowały przekształcanie skompromitowanych serwerów Linux w infrastrukturę proxy.

Jak działała automatyzacja

Skrypty wdrażające filtrowały beacony Linux, które zgłosiły się w ciągu ostatnich dziesięciu minut.

Każdy aktywny beacon reprezentował skompromitowany host, który mógł odbierać polecenia.

Następnie skrypty:

Identyfikowały aktywne beacony Linux.
Przesyłały plik binarny Chisel na każdy host.
Instalowały Chisel jako trwałą usługę.
Przypisywały każdemu hostowi port proxy SOCKS5.
Testowały, czy host może połączyć się z usługami SMTP.
Dodawały działające hosty do puli używalnych proxy.

Port proxy SOCKS5 był generowany deterministycznie z skrótu MD5 identyfikatora UUID Slivera i mapowany na zakres portów 10000–14999.

Oznaczało to, że ten sam skompromitowany host zawsze trafiał na ten sam port w kolejnych uruchomieniach, co eliminowało potrzebę wspólnego, centralnego rejestru portów.

To mały, ale ważny szczegół operacyjny. Pokazuje, że zestaw narzędzi został zbudowany z myślą o powtarzalności i skali.

Bramka jakości SMTP

Jedną z najbardziej odkrywczych części operacji była bramka jakości SMTP.

Skrypt testował, czy każdy skompromitowany host może nawiązać połączenie wychodzące z:

smtp.gmail[.]com:587

Hosty, które nie przeszły testu, były pomijane.

Pokazuje to główny cel operacji: wartość dla potoku miały tylko systemy zdolne do przekazywania poczty.

Skompromitowany serwer może być przydatny do wielu rzeczy, ale w tej operacji kluczowe pytanie brzmiało, czy może wysyłać pocztę wychodzącymi ścieżkami SMTP.

Narzędzia przetwarzały beacony w partiach po 50, z wbudowanymi okresami oczekiwania uwzględniającymi wolniejsze zgłoszenia beaconów.

Późniejsze wersje skryptów wdrażających podobno usunęły bramkę SMTP i logikę partii, co sugeruje, że narzędzia ewoluowały wraz z dojrzewaniem operacji.

Ciągła weryfikacja węzłów proxy

Serwer C2 uruchamiał także demona w Pythonie o nazwie:

chisel_verifier.py

Skrypt ten wielokrotnie wyliczał aktywne porty tuneli Chisel za pomocą:

ss -tlnp

Co 60 sekund testował nowe porty pod kątem możliwości SMTP. Tunele, które zawiodły lub zostały zerwane, były usuwane z aktywnej puli.

Zweryfikowane proxy były wzbogacane o:

wyjściowy adres IP
kraj
numer ASN

Wzbogacanie opierało się na publicznych usługach, takich jak:

api.ipify[.]org
ip-api[.]com

Zweryfikowane listy proxy były następnie synchronizowane co pięć minut za pomocą SCP z serwerem docelowym pod adresem:

38.242.204[.]245

Serwer ten był niedostępny, gdy badacze zgłaszali aktywność, ale powtarzająca się synchronizacja mocno sugeruje, że inny system lub aktor korzystał z listy proxy.

Do czego służyła sieć?

Ostateczny cel operacji pozostaje niejasny.

Ukryta sieć przekaźników SMTP mogłaby jednak wspierać kilka rodzajów złośliwej aktywności, w tym:

kampanie spamowe
dostarczanie phishingu
infrastrukturę do ataków business email compromise
e-maile dostarczające malware
kampanie wyłudzania poświadczeń
nadużycia związane z rejestracją kont
„pranie” reputacji poczty e-mail
socjotechnikę na dużą skalę

Wykorzystanie skompromitowanych firmowych serwerów w chmurze pomaga atakującym uniknąć problemów z reputacją, które wiążą się z oczywistą infrastrukturą spamową.

Serwery w chmurze mogą mieć czystszą reputację adresów IP, niezawodną dostępność i globalne rozproszenie. To czyni je atrakcyjnymi do nadużyć związanych z pocztą e-mail.

Dlaczego serwery w chmurze są cenne dla atakujących

Środowiska chmurowe są atrakcyjnymi celami, ponieważ zapewniają skalowalną moc obliczeniową, globalny zasięg i zaufaną pozycję w sieci.

Skompromitowany serwer w chmurze może być przydatny do:

proxy ruchu
hostowania malware'u
skanowania internetu
przygotowywania ładunków
uruchamiania infrastruktury dowodzenia i kontroli
przekazywania poczty e-mail
tunelowania do systemów wewnętrznych
ukrywania aktywności atakujących za legalnymi dostawcami

Gdy atakujący kompromitują firmowe obciążenia w chmurze, obrońcy mogą przeoczyć ruch wychodzący, ponieważ wydaje się on pochodzić od legalnej organizacji.

Jest to szczególnie niebezpieczne, gdy ruch korzysta ze zwykłych narzędzi i oczekiwanych portów.

Dlaczego nadużywanie przekaźników SMTP ma znaczenie

Nadużywanie przekaźników SMTP nie jest nowością, ale podejście PCPJack pokazuje nowoczesną, natywną dla chmury wersję tego problemu.

Zamiast polegać na niewielkim zestawie serwerów pocztowych należących do atakujących, grupa zbudowała rozproszoną pulę skompromitowanych serwerów i na bieżąco weryfikowała, które z nich mogą przekazywać pocztę.

Utrudnia to likwidację i blokowanie.

Jeśli jeden węzeł zostanie usunięty, inne mogą pozostać aktywne. Jeśli jeden dostawca chmury zablokuje ruch, operator może nadal korzystać z węzłów u innego dostawcy. Jeśli reputacja IP spadnie, nowe skompromitowane serwery mogą zastąpić te, które przestały działać.

Pięciominutowy cykl synchronizacji sugeruje, że odbiorca docelowy potrzebował w każdej chwili świeżej, działającej listy proxy zdolnych do przekazywania poczty.

Wnioski dla zespołów chmurowych

Obrońcy środowisk chmurowych powinni traktować nieoczekiwaną możliwość SMTP jako sygnał wysokiego ryzyka.

Wiele obciążeń w chmurze w ogóle nie potrzebuje wychodzącego SMTP. Tam, gdzie to możliwe, organizacje powinny ograniczać połączenia wychodzące do usług pocztowych, chyba że obciążenie ma wyraźną potrzebę biznesową.

Zalecane mechanizmy kontrolne obejmują:

domyślne blokowanie wychodzącego SMTP
zezwalanie na SMTP tylko z zatwierdzonych systemów pocztowych
monitorowanie połączeń wychodzących na port 587
alertowanie o nietypowych połączeniach z smtp.gmail.com
wykrywanie Chisel, FRP i innych narzędzi do tunelowania
monitorowanie ukrytych plików binarnych w /var/tmp
alertowanie o nieznanych plikach wykonywalnych z kropką na początku nazwy
monitorowanie tworzenia usług systemd
monitorowanie podejrzanego utrwalania obecności przez cron
kontrolowanie nieoczekiwanych nasłuchujących proxy SOCKS5
śledzenie nowych portów nasłuchujących w zakresie 10000–14999
monitorowanie aktywności beaconów Sliver
badanie nieznanych, długo działających procesów na serwerach Linux

Obciążenia w chmurze należy traktować jako potencjalne cele nadużyć infrastruktury, a nie tylko jako hosty aplikacji.

Czego szukać podczas threat huntingu

Zespoły bezpieczeństwa powinny szukać oznak zachowań w stylu PCPJack na serwerach Linux w chmurze.

Przydatne wskaźniki obejmują:

ukryte pliki binarne, takie jak /var/tmp/.xs
pliki binarne lub procesy Chisel
nieoczekiwane usługi proxy SOCKS5
aktywność testowania wychodzącego SMTP
powtarzające się połączenia z smtp.gmail[.]com:587
nowe usługi systemd powiązane z nieznanymi plikami binarnymi
podejrzane wpisy cron
zachowanie beaconów Sliver
nietypowe wychodzące transfery SCP
połączenia ze znaną infrastrukturą C2 lub infrastrukturą odbiorcy docelowego
nieoczekiwane użycie ss -tlnp ze skryptów
zmiany reputacji IP powiązane z obciążeniami w chmurze

Wykrywanie powinno koncentrować się na zachowaniu, a nie tylko na skrótach. Narzędzia takie jak Chisel i Sliver można przemianować lub zbudować od nowa.

Dlaczego otwarte katalogi mają znaczenie

Operacja została ujawniona, ponieważ atakujący zostawił otwarte katalogi na serwerze C2.

Tego rodzaju błąd operacyjny może dać obrońcom cenny wgląd w narzędzia, infrastrukturę i sposób pracy atakujących.

Otwarte katalogi często ujawniają:

ładunki
skrypty
logi
listy ofiar
pliki konfiguracyjne
mapy infrastruktury
nawyki operatorów
historię rozwoju

W tym przypadku ujawnione pliki pokazały nie tylko, co robiło złośliwe oprogramowanie, ale też jak operator zautomatyzował przekształcanie skompromitowanych hostów w infrastrukturę zdolną do przekazywania poczty.

Taka widoczność jest rzadka i cenna dla obrońców.

Zalecenia dla organizacji

Organizacje korzystające z infrastruktury chmurowej powinny sprawdzić, czy jakieś serwery nie zostały nadużyte jako proxy lub przekaźniki SMTP.

Zalecane działania obejmują:

inwentaryzację wszystkich serwerów Linux wystawionych do internetu
przegląd reguł wychodzących zapory sieciowej
blokowanie zbędnego ruchu wychodzącego SMTP
monitorowanie logów przepływu w chmurze pod kątem nietypowego ruchu pocztowego
przegląd usług systemd i zadań cron
skanowanie w poszukiwaniu narzędzi do tunelowania
sprawdzanie ukrytych plików wykonywalnych w katalogach tymczasowych
rotację poświadczeń na podejrzanych hostach
odbudowę skompromitowanych serwerów ze sprawdzonych, czystych obrazów
kontrolę aktywności IAM w chmurze pod kątem kradzieży poświadczeń
egzekwowanie zasady najmniejszych uprawnień dla kont usługowych w chmurze
wdrożenie monitorowania w czasie wykonania dla obciążeń Linux
centralizację logów z instancji w chmurze

Jeśli serwer był używany jako proxy, należy zakładać głębsze włamanie, dopóki nie zostanie udowodnione inaczej.

Podsumowanie

Operacja PCPJack pokazuje, jak atakujący zamieniają skompromitowane serwery w chmurze w jednorazową infrastrukturę do przekazywania poczty i nadużyć proxy.

Łącząc Sliver, Chisel, zautomatyzowane skrypty wdrażające, weryfikację SMTP i pięciominutowe cykle synchronizacji, atakujący zbudowali praktyczną sieć przekaźników z przejętych serwerów firmowych u wielu dostawców chmury.

Ostateczny cel nie jest w pełni potwierdzony, ale infrastruktura mogłaby wspierać spam, phishing, oszustwa, dostarczanie malware'u lub inne nadużycia oparte na poczcie e-mail na dużą skalę.

Serwery w chmurze wymagają silnego monitorowania ruchu wychodzącego, a nie tylko ochrony ruchu przychodzącego. Jeśli obciążenie nie musi wysyłać poczty e-mail, nie powinno móc przekazywać ruchu SMTP. W bezpieczeństwie chmury zapobieganie nadużyciom oznacza obserwowanie, co robią Twoje serwery po kompromitacji — a nie tylko to, jak atakujący się do nich dostają.