WhatsApp, fałszywe dokumenty i RMM

TL;DR

Kampania opisana przez Kaspersky pokazuje, że WhatsApp może być kanałem dostarczenia złośliwego pliku, a nie tylko miejscem prywatnej rozmowy. Użytkownik dostaje załącznik od znanego kontaktu. Nazwa sugeruje fakturę, wyciąg, potwierdzenie płatności albo inny dokument biznesowy. W rzeczywistości plik ma rozszerzenie .vbs lub .vbe i po uruchomieniu w Windows rozpoczyna łańcuch infekcji.

Ryzyko nie wynika z samego komunikatora. Krytyczny moment pojawia się wtedy, gdy pracownik pobiera załącznik i uruchamia go na komputerze służbowym. W badanej kampanii skrypt mógł doprowadzić do instalacji legalnego narzędzia RMM, czyli Remote Monitoring and Management, skonfigurowanego tak, aby zapewnić zdalny dostęp osobie atakującej.

Dla organizacji to scenariusz do ćwiczenia w ramach programu security awareness. Pracownik musi wiedzieć, że znany nadawca nie oznacza zaufanego pliku, a dokument firmowy powinien przyjść przez zatwierdzony kanał, nie przez przypadkowy czat.

Jak działa kampania przez WhatsApp

Atak zaczyna się od kont WhatsApp, które zostały wcześniej przejęte albo nadużyte. Z takiego konta do kontaktów ofiary trafia sam załącznik albo krótka wiadomość sugerująca dokument. To zwiększa wiarygodność, bo odbiorca widzi znaną osobę, kontrahenta, współpracownika albo klienta.

Pliki mają nazwy przypominające codzienną dokumentację: raport finansowy, potwierdzenie zadłużenia, zestawienie płatności, wyciąg bankowy, formularz podatkowy albo fakturę. Część nazw była lokalizowana na różne języki, co wskazuje na próbę dopasowania przynęty do wielu regionów.

Po pobraniu i otwarciu pliku na Windows uruchamia się Windows Script Host. To standardowy składnik systemu odpowiedzialny za wykonywanie skryptów. W rękach administratora może być użyteczny, ale w tym scenariuszu wykonuje polecenia przygotowane przez atakującego. Skrypt tworzy katalog roboczy, pobiera kolejne komponenty i uruchamia następne etapy infekcji.

Końcowym elementem opisywanej kampanii była instalacja ManageEngine Endpoint Central. To legalna platforma do zarządzania urządzeniami, wdrażania oprogramowania i zdalnego wsparcia. Problemem nie jest sama technologia, tylko to, że agent RMM został dostarczony i skonfigurowany poza zgodą organizacji.

Dlaczego znany kontakt osłabia czujność

Wiadomość od obcej osoby łatwiej odrzucić. Wiadomość od znanego kontaktu uruchamia inny tok myślenia: „skoro to ktoś z mojej listy, dokument pewnie jest prawdziwy”. Ten mechanizm jest szczególnie skuteczny w firmach, gdzie wiele spraw dzieje się szybko i równolegle.

Nazwa pliku nie musi być idealna. Wystarczy, że przypomina coś, co faktycznie pojawia się w pracy: fakturę od dostawcy, rozliczenie transportu, korektę danych, potwierdzenie płatności, zestawienie z księgowości albo dokument dla zarządu. Użytkownik może skupić się na sensie biznesowym nazwy, a nie na rozszerzeniu.

Drugi problem to konfiguracja systemu. Jeżeli Windows ukrywa rozszerzenia znanych typów plików, odbiorca może nie zauważyć końcówki .vbs. Jeżeli plik ma ikonę podobną do dokumentu albo jest spakowany w archiwum, ryzyko błędnej oceny rośnie.

Trzeci element to legalne narzędzia. RMM nie musi wyglądać jak klasyczne malware. W wielu firmach podobnych rozwiązań używa helpdesk albo administratorzy. Dlatego zespoły IT i SOC powinny patrzeć nie tylko na nazwę produktu, ale też na źródło instalacji, konfigurację, konto użytkownika i moment pojawienia się agenta.

Polski i firmowy kontekst

W Polsce WhatsApp, Signal, Messenger i inne komunikatory są często używane na styku spraw prywatnych i służbowych. W małych firmach bywają kanałem kontaktu z klientami, wykonawcami i podwykonawcami. W większych organizacjach pojawiają się w sprzedaży, logistyce, serwisie, rekrutacji, kontaktach terenowych i komunikacji zarządczej.

Podobny scenariusz może wyglądać zwyczajnie. Ktoś wysyła na czacie plik opisany jako faktura, potwierdzenie przelewu, lista zaległości, dokument kadrowy, potwierdzenie dostawy albo korekta danych. Jeżeli pracownik otworzy plik na laptopie służbowym, skutki nie dotyczą już tylko prywatnej rozmowy.

Warto połączyć ten temat z podstawową edukacją o tym, co to jest phishing, ale nie ograniczać się do poczty. Phishing w firmie coraz częściej dotyczy momentów, w których pracownik ufa relacji, kanałowi albo rutynowemu procesowi. W komunikatorze takie zaufanie działa bardzo mocno.

Szczególnie narażone są obszary, w których dokumenty krążą szybko i często: sprzedaż, księgowość, transport, logistyka, serwis, HR oraz współpraca z zewnętrznymi dostawcami. Dlatego scenariusz warto włączyć do ćwiczeń dla biur rachunkowych, zespołów operacyjnych i firm, które regularnie wymieniają dokumenty z kontrahentami.

Co powinien zrobić użytkownik

Użytkownik nie powinien uruchamiać plików .vbs, .vbe, .js, .bat, .cmd, .ps1, .scr, .exe ani nieznanych pakietów instalacyjnych otrzymanych przez komunikator. Jeżeli plik ma udawać dokument, trzeba sprawdzić rozszerzenie i potwierdzić nadawcę innym kanałem.

Dobre pytanie kontrolne brzmi: czy ten dokument powinien przyjść właśnie tędy? Faktura, wyciąg, umowa, dokument kadrowy albo potwierdzenie płatności powinny mieć ustaloną ścieżkę: pocztę firmową, system obiegu dokumentów, portal dostawcy, system księgowy albo repozytorium plików. Komunikator może być kanałem rozmowy, ale nie powinien zastępować procesu.

Jeżeli wiadomość wygląda nietypowo, użytkownik powinien ją zgłosić. Nie trzeba samodzielnie analizować skryptu ani sprawdzać, „czy się otworzy”. Wystarczy zachować plik, zrobić zrzut ekranu rozmowy, przekazać informację do IT/Security i poczekać na decyzję.

W kontrolowanych testach phishingowych dla firm taki scenariusz można ćwiczyć bez prawdziwych plików wykonywalnych. Celem nie jest szukanie winnego, tylko sprawdzenie momentu decyzji: czy zauważy rozszerzenie, czy potwierdzi kanał, czy zgłosi zdarzenie i czy nie przeniesie prywatnego zaufania na firmowy komputer.

Co powinny zrobić IT, Security i SOC

IT powinno sprawdzić, czy w organizacji są realne powody do uruchamiania skryptów VBS przez zwykłych użytkowników. Jeżeli nie, warto ograniczyć Windows Script Host, wprowadzić reguły kontroli aplikacji i zablokować uruchamianie skryptów z katalogów pobierania, profilu użytkownika oraz lokalizacji tymczasowych.

Drugim krokiem jest kontrola narzędzi RMM. Organizacja powinna mieć listę dopuszczonych rozwiązań, znanych serwerów zarządzających, certyfikatów, nazw usług i kont używanych do administracji. Każdy agent RMM spoza tej listy powinien być traktowany jako sygnał wymagający wyjaśnienia.

Security i SOC mogą monitorować sekwencje zdarzeń, a nie tylko pojedynczy alert. Przydatne są sygnały takie jak pobranie pliku z komunikatora, uruchomienie wscript.exe lub cscript.exe, start instalatora MSI, utworzenie nowej usługi, połączenie do nieznanej infrastruktury oraz pojawienie się agenta zdalnego zarządzania.

Ważny jest też proces zgłaszania. Jeżeli pracownik może raportować wyłącznie e-maile, to nie zgłosi podejrzanej wiadomości z WhatsApp. Warto dopuścić zgłoszenia ze zrzutem ekranu, nazwą pliku, godziną, opisem kanału i informacją, czy plik został uruchomiony.

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

Jeżeli użytkownik uruchomił podejrzany plik, powinien natychmiast zgłosić zdarzenie do IT lub Security i odłączyć urządzenie od sieci zgodnie z wewnętrzną procedurą. Nie powinien usuwać pliku, czyścić historii, restartować komputera bez polecenia ani próbować samodzielnie „naprawiać” systemu, jeśli urządzenie ma być analizowane.

Zespół techniczny powinien zabezpieczyć plik, historię pobierania, ścieżkę uruchomienia, logi procesu, listę nowych usług, zadania harmonogramu, świeżo zainstalowane programy, połączenia sieciowe i aktywne sesje użytkownika. Jeżeli pojawiło się narzędzie RMM, trzeba sprawdzić jego konfigurację i serwer zarządzający.

Następnie warto unieważnić sesje kont używanych na komputerze, sprawdzić logowania do poczty, Microsoft 365, Google Workspace, VPN, aplikacji finansowych i systemów SaaS. Jeżeli pracownik miał dostęp do danych klientów albo dokumentów finansowych, zakres analizy powinien objąć również możliwe użycie tych uprawnień.

Jeżeli wiadomość przyszła od znanej osoby, trzeba założyć, że jej konto WhatsApp mogło zostać nadużyte. Tę osobę należy poinformować innym kanałem. W polskim kontekście podejrzane incydenty można zgłaszać również przez formularz CERT Polska, zwłaszcza gdy pojawia się szersza kampania albo linki i infrastruktura wykorzystywane do ataku.

Jak ćwiczyć ten scenariusz w awareness

Ten scenariusz dobrze nadaje się do ćwiczeń, bo ma kilka mierzalnych decyzji. Nie trzeba wysyłać prawdziwego malware. Wystarczy bezpieczna symulacja wiadomości z komunikatora, nazwa pliku udająca dokument i jasny proces raportowania.

Warto mierzyć nie tylko kliknięcie. Ważne są kolejne momenty: pobranie pliku, próba uruchomienia, sprawdzenie rozszerzenia, kontakt z nadawcą innym kanałem, zgłoszenie do IT/Security i reakcja po informacji zwrotnej. Dopiero taki pomiar pokazuje, czy pracownik zna procedurę, czy tylko wie, że „phishing istnieje”.

Dobrą praktyką jest też rozmowa o kanałach. Firmy powinny jasno określić, gdzie przyjmują faktury, umowy, dokumenty HR, potwierdzenia płatności i pliki od dostawców. Jeżeli proces biznesowy jest niejasny, użytkownik będzie podejmował decyzję sam, często pod presją czasu.

PHISHLY może wspierać takie ćwiczenia jako część programu edukacyjnego i testów reakcji użytkowników. Jeśli chcesz sprawdzić, jak taki scenariusz wyglądałby w Twojej organizacji, skorzystaj z kontaktu z PHISHLY i opisz, jakie komunikatory oraz procesy wymiany dokumentów są używane w firmie.

Konkretna zasada na koniec

Znany nadawca nie zmienia skryptu w dokument. Jeżeli faktura, wyciąg albo potwierdzenie płatności przychodzi przez WhatsApp jako plik uruchamialny, właściwą decyzją jest zatrzymanie procesu, weryfikacja innym kanałem i zgłoszenie zdarzenia. W tym scenariuszu odporność zaczyna się nie od technicznej analizy malware, ale od prostego pytania: czy ten plik powinien być uruchomiony na firmowym komputerze?