Amazon SES jako przekaźnik phishingu. Gdy SPF, DKIM i DMARC nie wystarczają

2026-05-05

TL;DR

Kaspersky opisał kampanie phishingowe i BEC, w których atakujący nadużywają Amazon Simple Email Service, czyli legalnej usługi AWS do wysyłki wiadomości e-mail. Firmy używają Amazon SES do wysyłania powiadomień, maili transakcyjnych, komunikacji marketingowej i wiadomości systemowych. Problem zaczyna się wtedy, gdy przestępca uzyska dostęp do takiej usługi albo do kluczy pozwalających jej używać. Dzięki temu wiadomości mogą wyglądać technicznie poprawnie, przechodzić standardowe kontrole SPF, DKIM i DMARC, a mimo to prowadzić do wyłudzenia danych albo oszustwa finansowego.

To nie jest historia o tym, że Amazon SES jest złośliwy. To historia o tym, że legalna infrastruktura może zostać użyta jako nośnik ataku. Dla firm najważniejszy wniosek jest prosty: poprawne uwierzytelnienie poczty potwierdza ścieżkę techniczną wiadomości. Nie potwierdza, że jej treść jest bezpieczna.

O co chodzi w tej kampanii

Według Kaspersky Securelist, atakujący wykorzystują Amazon SES do wysyłania phishingu oraz wiadomości używanych w scenariuszach Business Email Compromise. BEC to oszustwo biznesowe prowadzone przez e-mail. Przestępcy podszywają się pod kontrahenta, przełożonego, dział finansów albo zaufany proces, aby wyłudzić płatność, zmianę numeru konta, dokumenty lub dane dostępowe.

Amazon SES jest legalną usługą, z której firmy korzystają na co dzień. Wysyła potwierdzenia zamówień, alerty systemowe, powiadomienia z aplikacji, wiadomości marketingowe i komunikację transakcyjną. W rękach napastnika taka usługa daje jednak bardzo cenną przewagę: reputację infrastruktury. Wiadomość nie musi wychodzić z podejrzanego serwera ani z losowej domeny. Może zostać wysłana przez usługę, którą wiele systemów pocztowych zna i traktuje jako wiarygodną technicznie.

Kaspersky opisuje między innymi wiadomości podszywające się pod powiadomienia z usług podpisu elektronicznego. Ofiara dostaje mail wyglądający jak informacja o dokumencie do podpisu, klika link i trafia na stronę phishingową. Techniczne nagłówki potwierdzają, że wiadomość przeszła przez Amazon SES, co może uśpić czujność części filtrów i osób analizujących incydent.

Dlaczego SPF, DKIM i DMARC nie wystarczają

Przez lata w edukacji użytkowników i konfiguracji poczty mocno podkreślano znaczenie SPF, DKIM i DMARC. Słusznie. To ważne mechanizmy, które pomagają ograniczać spoofing domen i podszywanie się pod cudzą infrastrukturę. Warto jednak rozumieć, co one naprawdę sprawdzają.

SPF pomaga potwierdzić, czy dana infrastruktura ma prawo wysyłać pocztę dla określonej domeny. DKIM dodaje do wiadomości podpis kryptograficzny, który pozwala sprawdzić, czy wiadomość nie została zmieniona po drodze i czy pochodzi z autoryzowanego źródła. DMARC spina te mechanizmy i sprawdza zgodność domeny widocznej dla odbiorcy z domeną uwierzytelnioną przez SPF albo DKIM.

Problem polega na tym, że atakujący coraz częściej nie muszą już brutalnie podszywać się pod domenę. Mogą użyć legalnej platformy, przejętego konta, skradzionych kluczy albo poprawnie skonfigurowanej usługi wysyłkowej. Wtedy wiadomość może przejść kontrole techniczne, bo faktycznie wychodzi z uprawnionej infrastruktury.

To jest kluczowa różnica. SPF, DKIM i DMARC odpowiadają na pytanie, czy wiadomość przeszła określone mechanizmy autoryzacji. Nie odpowiadają na pytanie, czy osoba, która ją wysłała, miała uczciwy zamiar.

Ten sam problem opisywaliśmy już przy kampaniach Kuse.ai jako nośnik phishingu oraz Google AppSheet jako przekaźnik phishingu. W każdym z tych przypadków legalna usługa stawała się pierwszą warstwą zaufania.

Jak atakujący zdobywają możliwość wysyłki przez Amazon SES

Najważniejszy techniczny element tej historii dotyczy kluczy dostępowych AWS. W AWS takie klucze są poświadczeniami, które pozwalają aplikacjom, skryptom lub użytkownikom wykonywać określone operacje w chmurze. Jeśli mają dostęp do Amazon SES, mogą posłużyć do wysyłania wiadomości.

Kaspersky wskazuje, że atakujący mogą wykorzystywać wykradzione albo przypadkowo ujawnione klucze AWS IAM. IAM, czyli Identity and Access Management, to system AWS służący do zarządzania użytkownikami, rolami i uprawnieniami. Źle chroniony klucz IAM nie jest drobnym sekretem technicznym. To poświadczenie, które może zamienić legalną infrastrukturę firmy w narzędzie phishingowe.

Takie klucze bywają znajdowane w publicznych repozytoriach GitHub, plikach .env, obrazach Docker, backupach konfiguracji, archiwach albo źle zabezpieczonych zasobach chmurowych. Jeśli klucz ma uprawnienia do SES, napastnik może sprawdzić limity wysyłki, przygotować kampanię i zacząć dystrybucję wiadomości. Z perspektywy odbiorcy wszystko może wyglądać jak normalna wiadomość wysłana przez legalną usługę chmurową.

Amazon SES jako narzędzie do phishingu i BEC

W analizie Kaspersky pojawia się nie tylko phishing na dane logowania, ale także scenariusze BEC. To istotne, bo w Business Email Compromise najważniejsza często nie jest sama strona phishingowa, ale wiarygodność procesu biznesowego.

Atakujący może wysłać wiadomość dotyczącą rzekomego dokumentu, płatności, umowy, podpisu elektronicznego albo faktury. Jeśli wiadomość technicznie wygląda poprawnie, łatwiej przechodzi przez pierwszą warstwę weryfikacji. Dalej liczy się już kontekst: czy odbiorca spodziewa się dokumentu, czy temat dotyczy jego pracy, czy presja czasu jest wiarygodna i czy link prowadzi do procesu wyglądającego znajomo.

To właśnie dlatego BEC jest tak trudny do zatrzymania samymi regułami technicznymi. Jeżeli wiadomość nie zawiera malware, pochodzi z legalnej infrastruktury i prowadzi do dobrze przygotowanego procesu, ciężar obrony przesuwa się na analizę kontekstu, zachowania i procedur wewnętrznych.

Ten trend dobrze łączy się z naszym materiałem Kwiecień 2026 w phishingu. Miesiąc, w którym kliknięcie przestało być największym problemem. Współczesny phishing coraz częściej nie jest jednym mailem. Jest łańcuchem zaufania.

Fałszywy dokument do podpisu działa, bo pasuje do codziennej pracy

Jednym z przykładów opisanych przez Kaspersky są wiadomości udające powiadomienia z usług podpisu elektronicznego. To bardzo dobry pretekst, bo pasuje do normalnego rytmu pracy wielu firm. Dokument do podpisu nie budzi takiej czujności jak wiadomość o wygranej albo egzotyczny załącznik. Może dotyczyć umowy, zamówienia, rozliczenia, dokumentacji HR albo współpracy z klientem. Jeżeli dodatkowo mail wygląda technicznie poprawnie, odbiorca ma mniej powodów, żeby go kwestionować.

To mechanizm podobny do kampanii opartych na fałszywych dokumentach hostowanych na legalnych platformach. Użytkownik nie widzi od razu złej domeny. Widzi proces, który zna. Dokument. Podpis. Logowanie. Potwierdzenie. Właśnie tam phishing jest dziś najskuteczniejszy: nie w egzotycznych scenariuszach, ale w miejscach, które wyglądają jak zwykła praca.

Co powinno zapalić lampkę ostrzegawczą

Najważniejszy sygnał ostrzegawczy to rozbieżność między techniczną wiarygodnością wiadomości a biznesowym kontekstem. To, że mail przeszedł SPF, DKIM i DMARC, nie oznacza, że należy kliknąć link.

Użytkownik powinien zatrzymać się, jeśli otrzymuje dokument do podpisu, którego się nie spodziewa, nadawca lub temat nie pasują do bieżącej współpracy, link prowadzi przez nietypową domenę albo skracacz, wiadomość wymusza szybkie działanie, a po kliknięciu pojawia się logowanie do Microsoft, Google lub innej usługi, mimo że proces miał dotyczyć dokumentu.

Podejrzane jest też, gdy wiadomość pochodzi z legalnej platformy, ale treść wywołuje presję, strach przed konsekwencjami albo pilną potrzebę zmiany danych płatności.

Najprostsza zasada brzmi: legalna infrastruktura nie zwalnia z weryfikacji kontekstu. Jeśli dokument jest ważny, da się go potwierdzić drugim kanałem.

Co powinny zrobić firmy korzystające z AWS

Ten temat ma dwa wymiary. Pierwszy dotyczy odbiorców phishingu. Drugi dotyczy firm, których własna infrastruktura chmurowa może zostać nadużyta do wysyłki.

Jeśli organizacja używa AWS, powinna sprawdzić, kto ma uprawnienia do Amazon SES, jakie są limity wysyłki, jakie domeny są zweryfikowane, czy istnieją stare klucze IAM i czy w logach nie ma nietypowych wzorców wysyłki. Szczególnie ważne są konta techniczne, integracje CI/CD, aplikacje marketingowe i stare projekty, które kiedyś potrzebowały wysyłki maili, ale dziś nikt ich nie kontroluje.

Praktyczne minimum obejmuje ograniczenie uprawnień SES zgodnie z zasadą least privilege, czyli nadawania tylko tych praw, które są naprawdę potrzebne. Warto usuwać długotrwałe klucze tam, gdzie można zastąpić je rolami i poświadczeniami tymczasowymi, regularnie przeglądać użytkowników IAM, role, polityki i access keys, a także ustawić alerty na nietypowe wolumeny wysyłki.

Firmy powinny również kontrolować zweryfikowane domeny i adresy, monitorować odbicia, skargi oraz reputację wysyłkową, skanować repozytoria i obrazy kontenerów pod kątem sekretów oraz szybko unieważniać klucze przy podejrzeniu wycieku.

To nie jest tylko higiena chmury. To element ochrony reputacji domeny i ochrony klientów przed phishingiem wysłanym z legalnie wyglądającego kanału.

Co powinny zrobić zespoły odpowiedzialne za pocztę

Zespoły bezpieczeństwa poczty powinny traktować poprawne SPF, DKIM i DMARC jako ważny sygnał, ale nie jako końcowy werdykt. Coraz częściej potrzebna jest analiza reputacji treści, linków, intencji wiadomości i kontekstu biznesowego.

W praktyce warto zwracać uwagę na wiadomości, które pochodzą z legalnych usług wysyłkowych, ale zawierają nietypową treść względem nadawcy, prowadzą do logowania poza oczekiwanym procesem, używają presji czasu, podszywają się pod dokumenty do podpisu, zachęcają do zmiany danych płatności albo tworzą nowy wątek finansowy bez wcześniejszego kontekstu.

W analizie technicznej warto też pamiętać, że wiadomości wysyłane przez Amazon SES mogą mieć ślady tej usługi w nagłówkach, między innymi w polu Message-ID z domeną amazonses.com. To nie jest samo w sobie dowodem ataku. Może być jednak użytecznym elementem analizy, jeśli wiadomość deklaruje inną markę, inny proces albo inne źródło zaufania.

To szczególnie istotne przy BEC. Tego typu wiadomości mogą nie mieć załącznika, malware ani oczywistych wskaźników kompromitacji. Mogą wyglądać jak zwykły proces biznesowy.

Co powinno trafić do awareness

W szkoleniach dla pracowników warto jasno powiedzieć jedną rzecz: zielona lampka po stronie technologii nie oznacza zielonej lampki dla użytkownika. Pracownik nie musi znać szczegółów Amazon SES, DKIM, DMARC czy IAM. Powinien jednak rozumieć, że wiadomość może przyjść z legalnej platformy i nadal być phishingiem.

To szczególnie ważne w scenariuszach dokumentów, podpisów elektronicznych, faktur, płatności i kont firmowych. Dobry scenariusz awareness może wyglądać tak: użytkownik dostaje dokument do podpisu, wiadomość technicznie wygląda poprawnie, link prowadzi do estetycznej strony, a po chwili pojawia się prośba o logowanie. Zadaniem użytkownika nie jest wtedy analiza nagłówków. Zadaniem jest zatrzymanie procesu i zadanie pytania: czy ja rzeczywiście spodziewam się tego dokumentu i czy to jest właściwy kanał?

To właśnie ten typ ćwiczeń jest dziś bardziej wartościowy niż klasyczne przykłady z literówkami i podejrzanym załącznikiem.

Dlaczego to pasuje do polskich firm

W polskich firmach takie scenariusze mogą być bardzo skuteczne, bo codzienna praca opiera się na dokumentach, fakturach, podpisach, zamówieniach, płatnościach i komunikacji z dostawcami. Jeżeli do takiego procesu dołożymy legalną usługę wysyłkową i poprawną autoryzację poczty, wielu użytkowników może uznać wiadomość za bezpieczną.

To podobny problem jak przy fałszywych fakturach i KSeF. Różnica polega na tym, że w kampaniach nadużywających Amazon SES pierwsza warstwa techniczna może wyglądać jeszcze bardziej wiarygodnie. Atakujący nie musi walczyć z filtrami przez podejrzany serwer. Może użyć reputacji dużej platformy chmurowej.

Dlatego ten temat dobrze łączy się z naszymi materiałami Fałszywa faktura w KSeF, Kuse.ai jako nośnik phishingu i Google AppSheet jako przekaźnik phishingu.

Gdy legalna infrastruktura wysyła fałszywą treść

Amazon SES w tym scenariuszu nie jest problemem samym w sobie. Problemem jest zaufanie, które organizacje i użytkownicy przypisują legalnej infrastrukturze. Atakujący bardzo dobrze to rozumieją. Zamiast budować podejrzane serwery, coraz częściej używają usług, które już mają dobrą reputację.

To ważna lekcja dla firm. SPF, DKIM i DMARC są potrzebne, ale nie wystarczą. Chronią przed częścią podszywania się, ale nie przed sytuacją, w której prawdziwa platforma wysyła fałszywą treść na zlecenie napastnika.

Nowoczesna ochrona przed phishingiem musi łączyć uwierzytelnianie poczty, analizę treści, monitoring chmury, ochronę kluczy IAM, procedury BEC i szkolenia użytkowników. Dopiero wtedy organizacja zaczyna widzieć cały łańcuch ataku, a nie tylko techniczny wynik jednej kontroli.

Jeżeli chcesz sprawdzić, czy Twoi pracownicy rozpoznają phishing wysłany z legalnej platformy, a nie tylko z podejrzanej domeny, dobrym początkiem jest quiz phishingowy PHISHLY.