Po zakończonej wrześniowej edycji Advanced In-The-Wild Malware Test publikujemy podsumowanie, w którym przyglądamy się nie tylko skuteczności ochrony, ale również temu, co dzieje się w systemie pomiędzy uruchomieniem złośliwego systemu a jego wykryciem i neutralizacją. Rozpatrzymy dzisiaj sytuację, kiedy kilka rozwiązań osiąga identyczny wynik skuteczności, mimo iż przebieg ochrony był zupełnie inny. Jeden produkt zatrzymuje zagrożenie jeszcze przed uruchomieniem, drugi dopiero po wykonaniu części złośliwych operacji. W obu przypadkach wynik testu może wskazywać na skuteczną ochronę, jednak z perspektywy bezpieczeństwa istotne jest również to, co malware zdążyło zrobić w systemie.
Chcemy zwrócić szczególną uwagę na przebieg ataków, moment reakcji produktów ochronnych oraz ślady pozostawione przez złośliwe oprogramowanie. Wykorzystując zgromadzoną telemetrię, pokażemy, dlaczego sam procent zablokowanych zagrożeń nie zawsze przedstawia pełny obraz działania ochrony.
Rozróżniamy następujące poziomy ochrony
W analizach uwzględniamy dwa główne poziomy ochrony:
- Web-Layer Protection, czyli blokowanie zagrożeń na etapie dostępu do złośliwego adresu lub pobierania pliku
- oraz Runtime Defense obejmujący wykrywanie i neutralizację malware po jego uruchomieniu.
W drugim przypadku szczególnie istotne jest ustalenie, jakie działania zdążyło wykonać złośliwe oprogramowanie przed reakcją produktu ochronnego oraz czy zostały usunięte skutki jego aktywności.
Ogólnie przebieg aktywności złośliwego systemu w naszym środowisku testowym można przedstawić w następujących etapach:
Czy testowane rozwiązania zapewniały porównywalny poziom ochrony systemu?
Przebieg ataku i reakcje ochrony
Próbka SHA-256 [4f9…32f] dla CatchPulse Pro:
Aby wyjaśnić tę sytuację, warto przypomnieć konfigurację CatchPulse Pro, stosowaną w naszych testach. Korzystamy z ustawień domyślnych z włączonym trybem „Block Mode”, który odpowiada za blokowanie wykrytych zagrożeń. W analizowanym przypadku próbka nie została zatrzymana na etapie Web-Layer Protection. Plik został pobrany, a następnie uruchomiony, co pozwoliło nam zaobserwować reakcję produktu na aktywne zagrożenie.
CatchPulse Pro wykrył i zablokował złośliwą aktywność. Czy to jednak oznacza, iż system pozostał wolny od zmian i pozostałości po malware? Sprawdźmy na podstawie zarejestrowanej telemetrii dostępnej dla producentów po teście.
Oś czasu
Godzina (UTC) | Zdarzenie |
21:17:16.110 | Próba pobrania malware (exe) |
21:17:32.828 | Zapisanie próbki na dysku |
21:17:33.508 | Zarejestrowanie zdarzenia FileCreateStreamHash dla pliku |
21:17:33.545 | Utworzenie strumienia Zone.Identifier |
21:19:10.206 | Uruchomienie cmd.exe i obliczanie SHA256 (nasza procedura testowa) |
21:20:16.205 | Próba uruchomienia malware |
21:20:20.609 | Komponent antywirusowy SecureAge tworzy plik Blocked.log (potwierdzenie blokady z informacjami technicznymi [1]) |
W analizowanym przypadku utworzenie pliku Blocked.log nastąpiło dokładnie 4,4 sekundy po próbie uruchomienia malware. Nie oznacza to jednak, iż silnik ochronny potrzebował dokładnie tyle czasu w wykrycie i zablokowanie zagrożenia. Dodatkowo warto zauważyć, iż próbka pozostawała na dysku przez 2 minuty i 43 sekundy przed próbą jej uruchomienia. W tym czasie wykonywane były różne procedury testowe, w tym obliczanie sumy kontrolnej SHA256. CatchPulse Pro nie zablokował pliku na tym etapie. Reakcję produktu odnotowaliśmy dopiero po próbie uruchomienia malware.
Próbka malware SHA-256 [4f9…32f] dla WithSecure Elements
W tym scenariuszu WithSecure nie zatrzymało zagrożenia podczas pobierania pliku. Próbka została zapisana na dysku i pozostawała tam przez około 2 minuty i 38 sekund przed uruchomieniem. W tym czasie podobnie były wykonywane różne procedury testowe. Ochrona zareagowała na etapie Runtime Defense. W logach widzimy, iż Sysmon potwierdził uruchomienie złośliwego pliku, a następnie zakończenie jego procesu po około 0,8 sekundy. Niemal równocześnie komponent WithSecure rozpoczął zapisywanie danych w repozytorium kwarantanny.
W zarejestrowanych zdarzeniach nie stwierdziliśmy dodatkowych procesów uruchomionych przez malware ani zmian w plikach lub rejestrze przypisanych do jego procesu. Oznacza to, iż zagrożenie zostało zatrzymane na bardzo wczesnym etapie działania.
Oś czasu
Godzina (UTC) | Zdarzenie |
21:17:22.563 | Pobieranie pliku exe przez przeglądarkę. |
21:17:38.921 | Zapis pliku na dysku. |
21:17:40.258 | Zapis identyfikatora Zone.Identifier. |
21:19:10.627 | Certutil.exe oblicza SHA256 próbki. |
21:20:16.667 | Uruchomienie malware. |
21:20:17.502 | Sysmon rejestruje zakończenie procesu próbki. |
21:20:17.504 – 21:20:17.968 | Produkt ochronny tworzy pliki kwarantanny. |
Sample SHA-256 [4f9…32f] dla Emsisoft Enterprise Security
Z kolei tutaj na podstawie logów wiemy, iż Emsisoft dopuścił do pobrania próbki i zapisania jej na dysku. Podczas późniejszej próby uruchomienia pliku nie odnotowaliśmy utworzenia procesu malware. Za to odnotowaliśmy, iż komponent antywirusowy „a2service.exe” zapisał dane w dzienniku EDR i utworzył plik w katalogu kwarantanny.
Na podstawie zdarzeń możemy zatem wywnioskować, iż produkt przejął zagrożenie podczas próby uruchomienia, zanim Sysmon zarejestrował wykonanie złośliwego pliku.
Oś czasu
Godzina (UTC) | Zdarzenie |
21:17:10.537 | Próba pobrania malware (exe) przez Operę. |
21:17:27.756 | Zapisanie próbki na dysku. |
21:17:28.804 | Zarejestrowanie zdarzenia FileCreateStreamHash dla pliku. |
21:17:28.842 | Zarejestrowanie strumienia Zone.Identifier. |
21:18:07.417 – 21:18:07.690 | Obliczenie SHA256 (wg procedury testowej poprzez certutil.exe) |
21:19:09.559 | Próba otwarcia malware. |
21:19:09.561 | a2service.exe zapisuje dane w dzienniku EDR. |
21:19:14.850 | a2service.exe tworzy plik .EQF w katalogu kwarantanny. |
Najważniejsze wnioski z tych 3 przypadków
Pobranie pliku nie spowodowało jego natychmiastowego zablokowania.
We wszystkich trzech przypadkach próbka została zapisana na dysku i pozostawała tam przez ponad dwie minuty przed próbą uruchomienia. W tym czasie wykonywaliśmy również różne procedury testowe. Ochrona zareagowała dopiero na późniejszym etapie związanym z próbą uruchomienia zagrożenia.
Samo uruchomienie procesu nie oznacza skutecznego przeprowadzenia ataku.
WithSecure pozwolił na utworzenie procesu malware, ale zakończył on działanie po około 0,8 sekundy. W dostępnej telemetrii nie stwierdziliśmy dodatkowej aktywności złośliwego pliku. Pokazuje to, iż choćby po rozpoczęciu wykonywania kodu mechanizmy Runtime Defense mogą skutecznie ograniczyć działanie zagrożenia.
Advanced In-The-Wild Malware Test
Wrzesień (Runda 5/6, 2026)
Konfiguracja testowanych rozwiązań
Rozwiązania klasy Enterprise
Elastic Defend + EDR
All Shields on Prevent mode + Attack surface reduction Enabled + collect all Events from workstationEmsisoft Enterprise Security + EDR
Default settings + automatic PUP repair + EDR + Rollback + browser protection
Microsoft Defender for Business + EDR
Default policy + configuration settings („Block at First Sight” enabled + EDR in block mode
mks_vir Endpoint Security + EDR
Extended http/https scanning enabled + browser protection + EDR
ThreatDown Endpoint Protection + EDR
Default settings + browser protection + EDR
WithSecure Elements EPP
Default settings + browser protection + Turn on Browser Protection for untrusted browsers
Dla małego biura i dla domu
Avast Free Antivirus
Default settings + automatic PUP repair + browser protection
Bitdefender Total Security
Default settings + browser protection
Eset Smart Security
Default settings + browser protection
F-Secure Total
Default settings + browser protection
Malwarebytes Premium
Default settings + browser protection
Norton Antivirus Plus
Default settings + browser protection
Surfshark One
Default settings + browser protection
Trend Micro Internet Security
Default settings + browser protection
Webroot Antivirus
Default settings + browser protection
Environment Configuration
Jakich ustawień używamy?
Podczas testów korzystamy z ustawień zapewniających pełną ochronę przed zagrożeniami, zgodnie z możliwościami produktu i zaleceniami producenta. Włączamy dostępne mechanizmy odpowiedzialne za wykrywanie i blokowanie malware, w tym:
- ochronę w czasie rzeczywistym,
- mechanizmy reputacyjne i analizę w chmurze,
- ochronę ruchu internetowego,
- analizę behawioralną,
- funkcje wykrywania i reagowania na zagrożenia (EDR/XDR),
- dedykowane rozszerzenia ochronne do przeglądarki, jeżeli są dostępne i wspierają blokowanie zagrożeń internetowych.
Polityka wobec PUP/PUA
W naszych testach nie wykorzystujemy próbek PUP/PUA, czyli potencjalnie niepożądanych aplikacji, które nie muszą być klasyfikowane jako malware. Mimo to zalecamy korzystanie z ochrony przed tego rodzaju oprogramowaniem. We wszystkich testowanych produktach włączamy wykrywanie PUP/PUA, jeżeli taka funkcja jest dostępna. Pozwala to ograniczyć ryzyko instalacji niepożądanych aplikacji, które mogą zmieniać ustawienia systemu, przeglądarki lub wpływać na komfort i bezpieczeństwo użytkownika.
Przejrzystość konfiguracji produktów
Domyślne ustawienia większości rozwiązań zapewniają odpowiedni poziom ochrony, ale nie zawsze obejmują wszystkie dostępne mechanizmy bezpieczeństwa. Dlatego przed rozpoczęciem testów weryfikujemy konfigurację produktu i w razie potrzeby dostosowujemy ją do zaleceń producenta. Wszelkie istotne zmiany względem ustawień domyślnych dokumentujemy i udostępniamy w wynikach testów. Niektóre produkty nie wymagają dodatkowej konfiguracji lub nie oferują możliwości zmiany poszczególnych ustawień.
Reakcja na incydenty i analiza zdarzeń
Testowane produkty konfigurujemy tak, aby automatycznie reagowały na wykryte zagrożenia, zgodnie z dostępnymi funkcjami i zaleceniami producenta. Może to obejmować blokowanie uruchomienia pliku, zakończenie złośliwego procesu, przeniesienie pliku do kwarantanny lub usunięcie zmian wprowadzonych w systemie. Podczas testów rejestrujemy i analizujemy zdarzenia systemowe, w tym aktywność procesów, operacje na plikach i rejestrze oraz połączenia sieciowe. Pozwala nam to ustalić, na jakim etapie produkt zatrzymał zagrożenie i czy malware zdążyło wykonać dodatkowe działania.
Advanced In-The-Wild Malware Test - metodologia i zakres badania
W ciągu roku przeprowadzamy sześć edycji testu rozwiązań konsumenckich i biznesowych. Sprawdzamy skuteczność ochrony przed rzeczywistymi zagrożeniami malware, analizując sposób i moment ich blokowania na poszczególnych etapach ataku.
Web-Layer Protection – ochrona przed zagrożeniami pochodzącymi z Internetu, obejmująca blokowanie złośliwych adresów URL, pobierania plików oraz dostępu do niebezpiecznych zasobów.
Runtime Defense – ochrona podczas próby uruchomienia malware i po rozpoczęciu wykonywania kodu, obejmująca analizę behawioralną, wykrywanie podejrzanych działań oraz przeciwdziałanie technikom fileless i innym zaawansowanym zagrożeniom.
Remediation Time – czas potrzebny na neutralizację zagrożenia i przywrócenie systemu do bezpiecznego stanu.
Podczas testów zbieramy również telemetrię systemową, która pozwala analizować techniki MITRE ATT&CK, wektory infekcji oraz taktyki, techniki i procedury (TTP) wykorzystywane przez cyberprzestępców.
Więcej o AVLab
AVLab Cybersecurity Foundation to niezależne laboratorium cyberbezpieczeństwa, które od 2012 roku specjalizuje się w testowaniu i ocenie skuteczności rozwiązań ochronnych. Jesteśmy członkiem AMTSO (Anti-Malware Testing Standards Organization) oraz uczestnikiem programu Microsoft Virus Initiative (MVI).
Prowadzimy testy oparte na rzeczywistych zagrożeniach i realistycznych scenariuszach ataków. Oceniamy zdolność produktów do wykrywania, blokowania i neutralizowania zagrożeń, analizując również ich zachowanie na poszczególnych etapach ataku. Publikowane wyniki, poparte danymi telemetrycznymi, pomagają użytkownikom i organizacjom podejmować świadome decyzje dotyczące wyboru technologii bezpieczeństwa.

![Cyberbezpieczeństwo: czy małych i średnich przedsiębiorców stać na skuteczną ochronę? [Wywiad infor.pl]](https://g.infor.pl/p/_files/39167000/cyberbezpieczenstwo-39167197.jpg)




.jpg)

