Fałszywy PDF z banku. Lekcja z Ousaban

TL;DR

Fałszywy PDF z banku albo dokumentem podatkowym nie musi od razu wyłudzać hasła. Może być pierwszym krokiem do pobrania malware, które czeka na sesję bankową i wtedy przejmuje znacznie więcej niż sam login.

FortiGuard Labs opisał kampanię Ousaban wymierzoną w użytkowników Windows w Hiszpanii i Portugalii. Przynętą był PDF udający uszkodzony dokument. Po kliknięciu przycisku aktualizacji użytkownik trafiał na stronę, która sprawdzała środowisko i dopiero wybranym osobom podawała kolejny etap ataku.

Dla firm w Polsce to dobry scenariusz do omówienia w programie awareness: nie tylko „czy klikniesz link”, ale też „czy zatrzymasz się, gdy dokument każe go naprawić”, „czy zgłosisz nietypowy załącznik” i „czy organizacja potrafi szybko zareagować po uruchomieniu podejrzanego pliku”.

Dlaczego fałszywy PDF jest tak skuteczną przynętą

PDF ma w pracy szczególny status. Ludzie traktują go jak dokument, a nie jak aktywny element ataku. Faktura, potwierdzenie przelewu, wezwanie, rozliczenie, dokument podatkowy, skan umowy albo załącznik od kontrahenta zwykle nie budzą takiego oporu jak plik wykonywalny.

Właśnie dlatego PDF dobrze nadaje się do scenariusza phishingowego. Użytkownik nie musi wierzyć w egzotyczną historię. Wystarczy, że zobaczy komunikat o uszkodzonym pliku, brakującym podglądzie albo konieczności aktualizacji dokumentu. Jeśli sprawa wygląda jak część codziennej pracy, odruch „naprawię i zobaczę treść” może wygrać z procedurą.

To nie jest osobny świat od klasycznego phishingu. Nadal chodzi o podszycie, zaufanie i nakłonienie odbiorcy do działania. Zmienia się tylko ciężar ataku. Zamiast od razu prosić o login i hasło, przestępca prowadzi użytkownika przez dokument, stronę, pobranie i uruchomienie kolejnego elementu.

Podobny mechanizm PHISHLY opisywało już przy fałszywych dokumentach biznesowych z malware. W przypadku Ousaban dochodzi jednak mocny kontekst bankowy: malware nie jest tylko ogólnym „złośliwym załącznikiem”, ale narzędziem przygotowanym do obserwowania i przejmowania aktywnej sesji finansowej.

Jak działała kampania Ousaban

Według analizy FortiGuard Labs kampania z maja 2026 zaczynała się od PDF-a udającego uszkodzony dokument. W środku pojawiał się komunikat z przyciskiem „Atualizar”, czyli „Aktualizuj”. Taki komunikat jest psychologicznie wygodny dla atakującego: nie prosi od razu o hasło, lecz sugeruje zwykłe rozwiązanie problemu technicznego.

Po kliknięciu użytkownik trafiał na stronę, która udawała miejsce z dokumentami podatkowymi albo instalatorami. W starszym wariancie sprawdzanie środowiska odbywało się po stronie przeglądarki. Analizowano między innymi adres IP, język, strefę czasu, użycie VPN i cechy przeglądarki. Nowszy wariant przenosił część tej logiki na serwer, więc analityk albo automatyczny sandbox mógł dostać tylko komunikat o braku dostępu.

Jeśli środowisko pasowało do celu kampanii, strona pobierała plik VBS. Dalej następował etap ukrycia payloadu w obrazie wyglądającym jak ikona PDF. Z obrazu wydobywany był ZIP, a z niego kolejny element prowadzący do uruchomienia Ousaban na komputerze z Windows.

Po uruchomieniu malware czekało na wejście użytkownika na wybrane serwisy bankowe. Wtedy mogło przechwytywać obraz, rejestrować wpisywane znaki, manipulować schowkiem, pokazywać fałszywe komunikaty i umożliwiać zdalne sterowanie. To scenariusz groźniejszy niż pojedyncza fałszywa strona logowania, bo atakujący może działać w trakcie realnej sesji użytkownika.

Co jest tu ważniejsze niż sama nazwa Ousaban

Nazwa rodziny malware jest istotna dla analityków, ale w edukacji pracowników nie powinna przesłonić mechanizmu. Pracownik zwykle nie zobaczy napisu „Ousaban”. Zobaczy dokument, błąd, przycisk, stronę i pobrany plik.

W tym scenariuszu warto skupić się na czterech sygnałach.

Pierwszy to dokument, którego odbiorca nie oczekiwał albo którego nie potrafi powiązać z konkretną sprawą. Nie chodzi o to, czy PDF wygląda profesjonalnie. Liczy się to, czy wiadomość pasuje do realnego procesu.

Drugi to komunikat naprawy lub aktualizacji wewnątrz dokumentu. Dokument nie powinien wymagać kliknięcia zewnętrznego przycisku, aby „odblokować” treść, pobrać dodatkowy składnik albo przenieść użytkownika na stronę instalatora.

Trzeci to selekcja ofiary. Jeżeli strona pokazuje błąd części użytkowników, a innym podaje plik, nie musi to oznaczać awarii. To może być celowe filtrowanie ruchu, aby ukryć malware przed narzędziami bezpieczeństwa.

Czwarty to przejście z dokumentu do urządzenia. Jeśli PDF prowadzi do pobrania skryptu, instalatora, archiwum albo „pomocnika”, użytkownik nie jest już w zwykłym obiegu dokumentów. W tym momencie sprawa powinna trafić do IT lub Security.

Dlaczego zabezpieczenia techniczne mogą tego nie zobaczyć od razu

Wiele organizacji polega na bramkach pocztowych, sandboxach i skanowaniu załączników. To potrzebna warstwa, ale nie rozwiązuje całego problemu. Kampania Ousaban pokazuje, że atakujący mogą selekcjonować ofiary i podawać złośliwy etap tylko wybranym środowiskom.

Jeśli automatyczny system otworzy link z innego kraju, z nietypową konfiguracją przeglądarki albo przez infrastrukturę przypominającą analizę, może dostać niewinny komunikat. Pracownik w docelowym kraju, na prawdziwym komputerze i z typowym językiem systemu może zobaczyć coś innego.

To ma praktyczną konsekwencję dla firm. Sam fakt, że wiadomość „przeszła przez pocztę”, nie może być dowodem bezpieczeństwa. Dlatego w programie security awareness trzeba uczyć nie tylko rozpoznawania złych nadawców, ale też zatrzymania procesu wtedy, gdy dokument zaczyna zachowywać się jak instrukcja instalacji.

Polski kontekst: bank, księgowość i dokumenty do rozliczenia

Z dostępnych źródeł nie wynika, że opisana kampania Ousaban była skierowana do polskich banków. To ważne rozróżnienie. Nie ma potrzeby sugerować, że ten konkretny wariant ataku działał w Polsce.

Mechanizm jest jednak łatwy do przeniesienia. W polskiej firmie podobna przynęta mogłaby udawać potwierdzenie przelewu, dokument z banku, rozliczenie podatkowe, notę księgową, wezwanie do uzupełnienia danych, potwierdzenie transakcji albo plik od kontrahenta. W organizacjach finansowych i księgowych taki dokument trafia dokładnie w codzienny rytm pracy.

Dla zespołów z sektora finansowego ważny jest jeszcze jeden element: skutkiem nie musi być tylko przechwycenie danych logowania. Jeśli malware działa na komputerze użytkownika, może obserwować prawdziwą sesję bankową, wpływać na to, co widzi użytkownik, i wspierać atakującego w dalszej manipulacji. Dlatego scenariusze z dokumentami bankowymi powinny być omawiane także na poziomie procesów operacyjnych, nie tylko jako problem skrzynki pocztowej.

W treściach i ćwiczeniach dla firm finansowych warto rozdzielić dwa typy reakcji. Inaczej reaguje użytkownik, który tylko dostał podejrzany PDF. Inaczej osoba, która kliknęła przycisk, pobrała plik albo zalogowała się do bankowości po takim zdarzeniu.

Co powinien zrobić użytkownik

Jeśli dostajesz PDF, który udaje dokument bankowy, podatkowy albo rozliczeniowy, sprawdź najpierw kontekst, a nie wygląd. Czy spodziewasz się takiego dokumentu? Czy nadawca jest zgodny z wcześniejszą korespondencją? Czy sprawa ma numer, zamówienie, fakturę albo osobę odpowiedzialną po Twojej stronie?

Nie klikaj przycisku naprawy, aktualizacji ani pobierania dodatkowego składnika z poziomu dokumentu. Jeżeli PDF twierdzi, że jest uszkodzony, bezpieczniejszą reakcją jest zgłoszenie wiadomości, a nie samodzielne rozwiązywanie problemu.

Nie przekazuj dokumentu dalej do współpracowników z komentarzem „sprawdź, czy Tobie się otwiera”. W ten sposób atak może rozprzestrzenić się w organizacji. Podejrzany załącznik powinien trafić do wyznaczonego kanału zgłoszeń, zespołu IT, SOC albo osoby odpowiedzialnej za bezpieczeństwo.

Jeżeli wiadomość dotyczy płatności, banku albo rozliczeń, potwierdź sprawę niezależnym kanałem. Nie odpowiadaj w tym samym wątku, jeśli podejrzewasz podszycie. Skorzystaj z numeru lub kontaktu znanego wcześniej, a nie z danych podanych w podejrzanej wiadomości.

Co powinny zrobić IT, Security i SOC

Z perspektywy zespołów technicznych ten scenariusz nie kończy się na blokowaniu jednego załącznika. Trzeba patrzeć na cały łańcuch: wiadomość, PDF, link w dokumencie, stronę filtrującą, pobrany plik, proces na stacji roboczej, logowanie do banku i ewentualne anomalie w ruchu sieciowym.

Warto sprawdzać, czy organizacja ma widoczność na nietypowe uruchomienia skryptów, pobrania z nieoczekiwanych domen, tworzenie nowych elementów autostartu, połączenia z dynamicznie zmienianymi adresami oraz aktywność związaną z przechwytywaniem schowka lub sesji użytkownika. Nie każda firma potrzebuje tego samego zestawu narzędzi, ale każda powinna wiedzieć, gdzie szukać śladów po podejrzanym załączniku.

Drugi obszar to proces zgłaszania. Jeśli użytkownik kliknął, ale szybko zgłosił zdarzenie, organizacja ma szansę odizolować komputer, zabezpieczyć wiadomość, zweryfikować logowania i skontaktować się z bankiem, zanim straty się rozwiną. Jeżeli użytkownik boi się zgłaszać pomyłkę, atakujący dostaje czas.

Trzeci obszar to testowanie. W kontrolowanych testach phishingowych dla firm taki scenariusz można ćwiczyć bez prawdziwego malware. Celem nie jest karanie za kliknięcie, tylko pomiar momentu zatrzymania: czy odbiorca rozpozna nietypowy dokument, czy przerwie kliknięcie przy komunikacie naprawy, czy użyje kanału zgłoszeń i czy organizacja odpowie zgodnie z procedurą.

Co zrobić, jeśli to już się stało

Jeżeli użytkownik tylko otworzył wiadomość, ale nie otworzył załącznika i niczego nie pobrał, powinien zgłosić mail zgodnie z firmową procedurą. Wiadomości nie należy kasować przed analizą, jeśli zespół bezpieczeństwa prosi o zachowanie oryginału.

Jeżeli PDF został otwarty i użytkownik kliknął przycisk prowadzący do strony, trzeba zgłosić link, czas zdarzenia i informacje o tym, czy coś zostało pobrane. To pomaga odróżnić samo wejście na stronę od uruchomienia kolejnego etapu.

Jeżeli pobrano albo uruchomiono plik, urządzenie powinno zostać potraktowane jako potencjalnie naruszone. Użytkownik powinien przerwać pracę, nie restartować komputera na własną rękę, nie usuwać plików i skontaktować się z IT lub Security. Dalsze kroki zależą od firmowej procedury, ale zwykle obejmują izolację urządzenia, analizę artefaktów, zmianę haseł, unieważnienie sesji oraz sprawdzenie logowań.

Jeżeli po zdarzeniu użytkownik logował się do bankowości, systemu płatności, panelu księgowego albo firmowej aplikacji finansowej, trzeba potraktować to jako wyższy poziom ryzyka. W takim przypadku liczy się szybki kontakt z bankiem lub właścicielem procesu finansowego, weryfikacja operacji i sprawdzenie, czy nie doszło do nietypowych przelewów, zmian odbiorców albo dodania nowych urządzeń zaufanych.

W polskich realiach podejrzane domeny i incydenty można zgłaszać również do właściwego CSIRT, w tym przez formularz CERT Polska, jeżeli organizacja nie ma własnego kanału albo chce przekazać informację o kampanii.

Jak ćwiczyć taki scenariusz w firmie

Dobry scenariusz szkoleniowy nie powinien kończyć się na pytaniu „czy kliknąłeś PDF”. To za mało. Warto rozbić ćwiczenie na kilka punktów decyzyjnych.

Pierwszy punkt to rozpoznanie nieoczekiwanego dokumentu. Użytkownik powinien umieć zadać sobie pytanie, czy dokument pasuje do jego roli, procesu i aktualnych spraw.

Drugi punkt to reakcja na komunikat o uszkodzonym pliku. W ćwiczeniu można pokazać, że „aktualizuj”, „napraw”, „pobierz podgląd” albo „otwórz w bezpiecznym widoku” bywają elementem manipulacji, a nie pomocą techniczną.

Trzeci punkt to zgłoszenie. Symulacja powinna mierzyć, czy użytkownik potrafi zgłosić wiadomość bez forwardowania jej do kolejnych osób, bez pobierania pliku i bez szukania obejścia.

Czwarty punkt to odpowiedź organizacji. Zespół IT lub Security powinien mieć jasną ścieżkę: kto odbiera zgłoszenie, jak zabezpiecza wiadomość, jak komunikuje się z użytkownikiem, kiedy izoluje urządzenie i kiedy eskaluje sprawę do procesu incydentowego.

Takie ćwiczenie dobrze łączy się z tematami, które PHISHLY opisuje przy złośliwych załącznikach w mailach z fakturą ZIP oraz przy scenariuszu, w którym infostealer zastępuje klasyczną fałszywą stronę logowania. W każdym z tych przypadków użytkownik nie tylko „klika link”, ale uruchamia proces prowadzący do utraty kontroli nad danymi, sesją albo urządzeniem.

Co zapamiętać z tej kampanii

Fałszywy PDF z banku jest groźny nie dlatego, że ma rozszerzenie PDF. Groźny jest moment, w którym dokument zaczyna instruować użytkownika, jak naprawić błąd, otworzyć treść, pobrać składnik albo przejść na zewnętrzną stronę.

Dla pracownika najlepszą reakcją jest zatrzymanie procesu i zgłoszenie wiadomości. Dla organizacji — szybkie rozróżnienie, czy doszło tylko do kontaktu z przynętą, czy także do pobrania pliku, uruchomienia kodu i logowania do systemów finansowych.

Jeżeli chcesz sprawdzić, czy pracownicy zatrzymają się na takim etapie, a nie dopiero po podaniu hasła, zaplanuj scenariusz w ramach programu security awareness. Możesz też skontaktować się z PHISHLY, aby dobrać ćwiczenia do procesów finansowych, księgowych i operacyjnych w Twojej organizacji.