Phishing & Business Email Compromise
Phishing & Business Email Compromise
Structured response playbook for suspected or confirmed phishing, credential theft and BEC — from early detection and containment to identity hardening, secure recovery and lessons learned.
Strukturiertes Reaktions-Playbook für vermutete oder bestätigte Phishing-, Credential-Theft- und BEC-Vorfälle — von früher Erkennung und Eindämmung über Identity-Härtung bis zur sicheren Wiederherstellung und Lessons Learned.
Use this playbook when one or more of the following are present:
- A user reports a suspicious email or link.
- A user clicked a suspected phishing link or opened an attachment.
- Credentials may have been entered on a suspected phishing page.
- A mailbox shows unusual sign-in activity.
- Unexpected MFA prompts or approvals are reported.
- Suspicious inbox rules, forwarding or delegates are found.
- Unauthorised emails have been sent from a legitimate account.
- Vendor or customer contacts report messages appearing to originate from your organisation.
- Fraudulent payment instructions, payroll redirection or supplier-bank changes are detected.
- A compromised mailbox is being used for impersonation.
Covers classic email-phishing and modern cloud/identity abuse (OAuth consent abuse, token/session misuse) where no malware is necessarily involved.
Default severity: High. Escalate to Critical if: privileged/admin/executive/finance/HR/system accounts are affected; mailbox is sending further phishing; payment fraud or confirmed financial loss occurred or is imminent; multiple accounts, tenants or cloud identities are affected; evidence of data exfiltration; or persistent access via OAuth, forwarding, inbox rules or tokens remains after a password change.
Incident objectives (first hours): Stop ongoing abuse · Secure identities, sessions and communication channels · Preserve evidence and maintain a reliable timeline · Determine scope, initial access vector and business impact · Minimise financial, privacy and operational damage · Conclude incident with tracked remediation and lessons learned.
Core principles: Treat suspected identity compromise as identity-first — examine sessions/tokens before assuming a password-only fix is sufficient. Separate confirmed facts from hypotheses. Preserve volatile evidence before destructive remediation. Centralise communication and coordinate Finance early for BEC risk. Include tokens, OAuth consents and app permissions in scope for cloud identities. Do not rely on a password change alone unless persistent sessions and consents have been invalidated.
Identity-first focus
- Successful/failing sign-ins, location/device anomalies.
- MFA events: approvals, denials, fatigue patterns, new factor registrations.
- Session/refresh token activity and revocations.
- Password resets and changes to recovery options.
- Privileged and business-critical accounts (executive, finance, HR, admin).
- OAuth consents, enterprise apps and app permissions.
Roles & Responsibilities
- Incident Commander: overall coordination, severity decisions, executive escalation.
- Identity & Access Lead: sessions/tokens, MFA, OAuth consents, account actions.
- Email / Collaboration Lead: headers/rules/forwarding, quarantine/remove messages.
- Endpoint/Security Analyst: endpoint telemetry for malware or credential theft.
- Finance / Business Owner: verify/stop payment flows, validate supplier or bank changes.
- Legal / Privacy / Compliance: regulatory and notification obligations.
Verwenden Sie dieses Playbook, wenn einer oder mehrere der folgenden Punkte vorliegen:
- Ein Benutzer meldet eine verdächtige E-Mail oder einen verdächtigen Link.
- Ein Benutzer hat auf einen mutmaßlichen Phishing-Link geklickt oder einen Anhang geöffnet.
- Zugangsdaten wurden möglicherweise auf einer mutmaßlichen Phishing-Seite eingegeben.
- Eine Mailbox zeigt ungewöhnliche Anmeldeaktivität.
- Unerwartete MFA-Prompts oder Bestätigungen werden gemeldet.
- Verdächtige Inbox-Regeln, Weiterleitungen oder Delegationen werden gefunden.
- Unautorisierte E-Mails wurden von einem legitimen Konto versendet.
- Lieferanten- oder Kundenkontakte melden Nachrichten, die aus Ihrer Organisation zu stammen scheinen.
- Betrügerische Zahlungsanweisungen, Gehaltsumleitungen oder Änderungen an Lieferanten-Bankdaten werden festgestellt.
- Eine kompromittierte Mailbox wird für Identitätsmissbrauch verwendet.
Deckt klassische E-Mail-Phishing-Angriffe und moderne Cloud-/Identity-Missbrauchsfälle ab (OAuth-Consent-Abuse, Token-/Session-Missbrauch), bei denen nicht zwingend Malware beteiligt ist.
Standard-Schweregrad: Hoch. Auf Kritisch eskalieren, wenn: privilegierte/Admin-/Executive-/Finance-/HR-/Systemkonten betroffen sind; Mailbox weitere Phishing-Mails versendet; Zahlungsbetrug oder bestätigter finanzieller Schaden eingetreten oder unmittelbar wahrscheinlich ist; mehrere Konten, Tenants oder Cloud-Identitäten betroffen sind; Anzeichen für Datenexfiltration vorliegen; oder persistenter Zugriff über OAuth, Weiterleitungen, Inbox-Regeln oder Tokens nach einem Passwortwechsel fortbesteht.
Incident-Ziele (erste Stunden): Laufenden Missbrauch stoppen · Identitäten, Sessions und Kommunikationskanäle absichern · Beweise sichern und eine belastbare Timeline führen · Umfang, initialen Angriffsvektor und Business-Impact bestimmen · Finanzielle, datenschutzrechtliche und operative Schäden minimieren · Den Vorfall mit nachverfolgter Remediation und Lessons Learned abschließen.
Kernprinzipien: Behandeln Sie vermuteten Identitätsmissbrauch als Identity-First-Thema — prüfen Sie Sessions/Tokens, bevor Sie von einer reinen Passwortlösung ausgehen. Trennen Sie bestätigte Fakten von Hypothesen. Sichern Sie volatile Beweise vor destruktiver Remediation. Zentralisieren Sie die Kommunikation und binden Sie Finance bei BEC-Risiken früh ein. Beziehen Sie bei Cloud-Identitäten Tokens, OAuth-Consents und App-Permissions mit ein. Verlassen Sie sich nicht auf einen Passwortwechsel allein, solange persistente Sessions und Consents nicht invalidiert wurden.
Identity-First-Fokus
- Erfolgreiche/fehlgeschlagene Anmeldungen, Standort-/Geräte-Anomalien.
- MFA-Ereignisse: Bestätigungen, Ablehnungen, Fatigue-Muster, neue Faktorregistrierungen.
- Session-/Refresh-Token-Aktivität und Widerrufe.
- Passwort-Resets und Änderungen an Recovery-Optionen.
- Privilegierte und geschäftskritische Konten (Executive, Finance, HR, Admin).
- OAuth-Consents, Enterprise-Apps und App-Permissions.
Rollen & Verantwortlichkeiten
- Incident Commander: Gesamtkoordination, Schweregrad, Eskalation.
- Identity & Access Lead: Sessions/Tokens, MFA, OAuth-Consents, Kontomaßnahmen.
- Email / Collaboration Lead: Header/Regeln/Weiterleitungen, Quarantäne/Entfernung.
- Endpoint/Security Analyst: Endpoint-Telemetrie auf Malware oder Credential-Theft.
- Finance / Business Owner: Zahlungsflüsse prüfen/stoppen, Lieferanten-/Bankdatenänderungen validieren.
- Legal / Privacy / Compliance: regulatorische und Meldepflichten.
▸ Act immediately
- Activate Incident Response Lead / Incident Commander.
- Start an incident timeline and decision log (who, what, when, why).
- Identify the affected account(s), mailbox, device, and the reported phishing item.
- Determine whether links were clicked, attachments opened or credentials submitted.
- Revoke suspicious sessions/tokens if compromise is likely.
- Preserve original message(s) with full headers, URLs, attachment hashes and screenshots.
- Search for similar messages across the tenant.
- Notify Finance / Legal / Management immediately if payments, payroll or executive impersonation are involved.
- Check mailbox rules, forwarding, delegates and OAuth app consents.
- Prepare containment actions (quarantine emails, block URLs, tenant search).
Do not
- Delete the original message before preserving evidence.
- Assume the incident is limited to the reporting user.
- Reset passwords without considering sessions/tokens and persistence.
- Trust mailbox content until rules, delegates and sent items have been reviewed.
- Communicate root cause, data exposure or financial impact externally until verified.
▸ Sofort handeln
- Incident-Response-Lead / Incident Commander aktivieren.
- Eine Incident-Timeline und ein Entscheidungsprotokoll starten (wer, was, wann, warum).
- Das betroffene Konto bzw. die betroffene Mailbox, das Gerät und das gemeldete Phishing-Objekt identifizieren.
- Feststellen, ob Links angeklickt, Anhänge geöffnet oder Zugangsdaten eingegeben wurden.
- Verdächtige Sessions/Tokens widerrufen, wenn eine Kompromittierung wahrscheinlich ist.
- Die Originalnachricht(en) mit vollständigen Headern, URLs, Anhang-Hashes und Screenshots sichern.
- Nach ähnlichen Nachrichten im Tenant suchen.
- Finance / Legal / Management sofort benachrichtigen, wenn Zahlungen, Payroll oder Executive-Impersonation betroffen sind.
- Mailbox-Regeln, Weiterleitungen, Delegationen und OAuth-App-Consents prüfen.
- Eindämmungsmaßnahmen vorbereiten (E-Mails quarantänisieren, URLs blockieren, tenantweite Suche).
Nicht tun
- Die Originalnachricht löschen, bevor Beweise gesichert wurden.
- Davon ausgehen, dass der Vorfall nur den meldenden Benutzer betrifft.
- Passwörter zurücksetzen, ohne Sessions/Tokens und Persistenz zu berücksichtigen.
- Mailbox-Inhalten vertrauen, bevor Regeln, Delegationen und Sent Items geprüft wurden.
- Root Cause, Datenexposition oder finanziellen Schaden extern kommunizieren, bevor dies verifiziert ist.
Rule 1 — Lock account or monitor?
■ Lock / restrict immediately if
- Credentials were entered on a phishing page.
- Suspicious successful logins, token misuse, or account takeover indicators exist.
- Mailbox sends suspicious messages or shows rule/forwarding manipulation.
- The account is privileged, executive or finance-related.
▲ Monitor only if
- No successful compromise is visible.
- Locking would significantly hinder evidence collection.
- Incident Commander explicitly approves.
Rule 2 — Is password reset enough?
■ No — also required if
- Sessions/tokens remain active.
- OAuth consents / app permissions persist.
- Inbox rules, forwards or delegates were added.
- Attacker persistence or secondary access paths exist.
Also revoke sessions, rotate tokens and remove app consents.
■ Rule 3 — Endpoint forensics?
Yes if: attachment was opened or executable run; browser-based credential entry with stored sessions suspected; endpoint shows infostealer/downloader indicators; user has admin privileges or access to sensitive resources.
No (focus cloud/identity) if: evidence points purely to OAuth/session abuse or credential submission without local execution.
Rule 4 — Stop finance process immediately? Yes if: payment instructions, supplier-bank changes or payroll redirection are suspected; an approval is pending or soon to be executed; communication trails show manipulated instructions.
Rule 5 — Can we recover now? Only if: (1) Attack path is understood. (2) Accounts, sessions, tokens, forwards and OAuth consents are cleaned. (3) No evidence of ongoing misuse. (4) Monitoring and communications for follow-on waves are active.
Regel 1 — Konto sperren oder beobachten?
■ Sofort sperren / einschränken, wenn
- Zugangsdaten auf einer Phishing-Seite eingegeben wurden.
- Verdächtige erfolgreiche Anmeldungen, Token-Missbrauch oder Kontoübernahme-Indikatoren vorliegen.
- Die Mailbox verdächtige Nachrichten versendet oder Manipulationen an Regeln/Weiterleitungen zeigt.
- Das Konto privilegiert, Executive- oder Finance-bezogen ist.
▲ Nur beobachten, wenn
- Kein erfolgreicher Missbrauch sichtbar ist.
- Eine Sperrung die Beweissicherung erheblich beeinträchtigen würde.
- Der Incident Commander ausdrücklich zustimmt.
Regel 2 — Reicht ein Passwort-Reset?
■ Nein — auch erforderlich, wenn
- Sessions/Tokens weiterhin aktiv sind.
- OAuth-Consents / App-Permissions fortbestehen.
- Inbox-Regeln, Weiterleitungen oder Delegationen hinzugefügt wurden.
- Angreifer-Persistenz oder sekundäre Zugriffspfade bestehen.
Zusätzlich: Sessions widerrufen, Tokens rotieren und App-Consents entfernen.
■ Regel 3 — Endpoint-Forensik?
Ja wenn: Anhang geöffnet oder ausführbare Datei gestartet wurde; Browser-basierte Credential-Eingabe mit gespeicherten Sessions vermutet wird; Endpoint Infostealer/Downloader-Indikatoren zeigt; Benutzer lokale Adminrechte oder Zugang zu sensiblen Ressourcen hat.
Nein (Fokus Cloud/Identity), wenn: Hinweise ausschließlich auf OAuth-/Session-Missbrauch oder Credential Submission ohne lokale Ausführung deuten.
Regel 4 — Finanzprozess sofort stoppen? Ja, wenn: Zahlungsanweisungen, Lieferanten-Bankänderungen oder Payroll-Umleitungen verdächtig sind; eine Freigabe ansteht oder kurz vor Ausführung steht; Kommunikationsverläufe manipulierte Anweisungen zeigen.
Regel 5 — Können wir jetzt wiederherstellen? Nur wenn: (1) Der Angriffsweg verstanden ist. (2) Konten, Sessions, Tokens, Weiterleitungen und OAuth-Consents bereinigt sind. (3) Keine Hinweise auf fortbestehenden Missbrauch vorliegen. (4) Monitoring und Kommunikation für Folgewellen aktiv sind.
- Collect user reports, gateway/quarantine entries, SIEM, IdP and endpoint telemetry.
- Preserve original message(s) with full headers and artifacts.
- Determine click/credential/attachment interactions.
- Identify affected accounts, mailboxes and recipients.
- Review sign-in logs, MFA events, session activity and OAuth consent logs.
- Search for similar messages or compromise patterns across the tenant.
- Check mailbox audit, sent items and recoverable items for attacker activity.
- Note whether the message was internal or from an external address.
- Build and maintain an incident timeline.
▸ Email & communication protection
- Check inbox rules, forwarding and delegates — attackers abuse mailbox config, not just sign-ins.
- Run tenant-wide search for similar messages.
- Check spoofing/Reply-To anomalies and headers.
- Notify external recipients if compromised mailbox sent malicious messages.
- Review message threads for fraud indicators (bank data changes, invoice manipulations).
Exit criteria
- Incident type validated.
- Initial scope identified.
- Potentially compromised accounts flagged.
- Evidence preservation started.
- Benutzerberichte, Gateway-/Quarantäne-Einträge, SIEM-, IdP- und Endpoint-Telemetrie sammeln.
- Originalnachricht(en) mit vollständigen Headern und Artefakten sichern.
- Klick-/Credential-/Anhangs-Interaktionen feststellen.
- Betroffene Konten, Mailboxen und Empfänger identifizieren.
- Anmelde-Logs, MFA-Ereignisse, Session-Aktivität und OAuth-Consent-Logs prüfen.
- Nach ähnlichen Nachrichten oder Kompromittierungsmustern im Tenant suchen.
- Mailbox-Audit, Sent Items und Recoverable Items auf Angreiferaktivität prüfen.
- Dokumentieren, ob die Nachricht intern oder extern versendet wurde.
- Eine Incident-Timeline aufbauen und fortführen.
▸ E-Mail- und Kommunikationsschutz
- Inbox-Regeln, Weiterleitungen und Delegationen prüfen — Angreifer missbrauchen oft die Mailbox-Konfiguration, nicht nur Anmeldungen.
- Tenantweit nach ähnlichen Nachrichten suchen.
- Spoofing-/Reply-To-Anomalien und Header-Prüfungen durchführen.
- Externe Empfänger benachrichtigen, wenn die kompromittierte Mailbox bösartige Nachrichten gesendet hat.
- Nachrichtenverläufe auf Fraud-Indikatoren prüfen (Bankdatenänderungen, Rechnungsmanipulationen).
Exit-Kriterien
- Vorfallsart validiert.
- Anfangs-Umfang identifiziert.
- Potenziell kompromittierte Konten markiert.
- Beweissicherung begonnen.
- Temporarily restrict or disable affected accounts.
- Revoke sessions and refresh tokens.
- Reset passwords when credential theft is likely.
- Remove unauthorized OAuth consents and enterprise apps.
- Remove malicious inbox rules, forwarding and delegates.
- Search tenant-wide and quarantine/remove malicious messages where possible.
- Block malicious domains, URLs, IPs, hashes at gateway and network level.
- Temporarily restrict outbound mail for compromised accounts if they're sending abuse.
- Engage Finance to pause risky payments and verify changes.
- Isolate endpoints if attachments/local artifacts are suspected.
Do not
- Assume password change alone resolves the problem.
- Focus only on the reporting mailbox if tenant-wide spread is possible.
- Delete evidence before it is preserved.
- Continue payment approvals when BEC risk exists without out-of-band verification.
Exit criteria
- Ongoing abuse reduced or stopped.
- Compromised accounts or channels secured.
- Message spread technically limited.
- Appropriate business owners informed (Finance, Legal).
- Betroffene Konten vorübergehend einschränken oder deaktivieren.
- Sessions und Refresh-Tokens widerrufen.
- Passwörter zurücksetzen, wenn Credential Theft wahrscheinlich ist.
- Unautorisierte OAuth-Consents und Enterprise-Apps entfernen.
- Bösartige Inbox-Regeln, Weiterleitungen und Delegationen entfernen.
- Tenantweit suchen und bösartige Nachrichten, soweit möglich, quarantänisieren/entfernen.
- Bösartige Domains, URLs, IPs, Hashes auf Gateway- und Netzwerkebene blockieren.
- Ausgehende E-Mails kompromittierter Konten vorübergehend einschränken, wenn sie Missbrauch versenden.
- Finance einbinden, um riskante Zahlungen zu pausieren und Änderungen zu verifizieren.
- Endpunkte isolieren, wenn Anhangs-/Lokalartefakte vermutet werden.
Nicht tun
- Nicht davon ausgehen, dass ein Passwortwechsel allein genügt.
- Nicht nur die meldende Mailbox betrachten, wenn eine tenantweite Ausbreitung möglich ist.
- Beweise nicht löschen, bevor sie gesichert wurden.
- Zahlungsfreigaben nicht fortsetzen, wenn BEC-Risiko ohne Out-of-Band-Verifikation besteht.
Exit-Kriterien
- Laufender Missbrauch reduziert oder gestoppt.
- Kompromittierte Konten oder Kanäle gesichert.
- Nachrichtenausbreitung technisch begrenzt.
- Zuständige Geschäftsverantwortliche informiert (Finance, Legal).
- Analyze headers, SPF/DKIM/DMARC, Reply-To, redirect chains and attachment artifacts.
- Review sign-in logs for geolocation anomalies, device changes or risky sign-ins.
- Examine MFA events (approvals, denials, unusual patterns).
- Evaluate session/token behaviour and refresh activity.
- Analyze OAuth/consent events and app permissions.
- Investigate mailbox-audit logs (send-as/send-on-behalf, deletions, searches).
- Identify recipients who received/opened/responded.
- Search for related messages across tenants and external domains.
- Assess whether data stores (OneDrive, SharePoint, file shares) were accessed.
- Review endpoint telemetry when local compromise is suspected.
▸ Scope documentation categories
- Affected accounts & mailboxes
- Affected users/roles and recipients
- Tokens, sessions, apps, OAuth consents
- Financial/process impacts
- Data stores and files accessed
- Endpoints implicated
Exit criteria
- Plausible attack path established.
- Compromised accounts, sessions and misconfigurations enumerated.
- Fraud/data impact assessed to plan eradication.
- Header, SPF/DKIM/DMARC, Reply-To, Redirect-Ketten und Anhangsartefakte analysieren.
- Anmelde-Logs auf Geolocation-Anomalien, Gerätewechsel oder riskante Anmeldungen prüfen.
- MFA-Ereignisse untersuchen (Bestätigungen, Ablehnungen, ungewöhnliche Muster).
- Session-/Token-Verhalten und Refresh-Aktivität auswerten.
- OAuth-/Consent-Ereignisse und App-Permissions analysieren.
- Mailbox-Audit-Logs untersuchen (Send-As/Send-on-behalf, Löschungen, Suchen).
- Empfänger identifizieren, die die Nachricht erhalten, geöffnet oder beantwortet haben.
- Nach verwandten Nachrichten in Tenants und externen Domains suchen.
- Prüfen, ob Datenablagen (OneDrive, SharePoint, File Shares) zugegriffen wurden.
- Endpoint-Telemetrie prüfen, wenn lokale Kompromittierung vermutet wird.
▸ Dokumentationskategorien für den Umfang
- Betroffene Konten & Mailboxen
- Betroffene Benutzer/Rollen und Empfänger
- Tokens, Sessions, Apps, OAuth-Consents
- Finanz-/Prozessauswirkungen
- Zugegriffene Datenablagen und Dateien
- Betroffene Endpunkte
Exit-Kriterien
- Plausibler Angriffspfad etabliert.
- Kompromittierte Konten, Sessions und Fehlkonfigurationen aufgeführt.
- Fraud-/Daten-Impact bewertet, um die Beseitigung zu planen.
- Perform controlled password resets.
- Invalidate active sessions and refresh tokens tenant-wide for affected users.
- Remove unauthorized OAuth grants, enterprise apps and app-consents.
- Remove inbox rules, forwards, delegates and reply-to manipulations.
- Review and reset recovery methods, MFA factors and self-service settings.
- Rotate API tokens, app secrets and stored credentials if exposed.
- Rebuild or remediate endpoints if local compromise cannot be trusted.
- Harden gateway/tenant/IdP protections and detection rules.
- Adjust payment-verification processes where BEC/fraud was involved.
Exit criteria
- Access paths removed.
- Mailbox and identity configuration cleaned.
- Sessions/tokens/app access no longer active.
- Compensating protections implemented.
- Kontrollierte Passwort-Resets durchführen.
- Aktive Sessions und Refresh-Tokens tenantweit für betroffene Benutzer invalidieren.
- Unautorisierte OAuth-Consents, Enterprise-Apps und App-Consents entfernen.
- Inbox-Regeln, Weiterleitungen, Delegationen und Reply-To-Manipulationen entfernen.
- Recovery-Methoden, MFA-Faktoren und Self-Service-Einstellungen prüfen und zurücksetzen.
- API-Tokens, App-Secrets und gespeicherte Zugangsdaten rotieren, wenn sie exponiert wurden.
- Endpunkte neu aufbauen oder remediieren, wenn lokale Kompromittierung nicht als vertrauenswürdig gilt.
- Gateway-/Tenant-/IdP-Schutz und Detection-Regeln härten.
- Zahlungsprüfprozesse anpassen, wenn BEC/Fraud beteiligt war.
Exit-Kriterien
- Zugriffspfade entfernt.
- Mailbox- und Identity-Konfiguration bereinigt.
- Sessions/Tokens/App-Zugriff nicht mehr aktiv.
- Ausgleichsmaßnahmen implementiert.
▸ Recovery gate — do NOT recover until
- Attack path is sufficiently understood.
- Accounts, sessions, tokens and forwarding/OAuth consents are cleaned.
- Active misuse indicators are absent.
- Monitoring, detection and communications for follow-up waves are in place.
- Re-enable accounts in a controlled manner.
- Re-establish or strengthen MFA (prefer phishing-resistant options for high-risk users).
- Inform users of safe re-start steps and any forced changes (passwords, MFA).
- Notify partners, customers or vendors if they were affected by messages.
- Increase monitoring for re-entry signs for 14–30 days.
- Continue tenant searches for related messages or indicators.
- Validate endpoints/browsers where relevant before normal operations resume.
Exit criteria
- Accounts and channels are deemed trusted.
- No active abuse indicators remain.
- Business processes are stable and owners assigned for residual risks.
▸ Recovery-Gate — NICHT wiederherstellen, bevor
- Der Angriffspfad hinreichend verstanden ist.
- Konten, Sessions, Tokens und Weiterleitungs-/OAuth-Consents bereinigt sind.
- Aktive Missbrauchsindikatoren fehlen.
- Monitoring, Detection und Kommunikation für Folgewellen eingerichtet sind.
- Konten kontrolliert wieder aktivieren.
- MFA neu etablieren oder stärken (für Hochrisiko-Benutzer möglichst phishing-resistente Optionen bevorzugen).
- Benutzer über sichere Wiederaufnahme und ggf. erzwungene Änderungen informieren (Passwörter, MFA).
- Partner, Kunden oder Lieferanten benachrichtigen, wenn sie betroffen waren.
- Das Monitoring auf erneute Angriffsindikatoren für 14–30 Tage erhöhen.
- Tenantweite Suchen nach verwandten Nachrichten oder Indikatoren fortsetzen.
- Endpunkte/Browser, wo relevant, validieren, bevor der Normalbetrieb wieder aufgenommen wird.
Exit-Kriterien
- Konten und Kanäle gelten als vertrauenswürdig.
- Keine aktiven Missbrauchsindikatoren mehr vorhanden.
- Geschäftsprozesse stabil und Verantwortliche für Rest-Risiken benannt.
- Conduct a structured post-incident review within 5–10 business days of stabilization.
- Finalize the incident timeline and decision log.
- Confirm the attack path, message patterns and scope.
- Identify control weaknesses in mail security, identity, MFA, conditional access, fraud workflows and user awareness.
- Evaluate response performance of Helpdesk, Security, Finance, Legal and Management.
- Update detection rules, mailbox protections and tenant-hardening measures.
- Strengthen payment verification and supplier change procedures.
- Update this playbook with lessons learned and assign remediation owners with due dates.
- Innerhalb von 5–10 Geschäftstagen nach Stabilisierung eine strukturierte Nachbesprechung durchführen.
- Incident-Timeline und Entscheidungsprotokoll finalisieren.
- Angriffspfad, Nachrichtenmuster und Umfang bestätigen.
- Kontrollschwächen in Mail-Security, Identity, MFA, Conditional Access, Fraud-Workflows und Awareness identifizieren.
- Reaktionsleistung von Helpdesk, Security, Finance, Legal und Management bewerten.
- Detection-Regeln, Mailbox-Schutz und Tenant-Härtung aktualisieren.
- Zahlungsprüfungen und Lieferantenänderungsprozesse stärken.
- Dieses Playbook mit Lessons Learned aktualisieren und Remediation-Owner mit Fälligkeitsdaten benennen.
Evidence to preserve
- Original phishing email(s) with full headers and Message-ID.
- Envelope sender, Reply-To, extracted URLs, redirect chains and attachment hashes.
- Screenshots of phishing pages and submitted form evidence.
- Sign-in logs, MFA logs and password reset logs.
- Session & token logs, refresh token events.
- Mailbox audit logs (rules, forwarding, delegates).
- OAuth/consent logs and enterprise app changes.
- Sent items, deleted items and recoverable items.
- Quarantine and message-trace records.
- Firewall, proxy, DNS, EDR and endpoint logs.
- Payment/invoice and supplier-change records.
- Incident timeline and decision log.
Communications checklist
- Notify IR stakeholders: IT, SOC, Helpdesk, Management, Legal, Finance, affected business areas.
- Provide clear instructions: report message, do not delete original, do not act on suspicious instructions.
- Maintain a single authoritative incident status channel.
- Inform external recipients if compromised accounts sent malicious messages — use verified out-of-band channels.
- Coordinate all external messaging with Legal and Communications.
- Do not make unverified claims about data exposure or financial loss.
- Notify banks, law enforcement or insurers as per policy when fraud occurred.
▸ Legal & regulatory considerations
Phishing/BEC incidents may trigger contractual, regulatory and notification duties if personal data, sensitive business data or financial transactions are affected. Involve Legal/Privacy early if: personal data or customer records may have been accessed; mailbox contents include regulated data; fraudulent payments occurred or supplier banking details changed; compromised accounts were used to impersonate customers or partners. This playbook is not legal advice — preserve evidence and escalate to counsel for notification decisions.
Zu sichernde Beweise
- Originale Phishing-E-Mail(s) mit vollständigen Headern und Message-ID.
- Envelope Sender, Reply-To, extrahierte URLs, Redirect-Ketten und Anhang-Hashes.
- Screenshots von Phishing-Seiten und belegte Formulareingaben.
- Anmelde-Logs, MFA-Logs und Passwort-Reset-Logs.
- Session- und Token-Logs, Refresh-Token-Ereignisse.
- Mailbox-Audit-Logs (Regeln, Weiterleitungen, Delegationen).
- OAuth-/Consent-Logs und Änderungen an Enterprise-Apps.
- Sent Items, Deleted Items und Recoverable Items.
- Quarantäne- und Message-Trace-Daten.
- Firewall-, Proxy-, DNS-, EDR- und Endpoint-Logs.
- Zahlungs-/Rechnungs- und Lieferantenänderungsdaten.
- Incident-Timeline und Entscheidungsprotokoll.
Kommunikations-Checkliste
- IR-Stakeholder benachrichtigen: IT, SOC, Helpdesk, Management, Legal, Finance, betroffene Geschäftsbereiche.
- Klare Benutzeranweisungen geben: Nachricht melden, Original nicht löschen, nicht auf verdächtige Anweisungen reagieren.
- Einen einzigen autoritativen Incident-Statuskanal pflegen.
- Externe Empfänger informieren, wenn kompromittierte Konten bösartige Nachrichten versandten — vertrauenswürdige Out-of-Band-Kanäle nutzen.
- Alle externe Kommunikation mit Legal und Communications abstimmen.
- Keine unbestätigten Aussagen zu Datenexposition oder finanziellem Schaden machen.
- Banken, Strafverfolgung oder Versicherer gemäß Richtlinie benachrichtigen, wenn Betrug eingetreten ist.
▸ Rechtliche & regulatorische Aspekte
Phishing-/BEC-Vorfälle können vertragliche, regulatorische und Meldepflichten auslösen, wenn personenbezogene Daten, sensible Geschäftsdaten oder finanzielle Transaktionen betroffen sind. Legal/Privacy frühzeitig einbinden, wenn: personenbezogene Daten oder Kundendaten möglicherweise zugegriffen wurden; Mailbox-Inhalte regulierte Daten enthalten; betrügerische Zahlungen stattfanden oder Lieferanten-Bankdaten geändert wurden; kompromittierte Konten genutzt wurden, um Kunden oder Partner zu imitieren. Dieses Playbook ist keine Rechtsberatung — Beweise sichern und für Meldeentscheidungen an Counsel eskalieren.
Immediate
Scope
Containment
Investigation
Recover
Post-Incident
Sofort
Umfang
Eindämmung
Untersuchung
Wiederherstellung
Nach dem Vorfall
Email security
- Enforce SPF, DKIM and DMARC.
- Use anti-phishing/impersonation protections and sender-rewrite/URL-rewrite where applicable.
- Sandbox attachments and detonate suspicious files.
- Restrict auto-forwarding to external addresses.
- Monitor creation of new inbox rules and tenant mail-flow rules.
- Use external-sender banners or warnings appropriately.
Identity security
- Enforce MFA for all users; prefer phishing-resistant methods for high-risk accounts.
- Disable legacy authentication.
- Apply Conditional Access.
- Monitor impossible-travel and risky sign-ins.
- Monitor MFA fatigue/auto-approve patterns and new factor registrations.
- Regularly review OAuth app consents.
Business process controls
- Require out-of-band verification for supplier-bank changes and high-risk payments.
- Implement dual-approval for significant transfers.
- Verify supplier bank changes using trusted channels.
- Do not rely on email alone for urgent payment instructions.
- Train finance, HR and executive assistants on BEC indicators.
- Maintain clear escalation for suspected fraud.
E-Mail-Sicherheit
- SPF, DKIM und DMARC durchsetzen.
- Anti-Phishing-/Impersonation-Schutz und Sender-/URL-Rewrite einsetzen, wo sinnvoll.
- Anhänge sandboxen und verdächtige Dateien detonieren.
- Auto-Forwarding an externe Adressen einschränken.
- Neue Inbox-Regeln und Tenant-Mailflow-Regeln überwachen.
- Externe-Absender-Banner oder Warnhinweise angemessen einsetzen.
Identity-Sicherheit
- MFA für alle Benutzer erzwingen; für Hochrisiko-Konten phishing-resistente Methoden bevorzugen.
- Legacy Authentication deaktivieren.
- Conditional Access anwenden.
- Impossible-Travel- und risky sign-ins überwachen.
- MFA-Fatigue-/Auto-Approve-Muster und neue Faktorregistrierungen überwachen.
- OAuth-App-Consents regelmäßig überprüfen.
Business-Prozess-Kontrollen
- Out-of-Band-Verifikation für Lieferanten-Bankänderungen und Hochrisikozahlungen verlangen.
- Dual-Approval für signifikante Überweisungen einführen.
- Lieferanten-Bankänderungen über vertrauenswürdige Kanäle verifizieren.
- Sich bei dringenden Zahlungsanweisungen nicht allein auf E-Mail verlassen.
- Finance, HR und Executive Assistants auf BEC-Indikatoren schulen.
- Klare Eskalation für vermuteten Fraud etablieren.
Threat Sentinel IR Playbook Library · CC BY 4.0