Test ochrony sesji bankowej online w Windows przez popularne rozwiązania antywirusowe

avlab.pl 2 godzin temu
Zdjęcie: Test ochrony sesji bankowej online w Windows przez popularne rozwiązania antywirusowe


Większość nowoczesnych programów antywirusowych dla systemów Windows 10, Windows 11 oraz macOS oferuje standardowo podstawową ochronę bankowości internetowej i płatności online. zwykle obejmuje ona mechanizmy antyphishingowe, anty-malware, ochronę przed keyloggerami i screenloggerami, blokowanie niezaufanych aplikacji i skryptów oraz wykrywanie nieautoryzowanych zmian w konfiguracji DNS. Część producentów idzie jednak o krok dalej, wdrażając dedykowane moduły zabezpieczające system operacyjny podczas realizacji płatności internetowych oraz innych wrażliwych i poufnych operacji.

Specjalne moduły do płatności internetowych zostały zaprojektowane w celu ochrony finansów oraz danych osobowych użytkowników przed cyberprzestępczością. Zwiększają one poziom bezpieczeństwa bankowości elektronicznej i transakcji online. Korzystanie z rozwiązań rekomendowanych przez Fundację AVLab dla Cyberbezpieczeństwa znacząco ogranicza ryzyko skutecznego cyberataku.

Założenia testu

Głównym celem testu była ocena skuteczności dedykowanych modułów ochrony bankowości internetowej w zabezpieczaniu użytkownika przed atakami, niezależnie od zastosowanego protokołu lub wektora początkowego. W tym celu opracowano złośliwe oprogramowanie oraz zasymulowano scenariusze, w których atakujący podejmował próbę kradzieży danych z systemu chronionego aktywnym oprogramowaniem antywirusowym, przy jednoczesnym włączonym trybie ochrony bankowości internetowej. W przypadkach, gdy dedykowany tryb nie był dostępny, wykorzystywano pełne możliwości rozwiązania poprzez odpowiednio dostosowaną konfigurację.

W systemach Windows zagrożenia dostarczano za pośrednictwem komunikatora Telegram. Scenariusz obejmował przesłanie ofierze złośliwego pliku podszywającego się pod zaufaną aplikację od „znajomego kontaktu”, na przykład rzekomej wersji beta gry. Tego typu ataki mogą być realizowane z użyciem dowolnego komunikatora i pozwalają ominąć przeglądarkę oraz część podstawowych mechanizmów ochronnych, co zapewnia bardziej realistyczną ocenę interakcji pomiędzy malware a zastosowanymi technologiami zabezpieczającymi.

Metodologia

Metodologia testowa została opracowana zgodnie z wytycznymi Anti-Malware Testing Standards Organisation (AMTSO)*, co zapewnia równe traktowanie wszystkich producentów oraz umożliwia im weryfikację wyników na podstawie dostarczonych logów. * https://www.amtso.org/amtso-ls1-tp168

Wszystkie testy przeprowadzono na komputerze z systemem Windows 11 25H2, z aktywnymi ustawieniami domyślnymi lub wzmocnionymi. Konfiguracja ta odzwierciedla środowisko typowo spotykane u użytkowników domowych oraz w środowiskach biurowych.

Złośliwe pliki były dostarczane do systemu z wykorzystaniem różnych wektorów ataku, w tym popularnych komunikatorów internetowych oraz mniej powszechnych protokołów, co odróżnia ten scenariusz od infekcji realizowanych wyłącznie przez przeglądarkę lub pocztę elektroniczną. Przy aktywnym trybie bankowym lub działającej w tle przeglądarce zadaniem testowanych rozwiązań było wykrycie i zatrzymanie ataku na dowolnym etapie – przed jego rozpoczęciem, w trakcie lub po nawiązaniu komunikacji z serwerem kontrolowanym przez atakującego.

Zastosowany scenariusz testowy obejmował następujące etapy:

1.

Próba wstrzyknięcia i uruchomienia złośliwego systemu w systemie, przy działającym w tle rozwiązaniu antywirusowym skonfigurowanym na ustawieniach domyślnych lub zgodnie z konfiguracją opisaną w raporcie końcowym.

2.

Aktywacja modułu ochrony płatności internetowych. W zależności od testowanego rozwiązania ochrona była uruchamiana automatycznie po wejściu na stronę banku lub manualnie przez użytkownika. W przypadku braku dedykowanego bezpiecznego środowiska wykorzystywano przeglądarkę Opera oraz stronę bankowości internetowej.

3.

Obserwacja reakcji rozwiązania ochronnego oraz zakresu informacji, które potencjalnie mógł pozyskać atakujący. Etap ten powtarzano dla wszystkich scenariuszy testowych.

4.

Wyciągnięcie wniosków oraz ocena produktu na podstawie uzyskanych wyników.

Przegląd scenariuszy testowych

Do symulacji działania złośliwego systemu wykorzystano język .NET. Opracowane narzędzia imitowały techniki stosowane przez malware, takie jak rejestrowanie klawiszy, manipulacja schowkiem, wykonywanie zrzutów ekranu oraz przesyłanie danych i logów do serwera kontrolowanego przez testerów, co pozwalało potwierdzić poprawność działania symulowanych ataków. W tym czasie oprogramowanie antywirusowe działało w tle z ustawieniami domyślnymi, o ile raport nie wskazywał inaczej. Dodatkowo aktywowano specjalne mechanizmy ochrony przeglądarek lub tryby bankowe wykorzystywane do bankowości internetowej. dla wszystkich scenariusza oceniano skuteczność ochrony i rejestrowano wszystkie wyniki.

Przechwytywania schowka
Ocena skuteczności systemu zabezpieczającego w wykrywaniu prób przechwytywania i przesyłania wrażliwych danych kopiowanych do schowka systemowego.
Podmiany zawartości schowka
Sprawdzenie reakcji zabezpieczeń na próby zastępowania zawartości schowka (np. numerów płatności lub adresów kryptowalut) oraz ich wyprowadzania poza system.
Symulacja keyloggera
Ocena skuteczności ochrony przed technikami przechwytywania danych wejściowych poprzez symulację rzeczywistego działania keyloggera.
Przechwytywanie ekranu
Weryfikacja, czy produkty bezpieczeństwa wykrywają wielokrotne próby wykonywania zrzutów ekranu pulpitu lub trybu bankowego oraz ich zdalnego przesyłania.
Wyszukiwanie i eksfiltracji plików
Odtworzenie scenariusza, w którym atakujący przeszukuje katalogi systemowe i próbuje skopiować odnalezione pliki do lokalizacji zewnętrznej.
Wykrywanie zdalnego sterowania
Ocena widoczności narzędzia zdalnego dostępu RustDesk działającego na stacji roboczej oraz jego interakcji z pulpitem użytkownika.
Atak ransomware
Symulacja zachowania ransomware, obejmująca szyfrowanie plików, tworzenie notatek okupu oraz modyfikowanie znaczników czasu.
Przetrwania kodu po restarcie
Tworzenie typowych mechanizmów autostartu w rejestrze systemowym, folderze uruchamiania oraz Harmonogramie zadań w celu oceny ich wykrywalności i trwałości po ponownym uruchomieniu systemu.
Atak typu „click-to-compromise”
Odtworzenie scenariusza phishingowego, w którym fałszywy komunikat systemowy nakłania użytkownika do uruchomienia kodu, testując mechanizmy ochrony przed socjotechniką, a nie rzeczywiste podatności.

Wszystkie scenariusze stanowią bezpieczne symulacje realizowane w kontrolowanym środowisku testowym i generują artefakty charakterystyczne dla rzeczywistych technik ataku. Należy podkreślić, iż część z tych działań może nie być klasyfikowana przez producentów jako typowe malware, co nie oznacza, iż legalne narzędzia nie mogą zostać wykorzystane przez atakujących do realizacji złośliwych celów na komputerach użytkowników.

Podstawowe informacje o testowanych pakietach bezpieczeństwa

Test rozpoczął się 3 listopada 2025 r. i zakończył 23 grudnia 2025 r. W całym okresie badania wykorzystywano najnowsze dostępne wersje testowanego oprogramowania. Nie wszystkie pakiety posiadały dedykowany tryb bankowości internetowej; w takich przypadkach testy przeprowadzano z użyciem wzmocnionych ustawień zabezpieczeń, co pozwoliło na pełniejszą ocenę rzeczywistych możliwości danego rozwiązania.
AVAST Premium
Specjalny moduł: Tryb Bankowy
BITEDEFENDER Total Security
Specjalny moduł: Safe Pay
COMODO Internet Security Pro
Specjalny moduł: Secure Shopping
ESET Home Security Premium
Specjalny moduł: Safe Banking & Browsing
F-SECURE Total
Specjalny moduł: Bank Mode
G DATA Internet Security
Specjalny moduł: niedostępny
KASPERSKY Plus
Specjalny moduł: Safe Money
MICROSOFT Defender
Specjalny moduł: niedostępny
MKS_VIR Internet Security
Specjalny moduł: Bezpieczna Przeglądarka
NORTON 360
Specjalny moduł: niedostępny
QUICK HEAL Total Security
Specjalny moduł: Safe Banking
TREND MICRO Maximum Security
Specjalny moduł: Pay Guard

Rozwiązanie Sophos Home zostało wykluczone z testu, ponieważ stwierdzono brak dodatkowych mechanizmów ochronnych lub wzmocnionych ustawień, które mogłyby mieć praktyczne znaczenie w analizowanych scenariuszach testowych.

Dodatkowo testy przeprowadzono zarówno na ustawieniach domyślnych, odzwierciedlających najczęściej spotykaną konfigurację oraz typowe zachowanie użytkownika końcowego, jak i na ustawieniach wzmocnionych, które pokazują pełny potencjał ochronny danego rozwiązania po świadomej konfiguracji zabezpieczeń.

Tabele z wynikami prezentują jednoznaczną ocenę skuteczności scenariusza ataku, niezależnie od klasyfikacji samej próbki. Oznaczenie „attack successful (X)” oznacza, iż symulowany atak osiągnął swój cel techniczny, taki jak przechwycenie danych, manipulacja sesją bankową, uzyskanie zdalnego dostępu lub utrzymanie trwałości w systemie, choćby jeżeli użyta próbka nie została sklasyfikowana jako złośliwa w konfiguracji domyślnej produktu.

Z kolei oznaczenie „attack blocked (V)” wskazuje, iż mechanizmy ochronne skutecznie uniemożliwiły realizację ataku, niezależnie od tego, czy blokada nastąpiła na etapie prewencji, detekcji behawioralnej, ochrony pamięci czy izolacji środowiska.

  • Wyniki testów odzwierciedlają skutki ataku, a nie klasyfikację złośliwego oprogramowania.
    Pakiety zabezpieczeń zostały początkowo przetestowane w ich domyślnej konfiguracji. jeżeli określone zabezpieczenia były domyślnie wyłączone, zostały one włączone w celu oceny tej funkcji. Gdy wykrycie nie nastąpiło w ustawieniach domyślnych, wypróbowano alternatywne konfiguracje.

Certyfikat

Certyfikat „Internet Banking Protection Test – 2026” jest przyznawany po spełnieniu określonych warunków.

Uzyskanie certyfikatu oznacza, iż pakiet zabezpieczeń skutecznie chroni przed przejęciem sesji bankowości internetowej i spełnia wysokie wymagania AVLab w zakresie ochrony transakcji finansowych.

  • AVAST Premium + Tryb Bankowy
  • COMODO Internet Security Pro + Secure Shopping
  • F-SECURE Total + Ochrona Bankowości
  • KASPERSKY Plus + Safe Money
  • MKS_VIR Internet Security + Bezpieczna Przeglądarka
  • NORTON 360

Wnioski z testu

1.

Występują sytuacje, w których – mimo poprawnego dostarczenia próbki do systemu z atrybutem ZoneID=3 – mechanizmy ochronne nie zawsze są w stanie wykryć pliki typu 0-day pozbawione podpisu cyfrowego. Dotyczy to w szczególności próbek o niskiej popularności w telemetrii producenta, w tym plików przygotowanych specjalnie na potrzeby testów. W takich przypadkach najważniejsze znaczenie ma nie klasyfikacja pliku, ale rzeczywisty wpływ na użytkownika, czyli to, czy symulowany atak umożliwia przechwycenie danych, manipulację sesją lub uzyskanie nieautoryzowanego dostępu.

* https://learn.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms537183(v=vs.85)

2.

Nie każda technika użyta w testach musi być klasyfikowana jako klasyczne malware w ujęciu sygnaturowym. W wielu scenariuszach wykorzystywane są legalne narzędzia systemowe, funkcje systemu operacyjnego lub mechanizmy powszechnie dostępne w środowisku użytkownika. Dlatego głównym kryterium oceny jest rzeczywisty wpływ na użytkownika (User Impact) oraz to, czy atak osiąga swój cel techniczny, np. kradzież danych uwierzytelniających, manipulację sesją bankową, zdalny dostęp czy eksfiltrację danych. Brak reakcji produktu na „nieszkodliwy” komponent traktowany jest jako skuteczny atak.

3.

Przy ustawieniach domyślnych rozwiązania bezpieczeństwa często nie filtrują skutecznie ruchu sieciowego generowanego przez pliki 0-day o niskiej lub zerowej reputacji (np. pliki EXE). W praktyce oznacza to, iż komunikacja wychodząca nie jest blokowana, o ile próbka nie była wcześniej obserwowana w chmurze producenta lub pojawiła się jedynie w marginalnej liczbie przypadków. Jest to typowa i pożądana sytuacja z punktu widzenia realizmu testu.

4.

Zwracamy uwagę użytkowników na konieczność stosowania bardziej restrykcyjnych trybów zapory sieciowej lub modułów HIPS. Ustawienia automatyczne są projektowane z myślą o minimalizacji liczby alertów i ingerencji w pracę użytkownika, co często odbywa się kosztem bezpieczeństwa. W efekcie możliwe staje się przechwytywanie schowka, wykonywanie zrzutów ekranu, rejestrowanie klawiszy oraz eksfiltracja danych do serwera atakującego. W testach zapory sieciowe w konfiguracji domyślnej wielokrotnie zawodziły, niezależnie od producenta.

5.

Testy potwierdzają, iż dedykowane tryby bankowości w wielu przypadkach skutecznie ograniczają działanie malware uruchomionego w tle. Kod złośliwy często nie jest w stanie poprawnie funkcjonować w środowisku izolowanym. Przykładowo, mechanizmy anty-keylogger szyfrują wprowadzane znaki, a próby uzyskania trwałości w systemie są wykrywane przez wyspecjalizowane moduły monitorujące mechanizmy autostartu.

6.

Najlepiej rozwinięte tryby bankowe w konfiguracji domyślnej zaobserwowano w rozwiązaniach F-Secure, mks_vir oraz Comodo. Produkty te stosują wielowarstwowe podejście prewencyjne, w tym izolowane środowisko dla operacji krytycznych. F-Secure automatycznie blokuje cały ruch sieciowy poza przeglądarką bankową, natomiast mks_vir ujawnia procesy działające w tle i wymaga świadomej decyzji użytkownika. Mechanizmy te skutecznie redukują powierzchnię ataku.

7.

W rozwiązaniach pozbawionych dedykowanego trybu bankowego ochrona pakietowa bywa ograniczona, o ile producent nie wdrożył dodatkowych mechanizmów prewencyjnych. Testy jednoznacznie pokazują, iż tryb bankowy przewyższa standardowy tryb ochrony, w którym podobne ograniczenia wobec aplikacji o nieznanej reputacji nie są stosowane.

Po zakończeniu testów poinformowaliśmy producentów wskazanych w raporcie o uzyskanych wynikach oraz przekazaliśmy rekomendacje dotyczące wzmocnienia ochrony. Zalecono również rozwój dodatkowych mechanizmów detekcyjnych dla technik i narzędzi wykorzystanych w tej edycji badania.

Test ochrony sesji bankowej online w Windows

Test trybu bankowego w nowoczesnych rozwiązaniach antywirusowych

Idź do oryginalnego materiału