Phishing z prawdziwym newsletterem: skradziona treść zmienia sygnały dla filtrów

Dopiero niżej, po około 70 pustych przełamaniach linii, znajdował się kompletny, niezwiązany legalny e-mail handlowy wysłany wcześniej do innej osoby w innej organizacji. Według IRONSCALES ta cudza wiadomość służyła jako wypełnienie, czyli padding: zwiększała objętość tekstu, liczbę normalnych linków i ilość typowego marketingowego HTML, podczas gdy człowiek widział głównie krótką przynętę u góry.

To nie oznacza, że taka technika automatycznie omija filtry. Pokazuje natomiast, że atakujący może próbować manipulować nie tylko tym, co czyta odbiorca, ale też statystycznym obrazem całej wiadomości analizowanym przez system ochrony poczty.

Co wykrył IRONSCALES 4 września 2026

IRONSCALES to dostawca zabezpieczeń poczty, który publikuje analizy wiadomości wykrytych przez własną platformę. W tym przypadku opisał dwie wiadomości dostarczone do skrzynek w firmie produkującej opakowania dla branży spożywczej.

Wiadomość miała pusty temat. Nadawca wyświetlał nazwę organizacji odbiorcy, choć faktyczna domena wysyłająca była inna. Treść zwracała się do odbiorcy po imieniu, przytaczała jego adres e-mail i informowała o dokumentacji czekającej na finalne zatwierdzenie. Jedyny przycisk wyglądał jak nazwa pliku PDF dotyczącego ugody.

To wystarczało, aby zbudować prosty kontekst biznesowy: odbiorca miał zobaczyć własną firmę, własne dane i pozornie oczekiwany dokument. Nie było potrzeby tworzenia rozbudowanej historii.

Jak wyglądał łańcuch od wiadomości do strony wyłudzającej dane

Link nie prowadził bezpośrednio do końcowej strony. Najpierw przechodził przez tracker platformy wysyłkowej Mandrill, a dopiero potem kierował do strony przechwytującej poświadczenia na długo istniejącej domenie w strefie .co.za.

IRONSCALES zwrócił uwagę na kilka elementów, które osobno mogły wyglądać zwyczajnie:

• domena nadawcy istniała od wielu lat i podpisywała wiadomość własnym kluczem DKIM;
• link korzystał z legalnej usługi śledzenia kliknięć;
• końcowa domena również nie była świeżo zarejestrowana;
• wiadomość przechodziła techniczne mechanizmy uwierzytelnienia domeny.

Jednocześnie zachowanie całości było podejrzane. Nazwa wyświetlana podszywała się pod organizację odbiorcy, lokalna część adresu nadawcy przypominała uszkodzony ciąg parametrów marketingowych, tekst widoczny po najechaniu na link nie zgadzał się z rzeczywistym adresem, a końcowa strona została sklasyfikowana jako złośliwa.

IRONSCALES podał 89% confidence dla kategorii credential theft i poinformował, że obie wiadomości zostały poddane kwarantannie.

Po co doklejać prawdziwy newsletter pod przynętą

Najbardziej nietypowy element znajdował się pod tym, co widział użytkownik. Po około 70 pustych przełamaniach linii wiadomość zawierała kompletny blok legalnej korespondencji handlowej: typowy kod szablonu, linki śledzące, stopkę oraz inne elementy występujące w zwykłych wiadomościach marketingowych.

Źródło podkreśla, że była to prawdziwa wiadomość, która wcześniej trafiła do innej osoby w innej organizacji. Nie ma danych pozwalających stwierdzić, w jaki sposób napastnik ją pozyskał, dlatego nie należy przypisywać jej konkretnemu wcześniejszemu włamaniu.

Po co w ogóle dodawać taką treść?

Krótka wiadomość phishingowa z jednym linkiem ma bardzo prostą strukturę. Prawie cały tekst dotyczy prośby napastnika, a jedyny link ma ogromne znaczenie w proporcji do całej wiadomości. Po doklejeniu prawdziwego newslettera obraz się zmienia:

• rośnie ilość zwykłego tekstu;
• pojawia się więcej linków prowadzących do legalnych miejsc;
• rośnie ilość typowego kodu HTML;
• pojawiają się stopki, informacje formalne i inne elementy charakterystyczne dla masowej korespondencji;
• złośliwy link staje się jednym z wielu linków analizowanych w całym dokumencie.

Puste linie mają dodatkowy efekt po stronie człowieka. Doklejona wiadomość ląduje daleko poniżej widocznego obszaru, więc odbiorca może w ogóle jej nie zobaczyć. Parser poczty nie ma jednak „dolnej krawędzi ekranu” — analizuje cały kod wiadomości.

To właśnie różnica między tym, co czyta użytkownik, a tym, co mierzy system, jest osią tego przypadku.

Dlaczego SPF, DKIM i DMARC nie rozstrzygają bezpieczeństwa treści

W opisanym incydencie SPF przeszedł, DKIM przeszedł dwukrotnie, DMARC przeszedł, a Microsoft composite authentication zwrócił wynik pass.

Nie jest to sprzeczność. Aktualna specyfikacja RFC 9989 wyjaśnia, że DMARC potwierdza autoryzowane użycie domeny widocznej w polu autora w relacji do wyników SPF lub DKIM. Standard wprost zaznacza, że wynik pass sam w sobie nie oznacza, że dostarczenie wiadomości jest bezpieczne lub pożądane.

W tym przypadku techniczne uwierzytelnienie odpowiadało na pytanie o domenę nadawcy. Nie odpowiadało na inne pytania:

• czy nazwa wyświetlana nadawcy uczciwie opisuje jego tożsamość;
• czy link prowadzi do strony, do której powinien trafić pracownik;
• czy dokument rzeczywiście istnieje;
• czy prośba pasuje do normalnego procesu biznesowego odbiorcy;
• czy treść doklejona pod wiadomością jest związana z jej celem.

Szersze ograniczenia tych mechanizmów opisujemy w artykule dlaczego phishing może przejść DMARC. Osobny przypadek nadużycia Amazon SES do wysyłki phishingu pokazuje podobną granicę od strony legalnej infrastruktury wysyłkowej.

Jakie sygnały nadal zdradzały phishing

Doklejony legalny e-mail nie usuwał wszystkich sygnałów ryzyka. IRONSCALES wskazał kilka elementów, które nadal można było zestawić w spójny obraz:

Nazwa firmy odbiorcy w nazwie wyświetlanej nadawcy

Wiadomość przychodziła z zewnątrz, ale nazwa wyświetlana sugerowała, że nadawcą jest własna organizacja odbiorcy. Taki konflikt można wykrywać niezależnie od SPF czy DKIM.

Nietypowy adres nadawcy

Lokalna część adresu zawierała długi ciąg przypominający parametry kampanii marketingowej. Nie wyglądała jak rzeczywista skrzynka człowieka ani systemu transakcyjnego.

Pusty temat i krótka prośba o zatwierdzenie

Sama forma nie dowodzi phishingu, ale w połączeniu z podszywaniem się pod firmę i dokumentem prowadzącym do logowania tworzy dodatkowy sygnał.

Rozbieżność między opisem linku a jego celem

Tekst widoczny przy linku sugerował inne miejsce niż faktyczny adres href. System może porównać te wartości bez znajomości reputacji domeny.

Tracker jako warstwa pośrednia

Legalny tracker kliknięć nie jest złośliwy sam w sobie. System ochrony powinien jednak rozwiązywać przekierowanie do końcowego miejsca i oceniać także stronę docelową.

Podobne różnice między tym, co renderuje interfejs, a tym, co analizuje parser, pojawiają się przy innych technikach. W artykule o ukrytym tekście i Unicode w phishingu opisujemy inny mechanizm: tam zmieniana jest reprezentacja znaków, tutaj — statystyczny kontekst całej wiadomości.

Co może zrobić organizacja po stronie filtrów i procesu

Przypadek pokazuje, dlaczego pojedynczy sygnał nie powinien decydować o werdykcie.

Analizować wiadomość po normalizacji

Długie serie pustych linii, duże bloki niezwiązanego HTML i nagłe przejście od krótkiej przynęty do pełnego newslettera mogą być sygnałem strukturalnym. System może porównywać widoczną część komunikatu z pełnym dokumentem i oddzielnie oceniać główną prośbę.

Rozwiązywać przekierowania

Jeżeli link prowadzi przez platformę śledzącą, warto ocenić nie tylko domenę trackera, ale również końcowe miejsce docelowe. Legalna warstwa pośrednia nie daje gwarancji bezpieczeństwa strony końcowej.

Łączyć uwierzytelnienie z zachowaniem wiadomości

SPF, DKIM i DMARC pozostają potrzebne. Powinny jednak być jednym z sygnałów, razem z analizą nazwy wyświetlanej, kontekstu organizacyjnego, struktury linków, treści i historii nadawcy.

Oznaczać zewnętrzne wiadomości podszywające się pod własną organizację

Jeżeli e-mail z zewnątrz wyświetla nazwę własnej firmy lub osoby z kierownictwa, może wymagać dodatkowej kontroli albo wyraźnego oznaczenia dla odbiorcy.

Warstwowe podejście szerzej omawiamy w materiale co musi działać w firmie, aby ograniczać phishing.

Co powinien zrobić pracownik

Użytkownik nie ma analizować surowego HTML ani liczyć linków w wiadomości. Jego rola jest prostsza: zatrzymać się wtedy, gdy prośba nie pasuje do oczekiwanego kontekstu.

W opisanym przypadku szczególnie istotne byłyby trzy pytania:

1. Czy naprawdę oczekuję dokumentu dotyczącego ugody lub zatwierdzenia?
2. Czy osoba albo system, który miałby go wysłać, zwykle kontaktuje się ze mną w ten sposób?
3. Czy mogę potwierdzić dokument innym kanałem bez korzystania z linku z wiadomości?

Jeżeli odpowiedź jest niejasna, bezpieczniejszym krokiem jest wejście do znanego systemu z zapisanej zakładki albo kontakt z osobą odpowiedzialną za sprawę poprzez znany numer lub komunikator firmowy.

Poprawne techniczne uwierzytelnienie wiadomości nie zmienia tej zasady. Pracownik zwykle nawet nie widzi pełnych wyników SPF, DKIM i DMARC, a system pocztowy nie powinien przerzucać na niego decyzji, której sam nie potrafił rozstrzygnąć.

Jak przełożyć ten przypadek na testy phishingowe

Ten scenariusz dobrze nadaje się do ćwiczeń, ponieważ nie wymaga krzykliwej przynęty. Można sprawdzić, czy użytkownik reaguje na:

• nieoczekiwany dokument do zatwierdzenia;
• nazwę własnej organizacji w polu nadawcy;
• link wyglądający jak nazwa pliku;
• komunikat bez wyraźnego kontekstu wcześniejszej rozmowy;
• przejście do strony logowania po kliknięciu.

W symulacji nie trzeba kopiować techniki użytej przez napastnika jeden do jednego. Celem jest zmierzenie decyzji użytkownika: czy kliknie, czy poda dane, czy przerwie proces i czy zgłosi wiadomość.

Projektowanie testów phishingowych dla firm warto oprzeć na takich realnych wzorcach, ale mierzyć zachowanie, a nie samą liczbę kliknięć. W tym przypadku szczególnie cenna jest informacja, czy pracownik potrafi rozpoznać niezgodność kontekstu mimo poprawnie wyglądającej wiadomości.

Co z tego wynika

IRONSCALES opisał konkretny przykład phishingu, w którym napastnik połączył kilka zaufanych elementów: długo istniejącą domenę, poprawne uwierzytelnienie, legalny tracker i prawdziwą cudzą korespondencję wykorzystaną jako wypełnienie.

Żaden z tych elementów samodzielnie nie przesądzał o bezpieczeństwie. Dopiero zestawienie zachowania wiadomości — podszywanie się pod organizację odbiorcy, nietypowy adres, rozbieżny link, końcowa strona przechwytująca poświadczenia i niezwiązany blok treści — pozwalało zobaczyć cały łańcuch.

Dla zespołów bezpieczeństwa oznacza to potrzebę łączenia sygnałów zamiast nadawania jednemu wynikowi rangi ostatecznego werdyktu. Dla użytkownika punkt decyzyjny pozostaje bardziej praktyczny: nieoczekiwany dokument, logowanie albo zatwierdzenie powinny zostać potwierdzone niezależnym kanałem, nawet jeśli wiadomość wygląda technicznie poprawnie.