Gdy zabezpieczenia pomagają spamerom: Jak przejąć reputację domeny bez łamania kryptografii?

Otwierasz skrzynkę pocztową i widzisz oficjalne powiadomienie bezpieczeństwa od Google. Wszystko wygląda w 100% wiarygodnie. Systemy pocztowe wyświetlają zielony ptaszek, a nagłówki potwierdzają sukces: dkim=pass

Klikasz w link i bezwiednie wpadasz w pułapkę phishingu.

Jak to możliwe? Żaden haker nie wykradł haseł, nie przejął serwerów Google ani nie złamał szyfrowania. Oszust po prostu wykorzystał oficjalny cyfrowy paszport Google, aby wślizgnąć się prosto do Twojej skrzynki odbiorczej.

Oto atak DKIM replay – fascynująca luka w mechanizmie zaufania poczty elektronicznej, gdzie zabezpieczenie stworzone do naszej ochrony staje się najlepszą bronią spamera.

TL;DR

• Zielony ptaszek to nie certyfikat uczciwości: wynik dkim=pass potwierdza tylko brak zmian w treści, ale nie gwarantuje, że mail jest bezpieczny ani do kogo miał trafić.
• Sfałszowany mail z prawdziwym podpisem: w ataku DKIM replay oszust przechwytuje oryginalną wiadomość znanej marki (np. Google, Apple, PayPal) i wysyła ją ze swoich serwerów do nowych ofiar.
• Dziura w cyfrowej kopercie: podpis DKIM1 jest jak pieczęć na liście, ale nie zawiera adresu odbiorcy. Zmiana adresata w sesji SMTP nie psuje podpisu.
• Przepustka omijająca filtry SPAM: filtry pocztowe widzą znany podpis zaufanej firmy, co pozwala oszustwom omijać folder ze spamem i lądować w skrzynce głównej.
• Ofiarą pada też nadawca: masowy replay potrafi zniszczyć reputację domeny firmy (jak w przypadku ProtonMaila), sprawiając, że jej prawdziwe maile trafiają do spamu.
• Brak jednego guzika “napraw“: standard DKIM2 dopiero powstaje w IETF. Ochrona wymaga dziś bezpiecznego projektowania maili, izolacji wysyłek testowych i segmentacji kluczy.

Czym tak naprawdę jest DKIM?

Większość ludzi uważa, że DKIM (DomainKeys Identified Mail) to cyfrowy stempel mówiący: „Ten mail na 100% pochodzi od tej firmy”.

To najpopularniejsza pułapka myślowa w poczcie. Specyfikacja RFC 6376 precyzuje to znacznie ostrożniej. DKIM oznacza jedynie, że domena z pola d= bierze odpowiedzialność za przesłaną treść. Nie musi być ona wcale tą samą domeną, którą widzisz w polu From:.

DKIM oddziela tożsamość podpisującego od deklarowanego autora. Maile mogą podpisywać dostawcy poczty, systemy powiadomień czy serwisy pośredniczące.

Lakowa pieczęć i papierowa koperta

Aby wyobrazić sobie DKIM bez technicznego żargonu, wróćmy do czasów tradycyjnego listu. Twój dokument zostaje zamknięty odciskiem lakowej pieczęci. Sygnet nadawcy reprezentuje klucz prywatny, a oficjalny wzór pieczęci w atlasie odpowiada kluczowi publicznemu w DNS. Każdy odbiorca może przyłożyć odcisk listu do wzoru z atlasu. Jeśli pasują idealnie, wie, że list zapieczętował posiadacz sygnetu i nikt nie zmienił treści pod pieczęcią. Ta piękna analogia kryje jednak dwa haczyki. Po pierwsze, DKIM nie zamyka wiadomości w sejfie i niczego nie szyfruje. Treść maila jest czytelna dla każdego serwera po drodze. Funkcja ta tworzy skrót kryptograficzny określonej treści email i szyfruje go przy pomocy klucza prywatnego  (RFC 6376, sekcja 1). Po drugie, lakowa pieczęć znajduje się na kartce papieru w środku, a nie na papierowej kopercie z adresem.

Co dzieje się pod maską podczas podpisywania?

Zanim e-mail opuści serwer nadawcy, system wykonuje szybki taniec kryptograficzny.

1. Wybiera nagłówki do ochrony (zawsze From:, często też To:, Subject: czy Date:) i zapisuje je w polu h=.
2. Czyści treść ze zbędnych spacji i nowych linii w procesie kanonizacji (c=relaxed/relaxed).
3. Liczy skrót kryptograficzny treści i zapisuje ją w polu bh=.

Oto jak taki nagłówek wygląda w nagłówkach wiadomości:

DKIM-Signature: v=1; a=rsa-sha256;

d=accounts.google.com; s=20230601;

c=relaxed/relaxed;
h=from:to:subject:date:message-id;
bh=mgcXM1MuCdJv67y24jPB/mMBhSFKoC0jv6I5FoRc3FE=;
b=cLs3K3a...

Serwer odbiorcy bierze domenę (d=accounts.google.com) oraz selektor (s=20230601), a następnie pyta serwer DNS o klucz publiczny pod adresem:

20230601._domainkey.accounts.google.com

Po pozytywnym zweryfikowaniu kryptograficznych podpisów dostajemy wynik dkim=pass  dkim=pass.

Podstępna pułapka dawnego tagu length

Warto wspomnieć o dawnej sztuczce, która pozwalała oszustom modyfikować maile pod nosem systemu. Opcjonalny tag l= (length) pozwalał podpisać tylko pierwsze N bajtów wiadomości. Jeśli serwer podpisał pierwsze 500 bajtów maila, spamer mógł dokleić na końcu własny kod HTML z linkiem phishingowym, a podpis nadal pozostawał ważny.

Dziś używanie tagu l= jest uważane za prosty przepis na katastrofę (RFC 6376, sekcja 8.2).

Złudzenie zielonego ptaszka dkim=pass

Kiedy Twój program pocztowy pokazuje zielony Ptaszek weryfikacji, łatwo ulec ułudzie bezpieczeństwa. Status dkim=pass mówi wyłącznie: „Ten konkretny fragment tekstu zgadza się z kluczem publicznym wybranej domeny”.

Nie mówi natomiast absolutnie nic o tym:

• Czy treść w mailu jest prawdziwa i bezpieczna.
• Czy e-mail trafił do osoby, dla której był pierwotnie przeznaczony.
• Czy obecna wysyłka została w ogóle autoryzowana przez właściciela domeny.

Organizacja M3AAWG podsumowuje to krótko: DKIM buduje relację z domeną, ale nie gwarantuje jakości ani legalności treści. Źródło: M3AAWG Technology Summary: DKIM.

Anatomia ataku: Prawidłowy list w nowej kopercie

Wyobraź sobie, że oszust podchodzi do Twojej skrzynki pocztowej.

Nie musi podrabiać sygnetu banku ani łamać pieczęci. Wystarczy, że wyjmie z prawowitej koperty prawdziwy, zapieczętowany list od banku, włoży go do własnej koperty i zaadresuje do Ciebie.

Pieczęć na liście jest prawdziwa. Dokument jest prawdziwy. Ale trafia do kogoś, kto nigdy nie powinien go dostać.

Dokładnie tak działa DKIM replay.

W poczcie elektronicznej rolę koperty pełni sesja SMTP. To w niej serwer podaje komendę nadawcy MAIL FROM oraz faktycznego odbiorcy RCPT TO.

Nagłówek To: wyświetlany w Twojej aplikacji e-mail to tylko napis na kartce. Nie ma żadnego wpływu na to, dokąd serwer naprawdę dostarczy wiadomość.

Poprawna pierwsza wysyłka wygląda tak:

MAIL FROM:<service@brand.example>

RCPT TO:<attacker@example.net>

From: alerts@brand.example

To: attacker@example.net

DKIM-Signature: d=brand.example; ...

Napastnik przechwytuje tego maila i wysyła go ponownie ze swojego serwera do nowej ofiary:

MAIL FROM:<bounce@attacker.example>

RCPT TO:<victim@gmail.com>

From: alerts@brand.example

To: attacker@example.net

DKIM-Signature: d=brand.example; ...

Spamer zmienił adresata w komendzie RCPT TO, ale sam list i podpis pozostały identyczne. Ponieważ DKIM1 nie podpisał komend sesji SMTP, podpis przechodzi śpiewająco. Filtry widzą oficjalny podpis Google czy Apple i wpuszczają maila prosto do skrzynki odbiorczej. Dokument RFC 6376 w sekcji 8.6 wprost wymienia replay jako znaną wadę architektury poczty.

Maszynka do podpisów, czyli Signing Oracle

Aby atak się powiódł, spamer potrzebuje przynęty. Musi sprawić, by oficjalny system znanej marki wygenerował maila zawierającego pułapkę oszusta i opatrzył go podpisem DKIM. Zjawisko to nazywamy Signing Oracle. Wystarczy wpisać fałszywy numer infolinii lub złośliwy link w pole, które automatycznie trafia do powiadomienia e-mail (np. nazwa konta użytkownika, komentarz do przelewu czy nazwa nowej aplikacji).

Przypadek 1: Prawdziwy alert Google OAuth (2025)

W kwietniu 2025 roku głośna kampania phishingowa uderzyła między innymi w Nicka Johnsona z Ethereum Name Service.

Oszust założył nową aplikację w panelu Google OAuth. W jej nazwie umieścił treść phishingową z odnośnikiem do fałszywego panelu pomocy osadzonego na platformie Google Sites.

Zarejestrowanie aplikacji zmusiło systemy Google do wygenerowania prawdziwego alertu bezpieczeństwa wysłanego na maila oszusta, z podpisem d=accounts.google.com.

Oszust przechwycił ten mały alert i bez żadnych zmian rozesłał go ze swojego serwera pocztowego (fwd-04-1.fwd.privateemail.com) do docelowych ofiar.

Gmail dołączył sfałszowaną wiadomość do oficjalnego wątku alertów bezpieczeństwa, ponieważ poprawny podpis cyfrowy i DMARC zmyliły mechanizm grupowania wiadomości.

Źródła:

• Analiza techniczna EasyDMARC
• Opis ataku w BleepingComputer
• Oświadczenie Google opublikowane przez The Hacker News

Przypadek 2: Apple i PayPal jako cyfrowa przynęta (2026)

W lutym 2026 roku specjaliści Kaseya/INKY opisali wykorzystanie prawdziwych wiadomości transakcyjnych firm Apple i PayPal w tzw. callback scamach.

W przypadku Apple oszuści wpisali złośliwy numer telefonu infolinii w pola danych konta. System Apple wygenerował oficjalne powiadomienie o subskrypcji podpisane domeną email.apple.com.

W przypadku PayPal złośliwy tekst umieszczano w nazwie sprzedawcy przy tworzeniu faktury, a system generował wiadomość z cyfrowym podpisem paypal.com.

Napastnicy przechwycili te maile i nadali je ponownie przez własne serwery SMTP. Odbiorcy widzieli prawdziwe maile od gigantów z prośbą o natychmiastowy kontakt telefoniczny.

Źródło: Raport Kaseya/INKY o atakach DKIM Replay.

ProtonMail: Gdy replay niszczy reputację nadawcy (2021)

Ataki na Google czy Apple były precyzyjne. Incydent ProtonMaila z grudnia 2021 roku pokazał jednak drugą stronę medalu: masowe zniszczenie reputacji.

Spamerzy przechwycili jedną oficjalnie podpisaną wiadomość wysłaną z ProtonMaila i zorganizowali jej masowy replay z rosyjskich adresów IP do użytkowników Gmaila.

W szczytowym momencie fałszywy ruch stanowił 98% wszystkich maili, które Gmail odbierał jako pochodzące z domeny protonmail.com. Wolumen był 50-krotnie większy od normalnego ruchu!

Efekt był katastrofalny. Filtry antyspamowe Google obniżyły reputację całej domeny Protona. W efekcie prawdziwe maile zwykłych użytkowników zaczęły masowo wpadać do spamu.

Proton musiał wywrócić stolik i przeprowadzić natychmiastową rotację kluczy DKIM, by unieważnić sfałszowaną sygnaturę.

Źródła:

• Oficjalny postmortem Protona
• Komunikat Proton w serwisie Reddit

Dlaczego filtry pocztowe mają związane ręce?

Dla serwera odbierającego odróżnienie ataku replay od legalnej komunikacji jest niezwykle trudne.

Ten sam podpis DKIM powraca w sieci z wielu jak najbardziej legalnych powodów:

• Użytkownik ustawił automatyczne przekazywanie poczty (forwarding).
• Mail został przesłany do grupy lub listy dyskusyjnej.
• Wiadomość trafiła do odbiorcy ukrytego w polu BCC:.

Duzi dostawcy analizują miliony maili, tworzą skróty z sygnatur b= (tzw. signature fingerprinting) i szukają nagłych skoków powtórzeń.

Są to jednak tylko heurystyki. System nie może po prostu odrzucić maila za to, że ten sam podpis pojawił się w sieci kilka razy.

Gmail nie rozpoznaje ataku replay na podstawie samego DKIM. Musi kojarzyć ze sobą telemetrię, treść wiadomości, trasę przesyłki i zachowania odbiorców.

Standard przyszłości: DKIM2 oraz rola IETF i M3AAWG

Aby załatać tę lukę w architekturze poczty, grupa robocza IETF rozwija specyfikację DKIM2.

Projekt (draft-ietf-dkim-dkim2-spec) zakłada cyfrowe przypięcie podpisu do danych koperty SMTP.

W nagłówku DKIM2 pojawiają się nowe pola:

• mf= zawierające adres nadawcy kopertowego (MAIL FROM),
• rt= zawierające tablicę odbiorców kopertowych (RCPT TO).

Dzięki temu zmiana odbiorcy w kopercie automatycznie unieważnia podpis.

Warto przy tym jasno rozdzielić role organizacji:

• IETF (Internet Engineering Task Force) tworzy oficjalne standardy internetowe RFC.
• M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group) to forum eksperckie dostawców i operatorów zwalczających nadużycia w praktyce.

Źródła:

• Specyfikacja robocza DKIM2 w IETF
• M3AAWG o sesjach poświęconych DKIM Replay

Rekomendacje eksperckie: Jak chronić własną domenę?

Nie ma jednego magicznego guzika, który wyłącza problem DKIM replay. Ochrona polega na ograniczaniu pola rażenia (blast radius) oraz skracaniu czasu ważności podpisów.

1. Sanitizacja danych i kontrola Signing Oracle

Każde pole tekstowe wprowadzane przez użytkownika, które trafia do maili transakcyjnych, musi być czyszczone. Ogranicz długość znaków, usuwaj numery telefonów i odnośniki URL.

2. Krótki czas ważności w tagu x=

Tag x= pozwala ustawić czas ważności podpisu (np. 48 godzin). Po tym czasie serwer odbiorcy traktuje sygnaturę jako wygasłą, skracając okno na przeprowadzenie ataku (RFC 6376, sekcja 3.5).

3. Izolacja funkcji testowych

Wysyłanie maili testowych w systemach SaaS to ulubiony cel spamerów. Funkcje te powinny korzystać z osobnej subdomeny, osobnego selektora oraz surowych limitów ilościowych.

4. Segmentacja domen i kluczy

Poczta transakcyjna i marketingowa nie powinny dzielić tej samej subdomeny ani tego samego klucza DKIM. W razie wycieku maila marketingowego, reputacja Twojej głównej poczty pozostanie bezpieczna (RFC 5863, sekcja 2.3).

5. Świadome podwójne podpisywanie (Double Signing)

Drugi podpis dostawcy infrastruktury (ESP) pomaga w ocenie reputacji operatora. Pamiętaj jednak: oszust przechwytujący maila z dwoma podpisami zachowuje oba przy retransmisji (M3AAWG Best Practices).

6. Rotacja kluczy i monitoring

Rotuj klucze DKIM (np. co 6 miesięcy) i bądź przygotowany na ich natychmiastowe odwołanie przy masowym ataku (M3AAWG DKIM Key Rotation BCP). Monitoruj logi pod kątem skoków wolumenu i powtórzeń skrótów b=.

Podsumowanie

Atak DKIM replay przypomina podstawową zasadę bezpieczeństwa: poprawność kryptograficzna to nie to samo co uczciwe intencje nadawcy.

DKIM1 sprawdza niepodważalność treści, ale nie daje gwarancji co do trasy i odbiorcy maila.

Zanim DKIM2 stanie się powszechnym standardem, ochrona Twojej firmy zależy od sanitizacji danych wyjściowych, segmentacji kluczy i ciągłego monitorowania poczty.

Zapamiętaj: DKIM podpisuje wiadomość, ale nie podpisuje jej dostarczenia.

---

O autorze