Case study incydentu bezpieczeństwa: atak przez RDP, Mimikatz i rekonesans na serwerach Linux

Atak przez RDP, Mimikatz i rekonesans na serwerach Linux

W lutym zespół SOC w ramach świadczenia usługi reakcji na incydenty bezpieczeństwa, został poproszony o wsparcie przy analizie włamania. Wstępna analiza wykazała infekcję serwerów ransomwarem.

Pierwsze ślady aktywności atakującego wskazują na początek infekcji już pod koniec listopada zeszłego roku. System EDR poprawnie alertował podejrzane działania, lecz zabrakło personelu do obsługi konsoli EDR.

Z pozoru nieszkodliwe zaniedbania – brak aktywnego monitorowania, publicznie dostępne usługi – z czasem przerodziły się w pełnoprawny incydent bezpieczeństwa.

Jak zaniedbania prowadzą do kompromitacji systemów

Większość poważnych incydentów bezpieczeństwa nie zaczyna się od spektakularnego włamania. Zaczyna się od zaniechań czy zaniedbań. Rutyna, brak reakcji na pierwsze sygnały, zignorowane alerty — to one stopniowo osłabiają system, aż w końcu dochodzi do kompromitacji.

Zgłoszenie incydentu oraz zapotrzebowania na wsparcie przy analizie trafiło do zespołu SOC pod koniec lutego. W toku analizy potwierdzono infekcję serwerów oprogramowaniem typu ransomware. Złośliwe pliki wykryto na maszynach znajdujących się w jednej z wydzielonych podsieci. Dalsze dochodzenie wykazało, że nieautoryzowana aktywność w tej części środowiska miała miejsce już kilka miesięcy wcześniej — ślady wskazują na początek infekcji pod koniec listopada poprzedniego roku.

Źródło identyfikacji incydentu

Użytkownik, który rozpoczynał pracę, nieskutecznie próbował zalogować się do serwera. Po zgłoszeniu tego faktu przez pracownika, dział IT klienta ustalił, że serwery zostały zainfekowane ransomwarem.

Wstępnie ustalono, że zainfekowane zostały wszystkie serwery Windows w danej podsieci. Serwery Linux, również znajdujące się w podsieci, nie zostały zainfekowane ransomwarem, lecz posłużyły do rekonesansu.

Natychmiastowo, zespół IT klienta odizolował całą podsieć.

Zabezpieczenie dowodów

• kopie zainfekowanych maszyn wirtualnych,
• polityki bezpieczeństwa,
• raporty z skanów podatności,
• raporty bezpieczeństwa przeprowadzonego przez firmę zewnętrzną,
• kopie konfiguracji zapory sieciowej,
• screenshooty z logów serwerów Linux wskazujących na kompromitacje serwerów Windowsowych,
• wyniki OSINT z platform Shodan oraz Censys,
• kopie zapasowa dla zainfekowanych serwerów Windows,
• dostępy do konsoli firewalla, systemów monitoringu, EDR oraz UTM.

Wstępna analiza

Po ustaleniu szczegółów, wymienieniu informacji z klientem oraz otrzymaniu logów oraz dostępów do narzędzia EDR, zespół SOC Trecom podjął się wstępnej analizy.

Na początku zespół przejrzał dane z narzędzia EDR (Endpoint Detection and Response). W logach znaleziono alerty dotyczące wykrycia narzędzia Mimikatz, znanego z wykradania poświadczeń. Co istotne, pierwsze z tych alertów pochodziły już z końca listopada zeszłego roku, co wskazuje, że aktywność atakującego trwała przez kilka miesięcy, zanim doszło do pełnej infekcji ransomwarem.

Zespół skupił uwagę na ustaleniu wektora ataku. Ujawniono, że serwer „zero” posiadał otwarty port 3389 na świat. Port 3389 to domyślny port, na którym działa usługa RDP (Remote Desktop Protocol).

Informację o otwartym porcie 3389 oraz związanym z nim ryzyku niezwłocznie przekazano zespołowi IT klienta. Najprawdopodobniej port ten został pozostawiony otwarty przez przypadek po zakończeniu prac serwisowych, co stworzyło lukę umożliwiającą nieautoryzowany dostęp.

Weryfikacja dzienników zdarzeń oraz logów sieciowych potwierdziła przypuszczenia. Odnotowano udane logowania RDP z wielu unikatowych adresów, głównie należących do komercyjnych dostawców VPN.

Analiza serwerów Linux

Po ustaleniu wektora ataku, podjęto działania na serwerach Linux. Celem było ustalenie, czy serwery zostały również zainfekowane.

Zespół SOC skupił się na godzinach, w których odnotowano pierwsze alerty w konsoli EDR. Szybko w logach odnotowano żądania GET na ścieżkę /nice ports./Trinity.txt.bak.

Ścieżka /nice+ports./Trinity.txt.bak to jedna z celowo używanych nazw plików, które są wbudowane w niektóre skrypty narzędzia Nmap – popularnego narzędzia do skanowania sieci.

Jak można było temu zapobiec?

W analizowanym przypadku wiele sygnałów ostrzegawczych pojawiło się na długo przed momentem, w którym ransomware sparaliżował część infrastruktury. Pierwsze alerty EDR wskazujące na aktywność Mimikatz wystąpiły już kilka miesięcy wcześniej, a otwarty port RDP wystawiony na świat pozostawał niezabezpieczony przez dłuższy czas — prawdopodobnie przez przeoczenie po zakończeniu prac administracyjnych. To nie były ani zaawansowane techniki, ani nieznane wektory ataku. To były klasyczne symptomy — łatwe do wykrycia, o ile są regularnie monitorowane.

Gdyby kluczowe elementy infrastruktury były na bieżąco monitorowane, wiele sygnałów ostrzegawczych mogłoby zostać wychwyconych znacznie wcześniej. Alerty z systemu EDR, wystawiony do internetu port 3389, nietypowa aktywność w logach sieciowych czy rekonesans prowadzony na serwerach Linux — to wszystko były wyraźne znaki, które dało się zauważyć i odpowiednio zareagować, zanim doszło do pełnej kompromitacji. Sam fakt, że dane istniały, a alerty były generowane, pokazuje, że zagrożenie mogło zostać powstrzymane — zabrakło jedynie systematycznej obserwacji, analizy tych sygnałów oraz skutecznej reakcji.