RATKing: nowa kampania z trojanami zdalnego dostępu
Pod koniec maja wykryliśmy kampanię mającą na celu dystrybucję trojana zdalnego dostępu (RAT) — programów umożliwiających osobom atakującym zdalną kontrolę nad zainfekowanym systemem.
Badaną przez nas grupę wyróżniało to, że nie wybrała do zakażenia żadnej konkretnej rodziny RAT. W ramach kampanii wykryto kilka trojanów (wszystkie były powszechnie dostępne). Dzięki tej funkcji grupa przypomniała nam króla szczurów – mityczne zwierzę składające się z gryzoni o splecionych ogonach.
Oryginał pochodzi z monografii K. N. Rossikowa „Myszy i gryzonie myszopodobne, najważniejsze ekonomicznie” (1908)
Na cześć tego stworzenia nazwaliśmy grupę, którą rozważamy RATKing. W tym poście szczegółowo omówimy, w jaki sposób napastnicy przeprowadzili atak, jakich narzędzi użyli, a także podzielimy się naszymi przemyśleniami na temat atrybucji tej kampanii.
Postęp ataku
Wszystkie ataki w tej kampanii odbyły się według następującego algorytmu:
Użytkownik otrzymał wiadomość e-mail typu phishing zawierającą link do Dysku Google.
Korzystając z łącza, ofiara pobierała złośliwy skrypt VBS, który określał bibliotekę DLL w celu załadowania ostatecznego ładunku do rejestru systemu Windows i uruchamiał program PowerShell w celu jego wykonania.
Biblioteka DLL wstrzyknęła ostatni ładunek — w rzeczywistości jeden z RAT używanych przez atakujących — do procesu systemowego i zarejestrowała skrypt VBS w trybie automatycznego uruchamiania, aby zdobyć przyczółek na zainfekowanej maszynie.
Ostateczny ładunek został wykonany w procesie systemowym i dał osobie atakującej możliwość kontrolowania zainfekowanego komputera.
Schematycznie można to przedstawić w następujący sposób:
Następnie skupimy się na pierwszych trzech etapach, ponieważ interesuje nas mechanizm dostarczania szkodliwego oprogramowania. Nie będziemy szczegółowo opisywać mechanizmu działania samego szkodliwego oprogramowania. Są one powszechnie dostępne – sprzedawane na specjalistycznych forach lub nawet rozpowszechniane jako projekty open source – i dlatego nie są unikalne dla grupy RATKing.
Analiza etapów ataku
Etap 1. E-mail phishingowy
Atak rozpoczął się od otrzymania przez ofiarę złośliwego listu (napastnicy użyli różnych szablonów tekstu; jeden z przykładów przedstawia zrzut ekranu poniżej). Wiadomość zawierała link do legalnego repozytorium drive.google.com, który rzekomo prowadził do strony pobierania dokumentu PDF.
Przykładowy e-mail phishingowy
Jednak w rzeczywistości nie był to w ogóle załadowany dokument PDF, ale skrypt VBS.
Po kliknięciu linku z wiadomości e-mail na powyższym zrzucie ekranu plik o nazwie Cargo Flight Details.vbs. W tym przypadku napastnicy nawet nie próbowali zamaskować pliku jako legalnego dokumentu.
Jednocześnie w ramach tej kampanii odkryliśmy skrypt o nazwie Cargo Trip Detail.pdf.vbs. Może już uchodzić za legalny plik PDF, ponieważ system Windows domyślnie ukrywa rozszerzenia plików. To prawda, że w tym przypadku podejrzenia nadal mogła budzić jego ikona, która odpowiadała skryptowi VBS.
Na tym etapie ofiara może rozpoznać oszustwo: wystarczy przez chwilę przyjrzeć się pobranym plikom. Jednak w takich kampaniach phishingowych napastnicy często polegają na nieuważnym lub pośpiesznym użytkowniku.
Etap 2. Obsługa skryptu VBS
Skrypt VBS, który użytkownik mógł przypadkowo otworzyć, zarejestrował bibliotekę DLL w rejestrze systemu Windows. Skrypt został zaciemniony: linie w nim zapisane zostały w postaci bajtów oddzielonych dowolnym znakiem.
Przykład zaciemnionego skryptu
Algorytm usuwania zaciemnień jest dość prosty: co trzeci znak został wykluczony z zaciemnionego ciągu, po czym wynik został zdekodowany z base16 do oryginalnego ciągu. Na przykład od wartości 57Q53s63t72s69J70r74e2El53v68m65j6CH6Ct (podświetlony na zrzucie ekranu powyżej) wynikowa linia była WScript.Shell.
Aby rozjaśnić ciągi znaków, użyliśmy funkcji Pythona:
def decode_str(data_enc):
return binascii.unhexlify(''.join([data_enc[i:i+2] for i in range(0, len(data_enc), 3)]))
Poniżej, w liniach 9–10, podkreślamy wartość, której oczyszczenie spowodowało utworzenie pliku DLL. To właśnie on został uruchomiony w kolejnym etapie przy użyciu PowerShella.
Ciąg z zaciemnioną biblioteką DLL
Każda funkcja w skrypcie VBS została wykonana po usunięciu zaciemnienia ciągów znaków.
Po uruchomieniu skryptu wywołano funkcję wscript.sleep — został wykorzystany do wykonania odroczonego wykonania.
Następnie skrypt współpracował z rejestrem systemu Windows. Wykorzystał do tego technologię WMI. Za jego pomocą stworzono unikalny klucz, a do jego parametru zapisano treść pliku wykonywalnego. Dostęp do rejestru uzyskano poprzez WMI za pomocą następującego polecenia:
Na trzecim etapie złośliwa biblioteka DLL ładowała ostateczny ładunek, wstrzykiwała go do procesu systemowego i zapewniała automatyczne uruchomienie skryptu VBS po zalogowaniu się użytkownika.
Uruchom przez PowerShell
Biblioteka DLL została wykonana przy użyciu następującego polecenia w PowerShell:
otrzymał dane wartości rejestru z nazwą rnd_value_name — dane te były plikiem DLL napisanym na platformie .Net;
załadował powstały moduł .Net do pamięci procesu powershell.exe za pomocą funkcji [System.Threading.Thread]::GetDomain().Load()(szczegółowy opis funkcji Load(). dostępne na stronie internetowej Microsoftu);
pełnił funkcję GUyyvmzVhebFCw]::EhwwK() - od niej rozpoczęło się wykonanie biblioteki DLL - od parametrów vbsScriptPath, xorKey, vbsScriptName. Parametr xorKey przechowywał klucz do odszyfrowania końcowego ładunku i parametry vbsScriptPath и vbsScriptName zostały przesłane w celu zarejestrowania skryptu VBS w autorun.
Opis biblioteki DLL
W zdekompilowanej formie bootloader wyglądał następująco:
Loader w formie zdekompilowanej (na czerwono podkreślono funkcję, od której rozpoczęło się wykonywanie biblioteki DLL)
Bootloader jest chroniony przez zabezpieczenie .Net Reactor. Narzędzie de4dot doskonale radzi sobie z usuwaniem tego zabezpieczenia.
Ten moduł ładujący:
wstrzyknął ładunek do procesu systemowego (w tym przykładzie jest to svchost.exe);
Dodałem skrypt VBS do autorun.
Wstrzyknięcie ładunku
Przyjrzyjmy się funkcji wywoływanej przez skrypt PowerShell.
Funkcja wywoływana przez skrypt PowerShell
Funkcja ta wykonywała następujące czynności:
odszyfrowano dwa zestawy danych (array и array2 na zrzucie ekranu). Oryginalnie zostały skompresowane za pomocą programu gzip i zaszyfrowane algorytmem XOR z kluczem xorKey;
skopiowane dane do przydzielonych obszarów pamięci. Dane z array - do wskazanego obszaru pamięci intPtr (payload pointer na zrzucie ekranu); dane z array2 - do wskazanego obszaru pamięci intPtr2 (shellcode pointer na zrzucie ekranu);
nazywaną funkcją CallWindowProcA(описание Ta funkcja jest dostępna na stronie internetowej Microsoft) z następującymi parametrami (nazwy parametrów podano poniżej, na zrzucie ekranu są one w tej samej kolejności, ale z wartościami roboczymi):
lpPrevWndFunc - wskaźnik do danych z array2;
hWnd — wskaźnik do ciągu znaków zawierającego ścieżkę do pliku wykonywalnego svchost.exe;
Msg - wskaźnik do danych z array;
wParam, lParam — parametry wiadomości (w tym przypadku parametry te nie zostały wykorzystane i miały wartość 0);
utworzył plik %AppData%MicrosoftWindowsStart MenuProgramsStartup<name>.urlGdzie <name> - są to pierwsze 4 znaki parametru vbsScriptName (na zrzucie ekranu fragment kodu z tą akcją zaczyna się od polecenia File.Copy). W ten sposób szkodliwe oprogramowanie dodało plik URL do listy plików automatycznie uruchamianych, gdy użytkownik się zalogował, i w ten sposób przyłączyło się do zainfekowanego komputera. Plik URL zawierał łącze do skryptu:
Aby zrozumieć, w jaki sposób przeprowadzono wstrzyknięcie, odszyfrowaliśmy tablice danych array и array2. W tym celu użyliśmy następującej funkcji Pythona:
def decrypt(data, key):
return gzip.decompress(
bytearray([data[i] ^ key[i % len(key)] for i in range(len(data))])[4:])
W rezultacie dowiedzieliśmy się, że:
array był plikiem PE – to jest ostateczny ładunek;
array2 był kod powłoki wymagany do przeprowadzenia zastrzyku.
Shellcode z tablicy array2 przekazywana jako wartość funkcji lpPrevWndFunc w funkcję CallWindowProcA. lpPrevWndFunc — funkcja wywołania zwrotnego, jej prototyp wygląda następująco:
Więc kiedy uruchomisz funkcję CallWindowProcA z parametrami hWnd, Msg, wParam, lParam wykonywany jest kod powłoki z tablicy array2 z argumentami hWnd и Msg. hWnd jest wskaźnikiem do ciągu znaków zawierającego ścieżkę do pliku wykonywalnego svchost.exeI Msg — wskaźnik do końcowego ładunku.
Kod powłoki, z którego otrzymano adresy funkcji kernel32.dll и ntdll32.dll na podstawie wartości skrótu z ich nazw i wstrzyknął końcowy ładunek do pamięci procesu svchost.exewykorzystując technikę Process Hollowing (więcej na ten temat przeczytasz w tym Artykuł). Podczas wstrzykiwania kodu powłoki:
stworzył proces svchost.exe w stanie zawieszenia za pomocą tej funkcji CreateProcessW;
następnie ukrył wyświetlanie sekcji w przestrzeni adresowej procesu svchost.exe za pomocą funkcji NtUnmapViewOfSection. W ten sposób program zwolnił pamięć oryginalnego procesu svchost.exeaby następnie przydzielić pamięć dla ładunku pod tym adresem;
przydzielona pamięć dla ładunku w przestrzeni adresowej procesu svchost.exe za pomocą funkcji VirtualAllocEx;
Rozpoczęcie procesu wtrysku
zapisał zawartość ładunku w przestrzeni adresowej procesu svchost.exe za pomocą funkcji WriteProcessMemory (jak na zrzucie ekranu poniżej);
wznowił proces svchost.exe za pomocą funkcji ResumeThread.
Zakończenie procesu wtrysku
Do pobrania złośliwe oprogramowanie
W wyniku opisanych działań na zainfekowanym systemie został zainstalowany jeden z kilku szkodliwych programów klasy RAT. W poniższej tabeli wymieniono złośliwe oprogramowanie użyte w ataku, które możemy z całą pewnością przypisać jednej grupie napastników, ponieważ próbki uzyskały dostęp do tego samego serwera dowodzenia i kontroli.
Przykłady rozproszonego złośliwego oprogramowania z tym samym serwerem kontrolnym
Godne uwagi są tutaj dwie rzeczy.
Po pierwsze, sam fakt, że napastnicy korzystali z kilku różnych rodzin RAT jednocześnie. Takie zachowanie nie jest typowe dla znanych grup cybernetycznych, które często korzystają z mniej więcej tego samego zestawu narzędzi, które są im znane.
Po drugie, RATKing wykorzystywał złośliwe oprogramowanie, które albo jest sprzedawane na specjalistycznych forach za niską cenę, albo jest nawet projektem typu open source.
Pełniejsza lista złośliwego oprogramowania użytego w kampanii – z jednym ważnym zastrzeżeniem – znajduje się na końcu artykułu.
O grupie
Nie możemy przypisać opisanej złośliwej kampanii żadnemu znanemu napastnikowi. Na razie uważamy, że ataki te przeprowadziła całkowicie nowa grupa. Jak pisaliśmy na początku, nazwaliśmy to RATKingiem.
Do stworzenia skryptu VBS grupa prawdopodobnie użyła narzędzia podobnego do tego narzędzia Krypter VBS od dewelopera NYAN-x-CAT. Wskazuje na to podobieństwo skryptu tworzonego przez ten program do skryptu atakującego. Konkretnie obaj:
wykonaj opóźnione wykonanie za pomocą funkcji Sleep;
użyj WMI;
zarejestruj treść pliku wykonywalnego jako parametr klucza rejestru;
wykonaj ten plik przy użyciu programu PowerShell we własnej przestrzeni adresowej.
Dla jasności porównaj polecenie PowerShell do uruchomienia pliku z rejestru, którego używa skrypt utworzony za pomocą VBS-Crypter:
Należy pamiętać, że napastnicy wykorzystali inne narzędzie firmy NYAN-x-CAT jako jeden z ładunków - LimonkowyRAT.
Adresy serwerów C&C wskazują na kolejną charakterystyczną cechę RATKing: grupa preferuje usługi dynamicznego DNS (patrz lista C&C w tabeli IoC).
MKOl
Poniższa tabela zawiera pełną listę skryptów VBS, które najprawdopodobniej można przypisać do opisywanej kampanii. Wszystkie te skrypty są podobne i wykonują w przybliżeniu tę samą sekwencję działań. Wszystkie wprowadzają złośliwe oprogramowanie klasy RAT do zaufanego procesu systemu Windows. Wszystkie mają adresy C&C zarejestrowane przy użyciu usług Dynamic DNS.
Nie możemy jednak twierdzić, że wszystkie te skrypty były dystrybuowane przez tych samych napastników, z wyjątkiem próbek o tych samych adresach C&C (na przykład kimjoy007.dyndns.org).