Jak wygląda zaawansowane włamanie krok po kroku – raport z incydentu

Szczegółowe raporty z incydentów są trochę jak yeti – podobno istnieją. Czasem możemy się z nimi zapoznać na skutek innych incydentów, w których wyciekły. Rzadko jednak publikuje je sama zaatakowana instytucja.

Uwielbiamy raporty z włamań i ubolewamy, że tak rzadko mamy okazję je prezentować. Tym skrupulatniej wygrzebujemy tak nieliczne przypadki, gdzie ktoś podzielił się swoimi doświadczeniami. Dzisiaj mamy dla was incydent z drugiej strony świata – a będzie nim włamanie do sieci Australijskiego Uniwersytetu Narodowego.

Co, jak i kiedy

Australijski Uniwersytet Narodowy to ciekawy cel dla włamywaczy. Zajmujący wysokie pozycje w międzynarodowych rankingach (okolice miejsc 30-50, podczas gdy polskie UJ czy UW oscylują koło trzeciej – czwartej setki) prowadzi liczne badania na światowym poziomie. Nic więc dziwnego, że mógł stać się celem atakujących – i to kilkukrotnie. Do jednego z incydentów doszło w maju 2018, jednak dopiero incydent odkryty w kwietniu 2019 okazał się dość ciekawy. Uniwersytet opublikował obszerny raport, my ten raport przeanalizowaliśmy i streściliśmy poniżej w porządku chronologicznym, wybierając najciekawsze naszym zdaniem wątki.

Ważne wyjaśnienie – z uwagi na sposób działania napastnika (troskliwe usuwanie logów, plików i innych śladów swojej działalności) oraz opóźnioną reakcję obrońców wiele elementów tego ataku zostało zidentyfikowanych tylko w ograniczonym zakresie. Mimo tego dostępny materiał jest ciekawą lekturą.

Wydarzenia krok po kroku

Pierwszy e-mail phishingowy dotarł 9 listopada 2018 do jednego z wyższych rangą pracowników uniwersytetu. Niestety wiadomość się nie zachowała, jednak w oparciu o późniejsze ataki i zachowane logi z dużym prawdopodobieństwem można powiedzieć, że nie zawierała linków phishingowych. Według raportu e-mail został przez odbiorcę otwarty – i to wystarczyło atakującemu, by otrzymać poświadczenia ofiary. Raport nie pisze tego wprost, ale obstawiamy, że chodzi o atak pozwalający na kradzież haszy NTLM za pomocą obiektu OLE wczytywanego ze zdalnego serwera za pomocą protokołu SMB, osadzonego w e-mailu w formacie RTF. Pod tym linkiem znajdziecie szczegółowy opis przebiegu takiego ataku. Jeśli dana organizacja nie blokuje wychodzącego ruchu SMB, jego przeprowadzenie jest dość proste i skuteczne. W innym wariancie pobranie pliku z zewnętrznego zasobu za pomocą SMB jest inicjowane przez odpowiednio spreparowany dokument Worda.

Dzięki tej wiadomości atakujący uzyskał zarówno poświadczenia użytkownika, jak i dostęp do kalendarza ofiary. W dniach 12-14 listopada wykradzione poświadczenia prawdopodobnie pomogły włamywaczowi dostać się do jednego z serwerów WWW uniwersytetu i zainstalować tam webshella. Serwer ten był w kolejnych dniach używany jako C&C, który łączył się z siecią Tor.

16 listopada napastnik, korzystając z serwera WWW, dobrał się do serwera zawierającego bliżej niesprecyzowane oprogramowanie w wersji „trial”, dawno nieużywane. Serwer miał zostać wyłączony pod koniec roku. Ten drugi serwer był podłączony do VLAN-u, dającego szeroki dostęp do sieci uniwersyteckiej. Na nim napastnik podniósł swoje uprawnienia do poziomu administratora i zaczął konfigurować narzędzia do dalszej fazy ataku.

Dni 20-21 listopada atakujący spędził na pobieraniu narzędzi i skryptów z sieci oraz budowaniu swojego środowiska pracy. Część narzędzi służyła wyłącznie kasowaniu logów – zadanie takie było regularnie uruchamiane w celu ukrycia obecności atakującego na przejętych maszynach. 21 listopada rozpoczęło się mapowanie sieci uniwersytetu.

22 listopada atakujący zainstalował na zaatakowanym serwerze narzędzia do wirtualizacji, a następnie pobrał za pomocą protokołu BitTorrent (!) obrazy Windowsa XP oraz Kali Linuxa, które uruchomił w środowisku wirtualnym. Atakujący uruchomił także sniffer sieciowy, którego zadaniem było przechwytywanie poświadczeń użytkowników oraz przejął kontrolę za pomocą protokołu RDP nad serwerem uniwersytetu, który dysponował publicznym adresem IP. Przez resztę dnia skanował sieci.

23 listopada wyniki skanowania sieci zostały przesłane za pomocą trzech wiadomości poczty elektronicznej na zewnętrzne skrzynki. Do wysłania e-maili użył starego uniwersyteckiego serwera poczty, który nie wymagał uwierzytelnienia. Tego samego dnia skonfigurował usługę proxy, której zadaniem było tunelowanie ruchu wychodzącego z sieci uniwersyteckiej.

25 i 26 listopada atakujący przeprowadził kolejne ataki spear phishingowe. Wysłał 11 wiadomości, których część mogła być próbą weryfikacji sposobu działania mechanizmów bezpieczeństwa uniwersytetu. W atakach zostały użyte pliki DOC wykorzystujące opisany wcześniej mechanizm wycieku poświadczeń NTLM. Na skutek ataku napastnik pozyskał jeden zestaw poświadczeń, lecz dały mu one dość ograniczony dostęp. Atakujący uzyskał także dostęp do serwera LDAP, pobierając dane użytkowników oraz urządzeń. Napastnik najwyraźniej nadal nie posiadał dostępów, których poszukiwał.

27 listopada atakujący przeprowadził serię ataków na liczne serwery uniwersyteckie z użyciem exploitów oraz wykradzionych poświadczeń. Brak szczegółów tych działań – wiadomo jednak, że najwyraźniej trafił na to, czego szukał, ponieważ po zdobyciu dostępu do wielu różnych udziałów plikowych zainteresował go wyłącznie udział należący do Działu Zarządzania. Był to folder plików tymczasowych, używany do wymiany danych z innymi działami. Atakujący posiadał znacznie szersze dostępy, lecz nie zaglądał do innych zasobów.

Napastnik kontynuował mapowanie serwerów, tym razem skupiając się wyłącznie na serwerach Działu Zarządzania. Zlokalizował serwery baz danych używane przez komórki odpowiedzialne za sprawy kadrowe, finansowe, zarządzanie danymi studentów i formularzy elektronicznych. Próbował wielokrotnie dostać się do tych systemów, lecz bez skutku. 27 listopada, pod koniec dnia, napastnik pobrał kod źródłowy nieznanego narzędzia, skompilował je w sieci uniwersytetu i uruchomił. Niestety posprzątał po sobie bardzo skutecznie – zarówno kod źródłowy, jak i skompilowany, zostały skrupulatnie usunięte. Ślady wskazują jednak na to, że krótko potem użyto narzędzi do łamania haszy haseł. Najwyraźniej operacja musiała przynieść spodziewany skutek, ponieważ kolejnym krokiem było połączenie z wieloma bazami danych za pomocą standardowego komercyjnego narzędzia. Bazy zostały przeszukane, wybrane rekordy pobrane, wyeksportowane do formatu PDF i wysłane do innego uniwersyteckiego serwera znajdującego się pod kontrolą napastnika w celu eksfiltracji z sieci uniwersytetu.

29 listopada ma miejsce trzeci atak spear phishingowy. Tym razem napastnik manipuluje uniwersyteckim filtrem antyspamowym, by wyłączyć detekcję wysyłanych wiadomości. Nie wiadomo, czy działanie to zakończyło się sukcesem. Napastnik wysłał 75 wiadomości, 50 na adresy uniwersyteckie, a pozostałe na adresy zewnętrzne. Dowody wskazują, że ta faza ataku pozwoliła na zdobycie co najmniej jednego zestawu poświadczeń osoby z uprawnieniami administracyjnymi.

Tego samego dnia atakujący zabrał się do skrupulatnego usuwania śladów swojej aktywności. Kasował i nadpisywał zarówno logi, jak i narzędzia, w tym także informacje na serwerze używanym do przeprowadzania większości ataków. Miał jednak pecha, ponieważ rutynowa zmiana konfiguracji firewalla 30 listopada odcięła mu dostęp do tego serwera. Napastnik niezwłocznie podjął próby odzyskania dostępu do sieci uniwersytetu, które trwały do 13 grudnia. Przypadkowe odcięcie napastnikowi dostępu do serwera w trakcie czyszczenia śladów pozwoliło na przeprowadzenie analizy śledczej – większość informacji z cytowanego raportu została zebrana właśnie dzięki badaniu tego serwera, którego czyszczenia atakujący nie dokończył.

13 grudnia napastnik dostał się do serwera jednej z jednostek uniwersytetu. Serwer ten działał pod kontrolą starej wersji systemu operacyjnego, posiadał publiczny adres IP i nie był chroniony przez uniwersyteckie firewalle. Dostępne logi wskazują, że przejęty serwer był intensywnie wykorzystywany w komunikacji z internetem, w tym z siecią Tor. 19 grudnia z jego pomocą wyprowadzono z sieci uniwersyteckiej 13 skompresowanych plików o nieznanej zawartości.

21 grudnia napastnik wysłał czwartą porcję e-maili spear phishingowych do 40 uniwersyteckich administratorów. Wiadomości miały w tytule „New Planning for Information Technology Services” i wykorzystywały informacje wykradzione z kalendarza osoby zaatakowanej jako pierwszej jeszcze w listopadzie. Atakującemu udało się dzięki temu zdobyć co najmniej kilka zestawów poświadczeń, jednak zapewne z uwagi na zakres ataku phishingowego operacja została wykryta przez dział IT i atakujący utracił dostęp do swojego serwera w sieci uniwersyteckiej. Niestety incydent potraktowano jako odosobniony przypadek i nie podjęto szerzej zakrojonych działań śledczych.

Ślady wskazują, że między grudniem 2018 a marcem 2019 dochodziło do automatycznej komunikacji z serwerem sterującym. Brak jednak śladów aktywności włamywacza w sieci uniwersytetu – jedyne podejrzane zdarzenie miało miejsce w lutym 2019, gdy nastąpił atak na jeden z serwerów WWW. Atak był nieudany, jednak jego przebieg wskazuje na duże podobieństwo z poprzednimi działaniami tego samego napastnika. Ostatni ślad komunikacji z serwerem C&C pochodzi z 4 marca 2019.

W kwietniu 2019, podczas rutynowych, zaplanowanych działań poszukiwawczych (threat hunting) natrafiono na ślady aktywności przestępców. Analiza incydentu 17 maja doprowadziła śledczych do odkrycia wycieku danych. 4 maja ogłoszono publicznie informacje o incydencie. Tego samego dnia sieć uniwersytetu została zaatakowana przez botnet, a kolejnego dnia doszło do próby ataku na uniwersyteckie systemy antyspamowe, które już wcześniej stanowiły cel ataku włamywacza. To ostatnie wydarzenia, które można powiązać z tym incydentem.

Dodatkowe informacje

Raport wskazuje także, że napastnik w prosty sposób unikał wykrycia przez uniwersyteckie mechanizmy bezpieczeństwa. Używał na przykład dostępnych publicznie narzędzi, lecz modyfikował nieznacznie ich zawartość, powodując zmianę sum kontrolnych plików. Część narzędzi kompilował w sieci uniwersytetu, unikając dzięki temu wykrycia ich formy skompilowanej przez rozwiązania monitorujące ruch internetowy na punkcie styku sieci uniwersyteckiej z siecią publiczną. Warto także pamiętać o tajemniczym narzędziu, dzięki któremu napastnik uzyskał dostęp do docelowych baz danych i którego wszelkie ślady skrupulatnie zatarł.

W trakcie ataku używane były zarówno dostępne narzędzia, jak i stworzone przez atakującego dedykowane skrypty (JavaScript i Powershell). Dzięki dostępowi do baz danych za pomocą zewnętrznego narzędzia atakujący uniknął mechanizmów bezpieczeństwa zaimplementowanych w aplikacjach używanych na co dzień przez pracowników uniwersytetu.

O co chodziło napastnikowi

Niestety skrupulatność atakującego w kasowaniu śladów swojej działalności połączona z brakiem niezależnych mechanizmów rejestrujących zarówno operacje na bazach danych, jak i treść danych opuszczających sieć uniwersytecką, nie pozwalają na jednoznaczne stwierdzenie, jakie dane zostały wykradzione.

Systemy, które najwyraźniej były celem ataku, przechowują dane studentów i pracowników, w tym informacje takie jak:

• imiona i nazwiska,
• adresy,
• numery telefonów,
• daty urodzenia,
• dane kontaktowe na wypadek nagłych przypadków,
• numery podatkowe,
• dane płacowe,
• dane kont bankowych,
• wyniki studiów.

Przechowywane w uniwersyteckich systemach dane sięgały nawet 19 lat wstecz, lecz objętość wykradanych plików wskazuje, że złodziej nie zabrał ze sobą wszystkich dostępnych danych. Napastnik nie próbował też szukać wyników badań naukowych ani żadnych innych informacji. Po co mogły mu być przydatne dane osobowe pracowników i studentów? Zaatakowany uniwersytet jest kuźnią kadr rządu i australijskich elit – być może takie dane są przydatne dla wywiadów obcych krajów. Uniwersytet stanowczo oświadczył, że nie widzi podstaw do określania źródła ataku. Wskazał jedynie na jego spore zaawansowanie techniczne i operacyjne.

Wnioski płynące z incydentu

W momencie ataku uniwersytet wdrażał już bardziej rozbudowane mechanizmy bezpieczeństwa, co było plonem rekomendacji po ataku z maja 2018. Nie zdążył jednak wdrożyć wszystkich mechanizmów, a kolejny atak pokazał, że kwestie bezpieczeństwa wymagają większych nakładów. Główne rekomendacje obejmują:

• szkolenia w wykrywaniu phishingu,
• identyfikacja i eliminacja lub utwardzenie konfiguracji serwerów i aplikacji starszej generacji,
• podniesienie poziomu ochrony kluczowych systemów bazodanowych,
• eliminacja starszych rozwiązań poczty elektronicznej, centralizacja platformy pocztowej,
• rozszerzenie zakresu wdrożenia mechanizmów dwuskładnikowego uwierzytelnienia w systemach i aplikacjach używanych przez administratorów,
• rozszerzenie zakresu sieci chronionego przez firewalle,
• rozszerzenie zakresu programu poprawy zarządzania podatnościami i aktualizacjami,
• rozpoczęcie ćwiczeń obejmujących symulacje prawdziwych ataków.

Podsumowanie

Choć raport na skutek poziomu zaawansowania napastnika nie jest kompletny, to daje dobry obraz działania przestępcy w rozbudowanej sieci ofiary. Mamy nadzieję, że jego lektura pomoże wam w planowaniu własnych działań obronnych i wykrywających. Jeśli chcecie podzielić się swoimi historiami podobnych incydentów, to zapraszamy z otwartymi ramionami – gwarantujemy daleko posuniętą anonimizację opisywanych wydarzeń.