Zobaczcie całkiem normalne zapytanie ofertowe z Wyższego Urzędu Górniczego. W środku niespodzianka: malware! [analiza]

Dwa tygodnie temu (13 grudnia 2022 r.) otrzymaliśmy od Czytelnika kopię pewnego e-maila. Ktoś podający się za przedstawiciela Wyższego Urzędu Górniczego zaprasza do złożenia oferty. W załączeniu jest również szczegółowy opis przedmiotu oraz sposób złożenia oferty – spakowane zapytanie-ofertowe.rar. Urząd dosyła szczegóły spakowane rar-em? Podejrzane…

Sam e-mail wygląda całkiem normalnie, a wysłany został z adresu: zakupy@wug.gov.pl (więcej o tym za chwilę):

Rys.1. Mail zgłoszony przez Czytelnika

Czy doszło do podszycia się pod WUG.GOV.PL, a może do włamania na skrzynkę urzędu? Jedną z popularniejszych metod utrudnienia podszycia się pod nadawców z danej domeny jest mechanizm SPF (ang. Sender Policy Framework), w którym właściciel domeny informuje, skąd mogą pochodzić prawowite maile wysyłane przez skrzynki w tej domenie.

SPF dla domeny WUG.GOV.PL przez wiele lat kończył się ?all (rekord niewpływający na dostarczalność poczty, zgodnie z RFC raczej służący do testów, niż do produkcyjnych implementacji SPF). W dużym uproszczeniu oznacza to, że przynajmniej od połowy 2017 roku do 16 grudnia 2022r. (bo tak daleko sięga historia, do której mamy dostęp), rekordu SPF dla domeny WUG.GOV.PL w zasadzie nie było.

Rys. 2. Historia rekordów TXT (SPF) dla domeny wug.gov.pl

Nagłówek oryginalnej wiadomości wcale nie rozwiewał wątpliwości, czy mail został podrobiony czy nie (nasz Czytelnik zgodził się, aby nie cenzurować nagłówków).

Rys. 3. Nagłówki podejrzanego maila

W załączonym spakowanym archiwum znajdował się załącznik nr 1_formularz ofertowy.vbs, którego złośliwość obecnie potwierdza 20 z 61 silników antywirusowych dostępnych na Virus Totalu. 

13 grudnia, czyli w dniu wysłania złośliwego maila (i przesłania go przez Czytelnika do nas), dane z telemetrii serwisu Virus Total wskazywały, że wszystkie wcześniejsze analizy były wykonywane po przesłaniu pliku przez użytkowników z polskich adresów IP:

Rys. 4. Telemetria skryptu VBS na Virus Total

Analiza VBS

Po wykonaniu skryptu VBS z załącznika przez ofiarę do rejestru dodany zostaje klucz HCKU\Convene\Anseeligere\Overproficient140 z zakodowanym payloadem. W skrypcie umieszczona została także długa komenda Powershell’a, która jest kolejnym stagem malware’u.

Rys. 5. Wyczyszczony skrypt VBS

Drugi stage – skrypt Powershell

Skrypt zawiera kolejny zakodowany payload. Tym razem jednak obecna jest również funkcja dekodująca. Wybierany jest co czwarty znak z szyfrogramu i w ten sposób tworzona jest kolejna komenda Powershell’a, która będzie następnym etapem wykonania analizowanej próbki. W tym przypadku payload wykonywany jest w 32-bitowej wersji Powershell, niezależnie od architektury maszyny ofiary.

Rys. 6. Funkcja dekodująca Fundulinae9

Trzeci stage – Wykonanie shellcode’u

Kolejny skrypt PowerShell jest jeszcze bardziej zaciemniony niż poprzednie. Instrukcje są dekodowane pojedynczo, tuż przed ich wykonaniem. Mamy jednak dostęp do funkcji dekodującej, która opiera się na operacji XOR. 

Rys. 7. Funkcja dekodująca HTB i przykładowe zakodowane stringi

Po przeanalizowaniu drugiego skryptu Powershell doszliśmy do wniosku, że stworzony w pierwszym etapie klucz Overproficient140 był zakodowanym base64 shellcodem. Na tym etapie alokowane są dwa obszary pamięci – jeden mniejszy i drugi większy. Zdekodowany shellcode zostaje podzielony na 352 bajtowy blok i pozostałą część. Obydwa bloki zostaną przekopiowane do stworzonych pod nie stron. Blok I zawiera funkcję dekodującą, która dostaje w parametrach adres bloku II oraz wskaźnik do funkcji NtProtectVirtualMemory, wykorzystywanej do zmiany zabezpieczenia żądanej strony pamięci innego procesu. Ostatnim krokiem będzie wywołanie funkcji z pierwszego bloku, która dekoduje zawartość drugiego bloku, a następnie wykonuje znajdujące się w nim instrukcje. 

Rys. 8. Wyczyszczony fragment skryptu wykonującego shellcode

Shellcode potrafi wykryć, że działa w wirtualnej maszynie lub sandboxie, dlatego łatwiejsze było przeprowadzanie analizy na fizycznym hoście.

Rys. 9. Uruchomienie w maszynie wirtualnej kończy się błędem 

Process hollowing

Dzięki dynamicznej analizie złośliwej próbki możemy odkryć, że malware korzysta z techniki process hollowing. Złośliwy shellcode uruchamia zaufany proces caspol.exe, który jest częścią frameworku .NET. Następnie zostaje on wstrzymany i w tym czasie następuje modyfikacja jego kodu. Gdy zostanie on przywrócony do życia, kod który został wstrzyknięty wykonuje się już w ramach procesu caspol.exe, a nie procesu powershell.exe. Gdy przeanalizujemy pamięć uprowadzonego procesu możemy znaleźć podejrzane strony w sekcji .data z protection ustawionym na read-write-execute. Przykładowo w jednej z takich sekcji możemy znaleźć skrypt PowerShell, który będzie służył do zachowania persystencji.

Rys. 10. Drzewo procesów

Kradzież poświadczeń

Rys. 11. Klucze rejestru, które odczytywał proces caspol.exe

Rys. 12. Pliki które otwierał proces caspol.exe

Komunikacja z autorem (dystrybutorem?) malwaru

Analizując ruch sieciowy na zainfekowanym hoście nie znaleźliśmy tam żadnych prób komunikacji z serwerem autora próbki. Zauważyliśmy, że pobierany był zakodowany plik z Google Drive. Nie stwierdziliśmy zapisu tego pliku na dysku, więc najprawdopodobniej był on przechowywany jedynie w pamięci procesu. Na dzień publikacji artykułu plik pod odnalezionym URL nie jest już dostępny i próbka wydaje się być unieszkodliwiona.

Znajdowany jest także publiczny adres IP zainfekowanej maszyny, przy użyciu usługi api[.]ipify[.]org. Najprawdopodobniej wykradzione poświadczenia są wysyłane za pomocą serwera mailowego SMTP pod adresem mail[.]weseleznatura[.]pl. Serwer ten należy do firmy Kylos Sp. z o. o., a biorąc pod uwagę adres, z którym łączyła się próbka, za pewne autor malware’u pozyskał nieautoryzowany dostęp do konta jednego z klientów Kylos i za jego pomocą wykradzione poświadczenia trafiały na jego skrzynkę mailową. Poinformowaliśmy Kylos o tym, że z serwerem mailowym utrzymywanym na ich zasobach komunikuje się malware dystrybuowany w mailach rzekomo pochodzących od Wyższego Urzędu Górniczego.

Persystencja

Metoda, za pomocą której malware usiłuje przetrwać reboot, nie należy do zbyt wyrafinowanych. W rejestrze zapisywany jest klucz HKCU\SOFTWARE\AppDataLow\commemorative o podobnej zawartości co drugi skrypt Powershell. Następnie dodawana jest zmienna środowiskowa tulio, która przechowuje ścieżkę do 32-bitowego Powershell’a. Ostatnim etapem jest połączenie powyższych i dodanie skryptu z commemorative do autostartu.

HCKU\SOFTWARE\Microsoft\Windows\CurrentVerstion\Run\Startup Key

%tullio% -w 1 $Skrabuds=(Get-ItemProperty -Path 'HKCU:\SOFTWARE\AppDataLow\’).commemorative;%tullio% ($Skrabuds)

Aktualizacja. Otrzymaliśmy odpowiedzi z WUG:

możemy już po przeprowadzonych analizach (współpracowaliśmy w tej sprawie także z ABW i CESIRT GOV) stwierdzić, że ktoś się podszywał pod Wyższy Urząd Górniczy.

Atak był sprytny bo rzeczywiście body maila było prawdziwą wiadomością wysłaną z jednego z naszych adresów, ale z oryginalnego maila usunięto nasze 3 załączniki i zastąpiono je jednym z wirusem, a następnie rozesłano do prawdopodobnie około 3 tysięcy adresów.

Oczywiście nie posiadaliśmy tych kontrahentów w swoich bazach adresowych i fałszywe maile nie zostały wysłane z naszego urzędu, nie przechodziły też przez nasz serwer (braliśmy pod uwagę także włamanie i skompromitowanie adresu i serwera).

Prawdopodobnie źródłem problemu była jedna z firm do której został wysłany nasz oryginalny mail.

~ Jakub Wróbel (analiza), as, ms