TL;DR

1 Amazon SES jest coraz częściej nadużywany do wysyłania phishingowych wiadomości e-mail, które omijają standardowe filtry bezpieczeństwa i bloki oparte na reputacji. 2 Głównym czynnikiem wzrostu jest masowe wyciekanie AWS IAM access keys na publicznych zasobach. 3 Wyciekane klucze znajdują się w repozytoriach GitHub, plikach .ENV, obrazach Docker, backupach i publicznie dostępnych S3 bucketach. Dla polskich firm: jeśli Twoja organizacja korzysta z AWS, a Ty lub Twój zespół kiedykolwiek commitowali kod z credentials — jesteś w grupie ryzyka.

Wektor ataku: dlaczego Amazon SES jest idealna dla phisherów

Amazon Simple Email Service to usługa AWS do wysyłania e-maili na skalę. Dla legalnych użytkowników — narzędzie do powiadomień, raportów, komunikacji. Dla atakujących — infrastruktura z wbudowaną reputacją.

1 Phishingowe e-maile wysyłane przez SES omijają standardowe filtry bezpieczeństwa i bloki oparte na reputacji — ponieważ Amazon jako korporacja ma wysoką reputację w systemach filtrowania poczty. Gdy e-mail przychodzi z IP-u Amazona, filtry go przepuszczają. To jak wysłanie listu z pieczęcią banku — nawet jeśli zawartość to oszustwo.

4 Dodatkowo, atakujący nie muszą się martwić o kontrole autentyczności takie jak SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) i DMARC (Domain-based Message Authentication, Reporting and Conformance). Te protokoły weryfikują, czy e-mail naprawdę pochodzi z domeny nadawcy. Ale gdy wysyłasz przez SES, e-mail pochodzi z domeny Amazona — i ta domena ma wszystkie certyfikaty w porządku.

Jak atakujący zdobywają dostęp do SES

2 Wzrost nadużyć wiąże się z masowym wyciekiem AWS IAM access keys na publicznych zasobach. To nie jest nowy problem — to problem, który się skaluje.

3 Wyciekane AWS credentials znajdują się w:

  • publicznych repozytoriach GitHub (developer commitnął .env z kluczami)
  • plikach .env pozostawionych w projektach
  • obrazach Docker pushowanych na Docker Hub bez czyszczenia
  • backupach baz danych wrzuconych na S3 bez hasła
  • publicznie dostępnych S3 bucketach (błędna konfiguracja uprawnień)

5 Atakujący używają zautomatyzowanych narzędzi opartych na TruffleHog — skanerze open-source do wyszukiwania wyciekniętych sekretów — aby znaleźć te klucze. TruffleHog skanuje repozytoria, logi, obrazy i szuka wzorców (np. AKIA — prefiks AWS access key).

6 Cały proces jest zautomatyzowany: skanowanie sekretów → walidacja uprawnień (czy klucz rzeczywiście działa?) → dystrybucja e-maili phishingowych na masową skalę. Atakujący nie musi nic robić ręcznie.

Anatomia ataku: co widzą ofiary

7 Obserwowane phishingowe kampanie zawierają niestandardowe szablony HTML imitujące rzeczywiste usługi i realistyczne przepływy logowania. To nie są już banalne e-maile z błędami językowymi i prymitywnym formatowaniem. To są kampanie z zaangażowaniem.

8 Przykład: atakujący wysyłają fałszywe powiadomienia o podpisywaniu dokumentów imitujące DocuSign. E-mail wygląda jak od DocuSign, zawiera logo i prawidłową strukturę. Ofiara klika na przycisk przeglądania lub podpisania dokumentu i trafia na phishingową stronę hostowaną na AWS — która również wygląda jak DocuSign.

9 Inny wektor: atakujący tworzą fałszywe wątki e-mailowe (sfabrykowane łańcuchy odpowiedzi typu „Re: …”, imitujące wcześniejszą korespondencję) i wysyłają fałszywe faktury do działów finansowych. Wątek wygląda jak autentyczna korespondencja — dział finansowy, przyzwyczajony do przelewów, dokonuje płatności na konto atakującego.

Dla polskich firm MŚP — to szczególnie niebezpieczne. Małe zespoły finansowe, mniej procedur weryfikacyjnych, większe zaufanie do e-maili.

Wskaźniki kompromitacji

# Jeśli widzisz w logach SES:
- Nagły wzrost liczby e-maili wysyłanych z Twojego konta AWS
- E-maile wysyłane do adresów, które nie zatwierdziłeś
- Dostęp do SES z nieznanego adresu IP lub lokalizacji
- Błędy autentyczności w logach CloudTrail (nieudane próby logowania)

# Jeśli widzisz w poczcie przychodzącej:
- E-maile z domen Amazona (amazonses.com, amazonaws.com) zawierające treści phishingowe
- E-maile imitujące DocuSign, Stripe, PayPal, polskie banki
- Wiadomości z fałszywymi wątkami ("Re: Faktura", "Re: Umowa")
- Linki do stron hostowanych na AWS (*.s3.amazonaws.com, *.cloudfront.net)

Co zrobić w 24-48h

Dla administratorów AWS

  1. Natychmiast: przejrzyj AWS CloudTrail pod kątem nieautoryzowanego dostępu do SES.

    • Szukaj: SendEmail, SendRawEmail z adresów IP, które nie rozpoznajesz.
    • Jeśli znalazłeś — zmień wszystkie AWS credentials natychmiast.

  2. Rotacja kluczy: 10 Kaspersky zaleca regularne rotowanie kluczy dostępu. Jeśli masz klucze starsze niż 90 dni — wygeneruj nowe i usuń stare.

  3. Ograniczenie uprawnień: 10 Zastosuj zasadę najmniejszych uprawnień (least privilege). Jeśli developer potrzebuje dostępu do SES — daj mu dostęp TYLKO do SES, nie do całego AWS.

  4. Uwierzytelnianie wieloskładnikowe: 10 Włącz MFA (Multi-Factor Authentication) na wszystkich kontach AWS, szczególnie tych z dostępem do SES.

  5. Ograniczenia IP: 10 Jeśli to możliwe, ogranicz dostęp do SES tylko z konkretnych IP-ów (np. z Twojego biura lub VPN).

Dla wszystkich

  1. Skanowanie repozytoriów: jeśli Twoja organizacja ma kod na GitHub, GitLab lub innym repozytorium — uruchom TruffleHog lub podobne narzędzie, aby znaleźć wyciekłe dane uwierzytelniające.

    trufflehog filesystem . --json

    Jeśli znalazł coś — zmień te credentials natychmiast.

  2. Przegląd S3 bucketów: sprawdź, czy jakiś S3 bucket ma publiczny dostęp (Block Public Access powinno być włączone).

  3. Edukacja zespołu: nigdy nie commituj plików .env, kluczy AWS, tokenów czy haseł do repozytorium. Używaj .gitignore i narzędzi do zarządzania sekretami (np. AWS Secrets Manager, HashiCorp Vault).

  4. Monitoring: jeśli korzystasz z AWS — skonfiguruj alerty na nieoczekiwane użycie SES.

Dla działów bezpieczeństwa

  1. Raportowanie: 11 Jeśli podejrzewasz, że Twoje AWS resources są używane do phishingu — zgłoś to do AWS Trust & Safety (abuse@amazonaws.com).

  2. Blokowanie: 12 Blokowanie IP-ów dostarczających phishingowe e-maile nie jest rozwiązaniem — uniemożliwiłoby wszystkie e-maile z Amazon SES. Zamiast tego: blokuj konkretne domeny nadawcy (jeśli atakujący wysyła z fake-docusign.com), blokuj linki do stron phishingowych, zgłaszaj e-maile do AWS.

Polski kontekst: dlaczego to dotyczy Ciebie

Polskie firmy, szczególnie MŚP i startupy, coraz częściej migrują do AWS. To oznacza, że:

  • Więcej polskich danych uwierzytelniających AWS w kodzie — developer z Warszawy commituje .env z kluczami, TruffleHog go znajduje.
  • Polskie działy finansowe jako cel — atakujący wysyłają fałszywe faktury w polskim języku, imitując polskie banki (PKO, ING, mBank) lub polskie usługi (Allegro, InPost).
  • Brak procedur weryfikacji — mniejsze firmy nie mają dedykowanego zespołu bezpieczeństwa, więc phishing przechodzi przez filtry.

Dodatkowo: Amazon SES przechodzi kontrole autentyczności (SPF, DKIM, DMARC), co oznacza, że polskie systemy filtrowania poczty (w tym te w polskich firmach) mogą go nie blokować.

Źródła

Zobacz też

Footnotes

  1. Amazon SES jest nadużywany do wysyłania phishingowych e-maili, które omijają standardowe filtry bezpieczeństwa i bloki oparte na reputacji — https://www.bleepingcomputer.com/news/security/amazon-ses-increasingly-abused-in-phishing-to-evade-detection/ ↩ ↩2

  2. Głównym czynnikiem wzrostu nadużyć SES jest masowe wyciekanie AWS IAM access keys na publicznych zasobach — https://www.bleepingcomputer.com/news/security/amazon-ses-increasingly-abused-in-phishing-to-evade-detection/ ↩ ↩2

  3. Wyciekane AWS credentials znajdują się w repozytoriach GitHub, plikach .ENV, obrazach Docker, backupach i publicznie dostępnych S3 bucketach — https://www.bleepingcomputer.com/news/security/amazon-ses-increasingly-abused-in-phishing-to-evade-detection/ ↩ ↩2

  4. Wykorzystując Amazon SES, atakujący nie muszą się martwić o kontrole autentyczności takie jak SPF, DKIM i DMARC — https://www.bleepingcomputer.com/news/security/amazon-ses-increasingly-abused-in-phishing-to-evade-detection/ ↩

  5. Atakujący używają zautomatyzowanych narzędzi opartych na TruffleHog do skanowania i wyszukiwania wyciekniętych sekretów — https://www.bleepingcomputer.com/news/security/amazon-ses-increasingly-abused-in-phishing-to-evade-detection/ ↩

  6. Atakujący wykorzystują zautomatyzowane ataki do skanowania sekretów, walidacji uprawnień i dystrybucji e-maili phishingowych na masową skalę — https://www.bleepingcomputer.com/news/security/amazon-ses-increasingly-abused-in-phishing-to-evade-detection/ ↩

  7. Obserwowane phishingowe kampanie zawierają niestandardowe szablony HTML imitujące rzeczywiste usługi i realistyczne przepływy logowania — https://www.bleepingcomputer.com/news/security/amazon-ses-increasingly-abused-in-phishing-to-evade-detection/ ↩

  8. Ataki obejmują fałszywe powiadomienia o podpisywaniu dokumentów imitujące DocuSign, które kierują ofiary na phishingowe strony hostowane na AWS — https://www.bleepingcomputer.com/news/security/amazon-ses-increasingly-abused-in-phishing-to-evade-detection/ ↩

  9. Atakujący tworzą fałszywe wątki e-mailowe i wysyłają fałszywe faktury, aby oszukać działy finansowe do dokonania płatności — https://www.bleepingcomputer.com/news/security/amazon-ses-increasingly-abused-in-phishing-to-evade-detection/ ↩

  10. Kaspersky zaleca ograniczenie uprawnień IAM na podstawie zasady najmniejszych uprawnień, włączenie uwierzytelniania wieloskładnikowego, regularne rotowanie kluczy oraz zastosowanie ograniczeń opartych na IP i kontroli szyfrowania — https://www.bleepingcomputer.com/news/security/amazon-ses-increasingly-abused-in-phishing-to-evade-detection/ ↩ ↩2 ↩3 ↩4

  11. Amazon wskazuje, że osoby podejrzewające nadużycia zasobów AWS mogą zgłosić to do AWS Trust & Safety — https://www.bleepingcomputer.com/news/security/amazon-ses-increasingly-abused-in-phishing-to-evade-detection/ ↩

  12. Blokowanie adresów IP dostarczających phishingowe e-maile nie jest akceptowalnym rozwiązaniem, ponieważ uniemożliwiłoby wszystkie e-maile przesyłane przez Amazon SES — https://www.bleepingcomputer.com/news/security/amazon-ses-increasingly-abused-in-phishing-to-evade-detection/ ↩