E-Mail-Bedrohungen: Identitäten, Inhalte und Konten getrennt schützen

Was eine Bedrohung ausmacht – und was Statistiken tatsächlich messen

Bei einer verdächtigen Nachricht greifen oft mehrere Elemente ineinander: eine behauptete Identität, ein Anlass mit Zeitdruck und eine verlangte Handlung. Das kann die Preisgabe von Zugangsdaten, eine Zahlung, das Öffnen einer Datei oder das Ausführen angeblicher Reparaturschritte sein. Die Themen überschneiden sich; die elf beschriebenen Mechanismen bilden keine trennscharfe Statistik von elf Angriffstypen.

Die ENISA Threat Landscape 2026, veröffentlicht im September 2026, betrachtet Vorfälle vom 1. Januar bis 31. Dezember 2025. ENISA analysierte 8.257 Vorfälle, überwiegend aus offenen Quellen sowie ergänzenden freiwillig geteilten Informationen. Der Bericht bezeichnet das ausdrücklich nicht als vollständiges Bild der Bedrohungslage; der Zeitraum überlappt zudem sechs Monate mit der vorigen Ausgabe. ENISA, Methodik S. 9

In Abbildung 1 entfallen 77,8 % auf Phishing und 13 % auf Malspam – unter den identifizierten Social-Engineering-Techniken im untersuchten Datenbestand. Das heißt weder „77,8 % aller Cyberangriffe beginnen per E-Mail“ noch „77,8 % aller Nachrichten sind Phishing“. Unterschiedliche Quellen zählen Vorfälle, Beschwerden, Websites, Nachrichten oder gemeldete Schäden; diese Größen lassen sich nicht ohne Weiteres vergleichen. ENISA, S. 11, Abbildung 1

Gute Sprache ist kein Entwarnungsmerkmal. KI kann Täuschung unterstützen; daraus folgt aber keine hier gemessene KI-Quote und kein allein aus einer Jahresstatistik bewiesener Ursache-Wirkungs-Zusammenhang. Für die eigene Organisation sind tatsächliche Meldungen, Kontobefunde und Arbeitsabläufe aussagekräftiger als eine pauschale weltweite Erfolgsquote.

Vier Absenderfälle mit unterschiedlichen Folgen

DMARC betrifft die Domain im sichtbaren From und deren ausgerichtete Authentifizierung. Es ist kein allgemeines Urteil über Person, Inhalt oder Berechtigung einer konkreten Geschäftsentscheidung. RFC 9989 §§1, 2.2, 11.4

Angriffsmechanismen einordnen

Absender und Konten

Inhalte und Zustellformen

Domains und Infrastruktur

Diese Kurzbeschreibungen erklären Mechanismen, keine Häufigkeitsrangfolge und keine garantierten Erkennungsmerkmale. Eine ausgerichtet authentifizierte Mail ist in mehreren dieser Fälle möglich. Die technischen Grundlagen stehen in DMARC, DNS-Sicherheit und ARC/Gateways.

ATT&CK beschreibt Handlungsschritte

Für Sicherheitsteams können passende ATT&CK-Techniken die Dokumentation unterstützen. Die Zuordnung muss dem beobachteten Verhalten folgen, nicht allein dem Schlagwort auf einer Nachricht. Im geprüften Enterprise-Datenstand 19.2 gehören beispielsweise E-Mail-Headerfälschung zu T1684.002, Spearphishing-Anhang zu T1566.001, HTML-Smuggling zu T1027.006 und übernommene Domains zu T1584.001. QR-Links zum Sammeln sensibler Informationen werden bei T1598.003 beschrieben; nicht jeder QR-Code ist automatisch dieser konkrete Angriffsschritt. MITRE ATT&CK, versionierte Originaldaten

Der Katalog belegt keine Erfolgsquote und keine Garantie, dass ein bestimmtes Produkt einen Angriff erkennt. Für Kalendereinladungen wird hier keine eigene Techniknummer erfunden.

Schutzmaßnahmen und ihre Grenzen

SPF-, DKIM- und DMARC-Pass schützen nicht vor böswilligem Inhalt aus einem autorisierten Versandweg. TLS schützt eine Verbindung auch dann, wenn darüber eine gefährliche Nachricht transportiert wird. RFC 9989 §§1, 11, RFC 4033 §4

Kontoschutz und verlässliche Arbeitsabläufe

Für Zahlungen und Stammdatenänderungen sollte ein bekannter, unabhängig beschaffter Kontaktweg gelten. Eine Telefonnummer aus der verdächtigen Nachricht erfüllt das nicht. Mitarbeiter brauchen einen erreichbaren Meldeweg und die Erlaubnis, bei Unklarheit anzuhalten, auch wenn eine Nachricht angeblich von der Leitung kommt.

Verwenden Sie starke, möglichst phishingresistente Anmeldung wie geeignete Passkeys. Ein zusätzlicher Faktor allein verhindert nicht jedes Phishing: ENISA beschreibt unter anderem AiTM-Phishing und den Diebstahl von Sitzungscookies. Prüfen Sie deshalb auch aktive Sitzungen, Wiederherstellungswege, freigegebene Anwendungen und das Endgerät. ENISA 2026, S. 55–56, Google: Bindung von Passkeys an Website oder App

Unbekannte Weiterleitungs- oder Ausblenderegeln können einen übernommenen Account für Betrug nutzbar halten. Organisationen sollten außerdem Adminrechte, Relayfreigaben, neue Versanddienste und verwaiste DNS-Verweise in ihre Betriebskontrollen einbeziehen. Ein geplantes Test- und Schulungsprogramm muss zum eigenen Datenfluss passen; ein pauschaler DNS-Score misst es nicht. Konkrete Beispiele für Sitzungswiderruf, Anwendungsfreigaben und Weiterleitungsregeln enthält die Microsoft-Anleitung zur Wiederherstellung kompromittierter Konten; die Umsetzung bei anderen Diensten hängt von deren Funktionen ab.

Was Sie bei einem konkreten Verdacht tun können

1. Anhalten: Nicht auf Links, Anhänge oder QR-Anweisungen eingehen, keine zusätzlichen Freigaben bestätigen und nicht über die verdächtige Nachricht zurückrufen.
2. Unabhängig klären: Den angeblichen Absender über einen bereits bekannten Kontakt oder den Dienst über eine selbst aufgerufene Adresse erreichen.
3. Melden und Original erhalten: Den vorgesehenen IT-/Sicherheitskontakt informieren. Nachricht und Zeitpunkte so sichern, dass Header erhalten bleiben; sensible Inhalte nicht wahllos in fremde Prüfdienste kopieren.
4. Nach Dateneingabe oder Freigabe: Vom vertrauenswürdigen Gerät aus den echten Dienst kontaktieren, Zugangsdaten und Wiederherstellung prüfen, betroffene Sitzungen/Freigaben beenden und unbekannte Regeln untersuchen. Eine Kennwortänderung allein beseitigt nicht zwingend jede bereits aktive Sitzung.
5. Nach Dateiausführung: IT/Sicherheitsverantwortliche sofort einschalten und deren Vorfallsverfahren folgen; nicht durch weitere Experimente Beweise oder Systeme verändern.
6. Bei einer veranlassten Zahlung: Die eigene Bank unverzüglich über einen bekannten Weg kontaktieren und den Betrugsverdacht melden. Weitere Beweissicherung und gegebenenfalls Anzeige mit den zuständigen Stellen abstimmen.

Das konkrete Vorgehen hängt davon ab, was tatsächlich passiert ist. Ein DMARC-Fehlschlag allein beweist keinen erfolgreichen Angriff oder meldepflichtigen Vorfall. Rechtliche Pflichten, Empfänger und Fristen hängen vom Sachverhalt und Geltungsbereich ab; dazu dient das Kapitel Compliance und Dokumentation.

Was ein Domaincheck zu diesen Risiken beitragen kann

Der E-Mail Security Check liefert eine Momentaufnahme veröffentlichter DNS-Daten und begrenzter SMTP-Merkmale. Er untersucht keine empfangene Nachricht, keinen QR-Code, kein Konto, keine Anhänge und keine betrügerische Zahlungsaufforderung. Auch ein erkannter Gatewayname belegt keine aktive Lizenz, Filterkonfiguration oder Wirkung.

Nutzen Sie die Ergebnisse zur Prüfung Ihrer Domainkonfiguration. Für einen konkreten Vorfall benötigen Sie zusätzliche Nachrichten-, Konto- und Betriebsdaten. Weder fehlender Scanbefund noch hoher Punktwert sind eine Entwarnung für die hier behandelten Mechanismen. Der Prüfumfang benennt die Grenzen; die Einführung erklärt die Schutzschichten.