Inhaltsverzeichnis

1. Problem
2. 1) Trennmodell definieren
3. 2) Sichtbarkeit minimieren
4. 3) Plattformen priorisieren
5. 4) Verifikation
6. Mitigation Series (Week 1–4)
7. Tool-/Provider-abhängige Erläuterungen

---

Problem

Gleiche Handles über viele Plattformen machen Korrelation für Angreifer sehr einfach.

---

1) Trennmodell definieren

• beruflich
• privat
• pseudonym/experimentell

Jede Sphäre erhält eigenen Handle-Namensraum.

---

2) Sichtbarkeit minimieren

1. Bio-Texte auf direkte Querverweise prüfen.
2. Gleiches Profilbild nur dort nutzen, wo es bewusst sein soll.
3. Kontaktinfos und Standortdaten reduzieren.

---

3) Plattformen priorisieren

Start bei Plattformen mit hoher Suchmaschinen-Sichtbarkeit und hoher persönlicher Aussagekraft.

---

4) Verifikation

Vorher/Nachher-Scan fahren und Treffer im Bereich Social-Korrelation vergleichen.

Wenn Trefferzahl sinkt, reduziert sich die Angriffsfläche für Spear-Phishing und Profiling.

---

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
• Week 4: Handle-Hygiene im Security-Kontext: Re-Identifikation über Social-Korrelation reduzieren (du bist hier)
• 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.