Ukryty tekst w phishingu. Gdy atakujący próbują oszukać człowieka i filtr AI

2026-05-07

TL;DR

Przestępcy zaczynają ukrywać dodatkowy tekst w wiadomościach phishingowych nie po to, żeby przekonać człowieka, ale żeby wpłynąć na systemy analizujące pocztę. Taki tekst może być niewidoczny dla odbiorcy, lecz nadal dostępny dla filtra, który przetwarza kod HTML wiadomości. Jeżeli ukryta warstwa zawiera neutralne, marketingowe albo pozornie bezpieczne fragmenty, może rozmywać sygnały typowe dla phishingu i utrudniać klasyfikację.

Nie oznacza to, że sztuczna inteligencja w ochronie poczty przestaje mieć sens. Oznacza coś ważniejszego: filtr AI też jest częścią powierzchni ataku. Organizacje powinny więc testować nie tylko pracowników, lecz także sposób, w jaki ich zabezpieczenia interpretują treść wiadomości.

Atak na filtr, nie tylko na użytkownika

Klasyczny phishing był projektowany głównie z myślą o człowieku. Wiadomość miała wzbudzić pośpiech, strach, ciekawość albo zaufanie. Użytkownik miał kliknąć w link, pobrać plik, zeskanować kod QR, podać dane logowania albo zatwierdzić działanie, którego w normalnych warunkach by nie wykonał.

W tym przypadku problem jest bardziej subtelny. Według analizy Sublime Security, opisanej również przez Hackread, atakujący ukrywają w wiadomościach dodatkową treść, która ma wpływać na systemy AI i machine learning używane w ochronie poczty. Człowiek widzi przynętę phishingową. Filtr może zobaczyć coś więcej: fragmenty newslettera, neutralną opowieść, treść marketingową albo słowa, które zmieniają kontekst całej wiadomości.

AI, czyli artificial intelligence, to po polsku sztuczna inteligencja. W tym przypadku nie chodzi jednak o magiczny system, który samodzielnie rozumie intencje nadawcy. Chodzi o narzędzia klasyfikujące wiadomości na podstawie wielu sygnałów: treści, linków, załączników, reputacji nadawcy, podobieństwa do znanych kampanii i wzorców językowych. Jeżeli atakujący potrafi wpłynąć na te sygnały, może próbować przesunąć ocenę wiadomości w stronę mniej podejrzanej.

To przesuwa problem z poziomu podejrzanego maila na poziom interpretacji. Pytanie nie brzmi już tylko, czy pracownik rozpozna phishing. Równie ważne jest to, czy system bezpieczeństwa rozumie, która treść jest realnie widoczna dla użytkownika, a która została ukryta po to, żeby zmanipulować klasyfikację.

Jak działa ukryty tekst w phishingu

Technicznie sam pomysł nie jest nowy. Ukrywanie treści w HTML, bardzo mały font, biały tekst na białym tle albo znaki niewidoczne dla człowieka pojawiały się w spamie i phishingu od lat. Zmienia się jednak kontekst. Dziś wiadomości nie są oceniane wyłącznie przez proste reguły szukające słów kluczowych. Coraz częściej analizują je modele i systemy uczące się wzorców.

HTML, czyli HyperText Markup Language, to język używany do budowania struktury stron internetowych i wiadomości e-mail. CSS, czyli Cascading Style Sheets, odpowiada między innymi za wygląd: kolor, rozmiar tekstu, odstępy, układ i widoczność elementów. Jeżeli wiadomość e-mail jest przygotowana w HTML, nadawca może kontrolować nie tylko treść, ale też sposób jej prezentacji.

W opisywanych kampaniach pojawiają się przede wszystkim dwie techniki.

Pierwsza to zero-font HTML. Atakujący ustawia rozmiar tekstu na zero albo na wartość praktycznie niewidoczną. Odbiorca nie widzi tej treści w normalnym widoku wiadomości, ale system analizujący kod HTML może ją nadal odczytać.

Druga to color-matching, czyli dopasowanie koloru tekstu do tła wiadomości. Tekst formalnie znajduje się w mailu, ale jest dla człowieka niewidoczny, bo zlewa się z tłem. Najprostszy przykład to biały tekst na białym tle, choć w praktyce wariantów może być więcej.

W efekcie wiadomość może mieć dwie warstwy. Jedną widzi użytkownik. Drugą widzi system, który analizuje surową treść. Jeżeli ta druga warstwa została zaprojektowana pod model klasyfikujący, może utrudnić ocenę, czy wiadomość jest złośliwa.

Zero-font to nie to samo co prompt injection

Warto rozróżnić kilka pojęć, bo inaczej łatwo uprościć temat. Zero-font i color-matching to techniki ukrywania tekstu. Służą do tego, żeby jakaś treść była obecna w wiadomości, ale nie była widoczna dla człowieka w normalnym widoku.

Prompt injection to szerszy problem. Prompt to instrukcja lub treść wejściowa, którą przetwarza model językowy. LLM, czyli large language model, to duży model językowy, taki jak systemy generujące lub analizujące tekst. Prompt injection polega na takim przygotowaniu treści, żeby wpłynąć na zachowanie modelu albo na jego decyzję.

W bezpośrednim prompt injection użytkownik wpisuje instrukcję wprost do modelu. W pośrednim wariancie, nazywanym indirect prompt injection, instrukcja lub manipulująca treść znajduje się w danych, które model przetwarza później: w stronie internetowej, dokumencie, zgłoszeniu serwisowym, komentarzu, pliku albo wiadomości e-mail.

W tym konkretnym przypadku nie chodzi o prostą instrukcję w stylu zignoruj poprzednie zasady. Sublime opisuje raczej subtelniejszy wariant: ukryta treść ma rozmyć sygnały phishingowe i wpłynąć na decyzję modelu klasyfikującego wiadomość. To nadal mieści się w szerszym problemie pośredniego prompt injection, ale warto odróżnić manipulowanie klasyfikacją od przejmowania zachowania agenta AI.

Adidas, fikcyjna historia i rozmywanie sygnałów

W analizie Sublime Security opisano dwa przykłady kampanii. Pierwszy dotyczył wiadomości przypominającej scam związany z usługą chmurową. W ukrytej warstwie maila znalazł się tekst pobrany z prawdziwych newsletterów Adidas dostępnych w serwisach archiwizujących kampanie marketingowe. Cel był czytelny: sprawić, żeby system analizujący wiadomość zobaczył więcej treści kojarzącej się z rozpoznawalną marką, neutralnym marketingiem i normalną komunikacją.

Drugi przykład dotyczył fałszywej wiadomości o ubezpieczeniu zdrowotnym. W warstwie ukrytej umieszczono fikcyjną historię z serwisu z powieściami internetowymi. Taka treść mogła rozmywać sygnały typowe dla phishingu i kierować ocenę w stronę neutralnego, kreatywnego albo mało podejrzanego komunikatu.

To nie jest spektakularny exploit w stylu zdalnego wykonania kodu. To raczej próba manipulowania procesem decyzyjnym. Atakujący nie musi złamać filtra. Czasem wystarczy, że spróbuje przekonać go, że patrzy na coś innego niż rzeczywista przynęta phishingowa.

Właśnie dlatego ten przykład jest ciekawy dla firm. Pokazuje, że wiadomość phishingowa może być pisana równocześnie dla człowieka i dla systemu, który ma ją ocenić.

Czy użytkownik może zobaczyć ukryty tekst w mailu

Najczęściej nie. Na tym polega problem. Ukryty tekst może mieć zerowy rozmiar, kolor taki sam jak tło albo znajdować się w części HTML, której użytkownik nie widzi w normalnym widoku wiadomości. Pracownik nie powinien więc próbować samodzielnie analizować kodu maila ani szukać niewidocznych fragmentów.

Jego rola jest inna. Ma rozpoznać nietypowy kontekst, podejrzany link, nieoczekiwaną prośbę, presję czasu albo wiadomość, która nie pasuje do normalnego procesu. Jeśli mail dotyczy faktury, logowania, dopłaty, konta, dokumentu, paczki albo pilnego działania, ale coś w nim nie pasuje, powinien zostać zgłoszony do weryfikacji.

Dlatego w firmie nadal liczy się zgłaszanie podejrzanych wiadomości. Użytkownik nie musi wiedzieć, czy w mailu jest zero-font, prompt injection albo ukryty HTML. Wystarczy, że potrafi zatrzymać proces i przekazać wiadomość do zespołu bezpieczeństwa.

Dlaczego to ważne dla firm

W wielu organizacjach zabezpieczenia poczty są traktowane jak czarna skrzynka. Kupujemy usługę, włączamy polityki, ustawiamy kwarantannę i zakładamy, że system poradzi sobie z większością zagrożeń. Przez lata takie podejście było zrozumiałe, ale coraz mniej pasuje do obecnego krajobrazu.

Nowoczesny phishing nie zawsze ma jeden oczywisty wskaźnik kompromitacji. Może używać legalnych platform, dobrych domen, poprawnej składni, wiarygodnych brandów, kodów QR, załączników HTML, przekierowań, fałszywych CAPTCHA i treści ukrytej przed człowiekiem, ale dostępnej dla systemu analizującego wiadomość.

Na PHISHLY pisaliśmy już o tym szerzej przy okazji tekstu o kwietniu 2026 w phishingu. E-mail coraz częściej jest tylko początkiem procesu. Dalej pojawia się logowanie, sesja, SSO, MFA, komunikator, kod QR albo platforma SaaS.

SSO, czyli single sign-on, oznacza logowanie jednokrotne do wielu usług firmowych. MFA, czyli multi-factor authentication, to uwierzytelnianie wieloskładnikowe. SaaS, czyli software as a service, oznacza oprogramowanie dostępne jako usługa w chmurze. Wszystkie te elementy ułatwiają pracę, ale w atakach phishingowych stają się częścią większego procesu podszywania się pod zaufane narzędzia.

Ukryty tekst dokłada do tego kolejny poziom. Atak zaczyna się jeszcze wcześniej: na etapie oceny, czy wiadomość w ogóle powinna dotrzeć do użytkownika.

Co powinien sprawdzać zespół IT i Security

Pierwszy obszar to sposób, w jaki bramka pocztowa renderuje i normalizuje HTML. Sama analiza surowego kodu wiadomości może nie wystarczyć. System powinien rozróżniać treść widoczną dla użytkownika od treści ukrytej technikami CSS, nietypowym rozmiarem fontu, kolorem tła albo znakami specjalnymi. Jeżeli filtr traktuje całą treść tak samo, może dać się zmylić materiałem, którego odbiorca nigdy nie zobaczy.

Drugi obszar to detekcja niewidocznego tekstu. Ukryta treść nie musi automatycznie oznaczać phishingu. Są newslettery i systemy mailingowe, które generują dziwny HTML bez złych intencji. Mimo to duża ilość niewidocznego tekstu, nietypowe style, duplikaty treści i rozbieżność między warstwą widoczną a ukrytą powinny podnosić ryzyko wiadomości.

Trzeci obszar to ograniczone zaufanie do AI. Model może bardzo pomagać w klasyfikacji, ale nie powinien być jedynym źródłem prawdy. Wynik modelu warto łączyć z reputacją nadawcy, analizą domeny, linkami, historią komunikacji, zachowaniem po kliknięciu, sandboxingiem, regułami detekcji i sygnałami od użytkowników. Sandboxing oznacza uruchamianie podejrzanych plików lub linków w odizolowanym środowisku, aby sprawdzić ich zachowanie bez narażania prawdziwej infrastruktury.

Czwarty obszar to proces zgłaszania. Jeżeli pracownik widzi podejrzaną wiadomość, powinien mieć prosty sposób przekazania jej do analizy. Dobre zgłoszenie użytkownika nadal bywa jednym z najważniejszych sygnałów bezpieczeństwa. Szczególnie wtedy, gdy wiadomość ominęła część automatycznych filtrów albo wygląda nietypowo dopiero po zestawieniu z kontekstem biznesowym.

Awareness musi objąć fałszywe poczucie bezpieczeństwa

Ten temat ma ważny wymiar szkoleniowy. Wiele osób zakłada, że skoro wiadomość przeszła przez firmowe filtry, to jest bezpieczna. To przekonanie nigdy nie było w pełni prawdziwe, ale przy coraz bardziej złożonych kampaniach staje się szczególnie ryzykowne.

W programach security awareness warto więc uczyć nie tylko rozpoznawania przynęt, ale też zasady ograniczonego zaufania do skrzynki. Wiadomość w inboxie nie jest automatycznie wiarygodna. Podsumowanie przygotowane przez AI nie jest automatycznie prawdziwe. Zielona ikona, logo znanej marki i poprawny język nie kończą analizy.

Ten sam problem widać w innych scenariuszach, na przykład przy phishingu opartym o legalne usługi SaaS, fałszywe płatności za popularne narzędzia AI albo nadużycie znanych marek. Dobrym uzupełnieniem jest tekst o fałszywej płatności za ChatGPT, bo pokazuje podobny mechanizm zaufania: użytkownik widzi znaną usługę i łatwiej przechodzi do działania.

Dlatego testy phishingowe dla firm powinny mierzyć nie tylko kliknięcia. Ważne jest też zgłoszenie wiadomości, przerwanie procesu, reakcja po błędzie, wpisanie danych, podanie kodu MFA i zachowanie użytkownika wtedy, gdy wiadomość przeszła przez zabezpieczenia techniczne.

Co to oznacza dla skrzynek z AI

Dziś mówimy głównie o filtrach. Coraz więcej firm będzie jednak używać asystentów, którzy streszczają pocztę, sugerują odpowiedzi, wyciągają zadania, dopisują wydarzenia do kalendarza albo przekazują sprawy dalej. To wygodne, ale tworzy nową powierzchnię ataku.

Jeżeli asystent AI przetwarza wiadomość, której treści użytkownik nie widzi w całości, trzeba założyć, że ktoś będzie próbował wpłynąć na jego działanie. W prostym wariancie chodzi o błędną klasyfikację. W bardziej zaawansowanym o fałszywe podsumowanie, sugestię kliknięcia, zmianę priorytetu, ukrycie ostrzeżenia albo przekazanie sprawy niewłaściwym kanałem.

To nie jest powód, żeby rezygnować z AI w bezpieczeństwie poczty. To powód, żeby projektować ją ostrożniej: z separacją danych od instrukcji, ograniczonymi uprawnieniami, rejestrowaniem decyzji, testami odporności i możliwością ręcznej weryfikacji.

W praktyce oznacza to, że system AI nie powinien automatycznie wykonywać działań na podstawie samej treści wiadomości bez kontroli. Im większe uprawnienia ma asystent, tym większe znaczenie mają ograniczenia, audyt, logi i jasne zasady, co wolno mu zrobić samodzielnie, a co wymaga potwierdzenia człowieka.

Jak testować odporność na takie techniki

Firmy powinny patrzeć na ten problem w dwóch warstwach. Pierwsza to warstwa techniczna, czyli bramki pocztowe, filtry, reguły detekcji, sandboxing i narzędzia ochrony przed phishingiem. Druga to warstwa ludzka, czyli zachowanie pracownika po otrzymaniu wiadomości.

W testach technicznych warto sprawdzać, czy system wykrywa nietypowe style HTML, niewidoczny tekst, rozbieżność między tekstem widocznym a ukrytym, podejrzane linki, przekierowania i niezgodność brandu z domeną. Nie chodzi o to, żeby każda wiadomość z dziwnym HTML trafiała do kosza. Chodzi o to, żeby takie cechy podnosiły ryzyko i były widoczne w analizie.

W testach awareness warto natomiast budować scenariusze, które uczą zatrzymania procesu. Pracownik nie musi rozumieć wszystkich technik ukrywania tekstu. Powinien jednak umieć rozpoznać, że wiadomość prowadzi do nietypowego działania, wymaga logowania z linku, prosi o pilną decyzję albo nie pasuje do zwykłego procesu w firmie.

Dobre ćwiczenie phishingowe nie polega na złapaniu użytkownika na błędzie. Polega na sprawdzeniu, czy organizacja potrafi zobaczyć cały proces: dostarczenie wiadomości, ocenę przez filtr, reakcję użytkownika, zgłoszenie, analizę i poprawę zabezpieczeń.

Wniosek

Ukryty tekst w phishingu nie jest najbardziej widowiskową techniką ataku, ale dobrze pokazuje kierunek zmian. Przestępcy nie walczą już tylko o uwagę człowieka. Coraz częściej walczą o to, jak systemy bezpieczeństwa interpretują wiadomość, zanim człowiek ją zobaczy.

Dlatego obrona przed phishingiem w 2026 roku nie może opierać się na jednym filtrze, jednym modelu i jednym szkoleniu rocznie. Potrzebna jest warstwowa ochrona poczty, rozumienie kontekstu, kontrola tego, co widzi użytkownik, analiza tego, co widzi system, oraz regularne ćwiczenie reakcji na wiadomości, które wyglądają wiarygodnie mimo ukrytej manipulacji.

Najważniejsza lekcja jest prosta: wiadomość phishingowa może być dziś pisana równocześnie dla człowieka i dla systemu, który ma ją ocenić. Jeśli organizacja chce realnie mierzyć odporność, musi testować oba te poziomy. Nie tylko to, czy pracownik kliknie, ale także to, czy potrafi zatrzymać proces, zgłosić podejrzaną wiadomość i nie przenosić zaufania z narzędzia automatycznie na treść.