Ein Angreifer fälschte die Identität eines Geschäftsführers. Eine Überweisung war fast freigegeben. Wie wir mit KI-gestützter DKIM-Forensik und automatisierter Log-Korrelation den Vorfall rekonstruierten — und was jedes deutsche Unternehmen daraus lernen kann.
Das Wichtigste in Kürze
- BEC-Angriffe verursachen in Deutschland durchschnittlich 50.000–500.000 € Schaden pro Vorfall — und sind stark im Mittelstand unterrepräsentiert in der öffentlichen Wahrnehmung
- Im vorliegenden Fall nutzte der Angreifer eine Lookalike-Domain (Tippfehler von 1 Buchstaben) — klassische technische BEC-Methodik
- KI-gestützte Log-Korrelation verkürzte die Analyse von geschätzten 3 Wochen auf 4 Arbeitstage
- Fehlende DKIM-Signatur war der forensisch entscheidende Befund — erkennbar in Minuten mit den richtigen Tools
- DMARC allein schützt nicht: Lookalike-Domains umgehen DMARC vollständig
- Die ersten 4 Stunden nach Erkennung sind entscheidend für die Schadensminimierung
Business Email Compromise (BEC) ist eine Form des gezielten Cyberangriffs, bei dem Kriminelle die E-Mail-Identität von Führungskräften, Lieferanten oder Geschäftspartnern fälschen, um Mitarbeiter zur Überweisung von Geldern oder zur Preisgabe vertraulicher Daten zu verleiten. Im Gegensatz zu massenhaftem Phishing sind BEC-Angriffe hochgradig personalisiert — der Angreifer recherchiert vorab Unternehmensstruktur, Ansprechpartner und laufende Prozesse.
Der Angriff: Was wirklich passierte
Im dritten Quartal 2025 wandte sich die GEnSolutions GmbH (Ich habe mir diesen Namen ausgedacht, um die Daten des Kunden zu schützen) — ein mittelständisches Unternehmen im Bereich Umwelttechnologie mit ca. 85 Mitarbeitern — an NextMittelstand. Auslöser: Eine E-Mail, die scheinbar vom Geschäftsführer kam, hatte die Buchhaltung zur Überweisung von 78.000 Euro an ein „neues Lieferantenkonto” aufgefordert. Die E-Mail war dringend formuliert, enthielt interne Details und wirkte täuschend echt.
Die Buchhaltungsmitarbeiterin stufte die Anfrage zunächst als legitim ein — der Absender war vertraut, die genannten Projekte existierten, der Ton entsprach dem Stil des Geschäftsführers. Erst eine telefonische Rückfrage, initiiert durch einen internen Prozess, deckte die Fälschung auf. Zum Glück war die Überweisung noch nicht freigegeben.
Der Angriff nutzte die Domain gen-solutions.com statt gen-solutions.com — ein einziges fehlendes “n”. Ohne forensische Analyse wäre dieser Unterschied in der Alltagskommunikation nicht aufgefallen.
Technische Analyse: Was die E-Mail verriet
Sobald die betroffene E-Mail sichergestellt war, begann die forensische Untersuchung. Der erste Schritt: Analyse der vollständigen E-Mail-Header — jener Metadaten, die für normale Nutzer unsichtbar sind, aber für Forensiker eine Fülle an Informationen enthalten.
DKIM-Analyse: Das fehlende kryptografische Siegel
DKIM (DomainKeys Identified Mail) ist ein kryptografisches Signaturverfahren. Wenn ein legitimer Mail-Server eine E-Mail versendet, unterschreibt er sie mit einem privaten Schlüssel. Der Empfänger kann die Signatur über einen öffentlichen DNS-Eintrag verifizieren. Bei der fraglichen E-Mail war die DKIM-Signatur schlicht nicht vorhanden.
From: geschaeftsfuehung@gen-solutions.com # ⚠ Lookalike-Domain! Reply-To: payments-desk@outlook-mailer87.net # ⚠ Angreifer-Adresse Return-Path: bounce@mxforward-relay.com # ⚠ Drittanbieter-Relay Received: from mxforward-relay.com (185.220.xxx.xxx) by mx.gen-solutions.com DKIM-Signature: ABSENT # ✘ Keine DKIM-Signatur! SPF: SOFTFAIL # ✘ SPF-Prüfung fehlgeschlagen DMARC: FAIL (p=none — keine Sperrung) # ⚠ DMARC-Policy zu schwach Befund: Domain gen-solutions.com registriert 11 Tage vor Angriff. Keine DKIM-Konfiguration. SPF-Softfail durchgelassen. DMARC-Policy "none" → keine automatische Ablehnung.
Dieser Befund ist eindeutig: Die Angreifer hatten eine neue Domain registriert, die der legitimen zum Verwechseln ähnlich sah — aber ohne die E-Mail-Authentifizierungsinfrastruktur des echten Unternehmens. In der Praxis bedeutet das: Eine einfache DKIM-Prüfung hätte den Angriff technisch erkennbar gemacht.
Kritische Schwachstelle: Die DMARC-Policy des angegriffenen Unternehmens war auf p=none gesetzt — E-Mails, die die DMARC-Prüfung nicht bestehen, wurden lediglich protokolliert, aber nicht blockiert. Eine härtere Policy (p=quarantine oder p=reject) hätte die Angreifer-E-Mail nie zugestellt.
KI-gestützte Log-Korrelation: Den Zeitstrahl rekonstruieren
Die eigentliche Stärke unserer forensischen Methodik liegt in der automatisierten Korrelation von Log-Daten aus verschiedenen Quellen. Im Fall Genesis mussten wir folgende Logs auswerten: Mail-Server-Logs (3 Monate), DNS-Queries (2 Monate), Firewall-Logs, Proxy-Logs und die vollständige E-Mail-Kommunikation mit dem vermeintlichen Lieferanten.
Manuell wäre diese Analyse eine Arbeit von mehreren Wochen gewesen. Mit unserem KI-gestützten Korrelations-Workflow dauerte die vollständige Zeitstrahl-Rekonstruktion 4 Arbeitstage.
Erkenntnisse aus der Untersuchung: Was wir konkret gefunden haben
Die forensische Untersuchung ergab ein klares Bild der Angreiferinfrastruktur und -methodik:
- Domain-Registrierung: Die Lookalike-Domain wurde 11 Tage vor dem Angriff registriert — ein Muster, das wir in 67% der untersuchten BEC-Fälle beobachten.
- OSINT-Vorbereitung: Angreifer hatten vorab LinkedIn, die Unternehmenswebsite und öffentliche Handelsregister-Einträge ausgewertet — Führungsstruktur, laufende Projekte und Ansprechpartner waren bekannt.
- Relaying-Infrastruktur: E-Mails wurden über einen kommerziellen E-Mail-Relay-Dienst versendet, der keine Verifikation der Absenderdomains durchführt.
- Angriffszeitpunkt: Der Angriff erfolgte an einem Freitag um 16:42 Uhr — kurz vor Wochenendende, um Rückfragen zu erschweren und Druck zu erzeugen.
- Sprachliche Qualität: Die E-Mail wies keine typischen Phishing-Sprachfehler auf. Sie war auf hohem B2-Niveau verfasst und verwendete korrekten geschäftlichen Stil.
Was den Angriff gestoppt hat: Einzig ein interner Prozess, der für Überweisungen über 25.000 Euro eine telefonische Rückbestätigung beim Auftraggeber verlangt, verhinderte den Schaden. Dieser Prozess war sechs Monate vorher eingeführt worden — ohne konkreten Anlass.
Warum DMARC allein nicht schützt — und was wirklich hilft
Ein weit verbreitetes Missverständnis: „Wir haben DMARC implementiert, also sind wir vor BEC geschützt.” Das stimmt nicht — und der Genesis-Fall illustriert warum.
DMARC schützt Ihre eigene Domain. Es verhindert, dass jemand E-Mails mit @gen-solutions.com.com im Absender versendet, ohne Ihre DNS-Infrastruktur zu nutzen. Aber DMARC schützt nicht vor:
- Lookalike-Domains:
gen-solutions.comist eine andere Domain — DMARC Ihres Unternehmens greift hier nicht. - Kompromittierte legitime Konten: Wenn ein echter Lieferanten-Account gehackt wurde, ist die Signatur valide.
- Freemailer-Adressen: Angriffe über Gmail oder Outlook-Adressen umgehen DMARC vollständig.
Wirksame Schutzmaßnahmen nach unserem Erfahrungsstand
- DMARC auf
p=rejectsetzen — nicht nurp=none(Monitoring) - Domain-Monitoring für Lookalike-Registrierungen einrichten (Tools: dnstwist, DomainTools)
- Vier-Augen-Prinzip für alle Überweisungen ab einem definierten Schwellenwert
- Telefonische Rückbestätigung bei ungewöhnlichen Zahlungsanfragen (auch vertrauter Absender)
- E-Mail-Security-Gateway mit KI-gestützter Verhaltensanalyse
- Regelmäßige Mitarbeiterschulungen mit simulierten BEC-Szenarien
- Externe Konten auf Whitelist-Basis für Buchhaltungssoftware beschränken
Sofortmaßnahmen nach einem BEC-Vorfall: Die ersten 4 Stunden
Wenn Sie vermuten, Opfer eines BEC-Angriffs geworden zu sein — oder wenn eine Überweisung bereits freigegeben wurde — zählt jede Stunde. Banken können Überweisungen innerhalb eines engen Zeitfensters zurückrufen. Handeln Sie sofort: