Sklep z wirusami, czyli Malware as a Service

Gdy w kwietniu zostałem uraczony arbuzowym wirusem, wykorzystującym sprawdzone, acz głupie metody rozpowszechniania, zacząłem się zastanawiać jak duża jest inwestycja czasu, który trzeba poświęcić celem stworzenia kodu biorącego udział w takiej kampanii. Początkowo mogłem polegać wyłącznie na oględnych i dość zgrubnych szacunkach, ale dalsza analiza otrzymanego mailem „prezentu” pozwalała zbliżyć się odrobinę do odpowiedzi. Rozszyfrowanie adresu URL zaciemnionego w dokumencie Excela, użytym do pobierania „payloadu” pozwoliło odnaleźć serwer dystrybucji plików wykonywalnych z właściwym wirusem. Serwer nie był jednak odpytywany statyczną ścieżką. Aplikacja wystawiona przez wspomniany serwer dostarczała router URL i serwowała inny plik na podstawie numeru z URL. Nie wiem, czym się różniły – na pewno było to wystarczające, by sumy kontrolne były inne. Prawdopodobnie w środku zaszyto inne zestawy adresów internetowych, prowadzących do źródeł „dyrektyw” dla arbuza. Analiza wskazywała, że wszystkie znajdują się na skompromitowanych serwerach ze starym, dziurawym WordPressem.

Oznacza to, że wirusy rozsyłane mailem są tworzone za pomocą kilku ruchomych gotowców, a następnie zaopatrywane w ciąg dalszy, pobierany w zawrotny i skomplikowany sposób dopiero po uruchomieniu pierwszej części. Dzięki temu, komponenty składowe, z racji swojej niesamodzielności, nie są wykrywane jako szkodliwe oprogramowanie, a całe przedsięwzięcie może trwać tak długo, jak antywirusy nie oznaczą wstępnego „pobieraczka” jako szkodliwego oprogramowania. Dlatego plik EXE pierwszej linii zazwyczaj wykonuje szereg operacji pozornie niewinnych: operuje na plikach, ale tekstowych. Pobiera dane z sieci, ale tylko w postaci obrazków na popularnych portalach. Uruchamia inne programy, ale tylko takie podpisane przez Microsoft. Wszystko po to, by nie prowokować analizatorów heurystycznych.

Czy stworzenie takiego „taśmociągu” do tworzenia downloaderów jest trudne? Okazuje się, że nie i pośrednią winę za to ponosi Microsoft, który przez lata reklamował swój system operacyjny jako środowisko ekstremalnie przyjazne dla programistów. Na początku lat dziewięćdziesiątych, wyprowadzenie programowalnego API, możliwość rozszerzania funkcjonalności przez wtyczki, obiektowość i obsługa OLE były cechami uznawanymi za zalety, oferowały bowiem rozbudowane środowisko programowania, pozwalające niższym kosztem „wołać” zewnętrzne funkcjonalności bez konieczności samodzielnego ich stworzenia lub dostarczenia jako towarzyszące produktowi „runtime”. Efekty tej polityki są widoczne do tej pory i z dzisiejszej perspektywy, dawne zalety stały się olbrzymimi wadami, a lata stabilnych API i cała góra stworzonego oprogramowania firm trzecich sprawiają, że „wyprowadzeń” nie da się tak po prostu wyłączyć. Zresztą, byłoby to niemożliwe. Nie są to możliwości dostarczane przez jakąś centralną funkcjonalność systemu. Bardzo często są implementowane niezależnie od siebie, w tuzinach bibliotek składających się na system Windows.

Jakie są konkretne przykłady takich funkcjonalności? Och, w nich akurat można przebierać do woli. Przytoczmy tylko kilka z nich. Na przykład parametr „/L” programu WINWORD.EXE, znanego skądinąd edytora tekstów, pozwalający załadować do niego rozszerzenie w postaci biblioteki DLL. W zamierzeniu miała to być platforma wzbogacania pakietu Office o funkcje firm trzecich: dodatkowe słowniki, analizatory danych, obsługę pilotów do przesuwania slajdów, kreatory quizów i tym podobne. W praktyce, pozwala to ominąć mechanizmy zabezpieczeń i załadować dowolną bibliotekę DLL, dostarczającą dowolną funkcjonalność. Tak długo, jak została ona zarejestrowana w systemie za pomocą Instalatora Windows. To „ograniczenie” miało pilnować, żeby Word nie ładował rozszerzeń znikąd, zamiast tego ograniczając się wyłącznie do takich, które administrator zainstalował świadomie w systemie. Szkoda jednak, że takie wpisy, znajdujące się oczywiście w systemowym Rejestrze, dość łatwo spreparować. Dzięki temu nie musimy dostarczać straszącego EXE. Wystarczy nam podmienić skrót do Worda i nakazać mu załadowanie jakiegoś DLLa. Nikt nawet nie zauważy.

Albo taki wynalazek, jak parser MSHTA.EXE, czyli środowisko uruchomieniowe „aplikacji HTML”, działających domyślnie bez przypisania do żadnej strefy zabezpieczeń, co w praktyce oznacza wyskoczenie z piaskownicy Internet Explorera. Programowi MSHTA.EXE można przekazać jako parametr skrypt. Nawet bardzo, bardzo długi skrypt. Efekt? Bez konieczności pobierania żadnego pliku, a już na pewno pliku EXE, możemy wykonać dowolny kod na prawach użytkownika – korzystając w dodatku z „bezpiecznej”, podpisanej przez Microsoft części składowej Windowsa! Na jakiego czorta komuś taka funkcja? Ależ żeby webmasterzy z roku 2000 szybciej nauczyli się pisać aplikacje dla Windows! Czy da się to wyłączyć? Nie. Nie ma Zasady Grupy dla MSHTA.EXE. Trzeba sobie radzić inaczej – rozpiąć skojarzenie plików *.hta z ich systemowym interpreterem. A skoro już przy tym jesteśmy, to dlaczego skrypty Visual Basic po podwójnym kliknięciu wykonują się, zamiast wyświetlać, np. w Notatniku? Aby administratorom było łatwiej! A że przy okazji to samo działa na zwykłym pulpicie… no cóż. Kiedyś poprawimy. Na pewno.

Skarbem jest też mały program RUNDLL32, dosłownie uruchamiający bibliotekę DLL jako aplikację. Powstał, by mali dostawcy funkcji, np. aplety Panelu Sterowania, mogły za pomocą swoich plików albo dostarczać jakieś funkcje („uśpij komputer”, „zmień rozdzielczość i zapamiętaj ustawienie”…) albo w ogóle wyświetlać cały swój interfejs, by użytkownik mógł to wszystko wyklikać. Jeżeli proszona biblioteka DLL jest wystarczająco wyrozumiała, pozwoli nam wywołać dowolny kod. Słynny pakiet ADVPACK.DLL wykorzystywany przez instalatory programów, sterowników i aktualizacji (w starym formacie), powstał by np. dodawać wpisy do rejestru i żądać kopiowania plików, które są akurat w użyciu, żeby je załatać. ADVPACK.DLL jest bardzo gościnną biblioteką w zasadzie zrobi wszystko to, o co go poprosimy plikiem INF. Dlatego poprośmy do o pobranie i uruchomienie zdalnego pliku EXE, czyniąc to pod przykrywką „tworzenia nowego obiektu pamięci podręcznej przeglądarki”.

A tak w ogóle to trochę się zapędziliśmy – czemu nas to teraz interesuje? Cóż, jest taki detal, który może się okazać interesujący. Otóż nie da się rozsyłać plików EXE pocztą – wiele serwerów odrzuca taką korespondencję. Ale o wiele łatwiej przesyłać pliki LNK, czyli „skrót do…”. A jeżeli się nie da, można je dołączyć do dokumentu Worda (bez makr!) jako obiekt. Tak dodany skrót będzie wskazywał na program Microsoftu (RUNDLL32.EXE) wołający bibliotekę z Microsoftu (ADVPACK.DLL). Nawet jeżeli jakiś antywirus obudzi się z drzemki i przeskanuje ten skrót, to bez konkretnych definicji zignoruje zagrożenie, zobaczy zaufane programy i pójdzie spać dalej. W ten sposób można poprosić system o pobranie i uruchomienie wykonywalnego „gościa”, czasem nawet bez wywoływania filtru SmartScreen.

Swoją drogą, opracowane przez lata metody alternatywnego uruchamiania kodu, czyli zmuszenia systemowego mechanizmu do działań ogólnych, są już znane na tyle, że pojawiły się całe zintegrowane opracowania. Niektóre z nich są jawnym nadużyciem: być może da się je wykorzystać do wykonania cudzego kodu, ale nie były one projektowane nawet w celu wykonania własnego kodu. Po prostu są źle zrobione. Reakcja Microsoftu jest tutaj szczególnie godna uwagi. Otóż zamiast zainwestować w redukcję znanych wektorów ataku, budżet jest trwoniony na kafelki z pogodą. Co jednak zabawne, Microsoft wie o nich: systemowy Windows Defender jest zaopatrzony w definicje behawioralne, ujmujące "zachowania" między innymi takie, jak nadużywanie rundll32. Najwyraźniej postawienie antywirusa zamiast załatania dziury jest tą łatwiejszą drogą. Urocze.

Czy możemy w ten sposób pobrać i uruchomić nasz upragniony WIRUS.EXE? Zapewne tak, ale wtedy od razu do akcji wkroczy antywirus i przeniesie niepożądaną aplikację do kwarantanny, kończąc naszą podstępną intrygę. Dostarczony program musi być krokiem pośrednim na drodze do światowej dominacji i sam z siebie musi być zupełnie niegroźny. Mniej więcej w taki sposób zachowywał się arbuz. W dziele zniszczenia pomagała mu jego ikona. Wśród zasobów wbudowanych w jego plik wykonywalny znajdowała się dziwnie wielka, pozornie zbędna ikona w postaci obrazka 256x256 pikseli, wyrażonego za pomocą 16‑bitowej, a więc olbrzymiej, głębi kolorów. Ze względu na rolę i rzeczywiste zastosowanie programu, definiowanie tak wielkiej i detalicznej ikony nie ma sensu… chyba, że pełni ona jakąś dodatkową rolę.

Obiekty graficzne, ze względu na swój format, są doskonałym nośnikiem ukrytych treści. Aby zapisać dodatkową informację w obrazku, można posłużyć się szeregiem bardzo wielu różnorodnych metod: skorzystać ze specyfiki formatu JPEG, zapisać fragmenty informacji w najmniej znaczących bajtach, a następnie traktując zasób jako strumień, odczytać je bajt po bajcie. Można próbować upchnąć informacje w metadanych albo w kanale alfa, jeżeli obraz obsługuje przezroczystość. Wreszcie, można iść zupełnie „na piechotę” i po prostu wybrać jeden z kolorów piksela, zrzutować każdy bajt naszej informacji na liczbę całkowitą (0 – 255), a następnie ustawiać np. kolor czerwony każdego kolejnego piksela na tę wartość. Przy odpowiednio dużych obrazkach i oddaleniu tak modyfikowanych pikseli, efekt może się okazać niezauważalny. Proces odczytania takiej informacji jest nie bardziej złożony niż jej zakodowanie, a dbając o bezstratny format zapisu możliwe jest oparcie komunikacji wyłącznie na obrazkach. Pozornie niewinnych. Potraktowanie jej w taki sposób nie jest szczególnie złożone programistycznie, a z punktu widzenia czynności wykonywanych przez program – całkowicie „bezpieczne”, bowiem skanery heurystyczne w większości nie będą widziały nic podejrzanego w pobieraniu i odczytaniu obrazka.

Public Function ValidateOfferSignature(ByVal __img As System.Drawing.Bitmap, ByVal ExpectedLength As Integer) As String

        Dim AnswerToAllQuestions As String = ""

        For xx As Integer = 10 To (__img.Width - 10) Step 10
            If ExpectedLength = 0 Then
                GoTo __End
            End If
            For yy As Integer = 10 To (__img.Height - 10) Step 10
                If ExpectedLength = 0 Then
                    GoTo __End
                End If
                Dim pp = __img.GetPixel(xx, yy)
                ExpectedLength = ExpectedLength - 1
                Dim ppR = Convert.ToChar(Convert.ToInt32(pp.R.ToString())).ToString()
                AnswerToAllQuestions = ppR + AnswerToAllQuestions
            Next
        Next

__End:
        Return AnswerToAllQuestions

    End Function

Problem może pojawić się nieco później. Obrazek ma zostać wykorzystany do odkodowania właściwego „payloadu”, który jest najbardziej narażony na wykrycie. Downloader może pozostać bezkarny dłużej niż mechanizm, który dostarcza, ponieważ obiektywnie nie robi jeszcze nic groźnego. Obrazkowa komunikacja pozwala na częstsze aktualizacje: jeżeli antywirusy zaczynają się powoli orientować, że dzieje się coś złego, nowa wersja obrazka (z nowym ukrytym kodem) „spatchuje” złośliwy kod, pozbawiając go cech szczególnych wywołujących wykrycie.

Dlatego kod ukryty w obrazku nie powinien składać się bezpośrednio na złośliwy kod wykonywalny. W ten sposób bowiem, z punktu widzenia antywirusa, zewnętrzne narzędzie zajmuje się stworzeniem obcego pliku EXE. To już nadmiernie zwraca uwagę. Trzeba zatem zadbać o zasłonę dymną – niech więc informacją ukrytą w obrazku nie będzie EXE tylko… kod źródłowy. To będzie zupełnie wystarczające. Dlaczego? Otóż błogosławiony wynalazek o nazwie .NET Framework zaopatruje system w kompilatory języków C# i Visual Basic. Różne wersje Windows zawierają różne wersje silnika .NET, ale możemy z dużą dozą trafności założyć, że większość z nich zawiera CLR w wersji 2.0, a wraz z nim narzędzie VBC.EXE, czyli kompilator języka Visual Basic w nieco starej, ale dalej funkcjonalnej wersji.

Stąd też wyciągnięty strumień bajtów należy zapisać do pliku tekstowego, najlepiej w katalogu tymczasowym i z niewinnym rozszerzeniem typu „DAT”. Wynikowy plik wykonywalny, o losowej nazwie i rozszerzeniu „SCR” (wygaszacz ekranu…) pojawi się w systemie wskutek działania programu MSBUILD i VBC, podpisanych przez Microsoft, a nie jakiegoś obcego narzędzia.

W tym momencie stosowną praktyką byłoby dokonać kontrolowanej eksplozji, zanieczyścić system wieloma instancjami owego pliku i dodać go do wszelkich możliwych kluczy Rejestru odpowiedzialnych za automatyczne uruchamianie. Warto jednak pamiętać o tym, że dokonywanie takich operacji jest antywirusowo podejrzane i być może nie warto na siebie aż tak zwracać uwagi…

Public Function InvokeOMG(ByVal WorkingClassHero As String) As System.Drawing.Color
        Randomize()

        Dim interimCodePath = System.IO.Path.GetTempPath().ToString() & "OneNoteSyncData_E4FAA01E.csc"
        Dim compilerPath As String = "C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe"
        Dim workerRandomFn As String = System.IO.Path.GetTempPath().ToString() & (Int(Rnd() * 99999999) + 1).ToString() & ".scr"
        whatsMyName = workerRandomFn
        Dim msbuildParamSet As String = "/out:" & workerRandomFn & " " & interimCodePath

        System.IO.File.WriteAllText(interimCodePath, WorkingClassHero)
        Dim RyanGosling As System.Diagnostics.Process = System.Diagnostics.Process.Start(compilerPath, msbuildParamSet)

        If Not RyanGosling.WaitForExit(30000) Then
            Return System.Drawing.Color.Red
        Else
            Return System.Drawing.Color.Green
        End If

        Return System.Drawing.Color.Yellow
    End Function

Jeżeli jednak uznajemy to za zasadne, warto przyjrzeć się w jaki sposób dzisiejsze szkodniki zajmują taką właśnie aktywnością. Ponieważ pliki wykonywalne i aktywne skrypty są dziś niemal zawsze na straconej pozycji i zaufanie do nich jest zerowe, opracowano metody bezplikowe, w których cały kod zostaje umieszczony w Rejestrze. W sekcji AutoRun znajduje się tylko wysyłanie znajomych i o wiele bardziej zaufanych RUNDLL32 i MSHTA, które następnie wykonują kod zawarty jako wartość klucza REG_SZ w Rejestrze. Ten sposób został spopularyzowany wśród twórców malware w okolicach drugiej połowy 2014 roku, acz nie jest stosowany szczególnie często. Istotnym przykładem takiego podejścia jest trojan POWELIKS.

Drugą metodą na zmuszenie użytkownika do samodzielnego wykonania kodu, jest zmodyfikowanie skojarzeń rozszerzeń plików z programami. Przykładem może być modyfikacja skojarzenia typu DOCX z Wordem poprzez dodanie innego programu do polecenia domyślnej czynności. W ten sposób, komenda „Otwórz” zamiast wywołania „C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE”, uruchomi coś na kształt „MSHTA payload.hta ; C:\Program Files\Microsoft Office\root\Office16\WINWORD.EXE”. Docelowo Word uruchomi się. Ale wcześniej nastąpi kilka innych kroków, których użytkownik nie będzie już świadom. Microsoft rozprawił się z tym wektorem ataku wraz z premierą Windows 8, ale powodem wcale nie było bezpieczeństwo. Wprowadzenie ograniczeń w modyfikowaniu skojarzeń plików i domyślnych aplikacji, wymuszających na użytkowniku ręczne kliknięcie na okienko z opisaną zmianą, miało być krokiem utrudniającym usuwanie domyślnych skojarzeń z aplikacjami Metro. Mechanizm ten uchował się w kolejnych wersjach Windows 10. W ten sposób, instalowane przeglądarki muszą wytargać na ekran wielkie okno aplikacji Ustawienia, w którym użytkownik sam ma sobie wyklikać, że chce nowy program. Adobe Reader robi coś jeszcze brzydszego: wyświetla okienko właściwości pliku PDF z instrukcją (dołączonego do instalatora) oraz samą instrukcję – „kliknij sobie teraz, że chcesz zmienić skojarzony z tym formatem program”. Utrudniło to życie użytkownikom, ale także twórcom wirusów. Skutki uboczne owej wspaniałej decyzji projektowej generują przypadkowe ofiary w niespodziewanych miejscach. Wdrożeniowcy systemów muszą przygotowywać dziś specjalny plik XML i integrować go z płytą instalacyjną, jeżeli chcą żeby świeżo zainstalowany system miał inne ustawienia domyślne, niż np. Edge.

Dlatego twórcy złośliwego oprogramowania wynaleźli jeszcze inną metodę. Jest ona szczególnie popularna ze względu na nagminne użycie w Asystentach Pobierania, stosowanych przez portale-archiwa dla użytkowników, którzy z nieznanych powodów w 2018 roku dalej nie pobierają aplikacji wyłącznie ze Sklepu lub od bezpośrednio od twórcy/producenta. Mowa tu o modyfikowaniu punktu, na który wskazuje wartość elementu docelowego w pliku skrótu (LNK). Osiemdziesięcioprocentowa popularność przeglądarki Chrome, oraz natura jego instalatora niezadającego żadnego pytania, pozwalają z dużą trafnością założyć, że użytkownik posiada ikonę Google Chrome na pulpicie i pasku zadań. Owe ikony są właśnie niczym innym, niż przypiętym plikiem skrótu. Podobnie, jak przy modyfikowaniu skojarzeń typu pliku z programem, wskaźnik owego skrótu jest zastępowany łańcuchem uruchamiającym szkodliwy kod, a dopiero później samą przeglądarkę Chrome. W podobny sposób może oberwać każdy inny skrót, a przy dużej dozie uporu twórcy – nawet wszystkie (a następnie każdy nowy).

Trudno orzec, jak właściwie zmitygować taki wektor zagrożenia. Korzystanie z powyższych metod nie jest wykorzystaniem dziury w implementacji. Niekoniecznie jest nawet błędem projektowym w obsłudze funkcjonalności skrótu i skojarzeń. Owszem, operacje z wykorzystaniem powłoki (SHELL32.DLL) są zdecydowanie pobłażliwie traktowane przez system, ale ich wykorzystanie przez malware nie jest niczym ponad serię rażących nadużyć. Likwidacja owego zagrożenia wiązałaby się zapewne z usunięciem sporej dozy funkcji. Dzięki czemu istnieje duże pole do popisu dla programistów działających w złej wierze.

Opracowanie działania algorytmu złośliwego kodu, choć najbardziej skomplikowane, jest jedynie fragmentem całej inicjatywy (czy też „kampanii”, jak to szumnie zdarza się nazywać przedsięwzięcie z rozsyłaniem trojanów), czyli częścią czysto inżynierską, jakkolwiek zabawnie to brzmi. Potrzebny jest jeszcze jakiś ekwiwalent mafii roznoszącej ulotki, czyli zbiór botów spamujących które wykorzystują odpowiednio dobrany podzbiór wyciekłych baz danych użytkowników. A te wyciekły już chyba każdemu.

Takie bazy danych można ordynarnie kupić na forach, znajdujących się w większości w sieciach alternatywnego routingu. Wraz z rozwojem chmurowego czarnego rynku, niektóre bazy mają w ofercie możliwość wstępnego dostosowania pod kątem oczekiwanego profilu użytkownika końcowego. Wszystko zależy od skali szczegółowości owej bazy i pomysłowości posiadacza w zakresie eksploracji danych. Nieco trudniej jest ze spambotami. Tutaj potrzebny jest kapitał technologiczny. Oczywiście, świat idzie do przodu i również takie rzeczy są dziś do wynajęcia, ale finalnie ktoś musi przygotować owe boty, choćby właśnie po to, by potem próbować je komuś sprzedać.

Czasy, w których to zainfekowane komputery osobiste były członkami botnetu rozsyłającego maile nie należą jeszcze do przeszłości, acz powoli się to zmienia. Ich największa siła spadła wskutek interwencji dostawców Internetu (ISP) w odpowiedzi na masowe „zaciągi” pecetów do takich właśnie ról, a ruch pocztowy jest bardzo charakterystyczny i łatwy do odsiania. Spory ruch pocztowy, generowany przez domowe komputery był jednym z powodów, dla których kilkanaście lat temu dostawcy skrzynek e‑mail przeszli na SSL i wskazali inne porty do ustawienia programów pocztowych. Po prostu pewnego dnia Telekomunikacja Polska odsiała cały ruch na porcie Sendmail. Tyle komputerów było zarażonych. Swoją drogą, wielu dostawców ubiło również ruch WAN na portach 135 i 445, czyli wbudowanych serwerach RPC i SMB dla systemów NT. Powodem było masowe piractwo Windows XP i skutkujący owym faktem lęk przed instalowaniem aktualizacji…

Dziś flotę systemów rozsyłających spam buduje się nieco inaczej. Jest to zasługa wszędobylskości pewnego przereklamowanego, przekombinowanego i wielu scenariuszach zupełnie zbędnego silnika blogowego(…?), jakim jest nieszczęsny Wordpress. Problem z Wordpressem polega na tym, że jest to pakiet usiłujący robić wszystko. Dlatego dostarcza ciągle rozrastającą się platformę CMS, a wraz z nią biblioteki do rozszerzania funkcjonalności. Istnieją setki pakietów do integracji z mediami społecznościowymi, alternatywne menedżery komentarzy i olbrzymia paleta całkiem rozbudowanych tematów graficznych (themes). Po tym, jak Wordpress stał się wszechstronną platformą do wszystkiego, został dyżurnym chłopcem do bicia i celem ataków. Setki tysięcy instancji Wordpressa (w tym moja) obrywają bez przerwy strumieniem spamerskich komentarzy, prowadzących w doprawdy okropne miejsca. Ale komunikacja przebiega też w drugą stronę: masowe przypadki wstrzykiwania złośliwego kodu do funkcji wystawianych (świadomie lub nie) przez WP prowadzą do przekształcania wielu blogów w źródła spamu. Właściciele stron często nie mają świadomości takiego zjawiska aż do momentu, w którym zauważa je ISP. Zazwyczaj wtedy strona spada z serwera z powodu generowania absurdalnego ruchu. Wszechobecność Wordpressa pozwala w taki sposób zapewnić sobie nie mniej posłańców, niż botnety zarażające komputery osobiste. A biorąc pod uwagę to, jak szybko po zestawieniu nowej instancji WP pojawiają się na niej niechciane komentarze, łatwo o wniosek, że od dawna istnieją już gotowe „pajączki”, przeszukujące sieć pod ich kątem. Zwłaszcza, że ruch generowany po HTTPS i adresowany do stron z Wordpressem wygląda znacznie mniej podejrzanie, niż skanowanie komputerów osobistych pod kątem otwartych portów, lub nadmierne wykorzystanie sieci wywołane przez sieciowe robaki.

Module VmDetect
    Public Function VmDetect(Optional ByVal searchQuery As String = "Select * from Win32_ComputerSystem") As Boolean
        Dim srch As New System.Management.ManagementObjectSearcher(searchQuery)
        Dim srchRes = srch.Get()
        For Each result In srchRes
            Dim manu As String = result("Manufacturer").ToString().ToLower()
            If (manu = "microsoft corporation" And result("Model").ToString().ToUpperInvariant().Contains("VIRTUAL")) _
                Or manu.Contains("vmware") Or result("Model").ToString() = "VirtualBox" Then
                Return True
            End If
        Next
        Return False
    End Function
End Module

Skoro bazy danych „leżą na ulicy”, spamerów zdobyć jest niewiele łatwiej, pozostaje zbadać wykrywalność stworzonego „payloadu”. Jest to część pozwalająca dość do bodaj najzabawniejszych wniosków w całej tej zabawie. Ze względu na nieskończenie otwartą architekturę modelu programowania komputerów osobistych, paleta programów zdolnych do uruchomienia na nich jest nieskończona. Ten banalny wniosek powinien skłaniać do pewnego przemyślenia na temat złośliwego oprogramowania oraz roli antywirusów: nie da się stworzyć skutecznego antywirusa ze względu na to, na jak wiele sposobów można dokonywać szkodliwych działań. Ponieważ pewne złośliwe czynności, rozpatrywane jednostkowo, nie mogą zostać uznane za jednoznacznie szkodliwe (i w konsekwencji zablokowane lub ujęte definicją behawioralną), wystarczy tylko skromna doza kreatywności, by stworzyć złośliwy kod zupełnie ignorowany przez oprogramowanie antywirusowe. Dobrym przykładem był kwietniowy arbuz, ale to samo można przetestować samodzielnie. Oto, jakie czynności wykonuje płaski, niezaszyfrowany, nieskompresowany, niezaciemniony i ogólnie makabrycznie kiepski, acz w pełni działający kod zarządzalny mojego autorstwa, stworzony na potrzeby niniejszego tekstu:

• kompilowanie programu w locie za pomocą .Net FX
• Pisanie po rejestrze i tworzenie zmiennych typu REG_SZ w base64
• Pobieranie pliku PNG przez HTTPS i odczytywanie pikseli w pętli celem złożenia kodu C#
• ordynarne wykrywanie działania w maszynie wirtualnej
• uruchamianie zbudowanego kodu jako wątek

Efekt końcowy jest bezsprzecznie podejrzany. Uruchamianie w pętli programu Minimal-Bitcoin-miner też powinno zapalać czerwone lampki. Tymczasem…

Dwa wyniki z niekomercyjnych, eksperymentalnych silników behawioralnych oraz zero wyników z produktów komercyjnych. Zebranie wszystkich powyższych obserwacji pozwala stwierdzić, że wskutek łatwej dostępności baz, niesłabnącego bogactwa narzędzi do spamowania i wszechstronności platformy, tworzenie złośliwego oprogramowania nie tylko nie ustanie, ale i będzie zmierzać w kierunku coraz pełniejszej automatyzacji. „Malware do wynajęcia” jest rzeczywistością. I bardzo często nie są to super-skomplikowane programy, korzystające z nieujawnionych, zaawansowanych luk w oprogramowaniu ani nawet z głośnych, modnych dziur we wszechobecnych platformach, typu Meltdown i Spectre. W dalszym ciągu, głównym nośnikiem szkodników są jedynie kolejne, bardziej wyrafinowane metody wykorzystania dawnych wektorów ataku.

Z wieloma z nich można się zapoznać, przeglądając materiały udostępniane przez badaczy, których praca zainspirowała mnie do napisania niniejszego tekstu. Oto oni:

[list][item]bohops[/item][item]Eric[/item][item]Nick Carr[/item][item]MalwareTech[/item][item]Malwrologist

[/item][/list]

Załączony tu kod nie jest szkodliwy. Jest wręcz celowo niskiej jakości ;)

Cheers!