Phishing przez Amazon S3. Gdy legalna chmura prowadzi do fałszywego banku

TL;DR

19 sierpnia 2026 roku zespół Mimecast opisał kampanię phishingową wymierzoną w użytkowników w kilku krajach Europy. Atakujący wykorzystywali przejęte konta e-mail oraz linki prowadzące przez Amazon S3, czyli legalną usługę chmurową AWS. Podszywali się między innymi pod banki, administrację publiczną, aptekę, system emerytalny i usługi tożsamości cyfrowej.

Nie należy z tego wyciągać wniosku, że trzeba blokować Amazon S3. Legalna domena dostawcy chmury nie potwierdza, że konkretna strona lub link są bezpieczne.

W jednym z udokumentowanych scenariuszy fałszywa strona banku zbierała nie tylko identyfikator i PIN, ale również metodę autoryzacji oraz aktualne kody TAN. To pokazuje, że celem nie było wyłącznie poznanie hasła. Atak miał dostarczyć komplet danych potrzebnych do przejęcia bankowości i potencjalnego zatwierdzenia operacji.

Co dokładnie opisał Mimecast

Mimecast zaobserwował wielojęzyczne kampanie phishingowe wykorzystujące niemieckie, niderlandzkie i duńskie przynęty. Podszywano się pod organizacje z Niemiec, Holandii, Danii i Belgii.

Na liście podmiotów znalazły się banki, instytucje publiczne, apteka, dostawca usług emerytalnych oraz systemy tożsamości cyfrowej. To ważne, ponieważ nie mamy do czynienia z jednym fałszywym bankiem i jednym szablonem wiadomości. Mechanizm był lokalizowany do konkretnego kraju i usługi.

Według badaczy wiadomości pochodziły z przejętych kont. Następnie odbiorca trafiał na adres wykorzystujący Amazon S3. Taki adres mógł hostować element kampanii lub kierować dalej do strony kontrolowanej przez napastnika.

To daje atakującemu dwie warstwy wiarygodności już przed wyświetleniem fałszywego formularza:

1. wiadomość może pochodzić z prawdziwego, wcześniej przejętego konta;
2. link może zawierać domenę należącą do jednego z największych dostawców chmury na świecie.

Dopiero później pojawia się właściwa strona phishingowa.

Jak wygląda łańcuch ataku

Schemat można sprowadzić do czterech etapów.

1. Przejęty nadawca

Odbiorca dostaje wiadomość z istniejącego konta. To może zwiększyć wiarygodność nadawcy i utrudnić prostą ocenę na zasadzie „nie znam tej domeny, więc nie klikam”.

Przejęte konto nie oznacza oczywiście, że każda wiadomość od znanego nadawcy jest podejrzana. Problem polega na tym, że sama reputacja nadawcy przestaje być wystarczającym dowodem bezpieczeństwa.

2. Link do legalnej infrastruktury Amazon S3

Wiadomość kieruje do hosta Amazon S3. Dla użytkownika amazonaws.com może wyglądać bezpieczniej niż świeżo zarejestrowana losowa domena.

Dla części mechanizmów ochrony również ma to znaczenie. Prosta blokada oparta wyłącznie na reputacji całej domeny byłaby niepraktyczna, ponieważ z Amazon S3 korzystają miliony legalnych aplikacji, serwisów i firm.

3. Lokalnie dopasowana strona phishingowa

Kampania wykorzystywała strony podszywające się pod konkretne banki i instytucje. W opisanym przez Mimecast scenariuszu dotyczącym Volksbanken Raiffeisenbanken formularz pytał najpierw o lokalizację użytkownika, aby dopasować lokalny kontekst banku.

Potem zbierano dane potrzebne do logowania: między innymi VR-NetKey lub alias oraz PIN bankowości internetowej.

4. Przechwycenie autoryzacji

Na tym atak się nie kończył. Formularz pytał również o używaną metodę autoryzacji i aktualne TAN.

TAN, czyli Transaktionsnummer, jest jednorazową wartością wykorzystywaną w części systemów bankowych do autoryzacji logowania albo operacji. Jeżeli ofiara wpisze taki kod na stronie kontrolowanej przez napastnika, kod może zostać wykorzystany w czasie, gdy nadal jest ważny.

To przesuwa atak z poziomu „ukradnij hasło” do poziomu „spróbuj przejąć bieżący proces autoryzacji”.

Czy amazonaws.com to podejrzana domena?

Nie. I właśnie dlatego ten scenariusz jest dobrym przykładem problemu z prostymi poradami typu „sprawdź domenę”.

amazonaws.com jest częścią infrastruktury Amazon Web Services. Legalne aplikacje wykorzystują ją do przechowywania plików, dystrybucji zasobów i hostowania treści. Nie ma sensu traktować całej domeny jako złośliwej.

Trzeba jednak rozróżnić właściciela platformy od właściciela konkretnego zasobu na platformie.

Oficjalna dokumentacja AWS pokazuje, że w adresach S3 typu virtual-hosted nazwa bucketu staje się częścią hosta. Typowy format wygląda tak:

https://example-bucket.s3.eu-central-1.amazonaws.com/nazwa-pliku

To, że końcówka adresu należy do AWS, nie mówi jeszcze, kto kontroluje example-bucket ani jaka treść została tam umieszczona.

AWS umożliwia również hostowanie statycznych stron poprzez regionalne endpointy S3. Jest to legalna funkcja usługi. Tak jak każda publiczna platforma hostingowa może jednak zostać wykorzystana niezgodnie z przeznaczeniem przez jej użytkownika.

Dlatego właściwe pytanie nie brzmi:

„Czy rozpoznaję domenę amazonaws.com?”

Tylko:

„Dlaczego bank, urząd albo dostawca tożsamości prowadzi mnie właśnie tym linkiem i czego strona żąda ode mnie po kliknięciu?”

Samo sprawdzanie kłódki i domeny już nie wystarcza

Przez lata użytkownicy słyszeli trzy podstawowe rady: sprawdź nadawcę, sprawdź domenę i sprawdź kłódkę HTTPS. Wszystkie są nadal przydatne, ale żadna z nich nie może działać jako samodzielny test bezpieczeństwa.

W tej kampanii:

• nadawca mógł być prawdziwym, przejętym kontem;
• fragment domeny należał do legalnego dostawcy chmury;
• połączenie z infrastrukturą AWS mogło używać poprawnego HTTPS.

Każda z tych rzeczy może być technicznie prawidłowa, podczas gdy cały proces nadal prowadzi do phishingu.

Podobny problem opisujemy w artykule Amazon SES jako przekaźnik phishingu. Tam legalna infrastruktura AWS jest wykorzystywana po stronie wysyłki wiadomości. Tutaj nowa kampania pokazuje inny fragment łańcucha: hosting lub przekierowanie po kliknięciu.

To ważne rozróżnienie. Obrona przed współczesnym phishingiem nie może ograniczać się do pytania, czy pojedynczy element infrastruktury jest legalny. Trzeba oceniać cały kontekst i sekwencję działań.

23,2% zgłoszonych URL-i z amazonaws.com — ważny sygnał, ale nie globalna statystyka

Dodatkowy kontekst daje Council of Anti-Phishing Japan. W raporcie za lipiec 2026 organizacja podała, że przypadki wykorzystujące hostname amazonaws.com gwałtownie wzrosły i stanowiły około 23,2% zgłoszonych phishingowych URL-i w ich miesięcznym zbiorze.

Tę liczbę trzeba czytać precyzyjnie. Nie oznacza ona, że 23,2% całego phishingu na świecie działa przez Amazon S3. To udział w konkretnych zgłoszeniach obsłużonych przez japońską organizację w konkretnym miesiącu.

Raport jest jednak cennym niezależnym sygnałem, że nadużywanie legalnej infrastruktury AWS nie jest pojedynczym przypadkiem opisanym tylko przez jednego dostawcę security.

Ten sam raport wskazuje również rosnące użycie legalnych usług i przekierowań do utrudniania detekcji złośliwych URL-i.

Szerszy trend: napastnik chce odziedziczyć reputację platformy

Amazon S3 nie jest jedynym przykładem.

Kaspersky opisywał w sierpniu 2026 coraz częstsze nadużywanie legalnych platform takich jak Cloudflare Workers, Vercel, Netlify, GitHub Pages czy IPFS do budowania infrastruktury phishingowej.

Kilka dni wcześniej Mimecast pokazał z kolei nadużywanie legalnych usług przekierowań Google. Link może zaczynać się od zaufanej infrastruktury i dopiero później prowadzić do właściwego celu ataku.

Wspólny mechanizm jest prosty: zamiast budować cały atak na domenie, która od pierwszej sekundy wygląda podejrzanie, napastnik próbuje pożyczyć reputację legalnej usługi.

To właśnie dlatego w artykule 67% phishingu przechodzi DMARC. Zaufanie pod presją podkreślamy, że techniczny sygnał zaufania nie jest równoznaczny z bezpieczeństwem intencji.

Jak użytkownik powinien sprawdzać taki link

Najważniejsza zmiana w edukacji polega na odejściu od jednej magicznej reguły.

Nie wystarczy powiedzieć pracownikowi: „sprawdź, czy domena jest znana”. Zamiast tego warto nauczyć czterech pytań.

Czy oczekiwałem tej wiadomości?

Jeżeli bank, urząd, system emerytalny albo dostawca tożsamości nagle żąda weryfikacji konta, trzeba najpierw potwierdzić, że taki proces rzeczywiście został uruchomiony.

Dlaczego mam wejść do usługi właśnie z tego linku?

Jeżeli daną czynność można wykonać po wejściu do oficjalnej aplikacji lub po ręcznym wpisaniu znanego adresu, to jest bezpieczniejsza droga niż kontynuowanie procesu z wiadomości.

Czego strona żąda po kliknięciu?

Żądanie pełnych danych logowania, PIN-u, kodu MFA, TAN-u lub zatwierdzenia nieoczekiwanej operacji powinno natychmiast podnieść poziom ostrożności.

Czy mogę potwierdzić proces innym kanałem?

W przypadku banku należy otworzyć oficjalną aplikację. W przypadku systemu firmowego można wejść przez zapisany portal lub skontaktować się z helpdeskiem znanym wcześniej kanałem. W przypadku kontrahenta warto użyć numeru telefonu lub kontaktu, który nie pochodzi z podejrzanej wiadomości.

To jest praktyczna wersja zasady nie ufaj pojedynczemu sygnałowi technicznemu.

Co powinien zrobić dział bezpieczeństwa

Mimecast zaleca analizowanie pełnych nazw hostów S3 i wyszukiwanie konkretnych wskaźników kampanii w telemetrii pocztowej. Dla organizacji ważniejsze od blokowania całego AWS jest wykrywanie nietypowych kombinacji sygnałów.

W praktyce warto zwracać uwagę na:

• wiadomości z nieoczekiwanym wezwaniem do logowania lub autoryzacji operacji;
• linki do hostingu chmurowego pojawiające się w kontekście banku, podatków, tożsamości lub płatności;
• przekierowania prowadzące z legalnej platformy do nowej domeny;
• logowania i operacje następujące bezpośrednio po kliknięciu podejrzanego linku;
• zgłoszenia użytkowników dotyczące próśb o kody MFA, TAN lub potwierdzenie transakcji.

Ważna jest też możliwość szybkiego unieważnienia sesji i poświadczeń, jeżeli użytkownik zgłosi, że wpisał dane na podejrzanej stronie.

Jak przełożyć tę kampanię na testy phishingowe

Ten scenariusz jest dobrym materiałem do ćwiczeń security awareness, ponieważ testuje coś więcej niż rozpoznawanie literówki w domenie.

Pracownik powinien nauczyć się, że:

• znany dostawca chmury może być tylko techniczną warstwą pośrednią;
• poprawny HTTPS nie potwierdza intencji strony;
• przejęte konto nadawcy może wyglądać wiarygodnie;
• nieoczekiwane żądanie kodu autoryzacyjnego jest ważniejsze niż „ładny” adres;
• właściwą reakcją jest przejście do usługi niezależnym kanałem.

W testach phishingowych dla firm warto więc sprawdzać nie tylko, czy użytkownik rozpozna fałszywą domenę, ale czy potrafi zatrzymać proces wtedy, gdy każdy pojedynczy element wygląda wystarczająco wiarygodnie, lecz cały kontekst nie ma sensu.

Dla organizacji z sektora finansowego taki scenariusz dobrze łączy się również z edukacją dotyczącą zatwierdzania operacji i niezależnej weryfikacji. Więcej o podejściu branżowym opisujemy na stronie cyberbezpieczeństwo dla finansów.

Wniosek

Amazon S3 jest legalną usługą. I właśnie dlatego jego nadużycie jest interesujące z punktu widzenia phishingu.

Napastnik nie musi sprawić, żeby każdy element ataku był fałszywy. Wystarczy, że połączy kilka prawdziwych lub legalnych elementów w złośliwy proces: przejęte konto, chmurowy hosting, HTTPS, dobrze odwzorowaną markę i formularz, który w odpowiednim momencie poprosi o dane logowania oraz kod autoryzacyjny.

Dlatego dojrzała obrona nie pyta wyłącznie „czy ta domena jest legalna?”. Pyta: czy cały proces, którego właśnie ode mnie żądają, ma sens i czy mogę potwierdzić go niezależnym kanałem?

To jest reguła, która działa nie tylko dla Amazon S3, ale również dla wielu kolejnych kampanii wykorzystujących legalną infrastrukturę chmurową.