Draaiboek voor phishingonderzoek

In dit artikel wordt een phishingplaybook gedemonstreert. Het maakt deel uit van de playbookrichtlijnen voor het reageren op incidenten in de SecOps-discipline (Security Operations ).

Dit playbook is bedoeld voor alle rollen die verantwoordelijk zijn voor het bouwen of uitvoeren van playbooks voor het reageren op incidenten, waaronder SecOps-analisten, incidentresponsers, identiteitsbeheerders en IT-medewerkers.

Phishing-aanvallen zijn een van de meest voorkomende initiële toegangstechnieken die worden gebruikt door aanvallers. Een geslaagde phishing-aanval kan leiden tot inbreuk op referenties, het uitvoeren van malware, het exfiltratie van gegevens en laterale verplaatsing in identiteits-, e-mail- en eindpuntomgevingen.

In de richtlijnen in dit artikel wordt beschreven wat u moet onderzoeken en waarom. Productspecifieke voorbeelden (zoals Microsoft Defender XDR of Microsoft Sentinel) worden geleverd als referentie-implementaties.

Voordat u begint

Voordat u een phishingonderzoek start, controleert u of aan de volgende basisvoorwaarden is voldaan. Deze vereisten moeten worden voltooid voordat een incident plaatsvindt als onderdeel van de planning van de reactie op incidenten.

Area Vereiste Bijzonderheden
Accountgegevens Ten minste één id hebben voor de vermoedelijke doelgebruiker Id's kunnen zijn: UPN (User Principal Name), e-mailadres of gebruikersnaam/alias.

Deze informatie is vereist om e-mailactiviteiten, aanmeldingen en downstreamacties te correleren.
Microsoft 365 controle/logboekregistratie Postvakcontrole moet in de hele organisatie zijn ingeschakeld om ervoor te zorgen dat postvaktoegang en acties worden vastgelegd. Controleer of postvakcontrole standaard is ingeschakeld door de volgende opdracht uit te voeren in Exchange Online PowerShell: Get-OrganizationConfig | Format-List AuditDisable/.

Een waarde false geeft aan dat postvakcontrole is ingeschakeld voor alle postvakken.
Microsoft 365 controle/logboekregistratie Logboeken voor berichttracering zijn vereist om het oorspronkelijke phishingbericht te identificeren, status af te leveren, alle geadresseerden, berichtrouteringsgegevens. Berichttracering is beschikbaar in het Exchange-beheercentrum en in het Microsoft Defender-portal (E-mail en samenwerking > Berichttracering in Exchange).

Om effectief te kunnen werken met berichttraceringsgegevens, moeten onderzoekers bericht-id-waarden kunnen ophalen en interpreteren, die worden verkregen uit onbewerkte e-mailheaders.
Microsoft 365 controle/logboekregistratie Geïntegreerde auditlogboeken zijn vereist voor het controleren van gebruikers- en beheeractiviteiten in Microsoft 365 workloads. Zorg ervoor dat onderzoekers in het geïntegreerde auditlogboek kunnen zoeken om acties zoals postvaktoegang, acties voor e-mailitems, beheerwijzigingen en aanmeldgebeurtenissen te controleren.
Microsoft Entra-logboeken Microsoft Entra ID aanmeldings- en auditlogboeken worden gedurende een beperkte periode bewaard (30 of 90 dagen, afhankelijk van de licentie). Ter ondersteuning van onderzoeken, historische analyse en incidentbeoordeling exporteert u logboeken naar een langetermijnopslagplaats, zoals Microsoft Sentinel, Azure Monitor of een SIEM van derden.
toestemmingen Zorg ervoor dat onderzoekers over voldoende machtigingen beschikken om toegang te krijgen tot vereiste gegevens zonder accounts die te veel bevoegdheden hebben. Microsoft Entra ID: minimale aanbevolen rol is Beveiligingslezer.

Defender portal en Microsoft complianceportal: Beveiligingslezer.

Deze rollen bieden alleen-lezentoegang tot e-mail, waarschuwingen en controlegegevens.
Zichtbaarheid van eindpunt Microsoft Defender voor Endpoint Als Defender voor Eindpunt is geïnstalleerd, gebruikt u deze om:

- Controleer of gebruikers interactie hebben gehad met phishing-inhoud.
- Identificeer de uitvoering van de payload.
- Eindpuntactiviteit correleren met e-mailgebeurtenissen.
Hardware Een systeem dat PowerShell kan uitvoeren.
Software Deze PowerShell-modules worden vaak gebruikt tijdens phishingonderzoeken Microsoft Graph PowerShell SDK
Exchange Online PowerShell-module
Microsoft Entra Incident Response PowerShell-module.

Zorg ervoor dat alle modules zijn geïnstalleerd en up-to-date blijven.

Werkproces

De werkstroom voor phishingonderzoek volgt deze fasen op hoog niveau:

  1. Identificeer en bevestig het phishingbericht.
  2. Bepaal de impact en de getroffen gebruikers.
  3. Gebruikersinteractie en referentieblootstelling beoordelen.
  4. Identificeer downstreamactiviteit.
  5. Dreiging indammen en herhaling voorkomen

Deze werkstroom helpt reagerende gebruikers te verplaatsen van detectie naar insluiting zonder kritieke validatiestappen te overslaan.

Wat u moet controleren

Gebruik deze controlelijst als een kwaliteitspoort tijdens het onderzoek.

  • De phishing-e-mail en de oorspronkelijke bericht-id identificeren
  • Bepaal alle ontvangers en de bezorgingsstatus
  • Bepalen of gebruikers interactie hebben gehad met het bericht
  • Compromittering van inloggegevens of uitvoering van malware beoordelen
  • Laterale of vervolgactiviteit identificeren
  • Schadelijke berichten uit postvakken verwijderen
  • Betrokken accounts opnieuw instellen of beveiligen
  • Detecties en preventiecontroles verbeteren

Onderzoeksstappen

Stap 1: Het phishingbericht identificeren

  1. Haal de verdachte phishing-e-mail op.

  2. Haal de Message-ID uit de e-mailheaders.

  3. Gebruik berichttracering om het volgende te bepalen:

    • Wanneer het bericht is ontvangen
    • Welke gebruikers deze hebben ontvangen
    • Of het is afgeleverd, geblokkeerd of in quarantaine is gezet

Stap 2: Breng betrokken gebruikers in kaart

  1. Alle geadresseerden van het bericht identificeren
  2. Controleer of het bericht filters heeft omzeild
  3. Bepalen of vergelijkbare berichten zijn verzonden met behulp van varianten van dezelfde campagne

Stap 3: Gebruikersinteractie evalueren

  1. Bepaal voor elke betrokken gebruiker of ze:

    • Het e-mailbericht geopend
    • Op koppelingen geklikt
    • Geopende bijlagen
    • Ingediende referenties

    E-mailactiviteit correleren met:

    • Microsoft Entra-aanmeldingslogboeken
    • Controlelogboeken
    • Eindpuntactiviteit (indien beschikbaar)

Stap 4: Volgactiviteit identificeren

  1. Als inloggegevens mogelijk zijn blootgesteld, onderzoek dan het volgende:

    • Verdachte aanmeldingen
    • Wachtwoordspray- of brute-forceactiviteit
    • OAuth-toestemming verleent
    • Tokenmisbruik
    • Ongebruikelijke postvak- of samenwerkingsactiviteit

  2. Als bijlagen zijn geopend, controleert u of er malware wordt uitgevoerd op eindpunten.

Stap 5: Bevatten en herstellen

Op basis van bevindingen:

  1. Verwijder phishingberichten uit alle postvakken. Uitschakelen of opnieuw instellen.
  2. gekaapte accounts.
  3. Actieve sessies en tokens intrekken.
  4. Blokkeer schadelijke afzenders, domeinen en URL's.
  5. Betrokken eindpunten isoleren of herstellen.

Stap 6: Herstel

Na insluiting kunt u zich richten op het herstellen van normale bewerkingen en het verminderen van het terugkeerrisico.

Herstelacties kunnen bestaan uit:

  • Het opnieuw instellen van aanmeldingsgegevens en het afdwingen van multifactorauthenticatie
  • Postvakregels en doorstuurinstellingen controleren
  • E-mailfilters en antiphishingbeleid verbeteren
  • Detecties en waarschuwingen bijwerken
  • Playbooks voor phishing-reacties bijwerken of verfijnen

Volgende stappen 

Meer informatie over de SecOps-discipline.

  • Last updated on