Inhaltsverzeichnis

1. Incident-Ziel
2. 0-15 Minuten: Scope sichern
3. 15-40 Minuten: Rotation + Session-Kill
4. 40-60 Minuten: [MFA](#glossary-mfa)/[Passkey](#glossary-passkey) erzwingen
5. Danach (24h)
6. Mitigation Series (Week 1–4)
7. Tool-/Provider-abhängige Erläuterungen

---

Incident-Ziel

In der ersten Stunde nach einem Breach-Signal muss Account-Übernahme-Risiko sofort sinken.

---

0-15 Minuten: Scope sichern

1. Betroffene E-Mail/Identität festlegen.
2. Kritische Konten priorisieren (Mail, IdP, Admin-Panel, Code-Hosting, Zahlungsdienste).
3. Incident-Notiz starten (Zeitstempel, Owner, Maßnahmen).

---

15-40 Minuten: Rotation + Session-Kill

1. Passwörter in priorisierten Diensten auf einzigartige Secrets umstellen.
2. Alle aktiven Sessions beenden.
3. App-Passwörter und API-Tokens widerrufen.

---

40-60 Minuten: MFA/Passkey erzwingen

1. TOTP/Passkey auf allen kritischen Konten aktivieren.
2. Recovery-Codes neu ausstellen und sicher ablegen.
3. Fallback-Methoden (SMS/alte Mail) härten.

---

Danach (24h)

• Login-Historie prüfen
• Weiterleitungsregeln/OAuth-Apps validieren
• erneuter Scan im Digital Footprint Analyzer zur Wirksamkeitskontrolle

Dieses Playbook ist auf schnelle Risikoreduktion optimiert, nicht auf forensische Vollanalyse.

---

Mitigation Series (Week 1–4)

Bearbeite die Guides in dieser Reihenfolge, um schnell Wirkung zu erzielen:

• Week 1: DMARC Schritt für Schritt: Cloudflare, IONOS und M365 in der Praxis
• Week 2: SPF richtig setzen: Provider-Blueprint für Cloudflare, IONOS und Google Workspace
• Week 3: Passwort-Rotation und MFA-Erzwingung nach Breach: 60-Minuten Playbook (du bist hier)
• Week 4: Handle-Hygiene im Security-Kontext: Re-Identifikation über Social-Korrelation reduzieren
• Week 5: Account-Forensics nach Verdacht: Login-Historie, OAuth-Apps und Recovery-Drift prüfen
• Week 6: MX-Routing sauber absichern: IONOS, Cloudflare DNS und M365/Workspace Abgleich
• Week 7: CT- und Subdomain-Cleanup: Schatten-Assets über Zertifikatstransparenz abbauen
• Week 8: Open-Web-PII reduzieren: Suchtreffer bereinigen ohne Lösch-Illusionen
• Week 9: Kontinuierliches Exposure-Monitoring: Monatsroutine mit klaren Ownern

Sofort umsetzen: Digital Footprint Analyzer öffnen

---

Tool-/Provider-abhängige Erläuterungen

Google Mail (Gmail / Google Workspace)

• Wofür relevant? SPF, DKIM, DMARC, Login-Sicherheit, App-Zugriffe.
• Wie arbeitet es? Mail-Authentifizierung läuft primär über DNS (SPF, DKIM, DMARC), Kontoschutz über MFA/Passkeys und Security-Events.
• Worauf achten?
  1. SPF mit include:_spf.google.com konsistent halten.
  2. DKIM im Admin-Portal aktivieren und Selector im DNS prüfen.
  3. DMARC zunächst mit p=none, danach stufenweise härten.
• 3 häufige Fehler:
  1. Mehrere SPF-Records gleichzeitig publizieren.
  2. DKIM im Admin-Panel aktiviert, aber DNS-Selector fehlt/ist veraltet.
  3. DMARC zu früh auf reject, bevor alle legitimen Sender aligned sind.

Outlook (Microsoft 365)

• Wofür relevant? SPF, DKIM, DMARC, Sign-In-Risiken, OAuth-App-Governance.
• Wie arbeitet es? Zustellung und Trust basieren auf DNS-Authentifizierung; Zugriffskontrolle über Entra/Conditional Access und MFA.
• Worauf achten?
  1. SPF-Record um spf.protection.outlook.com ergänzen.
  2. DKIM in M365 aktivieren und DNS-CNAMEs sauber pflegen.
  3. Risky Sign-Ins/OAuth-Apps regelmäßig prüfen und unnötige Grants widerrufen.
• 3 häufige Fehler:
  1. SPF enthält M365 nicht oder enthält veraltete Drittanbieter-Include-Ziele.
  2. DKIM-CNAME zeigt auf falschen Tenant/Selector.
  3. Alte OAuth-App-Consents bleiben aktiv und werden nie rezertifiziert.

IONOS (Domain/DNS/Mail)

• Wofür relevant? DNS-Verwaltung, MX-Routing, SPF/DMARC Records.
• Wie arbeitet es? IONOS ist oft der autoritative DNS-Punkt; dort gesetzte Records entscheiden über Mail-Routing und Authentifizierung.
• Worauf achten?
  1. Keine doppelten SPF-TXT-Records.
  2. MX-Prioritäten auf den tatsächlich genutzten Maildienst abstimmen.
  3. DMARC/SPF-Änderungen nach Propagation per Header-Tests verifizieren.
• 3 häufige Fehler:
  1. Historische MX-Einträge bleiben nach Providerwechsel aktiv.
  2. SPF wird als zweiter TXT-Record statt als konsolidierter Record angelegt.
  3. Tests direkt nach Änderung ohne DNS-Propagation-Check.

Cloudflare (DNS/Edge)

• Wofür relevant? DNS-Records, schnelle Änderungen, Sichtbarkeit externer Assets.
• Wie arbeitet es? Als DNS/Proxy-Layer beeinflusst Cloudflare direkt SPF/DMARC/MX-Einträge und damit Mail-/Exposure-Verhalten.
• Worauf achten?
  1. DNS-Einträge im autoritativen Zone-View prüfen (nicht nur in Doku-Stand).
  2. Alte CNAME/A/MX-Einträge bereinigen, um Shadow-Assets zu vermeiden.
  3. Nach jeder Änderung Re-Scan im Analyzer für Vorher/Nachher-Vergleich.
• 3 häufige Fehler:
  1. Alt-DNS (z. B. alte CNAMEs) bleibt aktiv und erzeugt unnötige Angriffsfläche.
  2. MX-/TXT-Änderungen werden nicht gegen live aufgelöste Werte verifiziert.
  3. DNS-Änderung ohne Dokumentation/Change-Historie erschwert Incident-Analyse.

Kurz-Mapping: Welche Maßnahme betrifft welchen Provider?

• SPF/DMARC-Probleme: Google Mail, Outlook, IONOS, Cloudflare (DNS).
• MX-Routing-Probleme: IONOS/Cloudflare (DNS) + tatsächlicher Mail-Provider (Google/Microsoft).
• Account-Forensics/MFA: Google-/Microsoft-Konten sowie verbundene OAuth-Apps.
• CT/Subdomain-Cleanup: vor allem DNS-/Edge-Provider wie Cloudflare und Domainverwaltung bei IONOS.