Cisco Talos opisał 23 lipca msaRAT, implant przypisany grupie Chaos, który według analizy przekazuje komunikację C&C przeglądarce przez Chrome DevTools Protocol. Dla osób odpowiedzialnych za stacje robocze to powód, by sprawdzić, czy monitoring wiąże ruch przeglądarki z procesami i nietypowym użyciem funkcji administracyjnych.

Czy odpowiedź „to połączenie przeglądarki” wystarczy, żeby uznać aktywność stacji roboczej za wyjaśnioną? Opis msaRAT skłania do postawienia kolejnego pytania: co spowodowało, że przeglądarka wykonała tę komunikację? Jeżeli ocena kończy się na nazwie zaufanej aplikacji, pozostaje niewyjaśniony związek między jej ruchem a działaniem implantu. W przeglądzie monitoringu poprośmy więc o pokazanie całej dostępnej informacji o wybranym połączeniu oraz o procesach związanych z użyciem przeglądarki. Dopiero wtedy oceńmy, czy zespół potrafi uzasadnić cel tej aktywności. Przypadek opisany przez Cisco Talos daje konkretny punkt odniesienia do takiej rozmowy: aplikacja dopuszczona do pracy staje się pośrednikiem komunikacji sterującej atakiem.

msaRAT przekazuje przeglądarce komunikację C&C

Według Cisco Talos msaRAT wykorzystuje Chrome DevTools Protocol do przekazania przeglądarce komunikacji C&C, czyli komunikacji służącej sterowaniu. To ustalenie dotyczy sposobu działania opisanego implantu. Powiązanie msaRAT z grupą Chaos również jest przypisaniem dokonanym przez Cisco Talos.

Wniosek dla kontroli stacji roboczych wynika z roli pośrednika: wskazanie przeglądarki jako aplikacji prowadzącej komunikację nie wyjaśnia jeszcze, kto zainicjował jej działanie. W ocenie zdarzenia połączmy zatem obserwację ruchu z informacją o procesach oraz sposobie wykorzystania funkcji przeglądarki. Samą nazwę aplikacji potraktujmy jako początek analizy.

Z przekazywania komunikacji przez Chrome DevTools Protocol nie wyprowadzajmy automatycznej diagnozy każdego połączenia przeglądarki. Przy ocenie konkretnej stacji wymagajmy ustalenia związku między obserwowanymi zdarzeniami. Nazwa msaRAT nie zastąpi dowodu, że badana aktywność odpowiada opisanemu mechanizmowi, podobnie jak nazwa przeglądarki nie zastąpi uzasadnienia, że jej użycie było dozwolone.

Zaufanie do przeglądarki powinno obejmować sposób jej użycia, a ocena połączenia powinna wskazywać procesy, które do niego doprowadziły.

Dopuszczenie aplikacji wymaga sprawdzenia jej użycia

Opis msaRAT wykorzystajmy do porównania własnej procedury z dostępnymi zapisami aktywności. Jeżeli zasady dopuszczają ruch przeglądarki, sprawdźmy, czy określają również sposób oceny nietypowego użycia jej funkcji administracyjnych. Nie zakładajmy przy tym, że Cisco Talos udokumentował uchybienie procedur w naszej organizacji. Taki wniosek wymagałby sprawdzenia lokalnych zasad i zdarzeń.

Przegląd zacznijmy od wybranego połączenia przeglądarki na stacji roboczej. Poprośmy analityka o wskazanie, z jakim procesem je powiązał i na jakiej podstawie uznał aktywność za wyjaśnioną. Jeśli dostępny zapis pokazuje wyłącznie nazwę aplikacji, odnotujmy, jakiej informacji brakuje do oceny sposobu jej użycia. Nie wpisujmy w to miejsce domysłu o działaniu pracownika.

Osobno poprośmy administratora o opis dozwolonego użycia funkcji, których dotyczy przegląd. Dla Chrome DevTools Protocol ustalmy, czy organizacja przewiduje takie zastosowania, kto potrafi je potwierdzić i jak porównać je z badaną aktywnością. Wynikiem powinno być wskazanie zgodności z uzgodnionym zastosowaniem albo konkretnej rozbieżności do wyjaśnienia. Samo zapewnienie, że przeglądarka znajduje się na liście dozwolonych aplikacji, nie odpowiada na te pytania.

Zarząd powinien wymagać dowodu powiązania zdarzeń

Dla zarządzających ochroną stacji roboczych msaRAT jest powodem do postawienia wymagania wobec monitoringu: zespół powinien umieć zestawić ruch przeglądarki, powiązane procesy i nietypowe użycie funkcji administracyjnych. Przegląd zakończmy pokazaniem takiego powiązania na wybranym zapisie albo nazwaniem brakujących danych. Ogólna deklaracja „monitorujemy przeglądarki” pozostawia zakres tej kontroli niejasny.

Właścicielowi ochrony stacji przypiszmy ocenę braków. Administrator powinien wyjaśnić zatwierdzone zastosowania, a osoba analizująca zdarzenia wskazać, jakie informacje są potrzebne do ich rozróżnienia. Jeżeli zadania wykonują różne zespoły, ustalmy odbiorcę zgłoszenia i osobę odpowiedzialną za końcową ocenę. Przy każdym braku zapiszmy, kto ma go wyjaśnić oraz jaki materiał pozwoli uznać zadanie za zakończone.

Miara przydatności monitoringu to możliwość wyjaśnienia działania przeglądarki na stacji, wraz z procesami i funkcjami, które uczestniczyły w komunikacji.

Przed decyzją o zmianie kontroli oszacujmy nakład pracy dla wskazanego braku danych i sprawdźmy, jak zmiana wpłynie na zatwierdzone użycie przeglądarki. Z opisu mechanizmu msaRAT nie da się wyliczyć kosztu dla konkretnej firmy ani przesądzić, czy potrzebuje ona dodatkowego narzędzia. Najpierw wymagajmy odpowiedzi, czego obecny monitoring nie pozwala ustalić. Dopiero do tak określonego problemu dobierajmy zakres prac i odpowiedzialność.

Polska firma powinna sprawdzić własne stacje

W polskiej organizacji przełóżmy opis msaRAT na pytanie o własne stanowiska pracy: czy potrafimy uzasadnić sposób użycia zaufanej przeglądarki na podstawie dostępnych danych? Sam mechanizm opisany przez Cisco Talos nie pozwala ocenić liczby polskich ofiar ani rozpowszechnienia implantu w kraju. Nie uzasadnia też ogłaszania trendu na podstawie tego jednego przypadku.

Lokalny przegląd oprzyjmy na wybranej stacji i zapisach, do których zespół ma dostęp. Jeśli analizę wykonuje usługodawca, poprośmy go o przedstawienie powiązania ruchu przeglądarki z procesami oraz o wskazanie niewyjaśnionego użycia funkcji administracyjnych. Ustalmy, kto po stronie organizacji może potwierdzić cel takiej aktywności. Własne ustalenia zapiszmy oddzielnie od opisu msaRAT, aby rekomendacja kontroli nie stała się twierdzeniem o wykryciu implantu.

Co z tym zrobić w poniedziałek

  1. Sprawdź dostępność danych dla przeglądarki. W 30 minut przejrzyj wybrany zapis jej połączenia na stacji roboczej. Zapisz, czy można powiązać go z procesami i sposobem użycia aplikacji. Brakujące informacje wpisz jako pytania do właściciela monitoringu.
  2. Porównaj zasady z użyciem Chrome DevTools Protocol. Poświęć 30 minut na sprawdzenie dostępnej dokumentacji dozwolonych zastosowań. Wskaż osobę, która może je potwierdzić; jeśli dokumentacja nie daje odpowiedzi, przygotuj konkretne pytanie o zakres dopuszczonego użycia.
  3. Ustal odpowiedzialność za niewyjaśnioną aktywność. W 30 minut przejrzyj ścieżkę zgłaszania nietypowego użycia przeglądarki. Zapisz, kto zestawia ruch z procesami, kto potwierdza cel użycia funkcji administracyjnych i komu przekazać brakujące ustalenia.

Przypadek msaRAT uzasadnia wymaganie, by ocena ruchu przeglądarki obejmowała procesy i sposób użycia jej funkcji. Zaufana aplikacja powinna mieć jasno określony zakres dozwolonego działania, a monitoring powinien dostarczać danych do jego sprawdzenia. Od osób odpowiedzialnych za stacje robocze oczekujmy pokazania tego związku na konkretnym zapisie aktywności.

Źródła

Redakcja cyberinsight.pl.