Zelfstudie: Incidenten met UEBA-gegevens onderzoeken

Notitie

Azure Sentinel heet nu Microsoft Sentinel en we zullen deze pagina's in de komende weken bijwerken. Meer informatie over recente beveiligingsverbeteringen van Microsoft.

In dit artikel worden algemene methoden en voorbeeldprocedures beschreven voor het gebruik van UEBA (User Entity Behavior Analytics) in uw werkstromen voor normaal onderzoek.

Belangrijk

De genoteerde functies in dit artikel zijn momenteel beschikbaar als preview-versie. Zie de aanvullende gebruiksvoorwaarden voor Microsoft Azure Previews voor aanvullende juridische voorwaarden die van toepassing zijn op Azure-functies die bètaversies of preview-functies hebben of die nog niet algemeen beschikbaar zijn.

Notitie

Deze zelfstudie bevat op scenario's gebaseerde procedures voor een belangrijke klanttaak: onderzoeken met UEBA-gegevens. Zie Incidenten onderzoeken met Microsoft Sentinel voor meer informatie.

Vereisten

Voordat u UEBA-gegevens in uw onderzoek kunt gebruiken, moet u UEBA (User and Entity Behavior Analytics) inschakelen in Microsoft Sentinel.

Begin ongeveer één week na het inschakelen van UEBA te zoeken naar inzichten op basis van machines.

Proactieve, routinematige zoekopdrachten uitvoeren in entiteitsgegevens

We raden u aan om regelmatig, proactief te zoeken in gebruikersactiviteiten om leads te maken voor verder onderzoek.

U kunt de werkmap Microsoft Sentinel User and Entity Behavior Analytics gebruiken om query's uit te voeren op uw gegevens, zoals:

  • Meest riskante gebruikers, met afwijkingen of gekoppelde incidenten
  • Gegevens van specifieke gebruikers om te bepalen of het onderwerp inderdaad is gecompromitteerd of dat er sprake is van een bedreiging van binnenuit vanwege acties die afwijken van het profiel van de gebruiker.

Leg daarnaast niet-routinematige acties vast in de UEBA-werkmap en gebruik deze om afwijkende activiteiten en mogelijk niet-nalevingsprocedures te vinden.

Een afwijkende aanmelding onderzoeken

De volgende stappen volgen bijvoorbeeld het onderzoek van een gebruiker die verbinding heeft gemaakt met een VPN dat ze nog nooit eerder hebben gebruikt. Dit is een afwijkende activiteit.

  1. Zoek en open in het gebied Sentinel-werkmappen de werkmap User and Entity Behavior Analytics.

  2. Zoek een specifieke gebruikersnaam om te onderzoeken en selecteer hun naam in de tabel Top users to investigate.

  3. Blader omlaag door de tabellen Uitsplitsing van incidenten en Uitsplitsing van afwijkingen om de incidenten en afwijkingen te bekijken die zijn gekoppeld aan de geselecteerde gebruiker.

  4. Bekijk in de anomalie, zoals een met de naam Anomalous Successful Logon, de details die in de tabel worden weergegeven om te onderzoeken. Bijvoorbeeld:

    Stap Beschrijving
    Noteer de beschrijving aan de rechterkant Elke anomalie heeft een beschrijving, met een koppeling voor meer informatie in de MITRE ATT&CK Knowledge Base.
    Bijvoorbeeld:

    Initial Access _ _The adversary is trying to get *** into
    your network.*
    * Initial Access bestaat uit technieken die verschillende ingangsvectoren gebruiken om hun eerste voet aan de grond te krijgen binnen een netwerk. Technieken die worden gebruikt om voet aan de grond te krijgen, zijn onder andere gerichte spear phishing en het misbruiken van zwakke plekken op openbare webservers. Voetteksten die worden verkregen door de initiële toegang, kunnen zorgen voor voortdurende toegang, zoals geldige accounts en het gebruik van externe externe services, of kunnen beperkt worden gebruikt vanwege het wijzigen van wachtwoorden.*
    Noteer de tekst in de kolom Beschrijving Schuif in de anomalierij naar rechts om een aanvullende beschrijving weer te geven. Selecteer de koppeling om de volledige tekst te bekijken. Bijvoorbeeld:

    Aanvallers kunnen de referenties van een specifieke gebruiker of serviceaccount stelen met behulp van referentietoegangstechnieken of referenties vastleggen die eerder in hun reconnaissance-proces via social engineering zijn gemaakt om initiële toegang te krijgen. APT33 heeft bijvoorbeeld geldige accounts gebruikt voor initiële toegang. Met de onderstaande query wordt een uitvoer gegenereerd van een geslaagde aanmelding die wordt uitgevoerd door een gebruiker vanaf een nieuwe geografische locatie die hij nog nooit eerder heeft verbonden, en geen van zijn peers.
    Let op de UsersInsights-gegevens Schuif verder naar rechts in de anomalierij om de gebruikersinzichtgegevens weer te geven, zoals de weergavenaam van het account en de object-id van het account. Selecteer de tekst om de volledige gegevens aan de rechterkant weer te geven.
    Noteer de bewijsgegevens Schuif verder naar rechts in de anomalierij om de bewijsgegevens voor de anomalie weer te geven. Selecteer de tekstweergave van de volledige gegevens aan de rechterkant, zoals de volgende velden:

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

Gebruik de gegevens in de werkmap User and Entity Behavior Analytics om te bepalen of de gebruikersactiviteit verdacht is en verdere actie vereist.

UEBA-gegevens gebruiken om fout-positieven te analyseren

Soms is een incident dat is vastgelegd in een onderzoek een fout-positief.

Een veelvoorkomende voorbeeld van een fout-positief is wanneer een onmogelijke reisactiviteit wordt gedetecteerd, zoals een gebruiker die zich binnen hetzelfde uur heeft aangemeld bij een toepassing of portal vanuit Zowel New York als Londen. Hoewel Microsoft Sentinel de onmogelijke reis als een anomalie noteert, kan een onderzoek met de gebruiker verduidelijken dat een VPN is gebruikt met een alternatieve locatie waar de gebruiker zich daadwerkelijk bevindt.

Een fout-positief analyseren

Voor een incident met Onmogelijk traject bijvoorbeeld, nadat u met de gebruiker hebt bevestigd dat er een VPN is gebruikt, navigeert u van het incident naar de gebruikersentiteitspagina. Gebruik de gegevens die daar worden weergegeven om te bepalen of de vastgelegde locaties zijn opgenomen in de algemeen bekende locaties van de gebruiker.

Bijvoorbeeld:

Open de pagina gebruikersentiteiten van een incident.

De gebruikersentiteitspagina is ook gekoppeld vanaf de incidentpagina zelf en de onderzoeksgrafiek.

Tip

Nadat u de gegevens op de pagina met gebruikersentiteiten hebt bevestigd voor de specifieke gebruiker die aan het incident is gekoppeld, gaat u naar het gebied Microsoft Sentinel Hunting om te begrijpen of de peers van de gebruiker meestal ook verbinding maken vanaf dezelfde locaties. Als dat het geval is, is deze kennis nog sterker voor een fout-positief.

Voer in het gebied Hunting de query Voor aanmelding bij afwijkende geografische locatie uit. Zie Zoeken naar bedreigingen met Microsoft Sentinel voor meer informatie.

IdentityInfo-gegevens insluiten in uw analyseregels (openbare preview)

Omdat aanvallers vaak de eigen gebruikers- en serviceaccounts van de organisatie gebruiken, zijn gegevens over deze gebruikersaccounts, met inbegrip van de gebruikersidentificatie en bevoegdheden, van cruciaal belang voor de analisten in het proces van een onderzoek.

Sluit gegevens uit de tabel IdentityInfo in om uw analyseregels af te stemmen op uw gebruiksgevallen, fout-positieven te verminderen en uw onderzoeksproces mogelijk te versnellen.

Bijvoorbeeld:

  • Beveiligingsgebeurtenissen correleren met de tabel IdentityInfo in een waarschuwing die wordt geactiveerd als een server wordt gebruikt door iemand buiten de IT-afdeling:

    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"
    
  • Azure AD-aanmeldingslogboeken correleren met de tabel IdentityInfo in een waarschuwing die wordt geactiveerd als een toepassing wordt gebruikt door iemand die geen lid is van een specifieke beveiligingsgroep:

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

De tabel IdentityInfo wordt gesynchroniseerd met uw Azure AD-werkruimte om een momentopname te maken van uw gebruikersprofielgegevens, zoals gebruikersmetagegevens, groepsgegevens en Azure AD-rollen die aan elke gebruiker zijn toegewezen. Zie de tabel IdentityInfo in de naslaginformatie over UEBA-verrijkingen voor meer informatie.

Wachtwoordlak en spear phishing-pogingen identificeren

Als meervoudige verificatie (MFA) niet is ingeschakeld, zijn gebruikersreferenties kwetsbaar voor aanvallers die aanvallen willen aanvallen met wachtwoordslaking of spear phishing-pogingen.

Een wachtwoordlakincident onderzoeken met UEBA-inzichten

Als u bijvoorbeeld een incident met wachtwoordlaken met UEBA-inzichten wilt onderzoeken, kunt u het volgende doen voor meer informatie:

  1. Selecteer in het incident linksonder Onderzoeken om de accounts, machines en andere gegevenspunten weer te geven die mogelijk het doelwit waren van een aanval.

    Als u door de gegevens bladert, ziet u mogelijk een beheerdersaccount met een relatief groot aantal aanmeldingsfouten. Hoewel dit verdacht is, wilt u het account mogelijk niet beperken zonder verdere bevestiging.

  2. Selecteer de entiteit met beheerdersaccounts op de kaart en selecteer vervolgens Insights aan de rechterkant voor meer informatie, zoals de grafiek van aanmeldingen in de tijd.

  3. Selecteer Info aan de rechterkant en selecteer vervolgens Volledige details weergeven om naar de gebruikersentiteitspagina te gaan om verder in te zoomen.

    Let bijvoorbeeld op of dit het eerste Potential Wachtwoordspray-incident van de gebruiker is of bekijk de aanmeldingsgeschiedenis van de gebruiker om te begrijpen of de fouten afwijkende fouten zijn.

Tip

U kunt ook de query Voor het opzoeken van afwijkende mislukte aanmeldingen uitvoeren om alle afwijkende mislukte aanmeldingen van een organisatie te controleren. Gebruik de resultaten van de query om onderzoek te starten naar mogelijke wachtwoordaanvallen.

URL-detonatie (openbare preview)

Wanneer er URL's in de logboeken zijn opgenomen in Microsoft Sentinel, worden deze URL's automatisch gedetoneerd om het triageproces te versnellen.

De onderzoeksgrafiek bevat een knooppunt voor de gedetoneerde URL, evenals de volgende details:

  • DetonationVerdict. De Booleaanse bepaling op hoog niveau van de detonatie. Bad betekent bijvoorbeeld dat de zijde is geclassificeerd als het hosten van malware of phishing-inhoud.
  • DetonationFinalURL. De uiteindelijke, waargenomen landingspagina-URL, na alle omleidingen vanaf de oorspronkelijke URL.
  • DetonationScreenshot. Een schermopname van hoe de pagina eruit zag op het moment dat de waarschuwing werd geactiveerd. Selecteer de schermopname die u wilt vergroten.

Bijvoorbeeld:

Voorbeeld van URL-detonatie die wordt weergegeven in de onderzoeksgrafiek.

Tip

Als u geen URL's in uw logboeken ziet, controleert u of URL-logboekregistratie, ook wel bedreigingslogboeken genoemd, is ingeschakeld voor uw beveiligde webgateways, web-proxies, firewalls of verouderde IDS/IPS.

U kunt ook aangepaste logboeken maken om specifieke URL's die van belang zijn naar Microsoft Sentinel te kanaalen voor verder onderzoek.

Volgende stappen

Meer informatie over UEBA, onderzoeken en opsporing: