Ponad 230 serwerów w chmurze przejętych do wysyłki spamu. Co zawiodło?
Operacja PCPJack ujawniła, jak łatwo przejąć słabo zabezpieczone serwery w chmurze. Atakujący wykorzystali je do budowy sieci przekaźników SMTP. Analiza przypadku i wnioski dla administratorów.
„PCPJack Hijacks 230 AWS, Google Cloud, and Azure Servers for Covert SMTP Relay Network” — tak badacze bezpieczeństwa opisali operację, która w czerwcu 2026 roku ujawniła słabość powszechnie stosowanych konfiguracji chmurowych. Atakujący przejęli kontrolę nad setkami serwerów, by zbudować ukrytą sieć przekaźników poczty elektronicznej. To nie spektakularny exploit, lecz efekt rutynowych błędów: domyślnych haseł, otwartych portów SMTP i braku segmentacji sieci.Czym była operacja PCPJack?
Badacze ujawnili szczegóły kampanii PCPJack, w ramach której przejęto łącznie ponad 230 serwerów działających na platformach AWS, Google Cloud oraz Azure. Wszystkie one zostały włączone do niejawnej sieci SMTP służącej do wysyłania spamu i potencjalnie szkodliwych wiadomości. Mechanizm ataku nie wymagał odkrycia krytycznej podatności dnia zerowego — wystarczyły maszyny wirtualne z domyślnymi lub słabymi danymi logowania oraz otwartym portem 25 (SMTP).
Atakujący skanowali przestrzeń adresową chmur publicznych, szukając instancji, które odpowiadały na standardowe zapytania SMTP i miały włączone uwierzytelnianie domyślne. Po uzyskaniu dostępu instalowali narzędzia do przekazywania poczty, maskując ruch jako legalny. Sieć przekaźników działała przez kilka tygodni, zanim została zidentyfikowana.
Dlaczego to ważne dla polskich firm i administracji?
Polska jest jednym z krajów o najszybciej rosnącym udziale usług chmurowych w sektorze publicznym i prywatnym. Wiele organizacji migruje do chmury z nadzieją na większe bezpieczeństwo, ale odpowiedzialność za konfigurację pozostaje po stronie klienta. Model współdzielonej odpowiedzialności w chmurze oznacza, że dostawca zabezpiecza fizyczną infrastrukturę, ale użytkownik musi zadbać o hasła, reguły zapór sieciowych i aktualizacje.
Jak wskazują analitycy, w przypadku PCPJack żaden z przejętych serwerów nie wymagał przełamania zabezpieczeń samego dostawcy. Błąd ludzki — pozostawienie serwera z konfiguracją domyślną — był jedynym wymaganym warunkiem. To samo może dotyczyć polskich instancji, zwłaszcza w mniejszych firmach, gdzie proces wdrażania chmury bywa pośpieszny.
Jakie błędy konfiguracyjne umożliwiły atak?
Eksperci wskazują trzy główne czynniki, które powtarzały się we wszystkich przejętych przypadkach:
- Słabe lub domyślne hasła – wiele instancji uruchomiono z fabrycznymi danymi logowania do systemu operacyjnego lub usługi SMTP.
- Otwarty port SMTP (25) bez ograniczeń – serwery akceptowały połączenia z dowolnego adresu IP, co pozwalało atakującym na wykorzystanie ich jako otwartych przekaźników.
- Brak monitoringu ruchu wychodzącego – nikt nie zauważył gwałtownego wzrostu liczby wysyłanych wiadomości, typowego dla przejętego serwera pocztowego.
Dodatkowo, w wielu przypadkach nie zastosowano segmentacji sieci – przejęta maszyna miała dostęp do innych zasobów wirtualnej chmury, co teoretycznie mogło ułatwić rozszerzenie ataku, choć badacze nie potwierdzili dalszej eskalacji w tej kampanii.
Co mogą zrobić administratorzy?
Rekomendacje dla administratorów są w tym przypadku proste i dobrze znane, ale wciąż często pomijane. Przede wszystkim należy:
- Zmienić domyślne hasła do wszystkich usług i systemów operacyjnych przed udostępnieniem instancji w sieci.
- Ograniczyć dostęp do portu SMTP – jeśli serwer nie musi odbierać poczty z dowolnego miejsca, należy skonfigurować reguły zapory sieciowej tak, aby akceptować połączenia tylko z zaufanych adresów IP.
- Włączyć logowanie i alerty dla ruchu SMTP oraz dla prób logowania – nietypowy wzrost wolumenu poczty wychodzącej jest jednym z najprostszych wskaźników przejęcia.
- Stosować narzędzia do zarządzania konfiguracją (np. Terraform, Ansible) z weryfikacją bezpieczeństwa (security as code).
W warunkach polskich szczególnie istotne jest, aby procedury te były egzekwowane przez polityki bezpieczeństwa organizacji, a nie tylko zalecane. Jak pokazuje PCPJack, nawet jeden niezabezpieczony serwer może stać się elementem globalnej sieci przekaźników wykorzystywanej do działań przestępczych.
Co dalej?
Kampania PCPJack jest kolejnym dowodem na to, że ataki na infrastrukturę chmurową nie muszą być wyrafinowane, by przynieść skutek. W dobie masowej migracji do chmury, podstawy — silne hasła, domyślnie zamknięte porty i monitoring — wciąż pozostają najskuteczniejszą linią obrony. Warto, aby każdy administrator polskiej firmy po lekturze tego opisu sprawdził konfigurację swoich instancji, zanim zrobią to osoby o złych zamiarach.
