Defender Attack Simulation Training: Setup, Simulationen, Reporting

Definition

Microsoft Defender Attack Simulation Training ist eine Funktion in Microsoft Defender for Office 365, die kontrollierte attack simulation und simulation training für E-Mail-basierte Angriffe wie phishing ermöglicht. Es ist ein Awareness- und Messwerkzeug im Defender portal und kein Penetrationstest der Infrastruktur.

Einleitung

Wenn deine Microsoft-Schutztechnik gut steht, bleibt oft eine Lücke: Menschen klicken, melden zu spät oder geben credentials preis. Genau hier hilft defender attack simulation training: Du simulierst Angriffe realistisch, weist training zu und bekommst reporting, das du wirklich steuern kannst.

Voraussetzungen: Lizenzen, Rollen, Compliance

Für Attack Simulation Training werden in der Praxis Lizenzen wie Microsoft Defender for Office 365 Plan 2 (oft auch über Microsoft 365 E5) benötigt. Ohne passende licensing fehlt dir entweder der Funktionsumfang oder die Möglichkeit, simulations sauber auszuwerten.

Operativ brauchst du restriktive Rollen: Nur ein kleiner Kreis darf campaigns erstellen, payloads ändern oder eine simulation launch auslösen. Das senkt das Risiko von Fehlkonfigurationen und verhindert „Wildwuchs“.

Compliance bleibt ein Teil des Nutzens: Ergebnisse sind personenbezogen und damit sensibel (GDPR). Lege fest, wofür Daten genutzt werden (Awareness, Prozessverbesserung), wie lange sie gespeichert werden und wer sie sehen darf. Für Anforderungen wie DORA oder interne Audits zählt nachvollziehbare evidence: Kampagnenziel, Zielgruppe, Technik (Technique), Ergebnis und Folgeaktion.

Schritt-für-Schritt: Einrichtung im Defender Portal

Der Ablauf ist standardisiert und sollte als wiederholbarer Prozess dokumentiert sein:

• Im Microsoft Defender portal (security.microsoft.com) Attack Simulation Training öffnen und eine neue campaign anlegen (Name, Ziel, Zeitraum).
• Target auswählen: Microsoft 365 groups oder dynamische Gruppen, damit neue Mitarbeitende automatisch im scope sind.
• Simulation technique wählen und payload festlegen (aus Templates/Global payloads oder Tenant payloads), anschließend Landing Page und Training modules zuordnen.

Plane den ersten Lauf bewusst als „Baseline“: nicht maximal sophisticated, sondern realistisch für deine Organisation und den aktuellen posture.

Simulationen gestalten: Phishing, Social Engineering, Payloads

Eine wirksame phishing simulation besteht aus drei Bausteinen: Message (E-Mail), Payload (was passieren soll) und Landing (was nach Klick/Eingabe passiert). Nur dann lernst du, ob Awareness und Meldewege tatsächlich funktionieren.

Gängige Payload types in Microsoft Defender Attack Simulation Training sind:

• Credential Harvest: Nutzer sollen (simuliert) credentials eingeben; ideal, um MFA- und Meldeverhalten zu testen.
• Malware Attachment oder Link to Malware / Link in Attachment: Fokus auf Vorsicht bei attachment und Links, ohne echte malware auszuliefern.
• Drive-by URL oder OAuth Consent Grant: testet, ob Nutzer ungewöhnliche OAuth-Consent-Aufforderungen erkennen und melden.

Landing pages sollten nicht bloß „erwischt“ sagen, sondern kurz erklären, was auffällig war, und direkt assign training. Das reduziert Frust und erzeugt messbare Verhaltensänderung.

Monitoring, Berichte, Kennzahlen und Dashboards

Der Wert entsteht in der Auswertung. Im Defender portal misst du typischerweise: Öffnen, Klick, Eingabe (Credential Harvest), sowie user reporting (wer meldet die email).

Damit das Management es versteht, übersetze Technik in Metrics:

• Reporting rate: Wie viele melden, statt zu klicken.
• Fehlerquote je Gruppe: Wo targeted Training wirkt (oder fehlt).
• Predicted Compromise Rate (PCR): Indikator, wie riskant das aktuelle Nutzerverhalten für real world threats ist.

Wichtig: Nicht nur Zahlen zeigen, sondern Maßnahmen ableiten (z. B. Training-Module anpassen, Meldeprozess vereinfachen, Kommunikation verbessern).

Automatisierung und wiederkehrende Simulationen

Ein einmaliger Test hat wenig Effekt. Ein Awareness program braucht wiederkehrende simulations mit Variation: andere Templates, andere Techniken, andere Zielgruppen. So erkennst du, ob Training tatsächlich works und nicht nur kurzfristig „aufweckt“.

Automatisierung reduziert Zeitaufwand: feste Rhythmen (monatlich/quartalsweise), wiederverwendbare Kampagnen und Gruppen-basierte Targets. Ergebnis: weniger manuelle Pflege, konsistentere reporting-Daten und bessere Vergleichbarkeit.

Governance: Zugriffskontrollen, Freigaben, Kommunikation

Ohne Governance wird AST schnell politisch oder chaotisch. Lege vor dem ersten launch fest, wer entscheidet, welche scenario gefahren wird, und wie Ergebnisse verwendet werden.

• Rollenmodell: wenige Admins, getrennte Leserechte für reporting.
• Freigabe: HR/Legal/Datenschutz für Textbausteine und Datenhaltung.
• Kommunikation: klar sagen, dass es um Lernen geht, nicht um Bloßstellung.

Häufige Fehler und Troubleshooting

Typische Fehler sind weniger technisch, mehr organisatorisch:

• Zu große Zielgruppe am Anfang: lieber Pilot, dann skalieren.
• Unrealistische Messages im „Office plan/Defender Office“-Stil, die intern nie so vorkommen: dann misst du nur Misstrauen, nicht Awareness.
• Keine Anschlussaktion: Simulation ohne Training Assignment ist nur ein Test, kein Verbesserungsprozess.

Wenn Ergebnisse „komisch“ wirken: prüfe Gruppenmitgliedschaften (target), Region-aware delivery/Timing, und ob Nutzer das Reporting-Add-in bzw. den Meldeweg tatsächlich nutzen.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung lohnt sich, wenn du AST nicht als Einzelaktion, sondern als dauerhaftes Programm mit Governance, messbaren Metrics und Audit-evidence betreiben willst. Auch wenn intern Zeit fehlt, ist es sinnvoll: kampagnenfähig sein heißt planen, auswerten, nachschärfen und wiederholen.

Wenn du willst, dass Defender XDR und dein Microsoft Security-Stack nicht nur lizenziert, sondern wirklich betrieben werden, kannst du ein kostenloses Erstgespräch vereinbaren: 30 Minuten remote, kein Verkaufsgespräch, kein Angebot ohne dein OK.