Integrity Tech: alert AA26-281A i przegląd dostępu do poczty

8 października Departament Sprawiedliwości USA i FBI ogłosiły sądowe przejęcie domen obsługujących narzędzia Microscan i FishHub. Według dokumentów przywołanych w komunikacie używali ich aktorzy związani z Integrity Technology Group. Wśród celów skanowania wymieniono polskie lotniska — to informacja o rozpoznaniu, a nie potwierdzenie włamania do tych organizacji. Źródłem jest komunikat DOJ.

Wspólne ostrzeżenie AA26-281A, opublikowane przez australijskie ASD 9 października, opisuje łączenie automatycznego rozpoznania z ręcznymi działaniami oraz zbieraniem poczty i poświadczeń. Powiązania Integrity Tech z chińskim rządem są oceną autorów ostrzeżenia. Dokument wskazuje podobieństwa do aktywności Flax Typhoon, ale zastrzega, że nazwy i zbiory aktywności nie pokrywają się jeden do jednego. Zawiera wskaźniki kompromitacji i listę wykorzystywanych podatności. Źródło: wspólny advisory na stronie ASD.

Wniosek Breachroad: wykorzystaj ten alert jako powód do sprawdzenia dostępu do poczty i infrastruktury. Sam komunikat ani przejęcie domen nie rozstrzygają, czy konkretna firma jest bezpieczna lub została naruszona. Poniższy plan jest naszą rekomendacją organizacyjną.

Komu przekazać zadanie

Włącz osoby odpowiedzialne za pocztę, tożsamość, urządzenia brzegowe i reagowanie na incydenty. W małej organizacji mogą to być dwie osoby oraz dostawca IT. Ważniejsze od nazwy stanowiska jest ustalenie, kto potrafi pokazać rzeczywisty stan konfiguracji i kto może zatwierdzić zmianę.

Zacznij od krótkiej mapy: gdzie działa poczta, jakie usługi wystawiono do internetu, kto ma konta administracyjne i jakie połączenia zdalne są dopuszczone. Zapisz również systemy utrzymywane przez partnerów. Deklaracja „zajmuje się tym dostawca” nie odpowiada na pytanie, czy ktoś przeanalizuje alert i przedstawi wynik.

Przegląd poczty powinien kończyć się dowodem

Proponujemy cztery pytania do właściciela usługi:

1. Kto może wejść do skrzynki? Sprawdź aktywne konta, delegacje, uprawnienia aplikacji i dostęp serwisowy. Wyjaśnij każdą pozycję, której właściciela nie potrafisz wskazać.
2. Co pozwala utrzymać dostęp? Oceń działające sesje, mechanizmy uwierzytelniania i wyjątki od polityki logowania. Samo zapisanie wymogu MFA w dokumentacji nie potwierdza objęcia nim wszystkich dróg dostępu.
3. Gdzie mogą trafić wiadomości? Przejrzyj przekierowania, reguły skrzynki oraz integracje odczytujące jej zawartość. Uzasadnienie biznesowe powinno być aktualne i sprawdzalne.
4. Co widać w historii? Ustal dostępny okres logów, osoby analizujące zdarzenia i sposób eskalacji. Brak zapisu oznacza lukę w widoczności, a nie dowód braku incydentu.

To przykład przeglądu kontrolnego, nie kompletna procedura dochodzeniowa. Wynik zapisz wraz z datą, zakresem oraz ograniczeniami. „Nie znaleźliśmy nieprawidłowości w sprawdzonych danych” jest bardziej użyteczne niż ogólne „wszystko jest bezpieczne”.

Wskaźnik z alertu potrzebuje kontekstu

W naszej ocenie trafienie w wskaźnik warto potraktować jako początek analizy. Sprawdź czas zdarzenia, urządzenie, konto i proces oraz to, czy organizacja posiadała wtedy daną usługę. Rozróżnij zablokowaną próbę od działania, które rzeczywiście osiągnęło system.

Brak trafień też wymaga kontekstu: czy szukano we wszystkich istotnych źródłach i czy logi obejmowały właściwy okres? Nie dopisuj do wyniku wniosków, których dane nie pozwalają uzasadnić. Jeśli pojawią się oznaki nieautoryzowanego dostępu, przekaż sprawę do obsługi incydentu, zachowaj materiał i uzgodnij ograniczenie dostępu z zespołem reagowania.

Praktycznym wynikiem jest krótki zapis decyzji: sprawdzone systemy, dostępne dowody, otwarte pytania i osoba odpowiedzialna za każde dalsze działanie. Zalecamy przypisanie brakującym dowodom właściciela i terminu przeglądu, zamiast uznawania niepełnego wyszukiwania za zamkniętą sprawę.

Przykład do omówienia na szkoleniu

Administrator znajduje narzędzie zdalnego dostępu, które wygląda jak legalny produkt. Pracownik pamięta, że „ktoś z serwisu” prosił o jego uruchomienie, ale nie ma zgłoszenia ani wskazanego opiekuna. To hipotetyczny scenariusz szkoleniowy, nie opis ofiary z komunikatu.

Dobre pytania dotyczą zleceniodawcy, zatwierdzonego celu, czasu działania i dostępnych uprawnień. Zespół powinien umieć zgłosić rozbieżność bez samodzielnego kasowania śladów. Takie ćwiczenie łączy świadomość pracowników z decyzjami administratorów i pomaga uniknąć pozornego zamknięcia sprawy po usunięciu jednej aplikacji.

Szerszy sposób pracy z alertami opisujemy w przewodniku po cyklu threat intelligence. Jeśli chcesz przećwiczyć w firmie ocenę ostrzeżeń, zgłaszanie podejrzanych próśb i kontrolę dostępu, sprawdź szkolenia z cyberbezpieczeństwa dla organizacji.