Samouczek: badanie zdarzeń przy użyciu danych ANALIZY UEBA

W tym artykule opisano typowe metody i przykładowe procedury dotyczące korzystania z analizy zachowania jednostek użytkownika (UEBA) w regularnych przepływach pracy badania.

Ważne

Zanotowane funkcje w tym artykule są obecnie dostępne w wersji zapoznawczej. Zapoznaj się z dodatkowymi warunkami użytkowania dla wersji zapoznawczych platformy Microsoft Azure , aby uzyskać dodatkowe postanowienia prawne dotyczące funkcji platformy Azure, które są w wersji beta, wersji zapoznawczej lub w inny sposób nie zostały jeszcze wydane w wersji ogólnodostępnej.

Uwaga

Ten samouczek zawiera procedury oparte na scenariuszach dla najważniejszego zadania klienta: badanie danych UEBA. Aby uzyskać więcej informacji, zobacz Badanie zdarzeń za pomocą usługi Microsoft Sentinel.

Wymagania wstępne

Przed rozpoczęciem korzystania z danych UEBA w badaniach należy włączyć analizę zachowań użytkowników i jednostek (UEBA) w usłudze Microsoft Sentinel.

Zacznij szukać szczegółowych informacji obsługiwanych przez maszynę około tygodnia po włączeniu analizy UEBA.

Uruchamianie proaktywnych, rutynowych wyszukiwań w danych jednostki

Zalecamy regularne, proaktywne wyszukiwanie za pośrednictwem aktywności użytkownika, aby utworzyć potencjalnych klientów w celu dalszego zbadania.

Możesz użyć skoroszytu Analizy zachowań użytkowników i jednostek usługi Microsoft Sentinel do wykonywania zapytań dotyczących danych, takich jak:

  • Najczęściej ryzykowni użytkownicy z anomaliami lub dołączonymi zdarzeniami
  • Dane dotyczące konkretnych użytkowników w celu ustalenia, czy podmiot rzeczywiście został naruszony, czy istnieje zagrożenie wewnętrzne spowodowane działaniem odbiegającym od profilu użytkownika.

Ponadto przechwyć nietypowe akcje w skoroszycie ANALIZY UEBA i użyj ich do znalezienia nietypowych działań i potencjalnie niezgodnych praktyk.

Badanie nietypowego logowania

Na przykład poniższe kroki są wykonywane zgodnie z badaniem użytkownika, który nawiązał połączenie z siecią VPN, której nigdy wcześniej nie używał, co jest nietypowym działaniem.

  1. W obszarze Skoroszyty usługi Sentinel wyszukaj i otwórz skoroszyt Analizy zachowań użytkowników i jednostek .

  2. Wyszukaj konkretną nazwę użytkownika, aby zbadać i wybrać ich nazwę w tabeli Najważniejsze użytkownicy, aby zbadać tabelę.

  3. Przewiń w dół tabele Podział zdarzeń i Podział anomalii , aby wyświetlić zdarzenia i anomalie skojarzone z wybranym użytkownikiem.

  4. W anomalii, na przykład o nazwie Anomalous Successful Logon, przejrzyj szczegóły wyświetlane w tabeli, aby zbadać. Przykład:

    Krok Opis
    Zanotuj opis po prawej stronie Każda anomalia zawiera opis z linkiem, aby dowiedzieć się więcej w baza wiedzy MITRE ATT&CK.
    Przykład:

    Dostęp początkowy
    Przeciwnik próbuje dostać się do sieci.
    Dostęp początkowy składa się z technik, które używają różnych wektorów wejścia w celu uzyskania początkowego przyczółka w sieci. Techniki używane do zdobycia przyczółka obejmują ukierunkowane wyłudzanie informacji i wykorzystanie słabych stron na publicznych serwerach internetowych. Przyczółki uzyskane za pośrednictwem początkowego dostępu mogą umożliwiać stały dostęp, taki jak prawidłowe konta i korzystanie z zewnętrznych usług zdalnych, lub mogą być ograniczone z powodu zmiany haseł.
    Zanotuj tekst w kolumnie Opis W wierszu anomalii przewiń w prawo, aby wyświetlić dodatkowy opis. Wybierz link, aby wyświetlić pełny tekst. Przykład:

    Przeciwnicy mogą ukraść poświadczenia określonego użytkownika lub konta usługi przy użyciu technik dostępu do poświadczeń lub przechwycić poświadczenia wcześniej w procesie rozpoznawczym za pomocą inżynierii społecznej w celu uzyskania dostępu początkowego. Na przykład apt33 używa prawidłowych kont do początkowego dostępu. Poniższe zapytanie generuje dane wyjściowe pomyślnego logowania wykonanego przez użytkownika z nowej lokalizacji geograficznej, z którą nigdy wcześniej nie nawiązał połączenia, i żaden z jego elementów równorzędnych.
    Zanotuj dane UsersInsights Przewiń w prawo w wierszu anomalii, aby wyświetlić dane szczegółowych informacji o użytkowniku, takie jak nazwa wyświetlana konta i identyfikator obiektu konta. Wybierz tekst, aby wyświetlić pełne dane po prawej stronie.
    Zanotuj dane dowodowe Przewiń w prawo w wierszu anomalii, aby wyświetlić dane dowodów dotyczące anomalii. Wybierz widok tekstu pełne dane po prawej stronie, takie jak następujące pola:

    - ActionUncommonlyPerformedByUser
    - NietypoweHighVolumeOfActions
    - FirstTimeUserConnectedFromCountry
    - CountryUncommonlyConnectedFromAmongPeers
    - FirstTimeUserConnectedViaISP
    - ISPUncommonlyUsedAmongPeers
    - CountryUncommonlyConnectedFromInTenant
    - ISPUncommonlyUsedInTenant

Użyj danych znalezionych w skoroszycie Analizy zachowań użytkowników i jednostek , aby określić, czy aktywność użytkownika jest podejrzana i wymaga dalszych działań.

Analizowanie wyników fałszywie dodatnich przy użyciu danych UEBA

Czasami zdarzenie przechwycone w dochodzeniu jest wynikiem fałszywie dodatnim.

Typowym przykładem fałszywie dodatniego wyniku jest wykrycie niemożliwego działania podróży, takiego jak użytkownik, który zalogował się do aplikacji lub portalu zarówno z Nowego Jorku, jak i Londynu w ciągu tej samej godziny. Chociaż usługa Microsoft Sentinel zauważa niemożliwą podróż jako anomalię, badanie z użytkownikiem może wyjaśnić, że sieć VPN została użyta z alternatywną lokalizacją, w której rzeczywiście był użytkownik.

Analizowanie wyników fałszywie dodatnich

Na przykład w przypadku zdarzenia Niemożliwe podróże po potwierdzeniu użytkownikowi, że sieć VPN została użyta, przejdź ze zdarzenia do strony jednostki użytkownika. Użyj wyświetlanych tam danych, aby określić, czy przechwycone lokalizacje znajdują się w powszechnie znanych lokalizacjach użytkownika.

Przykład:

Otwórz stronę jednostki użytkownika zdarzenia.

Strona jednostki użytkownika jest również połączona z samą stroną zdarzenia i wykresem badania.

Porada

Po potwierdzeniu danych na stronie jednostki użytkownika dla określonego użytkownika skojarzonego ze zdarzeniem przejdź do obszaru wyszukiwania zagrożeń usługi Microsoft Sentinel, aby dowiedzieć się, czy elementy równorzędne użytkownika zwykle łączą się z tych samych lokalizacji. Jeśli tak, ta wiedza sprawi, że wynik fałszywie dodatni będzie jeszcze silniejszy.

W obszarze Wyszukiwanie zagrożeń uruchom nietypowe zapytanie logowania do lokalizacji geograficznej . Aby uzyskać więcej informacji, zobacz Wyszukiwanie zagrożeń za pomocą usługi Microsoft Sentinel.

Osadzanie danych IdentityInfo w regułach analizy (publiczna wersja zapoznawcza)

Ponieważ osoby atakujące często używają własnych kont użytkowników i usług w organizacji, dane dotyczące tych kont użytkowników, w tym identyfikację i uprawnienia użytkownika, mają kluczowe znaczenie dla analityków w procesie badania.

Osadzanie danych z tabeli IdentityInfo w celu dostosowania reguł analitycznych do przypadków użycia, zmniejszenia liczby wyników fałszywie dodatnich i przyspieszenia procesu badania.

Przykład:

  • Aby skorelować zdarzenia zabezpieczeń z tabelą IdentityInfo w alercie, który jest wyzwalany, jeśli dostęp do serwera jest uzyskiwany przez osobę spoza działu IT :

    SecurityEvent
    | where EventID in ("4624","4672")
    | where Computer == "My.High.Value.Asset"
    | join kind=inner  (
        IdentityInfo
        | summarize arg_max(TimeGenerated, *) by AccountObjectId) on $left.SubjectUserSid == $right.AccountSID
    | where Department != "IT"
    
  • Aby skorelować dzienniki logowania Azure AD z tabelą IdentityInfo w alercie, który jest wyzwalany, jeśli aplikacja jest uzyskiwana przez osobę, która nie jest członkiem określonej grupy zabezpieczeń:

    SigninLogs
    | where AppDisplayName == "GithHub.Com"
    | join kind=inner  (
        IdentityInfo
        | summarize arg_max(TimeGenerated, *) by AccountObjectId) on $left.UserId == $right.AccountObjectId
    | where GroupMembership !contains "Developers"
    

Tabela IdentityInfo synchronizuje się z obszarem roboczym Azure AD w celu utworzenia migawki danych profilu użytkownika, takich jak metadane użytkownika, informacje o grupie i role Azure AD przypisane do każdego użytkownika. Aby uzyskać więcej informacji, zobacz Tabela IdentityInfo w dokumentacji wzbogaceń analizy UEBA.

Identyfikowanie spryskiwania haseł i prób wyłudzania informacji

Bez włączonego uwierzytelniania wieloskładnikowego (MFA) poświadczenia użytkownika są narażone na ataki atakujące, które chcą naruszyć ataki z użyciem spryskania haseł lub prób wyłudzania informacji .

Badanie incydentu sprayu haseł za pomocą szczegółowych informacji analizy UEBA

Aby na przykład zbadać incydent sprayu haseł za pomocą szczegółowych informacji ueBA, możesz wykonać następujące czynności, aby dowiedzieć się więcej:

  1. W zdarzeniu w lewym dolnym rogu wybierz pozycję Zbadaj , aby wyświetlić konta, maszyny i inne punkty danych, które były potencjalnie celem ataku.

    Przeglądając dane, możesz zobaczyć konto administratora z stosunkowo dużą liczbą niepowodzeń logowania. Chociaż jest to podejrzane, możesz nie chcieć ograniczyć konta bez dalszego potwierdzenia.

  2. Wybierz jednostkę użytkownika administracyjnego na mapie, a następnie wybierz pozycję Szczegółowe informacje po prawej stronie, aby znaleźć więcej szczegółów, takich jak wykres logowania się w czasie.

  3. Wybierz pozycję Informacje po prawej stronie, a następnie wybierz pozycję Wyświetl pełne szczegóły , aby przejść do strony jednostki użytkownika , aby przejść do szczegółów.

    Zwróć na przykład uwagę, czy jest to pierwszy potencjalny incydent sprayu haseł użytkownika, czy też obserwuj historię logowania użytkownika, aby dowiedzieć się, czy błędy były nietypowe.

Porada

Możesz również uruchomić zapytanie wyszukiwania nietypowych nieudanych logowań, aby monitorować wszystkie nietypowe nieudane logowania w organizacji. Użyj wyników zapytania, aby rozpocząć badanie możliwych ataków rozpytłania haseł.

Detonacja adresu URL (publiczna wersja zapoznawcza)

Jeśli w dziennikach pozyskanych do usługi Microsoft Sentinel znajdują się adresy URL, te adresy URL są automatycznie detonowane, aby przyspieszyć proces klasyfikacji.

Wykres Badanie zawiera węzeł dla zdetonowanego adresu URL, a także następujące szczegóły:

  • DetonationVerdict. Ogólne, logiczne określenie z detonacji. Na przykład Bad oznacza, że strona została sklasyfikowana jako hostowanie złośliwego oprogramowania lub wyłudzania informacji.
  • DetonationFinalURL. Ostatni, obserwowany adres URL strony docelowej, po wszystkich przekierowaniach z oryginalnego adresu URL.
  • DetonationScreenshot. Zrzut ekranu przedstawiający wygląd strony w momencie wyzwolenia alertu. Wybierz zrzut ekranu, aby powiększyć.

Przykład:

Przykładowa detonacja adresu URL wyświetlana na wykresie Badanie.

Porada

Jeśli w dziennikach nie widzisz adresów URL, sprawdź, czy rejestrowanie adresów URL, nazywane również rejestrowaniem zagrożeń, jest włączone dla bezpiecznych bram internetowych, internetowych serwerów proxy, zapór lub starszych identyfikatorów/adresów IP.

Możesz również utworzyć niestandardowe dzienniki, aby skierować interesujące cię adresy URL do usługi Microsoft Sentinel w celu dalszego zbadania.

Następne kroki

Dowiedz się więcej na temat analizy UEBA, badań i wyszukiwania zagrożeń: