67% phishingu przechodzi DMARC. Zaufanie pod presją

TL;DR

W pierwszej połowie 2026 roku 67% wiadomości phishingowych obserwowanych w zagregowanych wdrożeniach chmurowych klientów Darktrace przeszło DMARC. To nie jest globalna statystyka całego phishingu, lecz wyraźny sygnał: coraz więcej ataków nie musi już fałszować domeny nadawcy.

DMARC odpowiada na pytanie: „czy ta domena ma prawo wysłać tę wiadomość?”. Nie odpowiada na pytanie: „czy wiadomość jest bezpieczna?”. Gdy napastnik przejmuje legalne konto, korzysta z prawidłowo uwierzytelnionej usługi SaaS albo buduje wiarygodny kontekst biznesowy, zielone kontrolki SPF, DKIM i DMARC mogą współistnieć z phishingiem.

Dlatego zaufanie stało się nową powierzchnią ataku. Organizacje muszą chronić nie tylko domenę, ale też tożsamości, procesy zatwierdzania, integracje chmurowe i decyzje podejmowane przez ludzi.

Co dokładnie oznacza 67%

Darktrace przeanalizował dane z własnych wdrożeń klientów za okres od 1 stycznia do 30 czerwca 2026 roku. Po zastosowaniu filtrów jakości firma odnotowała, że 67% wykrytych wiadomości phishingowych przeszło kontrolę DMARC.

W tym samym zestawie danych 25,8% kampanii celowało w osoby określane jako VIP, 39% wykorzystywało nowe formy socjotechniki, a udział wiadomości z dużą ilością tekstu wzrósł do 37% z 32% rok wcześniej. Obraz jest spójny: atakujący inwestują w wiarygodny kontekst, zaufane kanały i komunikaty, które trudniej odróżnić od zwykłej pracy.

Liczbę 67% trzeba jednak czytać precyzyjnie. To:

• wynik z telemetrii klientów jednego dostawcy, a nie pomiar całego Internetu;
• udział w wiadomościach już rozpoznanych jako phishing, a nie wskaźnik skuteczności wszystkich ataków;
• dowód ograniczonego zakresu DMARC, a nie dowód jego nieskuteczności.

Wniosek nie brzmi więc „DMARC nie działa”. Brzmi: duża część współczesnego phishingu działa w granicach zaufanej infrastruktury.

Co DMARC sprawdza, a czego nie sprawdza

DMARC łączy wyniki SPF lub DKIM z domeną widoczną dla użytkownika w polu From. Jeżeli wymagane wyrównanie domen jest poprawne, wiadomość może przejść kontrolę. Właściciel domeny określa też politykę postępowania z wiadomościami, które kontroli nie przechodzą, oraz otrzymuje raporty pomocne w porządkowaniu źródeł wysyłki.

To ważna ochrona. Ogranicza możliwość prostego podszycia się pod dokładną domenę firmy, wspiera egzekwowanie polityki i zwiększa widoczność nadużyć. Aktualna specyfikacja RFC 9989 nie definiuje jednak DMARC jako systemu oceny bezpieczeństwa treści.

DMARC nie potwierdza:

• że właściciel prawdziwego konta rzeczywiście napisał wiadomość;
• że nadawca nie nadużywa legalnej platformy marketingowej lub transakcyjnej;
• że domena podobna wizualnie do domeny firmy jest uczciwa;
• że link prowadzi do bezpiecznej strony;
• że prośba o płatność, reset hasła lub udostępnienie dokumentu ma prawidłowy kontekst biznesowy.

Innymi słowy, DMARC weryfikuje relację techniczną między domenami. Nie weryfikuje intencji człowieka ani stanu bezpieczeństwa całego łańcucha wysyłki.

DMARC potwierdza zgodność domeny, ale złośliwa prośba nadal może dotrzeć z przejętego konta lub legalnej usługi. Bezpiecznym punktem zatrzymania jest weryfikacja innym kanałem.

Cztery drogi phishingu z poprawnym DMARC

1. Przejęte prawdziwe konto

Jeżeli napastnik uzyska dostęp do skrzynki pracownika, dostawcy lub partnera, wysyła wiadomość z infrastruktury uprawnionej do używania tej domeny. SPF, DKIM i DMARC mogą być poprawne, bo technicznie wiadomość pochodzi z legalnego systemu.

To szczególnie groźne w istniejącym wątku korespondencji. Odbiorca zna nadawcę, widzi historię rozmowy i oczekiwany podpis. Atak wykorzystuje reputację zgromadzoną wcześniej przez inną osobę. Podobny mechanizm omawiamy w analizie phishingu wysłanego z legalnego adresu Robinhood oraz w przypadku przejętych kont Microsoft 365.

2. Nadużycie legalnej platformy wysyłkowej

Platformy mailingowe, systemy fakturowe, formularze i usługi chmurowe mają poprawnie skonfigurowane mechanizmy uwierzytelniania. Jeżeli napastnik założy konto, przejmie tenant albo znajdzie funkcję pozwalającą kontrolować treść, phishing może podróżować legalnym kanałem.

Wtedy filtry widzą znanego dostawcę, prawidłowy podpis DKIM i zgodność DMARC. Problemem nie jest sfałszowany transport, lecz to, co zaufana usługa zgodziła się dostarczyć. Pokazuje to między innymi opisane przez nas wykorzystanie Amazon SES jako przekaźnika phishingu.

3. Domena podobna, ale niepodrobiona

DMARC może skutecznie chronić firma.pl, a jednocześnie nie zablokuje legalnie zarejestrowanej domeny fírma-support.pl lub innej nazwy podobnej wizualnie. Atakujący jest właścicielem takiej domeny, więc może poprawnie skonfigurować dla niej SPF, DKIM i DMARC.

Z punktu widzenia protokołu wszystko się zgadza. Z punktu widzenia człowieka podobieństwo nazwy, układ stopki i kontekst mogą stworzyć fałszywe poczucie ciągłości.

4. Złośliwa treść w legalnym procesie

Nie każda próba wyłudzenia zaczyna się od klasycznego linku do fałszywego logowania. Czasem wiadomość uruchamia rozmowę, prosi o zmianę numeru rachunku, skłania do otwarcia udostępnionego dokumentu albo przenosi kontakt do komunikatora.

Pierwszy e-mail może nie zawierać technicznie złośliwego elementu. Jego rolą jest zdobycie odpowiedzi i przeniesienie odbiorcy do kolejnego etapu. Filtr treści i DMARC widzą poprawną wiadomość, ale proces biznesowy został już skierowany na niewłaściwy tor.

Dlaczego zaufanie stało się powierzchnią ataku

Klasyczna powierzchnia ataku kojarzyła się z portami sieciowymi, podatnymi serwerami i niezałatanymi aplikacjami. W środowisku chmurowym równie ważne są relacje zaufania: kto może wysyłać w imieniu domeny, komu wolno udostępnić dokument, które aplikacje mają tokeny OAuth i czyja prośba może uruchomić płatność lub reset dostępu.

Każda z tych relacji skraca drogę do działania. To właśnie czyni ją atrakcyjną dla napastnika. Zaufany dostawca ma reputację. Zaufane konto ma historię. Zaufany wątek ma kontekst. Zaufany proces ma przywileje. Po przejęciu jednego elementu atakujący nie musi budować wiarygodności od zera — dziedziczy ją.

Darktrace opisuje też przypadki, w których pojedyncze przejęcie konta SaaS powodowało skutki widoczne jednocześnie w poczcie, aplikacji chmurowej i ruchu sieciowym. To ważna zmiana perspektywy: wiadomość nie jest odizolowanym obiektem do sklasyfikowania. Jest zdarzeniem w łańcuchu tożsamości, sesji, uprawnień i zachowania.

Co powinny zmienić IT, SOC i biznes

Utrzymywać DMARC, ale nie traktować go jak werdyktu

SPF, DKIM i DMARC powinny być prawidłowo wdrożone, monitorowane i stopniowo egzekwowane. Microsoft również wskazuje, że DMARC pomaga chronić domenę widoczną w polu From. Wynik pass musi jednak być sygnałem „nadawca jest technicznie zgodny”, a nie „wiadomość jest bezpieczna”.

Korelować pocztę z tożsamością i SaaS

SOC powinien łączyć nietypową wysyłkę z nowym logowaniem, zmianą reguł skrzynki, nadaniem zgody OAuth, utworzeniem tokenu, pobraniem danych lub aktywnością z nietypowej lokalizacji. Sam nagłówek wiadomości może wyglądać prawidłowo, gdy zachowanie konta jest wyraźnie anomalne.

Chronić procesy wysokiego ryzyka

Zmiana rachunku bankowego, reset MFA, udostępnienie danych i modyfikacja listy odbiorców nie powinny zależeć wyłącznie od wiarygodnego e-maila. Potrzebne są niezależny kanał potwierdzenia, rozdzielenie obowiązków i czytelna ścieżka eskalacji.

Weryfikować aplikacje i dostawców

Warto prowadzić spis aplikacji wysyłających pocztę, ograniczać ich zakresy, usuwać nieużywane integracje i sprawdzać, kto może tworzyć kampanie lub szablony. Zaufana platforma jest częścią powierzchni ataku tak samo jak konto pracownika.

Projektować obronę warstwowo

Nie ma jednego mechanizmu, który zatrzyma wszystkie warianty phishingu. Potrzebne są uwierzytelnienie domeny, ochrona tożsamości, analiza zachowania, filtrowanie treści, bezpieczna przeglądarka, procesy biznesowe i szybkie zgłaszanie incydentów. Szerszy model opisujemy w poradniku co musi działać w firmie poza samym filtrem poczty.

Jak testować użytkowników bez uczenia „sprawdzaj domenę”

Porada „sprawdź nadawcę” nadal ma wartość, ale jest zbyt wąska. Może wręcz tworzyć fałszywe poczucie bezpieczeństwa: jeśli domena wygląda poprawnie, pracownik uznaje wiadomość za bezpieczną.

Dobre ćwiczenia security awareness powinny obejmować scenariusze, w których:

• nadawca i domena wyglądają prawidłowo;
• wiadomość pojawia się w istniejącym kontekście biznesowym;
• prośba jest możliwa, ale nietypowa dla danej osoby lub procesu;
• presja czasu ma skłonić do pominięcia drugiego kanału weryfikacji;
• link prowadzi przez legalną usługę, a ryzyko ujawnia się dopiero później;
• poprawną reakcją jest zgłoszenie lub potwierdzenie prośby, a nie samodzielne śledztwo.

Celem nie jest nauczenie ludzi rozpoznawania każdej sztuczki graficznej. Celem jest zbudowanie nawyku zatrzymania się przy zmianie kontekstu i uruchomienia bezpiecznego procesu. Taki program powinien łączyć krótkie, regularne ćwiczenia z danymi o tym, czy pracownicy zgłaszają wiadomości i czy organizacja potrafi szybko na te zgłoszenia reagować. Więcej o podejściu procesowym opisujemy na stronie security awareness program.

Jeżeli chcesz sprawdzić odporność zespołu na wiadomości wysyłane z wiarygodnego kontekstu — nie tylko na oczywiste literówki w domenie — zobacz testy phishingowe dla firm.

Wniosek: poprawne uwierzytelnienie to początek oceny

Statystyka 67% nie odbiera DMARC wartości. Pokazuje, że sukces protokołów uwierzytelniania zmienił ekonomię ataku. Zamiast zawsze fałszować nadawcę, przestępcy częściej przejmują prawdziwe konta, nadużywają legalnych usług i wykorzystują relacje, którym firma już ufa.

Najważniejsza zmiana jest prosta: uwierzytelnienie domeny nie może kończyć analizy wiadomości. Musi ją rozpoczynać. Dopiero połączenie informacji o domenie, tożsamości, zachowaniu, treści i procesie biznesowym pozwala ocenić, czy zaufanie jest uzasadnione — czy właśnie zostało wykorzystane przeciw organizacji.