Der Angriff, der am besten funktioniert
Er braucht keine Sicherheitslücke und keine Schadsoftware. Er braucht nur eine echte Rechnung und eine geänderte Kontonummer.
Der Ablauf ist immer derselbe: Jemand verschafft sich Einblick in laufenden Schriftverkehr – über ein übernommenes Postfach beim Lieferanten, beim Kunden oder bei einem Dienstleister dazwischen. Dann wartet er, bis eine echte Rechnung ansteht, tauscht die IBAN aus und schickt sie weiter. Betrag, Positionen, Rechnungsnummer, Ansprechpartner, sogar der Tonfall der Nachricht: alles stimmt.
Bezahlt wird pünktlich – nur an den Falschen. Auffallen kann es frühestens, wenn der echte Lieferant mahnt, und bis dahin vergehen regelmässig Wochen. Das Geld ist dann in aller Regel nicht mehr zurückzuholen.
Warum das Nachsehen beim Empfänger liegt
Wer auf ein falsches Konto überweist, hat seine Schuld nicht getilgt – er schuldet den Betrag weiterhin. Ob und in welchem Umfang der Absender mithaftet, hängt vom Einzelfall ab und ist regelmässig Gegenstand von Streit. Versicherungen greifen häufig nicht, wenn keine angemessenen Vorkehrungen getroffen wurden. Der Schaden entsteht also dort, wo die Rechnung ankommt.
Warum Verschlüsselung dagegen nichts ausrichtet
„Wir übertragen verschlüsselt" ist die häufigste Antwort auf diese Frage, und sie geht am Problem vorbei. Verschlüsselung auf dem Transportweg – TLS – schützt die Nachricht zwischen zwei Servern. Sie beantwortet zwei Fragen nicht:
- Wer hat abgeschickt? Ein Betrüger kann seine Nachricht genauso verschlüsselt übertragen wie jeder andere.
- Wurde unterwegs etwas geändert? Die Änderung passiert vor dem Versand, nicht während der Übertragung.
Ein Geldtransporter schützt das Geld auf der Fahrt. Er prüft nicht, ob der Auftrag echt war.
Die drei Prüfungen, die es können
Sie beruhen alle darauf, dass der Inhaber einer Domain im DNS hinterlegt, was für seine Post gilt. Wer die Domain nicht kontrolliert, kann das nicht fälschen.
SPF – wer senden darf
Ein Eintrag im DNS nennt die Server, die für die Domain versenden dürfen.
- Kommt die Mail von woanders, ist sie nicht von dieser Domain
- Prüft nur den Umschlag, nicht die sichtbare Absenderzeile
- Allein deshalb nicht ausreichend
DKIM – ob etwas geändert wurde
Der versendende Server signiert die Nachricht kryptografisch; der Schlüssel steht im DNS.
- Passt die Signatur, stammt die Nachricht von dieser Domain
- Und sie wurde seither nicht verändert
- Hier fällt eine ausgetauschte IBAN auf
DMARC – die Klammer
Verlangt, dass das Ergebnis zur sichtbaren Absenderdomain passt.
- Ohne diese Ausrichtung nützen SPF und DKIM wenig
- Der Domaininhaber legt fest, was bei Durchfallen geschieht
- Er bekommt zudem Berichte über Versuche in seinem Namen
Zusammen beantworten sie die Frage, die vor jeder Zahlung steht: Kommt diese Rechnung wirklich von dem, der draufsteht, und steht noch drin, was drinstand?
Was das Portal daraus macht
Jede Rechnung, die per E-Mail eingeht, wird auf SPF, DKIM und DMARC geprüft. Das Ergebnis steht sichtbar an der Rechnung – nicht in einem technischen Protokoll, das im Zweifel niemand aufruft. Wer zahlen will, sieht vorher, ob die Herkunft belegt ist.
Fällt eine Nachricht durch, wird sie nicht stillschweigend verworfen: Sie kommt gekennzeichnet an. Eine weggeworfene Rechnung ist ein eigener Schaden – der Lieferant wartet auf Geld, das nie kommt, und niemand weiss, warum. Absender und ganze Domains lassen sich sperren; die Sperre wirkt sofort und für das ganze Konto.
Was die Technik nicht abnimmt, bleibt eine Frage der Gewohnheit: Eine geänderte Bankverbindung wird nie per E-Mail bestätigt. Wer eine Rechnung mit neuer IBAN erhält, ruft die Nummer an, die er vorher schon hatte – nicht die aus der Nachricht.
Und beim Versand?
Dieselben drei Einträge sollten für die eigene Domain gesetzt sein – sonst kann jeder in ihrem Namen schreiben, und die Kunden haben keine Möglichkeit, es zu bemerken. Das Adminpanel erzeugt die nötigen DNS-Einträge samt DKIM-Schlüssel; unter Die elektronische Rechnung steht, wie sie in den Gesamtzusammenhang gehören.
Häufige Fragen
- Wie läuft ein Rechnungsbetrug per E-Mail typischerweise ab?
- In der häufigsten Form fängt jemand eine echte Rechnung ab oder liest sie mit, tauscht die IBAN aus und schickt sie weiter – im Namen des tatsächlichen Lieferanten. Alles stimmt: Betrag, Positionen, Ansprechpartner, Rechnungsnummer. Nur das Geld geht auf ein fremdes Konto. Auffallen kann das erst, wenn der echte Lieferant mahnt, und das dauert oft Wochen.
- Reicht eine verschlüsselte Verbindung (TLS) gegen Rechnungsbetrug?
- Nein. TLS schützt die Nachricht auf dem Weg zwischen zwei Servern – so wie ein Geldtransporter das Geld auf der Fahrt schützt. Es sagt nichts darüber aus, wer die Nachricht abgeschickt hat und ob ihr Inhalt vorher jemand geändert hat. Eine gefälschte Rechnung wird durch TLS genauso zuverlässig übertragen wie eine echte.
- Was ist SPF?
- Ein Eintrag im DNS einer Domain, der festlegt, welche Server für diese Domain versenden dürfen. Kommt eine Mail von woanders, ist sie nicht von dieser Domain – auch wenn sie so aussieht. SPF prüft allerdings nur den Umschlag, nicht die Absenderzeile, die der Empfänger sieht.
- Was ist DKIM?
- Eine kryptografische Signatur, die der versendende Server über die Nachricht legt. Der öffentliche Schlüssel steht im DNS der Absenderdomain. Passt die Signatur, steht fest: Die Nachricht stammt von dieser Domain und wurde unterwegs nicht verändert. Genau das ist der Punkt, an dem eine ausgetauschte IBAN auffällt.
- Was ist DMARC?
- Die Klammer um beides. DMARC verlangt, dass SPF oder DKIM nicht nur bestehen, sondern zu der Domain passen, die der Empfänger im Absenderfeld sieht – die Fachbegriffe dafür sind Alignment beziehungsweise Ausrichtung. Zusätzlich legt der Domaininhaber fest, was mit Nachrichten geschehen soll, die durchfallen.
- Prüft dieses Portal eingehende Rechnungen auf Echtheit?
- Ja. Jede eingehende Nachricht wird auf SPF, DKIM und DMARC geprüft, und das Ergebnis steht sichtbar an der Rechnung – nicht in einem Protokoll, das niemand liest. Zusätzlich lassen sich Absender und ganze Domains sperren; die Sperre wirkt sofort und plattformweit.