ASCII smuggling w phishingu: niewidzialny Unicode

Skala była duża. W telemetrii Microsoft Defender for Office 365 liczba trafień sygnatury wzrosła z około 21 tysięcy 8 lutego do ponad 1,3 miliona 9 lutego 2026 roku. W fazie wysokiego wolumenu kampania osiągała ponad 2,3 miliona trafień dziennie, działała głównie w dni robocze i utrzymywała wysoki poziom przez około trzy miesiące.

Nie oznacza to jednak, że jedna niewidzialna sekwencja znaków wyłączyła nowoczesne zabezpieczenia poczty. Microsoft podaje, że ponad 99 procent badanych wiadomości zostało rozpoznanych przez inne warstwy ochrony. Przypadek pokazuje raczej, dlaczego obrona nie powinna zależeć od pojedynczej reguły, pojedynczego modelu ani samego faktu, że wiadomość dotarła do skrzynki.

Co zmienił przypadek opisany przez Microsoft

Ukrywanie treści przed człowiekiem lub filtrem nie jest nowym pomysłem. Spam i phishing od lat wykorzystują zerową szerokość znaków, miękkie łączniki, podobne wizualnie litery, bardzo mały tekst albo elementy HTML niewidoczne w normalnym widoku.

Nowy materiał Microsoftu jest istotny z trzech powodów. Po pierwsze, napastnicy sięgnęli po blok Unicode Tags, który wcześniej stał się szerzej znany dzięki badaniom nad bezpieczeństwem AI i ASCII smuggling. Po drugie, zastosowali go na dużą skalę w klasycznej kampanii phishingowej i spamowej. Po trzecie, ta sama własność znaków może być problemem zarówno dla filtrów poczty, jak i dla systemów AI przetwarzających surową treść.

To dobrze uzupełnia wcześniejsze przykłady opisane w tym artykule. W zero-font albo color-matching dodatkowa treść jest obecna w HTML, ale użytkownik jej nie widzi. W ASCII smuggling problem może występować jeszcze niżej: w samej reprezentacji tekstu.

Czym jest ASCII smuggling

Nazwa ASCII smuggling odnosi się do używania znaków Unicode, które mogą przenosić informację bez typowego wyświetlenia jej na ekranie. W przypadku opisanym przez Microsoft kluczowy był blok Unicode Tags U+E0000–U+E007F.

Znaki z tego zakresu mogą odpowiadać znakom znanym z ASCII, ale wiele interfejsów i fontów ich nie pokazuje. Oznacza to, że człowiek czyta jedno, a oprogramowanie pracujące na surowym tekście może otrzymać dodatkowe znaki.

W badaniach nad bezpieczeństwem AI wykorzystywano tę właściwość do ukrywania instrukcji przed człowiekiem przy jednoczesnym przekazaniu ich modelowi. W kampanii Microsoftu cel był inny. Napastnicy nie próbowali skłonić asystenta AI do wykonania polecenia. Wstawiali niewidzialne znaki do słów takich jak funding, aby utrudnić systemom dopasowanie całego wyrazu jako jednej sekwencji.

Dla odbiorcy słowo nadal wyglądało jak zwykły element wiadomości finansowej. Dla prostego mechanizmu analizującego znaki mogło już nie być tym samym słowem.

Co Microsoft zobaczył w telemetrii

Sygnatura przygotowana pierwotnie do wyszukiwania treści związanych z prompt injection zaczęła wykrywać coś innego. 8 lutego 2026 roku zanotowała około 21 tysięcy trafień. Dzień później liczba przekroczyła 1,3 miliona.

Microsoft opisuje następnie wielotygodniowy rytm kampanii. W dni robocze wolumen wynosił około 1–2,37 miliona wiadomości, a w weekendy gwałtownie spadał. Wysoki poziom użycia konkretnej techniki utrzymywał się przez około trzy miesiące i wyraźnie zmniejszył się po 15 maja. Niższa aktywność pozostawała widoczna jeszcze w czerwcu.

Większość wiadomości można było połączyć z grupą około 150 domen nadawców o tematyce finansowej. Przynęty dotyczyły pożyczek, linii kredytowych i finansowania przedsiębiorstw.

Microsoft połączył ten etap z szerszą kampanią SBA opisaną wcześniej przez Fortra. Fortra już w 2025 roku wskazywała na nadużywanie legalnej platformy ActiveCampaign do wysyłania spersonalizowanych wiadomości i prowadzenia odbiorców do stron zbierających dane biznesowe oraz finansowe.

Ważna jest granica faktów: szersza kampania istniała wcześniej, a Unicode Tags były jedną z późniejszych technik używanych w określonym okresie. Nie należy przedstawiać ASCII smuggling jako początku całej operacji.

Jak niewidzialny znak zmienia analizę wiadomości

Wyobraźmy sobie filtr, który szuka określonych słów albo buduje z tekstu tokeny do dalszej klasyfikacji. Jeżeli w środku słowa pojawi się znak, który nie jest widoczny dla użytkownika, system może podzielić tekst inaczej niż człowiek.

To nie musi automatycznie oznaczać skutecznego obejścia ochrony. Współczesne systemy pocztowe korzystają równocześnie z reputacji nadawcy, domeny, adresu IP, analizy linków, zachowania strony docelowej, uwierzytelniania poczty, modeli klasyfikacyjnych i innych sygnałów.

Właśnie dlatego opis Microsoftu jest dobrym przykładem znaczenia obrony warstwowej. Jeżeli jedna cecha treści zostanie zniekształcona, pozostałe sygnały nadal mogą zatrzymać wiadomość. W materiale Microsoftu ponad 99 procent analizowanego wolumenu zostało oznaczone przez mechanizmy, które nie zależały od bezpośredniego wykrycia Unicode Tags.

Podobny problem opisujemy w artykule o tym, dlaczego phishing może przejść przez DMARC i inne sygnały zaufania. Jeden poprawny sygnał nie powinien automatycznie przesądzać o bezpieczeństwie całej wiadomości.

ASCII smuggling, zero-font i color-matching to różne techniki

Warto rozdzielić trzy mechanizmy, które mogą prowadzić do podobnego efektu.

Zero-font ukrywa dodatkowy tekst przez ustawienie rozmiaru bardzo bliskiego zeru albo równego zeru. Treść może nadal istnieć w kodzie HTML, mimo że odbiorca jej nie widzi.

Color-matching polega na dobraniu koloru tekstu do tła. Człowiek widzi pustą przestrzeń, ale system analizujący HTML nadal może odczytać znajdujący się tam tekst.

ASCII smuggling z Unicode Tags nie wymaga ukrywania dużego bloku HTML. Niewidzialne znaki mogą zostać wstawione bezpośrednio do normalnie wyglądającego słowa i zmienić jego reprezentację dla systemu analizującego treść.

Te techniki nie są też automatycznie tym samym co prompt injection. Prompt injection dotyczy wpływania na zachowanie modelu przez dane, które model przetwarza. ASCII smuggling może służyć do ukrycia takiej instrukcji, ale w kampanii opisanej przez Microsoft zastosowano go jako metodę utrudniania klasycznej analizy phishingu i spamu.

Ukryty tekst może celować także w systemy AI

Wcześniejsze analizy Sublime Security pokazywały inny wariant problemu. Napastnicy umieszczali w wiadomościach niewidoczną treść przez zero-font lub color-matching, aby zmienić kontekst widziany przez systemy wykorzystujące AI i machine learning do klasyfikacji poczty.

To tworzy dwie możliwe asymetrie. W pierwszej człowiek widzi przynętę phishingową, a filtr widzi dodatkową neutralną treść. W drugiej człowiek widzi zwykłe słowo, a system analizujący surowe znaki dostaje sekwencję rozbitą przez niewidzialny Unicode.

Systemy korzystające z modeli językowych mają jeszcze jeden problem: treść, której użytkownik nie widzi, może zostać przetworzona jako część wejścia modelu. Dlatego normalizacja tekstu przed analizą ma znaczenie zarówno dla klasycznych filtrów, jak i dla aplikacji AI, które podsumowują pocztę lub podejmują na jej podstawie dalsze działania.

Czy pracownik może rozpoznać taki atak

Najczęściej nie rozpozna samego mechanizmu. Niewidzialny znak spełnia swoją rolę właśnie dlatego, że użytkownik go nie widzi.

Nie oznacza to, że pracownik jest bezradny. Jego zadaniem nie jest analiza kodu Unicode, lecz ocena sytuacji. Czy wiadomość była oczekiwana? Czy prośba pasuje do procesu biznesowego? Czy link prowadzi tam, gdzie powinien? Czy nadawca żąda logowania, płatności, przekazania danych albo szybkiej decyzji bez normalnego potwierdzenia?

Jeżeli odpowiedź budzi wątpliwości, właściwym działaniem jest przerwanie procesu i weryfikacja innym kanałem. Ten sam mechanizm omawiamy szerzej w poradniku co to jest phishing i jak działa w firmie.

W programie security awareness warto też usuwać fałszywe założenie, że wiadomość obecna w skrzynce została już w pełni zweryfikowana. Filtry redukują ryzyko, ale nie przenoszą odpowiedzialności za każdą decyzję biznesową na automat.

Co powinien sprawdzić zespół bezpieczeństwa

Pierwszy krok to normalizacja tekstu przed stosowaniem reguł, dopasowań i klasyfikacji. Microsoft zaleca usuwać lub ujednolicać niewidzialne znaki, w tym Unicode Tags U+E0000–U+E007F, zanim treść trafi do mechanizmów opartych na słowach, sygnaturach lub wyrażeniach regularnych.

Drugi krok to traktowanie rzadkich znaków jako sygnału, a nie samodzielnego wyroku. Niektóre prawidłowe sekwencje również korzystają z Unicode Tags. Microsoft zwraca uwagę między innymi na flagi Anglii, Szkocji i Walii. Prosta reguła blokująca każdy znak z tego zakresu może więc generować błędne alarmy.

Trzeci krok to łączenie treści z kontekstem. W opisywanej kampanii istotne były także rotujące domeny finansowe, charakterystyczny rytm wysyłki, wzorzec infrastruktury nadawczej i linki śledzące. Żaden z tych elementów nie powinien być oceniany w oderwaniu od pozostałych.

Dotyczy to szczególnie legalnych usług. Microsoft i Fortra wskazują na nadużycie ActiveCampaign, ale nie oznacza to, że domeny czy infrastruktura tej platformy są z definicji złośliwe. Współdzielona, legalna usługa nie jest sama w sobie wskaźnikiem kompromitacji.

Szerszy model ochrony opisujemy w materiale warstwa obrony przed phishingiem: co musi działać w firmie. Normalizacja treści jest jednym elementem, obok reputacji, analizy linków, uwierzytelniania, detekcji zachowania i szybkiego zgłaszania wiadomości przez użytkowników.

Co to zmienia w security awareness

Pracownik nie powinien być szkolony z rozpoznawania kodów U+E0000 albo ręcznego oglądania źródła wiadomości. Taki trening miałby małą wartość operacyjną.

Znacznie ważniejsze jest ćwiczenie reakcji na wiadomość, która wygląda wystarczająco dobrze, żeby przejść część automatycznych kontroli. Użytkownik powinien umieć zatrzymać się przy nieoczekiwanym żądaniu, sprawdzić proces niezależnym kanałem i zgłosić wiadomość bez potrzeby rozstrzygania, jaka technika techniczna została użyta.

Dla zespołu odpowiedzialnego za security awareness ten przypadek daje też dobry scenariusz do mierzenia współpracy człowieka i technologii. Można osobno oceniać skuteczność filtrów i zachowanie pracownika, a potem zestawić oba wyniki. Celem nie jest pokazanie, że filtr zawiódł albo użytkownik się pomylił, lecz znalezienie miejsca, w którym cały proces obronny daje zbyt mało marginesu na błąd.

Jak testować odporność na niewidzialny tekst

Test techniczny powinien sprawdzać, czy bramka pocztowa i kolejne systemy normalizują niewidzialne znaki przed analizą oraz czy potrafią zestawić treść z reputacją, linkami, domeną nadawcy i innymi sygnałami.

W przypadku rozwiązań AI warto dodatkowo sprawdzić, czy treść z wiadomości jest traktowana jako dane, a nie jako zaufane instrukcje. Jeżeli asystent może tworzyć zadania, odpowiadać, przekazywać wiadomości albo uruchamiać inne działania, jego uprawnienia powinny być ograniczone, a decyzje możliwe do prześledzenia.

Test awareness powinien natomiast mierzyć zachowanie po dostarczeniu wiadomości. Czy pracownik kliknie? Czy rozpocznie logowanie? Czy poda dane? Czy zgłosi wiadomość? Czy po błędzie potrafi szybko przerwać proces i uruchomić właściwą ścieżkę reakcji?

Takie podejście lepiej odzwierciedla realne ryzyko niż liczenie wyłącznie kliknięć. Technika po stronie wiadomości może się zmieniać, ale punkt decyzyjny użytkownika pozostaje podobny.

Wniosek

ASCII smuggling pokazuje, że granica między bezpieczeństwem AI a klasycznym phishingiem jest coraz mniej wyraźna. Technika znana z badań nad ukrywaniem instrukcji dla modeli została wykorzystana do innego celu: rozdzielania słów przed analizą filtrów poczty.

Dla firmy nie wynika z tego potrzeba kolejnego pojedynczego bloku reguł. Potrzebne są normalizacja treści, kilka niezależnych warstw detekcji, ostrożne traktowanie legalnej infrastruktury współdzielonej oraz użytkownik, który potrafi przerwać nietypowy proces i zgłosić wiadomość.

Jeżeli organizacja chce mierzyć odporność na współczesny phishing, powinna oceniać jednocześnie to, co widzi system bezpieczeństwa, i to, co robi człowiek po dostarczeniu wiadomości.