Załóżmy, że Twój program właśnie został uruchomiony na komputerze ofiary. Od czego zacząć rekonesans? I co dalej?

Ten odcinek będzie zdecydowanie najdłuższy z całego cyklu. I cała zawarta w nim wiedza jest niezbędna, jeśli odpowiedź na pytanie kilka wierszy niżej brzmi „infiltracja infrastruktury”, albo jeśli celujesz w konkretną osobę albo firmę.

W pozostałych przypadkach możesz kierować się po prostu zasadą 20/80, zgodnie z którą 20% nakładów czasowych i finansowych na implementację da 80% efektów – i działać „na wyrwę”, po prostu ignorując to, że część użytkowników zdąży zauważyć i przerwać proces szyfrowania swoich danych.

Wybór strategii działania

Zanim jeszcze przystąpisz do napisania choć jednej linii kodu, powinieneś sobie odpowiedzieć na zasadnicze pytanie: co jest Twoim celem?

• atak na pojedynczy komputer i ewentualnie na dane udostępniane przez sieć, oraz ewentualnie urządzenia podłączone do lokalnego komputera (np. przez USB)
• przygotowanie do infiltracji infrastruktury Active Directory, przy okazji szyfrując dane (od razu lub z opóźnieniem) – ale przede wszystkim celując w coś dużo większego niż bieżący komputer

Od konkretnej odpowiedzi na to pytanie zależy wiele szczegółów, które będzie trzeba ogarnąć później. Ważne jednak, aby odpowiedzieć sobie na to pytanie już teraz, aby wiedzieć, na co nie warto tracić czasu.

W obu przypadkach podstawowym celem do realizacji będzie uniknięcie wyświetlenia użytkownikowi komunikatów związanych z bezpieczeństwem:

• przede wszystkim z UAC
• ale także wszystkich innych dotyczących wpisywania haseł i zmiany uprawnień (przy dostępie do udziałów SMB, czy próbie zmiany uprawnień)
• oraz komunikatów z programów antywirusowych i podobnych
• a jeśli interesuje Cię infiltracja infrastruktury, również uniknięcie „cichego” wykrycia przez mechanizmy klasy SIEM

Unikać programów antywirusowych i SIEM nauczysz się w części pierwszej cyklu, dzisiaj zaś skupmy się przede wszystkim na UAC.

Pierwsze kroki w systemie

Jednym z pierwszych kroków jest oczywiście sprawdzenie wersji Windows (w tym dokładnej wersji aktualizacji funkcji Windows 10) – bowiem w każdej kolejnej edycji Windows szczegóły dotyczące różnych działań związanych z bezpieczeństwem systemu nieco się różnią.

To co nas interesuje na tym etapie, to jakie mamy efektywne (a więc niekoniecznie wynikające z członkostwa w grupach) uprawnienia:

• do lokalnych plików i katalogów
• do udziałów na zewnętrznych serwerach
• do wszelkiego rodzaju pozostałych zasobów

Dlaczego to ważne? W mniejszych firmach i na komputerach domowych, większość użytkowników pracuje na kontach uprzywilejowanych, a więc takich, których infekcja otwiera dostęp do całego komputera.

Z drugiej zaś strony, od wielu lat standardem korporacyjnym jest praca w środowisku Active Directory, na kontach nieuprzywilejowanych – infekcja takiego konta nadal umożliwia zaszyfrowanie plików użytkownika leżących w jego katalogu domowym, nie jest już jednak możliwe np. wyłączenie usług SQL Server i bezpośrednie zaszyfrowanie baz danych.

Co poza Active Directory?

Poza Active Directory istnieją też inne mechanizmy, np. FreeIPA czy OpenLDAP. Kiedy powinieneś się nimi interesować? Raczej tylko wtedy, gdy od początku myślisz o infiltracji infrastruktury. W pozostałych przypadkach nie warto tracić czasu – wystarczającym rozwiązaniem będzie po prostu zaszyfrowanie lokalnych plików należących do pojedynczego użytkownika i poprzestanie na tym.

A więc co dalej?

Wiedząc już, w jakim środowisku działa program, oraz jakie ma uprawnienia efektywne, czas na ocenę, czy trzeba i czy można te uprawnienia jakoś podnieść lub zmienić bez zaalarmowania użytkownika, czy też lepiej z takich prób zrezygnować i zadowolić się zaszyfrowaniem tego, na co pozwalają obecne uprawnienia:

• enumeracja lokalnych plików z prawami do zapisu
• enumeracja zdalnych udziałów sieciowych – tych zamapowanych na dysk sieciowych, ale też tych podłączanych bezpośrednio, w formie np. \\serwer\wspolny
• wyszukanie plików z prawem do odczytu (zapis nie jest konieczny), zawierających hasła do kolejnych zasobów, np.
  • pliki wcx_ftp.ini od Total Commandera, zawierające hasła do kont FTP
  • pliki fstab z systemów Linux, zawierające deskryptory udziałów NFS i SMB
  • pliki *.rdp zawierające hasła, pozwalające na połączenie z innym komputerem przez usługę Zdalnego Pulpitu
  • klucze prywatne ssh, połączone z konkretnym serwerem w konfiguracji programu PuTTY w rejestrze
  • pliki zawierające hasła do różnych baz danych (patrz niżej)

Kopiować czy modyfikować, oto jest pytanie…

Bardzo często powielanym błędem programów ransomware jest mylenie praw do zapisu pliku i katalogu. W efekcie większość ransomware kompletnie ignoruje sytuacje, gdy użytkownik ma dostęp do zapisu do konkretnych plików (poza swoim katalogiem domowym), ale już nie do katalogu – pliki takie pozostają niezaszyfrowane.

Inne programy szyfrują lub uszkadzają takie pliki, ale dostając błąd przy próbie zmiany nazwy pliku i dodania swojego rozszerzenia, porzucają całą operację na pliku lub katalogu i plik wygląda na „niedokończony”.

Co wymaga zastanowienia na tym etapie:

• szyfrować pliki in-place i dopiero zmieniać im rozszerzenie?
• czy raczej stworzyć zaszyfrowaną kopię, a dopiero potem skasować oryginał?
• co z dużymi plikami, mającymi wiele gigabajtów: w kontekście czasu potrzebnego na ich zaszyfrowanie, oraz miejsca na dysku?
• co z plikami zablokowanymi przez jakiś proces?
• co w przypadku, gdy proces szyfrowania zostanie zatrzymany przez błąd w Twoim programie, zabicie procesu z jakiegoś powodu, czy choćby przypadkowy brak prądu? jak zapobiec nieodwracalnemu uszkodzeniu takich plików?

Szyfrowanie i kasowanie w osobnych fazach – czy to ma sens?

Niektóre programy stosują następującą strategię:

• najpierw zaszyfrować wszystko „na bok”
• gdy szyfrowanie zostanie ukończone, dopiero wtedy rozpocząć kasowanie oryginalnych plików

Takie podejście może mieć sens w niektórych przypadkach:

• gdy zależy nam na możliwości „czystego” odzyskania wszystkich danych, bez błędów, artefaktów i różnych problematycznych sytuacji
• gdy chcemy mocno opóźnić pokazanie użytkownikowi, że jego pliki zostały zaszyfrowane
• w szczególności gdy chcemy skoordynować ujawnienie faktu zaszyfrowania danych na większej ilości komputerów (co najczęściej wiąże się z wcześniejszą infiltracją infrastruktury)

Takie podejście jest jednak kosztowne:

• komplikuje implementację Twojego programu – np. co z plikami, które program już zaszyfrował, a użytkownik zmodyfikował ich niezaszyfrowaną wersję?
• wymaga większej ilości wolnego miejsca na dysku (a co jeśli go nie ma? a co jeśli jest „na styk” i Windows ostrzeże użytkownika o kończącym się wolnym miejscu na dysku?)
• zwiększa możliwości samodzielnego (bez płacenia) odzyskania danych przez analizę usuniętych plików

Dobrym pomysłem jest natomiast podział samego procesu szyfrowania na 3 fazy:

• w pierwszej fazie szyfrowanie tylko plików „bezproblemowych”, aby uniknąć „wywalenia się” na różnych przypadkach brzegowych: plikach zablokowanych przez programy działające w tle, plikach zbyt dużych (brak miejsca na dysku), dziwnie skonfigurowanych uprawnieniach itp.
• w drugiej fazie „udrożnienie” dostępu do plików, których nie dało się zaszyfrować wcześniej – np. przez próby wyłączania usług typu Microsoft SQL Server i programów typu Outlook, czy przywracania domyślnych uprawnień na katalogach nadrzędnych z takimi plikami
• w trzeciej fazie szyfrowanie pozostałych plików (w idealnej sytuacji, druga i trzecia faza powinny się przeplatać, iterując po liście plików, których nie dało się wcześniej zaszyfrować)

Wówczas jeśli program „wywali się” w drugiej lub trzeciej fazie z powodu jakiegoś nieobsługiwanego błędu, albo stosowania przez administratora jakichś niestandardowych zabezpieczeń, większość plików i tak będzie już zaszyfrowana.

Efektywność czasowa procesu szyfrowania

W przypadku ataku na pojedynczy komputer, sytuacja jest prosta: najwyżej zaalarmowany przeciągającym się zamuleniem komputera użytkownik przerwie proces szyfrowania. I najwyżej nie zapłaci.

Dużo gorzej jeśli 1 niechcący wywołany alarm doprowadzi do przerwania całej operacji szyfrowania np. kilkunastu tysięcy komputerów w całej korporacji. Dlatego właśnie, poza opisanym nieco wyżej podejściem pozwalającym na synchronizację szyfrowania na wielu komputerach, warto przemyśleć też kilka innych kwestii:

• może jednak warto zaimplementować oba przytoczone wyżej algorytmy: szyfrowanie in-place, oraz szyfrowanie „na bok” z niskim priorytetem i zsynchronizowanym kasowaniem?
• ale jak wówczas najbezpieczniej zsynchronizować całą operację, nie nawiązując dodatkowej komunikacji sieciowej, która by była dość charakterystyczna i łatwa do wykrycia?
• na wypadek gdyby jednak doszło do wpadki, jak zarządzać kluczami sesji (komputera) w dużej kampanii (kilkanaście tysięcy osobnych kluczy czy 1-kilka wspólnych? ale co jeśli ktoś zdoła przechwycić taki klucz sesji?)
• jak liczyć ilość potrzebnego miejsca na dysku twardym w przypadku szyfrowania „na bok”? jak obsłużyć wiele partycji?
• jak wykrywać nośniki zewnętrzne (dyski, pen drive’y)? i jak je „obsługiwać”: szyfrowanie in-place czy „na bok”?
• jak odróżnić pen drive od innych typów nośników? jak skutecznie wybadać maksymalne osiągi (prędkość zapisu i ilość operacji zapisu na sekundę) pen drive’a bez zamulania komputera?
• w zależności od jakich czynników różnicować strategię szyfrowania: np. obciążenie procesora, model procesora i ilość rdzeni, ilość RAM, bieżące zużycie RAM przez procesy użytkownika, dysk SSD lub magnetyczny, ilość wolnego miejsca, ilość wartościowych danych do zaszyfrowania, wielkość kampanii – jakie jeszcze czynniki warto wziąć pod uwagę?
• jak podejść do samych plików: szyfrować po kolei katalogami, czy próbować wykryć najbardziej wartościowe dane, zaczynając od nich?
• jak podejść do dużych plików: szyfrować zawsze całość, czy tylko fragmenty? jeśli fragmenty, to in-place czy kopiując plik? jak oznaczać już zaszyfrowane miejsca, aby nie zaszyfrować ich omyłkowo kilka razy? i jak (nie)duże fragmenty różnych typów plików trzeba zaszyfrować, aby użytkownik nie miał już z nich żadnego pożytku?

Zapobieganie samodzielnemu odtworzeniu danych z backupów

Większość ofiar ransomware nigdy nie zapłaci – najczęstsze powody to:

• użytkownik odtworzył dane z backupu (wszystkie lub najważniejsze)
• na komputerze nie było unikalnych danych – te były w chmurze (np. Google Drive), a na komputerze były co najwyżej pojedyncze pliki, które można było odżałować
• zaszyfrowane dane nie są tyle warte (np. komputer z grami, gdzie jedyne „cenne” dane to save’y z gier)
• mimo że dane są cenne, to atak zniszczył użytkownikowi źródło dochodów, a nie mając rezerw finansowych, nie ma on już z czego zapłacić (sytuacja powszechna w biedniejszych krajach)

O ile z większością tych powodów nie jesteś w stanie nic zrobić, o tyle możesz przynajmniej spróbować wykryć i skasować lub uszkodzić backupy widoczne na komputerze – bowiem dość powszechną praktyką w małych firmach jest archiwizacja danych na dysk zewnętrzny albo NAS, do którego zabezpieczany tak serwer ma bezpośredni dostęp do zapisu (a więc może zarówno tworzyć własne backupy, jak i je kasować).

Przede wszystkim powinieneś skupić się na systemach:

• Windows Backup – wersje VHDX i ZIP, składnik Windows
• VSS (Volume Shadow Copy Service, kolejny składnik Windows)
• Cobian Backup – darmowy, bardzo popularny w Polsce
• AOMEI – również darmowy
• Acronis – najbardziej rozpowszechniony z płatnych

Postępowanie z bazami danych

W przypadku baz danych SQL Server, istnieją 4 podstawowe scenariusze, które powinieneś wziąć pod uwagę:

• Twój program został uruchomiony na prawach administratora – wówczas możesz po prostu wyłączyć usługi systemowe MSSQL i zaszyfrować pliki MDF
• program został uruchomiony na koncie nieuprzywilejowanym – wówczas:
  • nadal możesz szukać plików tworzonych przez różne instalowane programy, zawierających hasła do tych baz danych – mając hasło, możesz się połączyć i zaszyfrować lub usunąć dane zapytaniami SQL
  • warto też sprawdzić, czy któraś z instancji nie ma pustego hasła administratora – a w taki sposób instalowana jest np. domyślna baza danych systemu Insert GT, popularnego w polskich biurach rachunkowych
• niezależnie od uprawnień, możesz szukać plików z hasłami j/w, wskazujących na bazy danych działające na innych komputerach w sieci

A jak najłatwiej połączyć się z serwerem baz danych? W przypadku SQL Servera służy do tego narzędzie SQL Server Native Client (program sqlcmd.exe), od wersji 2012 bardzo często instalowane wraz z aplikacjami korzystającymi z SQL Servera.

Infiltracja infrastruktury

Jeśli Twoim celem – głównym lub dodatkowym – jest infiltracja czyjejś infrastruktury, wówczas pierwszym krokiem jest oczywiście zadbanie o wszystkie wymienione wyżej niuanse, aby żaden z użytkowników nie zorientował się wcześniej, co się dzieje.

Dotyczy to również działów IT, obecnych w każdej dzisiejszej dużej firmie i często przyglądających się temu, co się dzieje na komputerach pracowników za pomocą scentralizowanego oprogramowania.

Kolejne kroki infiltracji infrastruktury wykraczają już tematycznie poza zakres tej części. Poniżej znajdziesz jednak kilka linków uzupełniających odnośnie infiltracji Active Directory:

• https://adsecurity.org/?p=2535
• https://kapitanhack.pl/category/killchain/
• https://kapitanhack.pl/2018/09/14/killchain/bardzo-istotny-a-malo-znany-obiekt-w-ad-adminsdholder/
• https://kapitanhack.pl/2020/07/23/ad-persistence/zapowiedz-kampanii-2/
• https://kapitanhack.pl/2020/07/10/nieskategoryzowane/sabotaz-na-koncie-admina-kradziez-biletu-kerberos-i-uzycie-go-na-linux-unix-do-dalszego-ataku/

W kolejnej części – unikanie wykrycia.

Intencją autorów ani wydawcy treści prezentowanych w magazynie PAYLOAD nie jest namawianie bądź zachęcanie do łamania prawa. Jeśli popełniłeś lub masz zamiar popełnić przestępstwo, bądź masz wątpliwości, czy Twoje działania nie będą łamać prawa, powinieneś skonsultować się z najbliższą jednostką Policji lub Prokuratury, a jeśli są one związane z pieniędzmi, dla pewności również z Urzędem Skarbowym.

Nie zezwala się na użycie treści prezentowanych w magazynie PAYLOAD, ani produktów dostępnych w sklepie PAYLOAD, do celów popełniania przestępstw lub przestępstw skarbowych.