MSHTA w phishingu i cichy malware

TL;DR

MSHTA to legalne narzędzie Windows, które powstało do uruchamiania aplikacji HTA. Problem polega na tym, że atakujący wykorzystują je jako LOLBIN, czyli living-off-the-land binary. To legalny, podpisany komponent systemu, który może pośredniczyć w wykonaniu złośliwego kodu i wyglądać mniej podejrzanie niż obcy plik wykonywalny.

Według Bitdefendera i SecurityWeek wzrost nadużyć MSHTA widać w kampaniach phishingowych, fałszywych pobraniach oprogramowania, ClickFix, infostealerach, loaderach i trwałych infekcjach. Użytkownik jest często nakłaniany do wykonania pozornie technicznej instrukcji: pobrania darmowego programu, przejścia fałszywej weryfikacji, wklejenia komendy do okna Uruchom lub terminala.

Dla firm to mocny sygnał, że awareness musi obejmować nie tylko linki i załączniki. Trzeba uczyć pracowników, że żadna strona, konsultant ani instrukcja z wiadomości nie powinna wymagać uruchamiania komend systemowych, PowerShella, MSHTA, msiexec, rundll32, certutil ani podobnych narzędzi.

Dlaczego stare narzędzie Windows nadal ma znaczenie

MSHTA istnieje w Windows od wielu lat i zostało zachowane głównie ze względu na kompatybilność wsteczną. Sam fakt istnienia takiego komponentu nie jest błędem. Problem zaczyna się wtedy, gdy funkcja zaprojektowana do legalnego uruchamiania kodu staje się wygodnym pośrednikiem dla atakujących.

MSHTA może wykonywać lokalne lub zdalne treści HTA, obsługiwać VBScript i JavaScript, pobierać zasoby z internetu i działać w kontekście zaufanego składnika Microsoftu. W praktyce może więc stać się pomostem między socjotechniką a malware. Użytkownik nie pobiera pliku o nazwie malware.exe. Uruchamia komendę, która wygląda technicznie, ale w tle pobiera i wykonuje kolejny etap.

Ten model jest groźny, bo omija intuicję wielu użytkowników. W szkoleniach często mówi się o podejrzanych załącznikach i linkach. Rzadziej pokazuje się, że strona może próbować nakłonić człowieka do wklejenia polecenia do Windows + R, PowerShella albo terminala. Dla atakującego to świetny moment: człowiek staje się wykonawcą instrukcji, której system sam z siebie by nie uruchomił.

ClickFix i fałszywa weryfikacja człowieka

W kampaniach ClickFix użytkownik trafia na stronę udającą weryfikację, problem z dostępem, CAPTCHA albo instrukcję naprawy. Strona prosi o wykonanie kilku kroków: naciśnij Windows + R, wklej polecenie, zatwierdź. Użytkownik ma poczucie, że przechodzi zwykłą procedurę techniczną albo naprawia problem z dostępem.

To nie jest tylko problem techniczny. To czysta socjotechnika. Atakujący wykorzystuje rutynę pracy z komunikatami, przyciskami i instrukcjami. Użytkownik nie analizuje składni polecenia. Widzi zadanie do wykonania. Jeśli wcześniej kliknął link z maila, z komunikatora lub z wyników wyszukiwania, może uznać, że instrukcja jest częścią procesu.

W wariancie z MSHTA polecenie może uruchomić zdalną aplikację HTA albo inline script. Dalej łańcuch może przejść do PowerShella, loadera, stealera, clippera kryptowalutowego albo narzędzia utrzymującego trwałość. Dla użytkownika wszystko mogło zacząć się od fałszywej weryfikacji człowieka.

Co powinien zauważyć użytkownik

Najważniejszy sygnał jest prosty: normalna strona internetowa, wiadomość e-mail, SMS, komunikator, rekruter, helpdesk albo dostawca nie powinien kazać użytkownikowi uruchamiać komend systemowych. Jeżeli instrukcja prosi o Windows + R, PowerShell, terminal, CMD, mshta, rundll32, certutil, msiexec albo wklejenie długiego polecenia, proces trzeba przerwać.

Użytkownik nie musi znać wszystkich narzędzi Windows. Wystarczy zasada: nie uruchamiam komend z instrukcji otrzymanej przez wiadomość, stronę lub rozmowę przychodzącą. Jeśli sprawa dotyczy firmy, zgłaszam ją do IT. Jeśli dotyczy prywatnego komputera, szukam pomocy u zaufanego specjalisty, nie u przypadkowego konsultanta z linku.

To powinno być elementem security awareness program. Organizacje często szkolą rozpoznawanie fałszywych domen, ale rzadziej ćwiczą sytuację, w której pracownik jest nakłaniany do wykonania polecenia. Tymczasem właśnie to zachowanie bywa granicą między kliknięciem a infekcją.

Co powinien monitorować SOC

SOC powinien monitorować uruchomienia mshta.exe, zwłaszcza z nietypowymi argumentami, zdalnymi adresami URL, skryptami inline, procesami potomnymi PowerShell, cmd, wscript, cscript, rundll32 lub msiexec. Ważne są także relacje procesów: czy mshta.exe został uruchomiony przez explorer.exe po użyciu okna Uruchom, przez przeglądarkę, archiwum, dokument albo skrypt.

Sama obecność mshta.exe nie musi oznaczać incydentu. W niektórych środowiskach mogą istnieć starsze aplikacje biznesowe. Dlatego potrzebny jest kontekst: kto uruchomił proces, z jaką komendą, kiedy, czy wcześniej kliknięto link z wiadomości, czy nastąpiło pobranie pliku, czy pojawiła się komunikacja do internetu i czy później uruchomił się PowerShell.

W wielu firmach sensowne będzie ograniczenie MSHTA przez polityki aplikacyjne, WDAC, AppLocker, reguły EDR albo blokady tam, gdzie nie ma uzasadnionego użycia biznesowego. Taka decyzja wymaga testu kompatybilności, ale powinna być rozważona, bo narzędzia living-off-the-land są atrakcyjne właśnie dlatego, że są dostępne domyślnie.

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

Jeżeli użytkownik wkleił komendę z podejrzanej strony lub wiadomości, powinien natychmiast zgłosić zdarzenie do IT lub SOC. Nie należy zamykać sprawy stwierdzeniem, że nic się nie stało, bo okno zniknęło. W takich atakach złośliwy kod często działa w tle i nie pokazuje widocznego efektu.

Zespół techniczny powinien sprawdzić historię uruchomień, command line procesów, połączenia sieciowe, logi EDR, DNS i proxy, zadania harmonogramu, wpisy autostartu oraz nowe pliki w katalogach użytkownika. Trzeba też sprawdzić, czy po MSHTA uruchomiły się PowerShell, msiexec, rundll32, certutil, wscript, cscript albo nietypowe procesy podpisane przez legalnych dostawców.

Jeżeli wykryto infostealera lub loader, konieczna może być izolacja endpointa, reset haseł, unieważnienie sesji, kontrola przeglądarek, menedżerów haseł, tokenów i usług chmurowych. W takim incydencie samo usunięcie pliku może być niewystarczające.

Jak testować ten scenariusz w awareness

W testach phishingowych dla firm można bezpiecznie odtworzyć scenariusz fałszywej weryfikacji człowieka. Celem nie jest nakłanianie pracowników do realnego uruchamiania komend, ale sprawdzenie, czy rozpoznają niedopuszczalną instrukcję i zgłoszą ją przed wykonaniem.

Metryki powinny obejmować kliknięcie, dotarcie do instrukcji, próbę skopiowania polecenia, zgłoszenie, czas reakcji i reakcję helpdesku. To ważniejsze niż sam click rate, bo prawdziwe ryzyko pojawia się dopiero wtedy, gdy użytkownik wykonuje polecenie systemowe.

Wniosek

MSHTA pokazuje, że phishing coraz częściej nie prosi tylko o hasło. Prosi użytkownika, aby własnymi rękami uruchomił fragment łańcucha ataku. To zmienia sposób szkolenia: trzeba uczyć nie tylko rozpoznawania fałszywych stron, ale też odmawiania wykonania technicznych instrukcji z niezweryfikowanego źródła.

Praktyczna zasada dla pracownika jest krótka: jeśli wiadomość lub strona każe wklejać komendę do Windows, PowerShella albo terminala, zatrzymaj proces i zgłoś sprawę. Dla organizacji to sygnał, że awareness, EDR i kontrola aplikacji muszą działać razem.