462,48 € vom Finanzamt - inklusive Hinweis, dass es eine Testnachricht ist

Zwischen der Betragsbox und dem Button steht in einem gelb umrandeten Kasten: „Hinweis: Testnachricht – keine echten Steuerdaten."

Das ist keine Warnung von meinem Mailprovider. Das hat der Angreifer selbst geschrieben, für seinen eigenen Testlauf - und dann vergessen, es rauszunehmen. Die Mail ging am 15. September um 01:15 Uhr raus. Mit Testvermerk.

URLs und IPs sind im Folgenden defangt (hxxps, [.]), damit nichts aus Versehen angeklickt wird.

Was in der Mail steht

Betreff: Steuerbescheid –. Zwei Leerzeichen, ein Gedankenstrich, dann nichts mehr - ein Platzhalter, der nie befüllt wurde. Wir sind noch nicht mal im Body und haben schon zwei Fehler.

Der Rest ist ordentlich gemacht. Helles Layout im ELSTER-Grün, Wortmarke oben links, darunter „Ihr Online-Finanzamt". Kein Neongrün aus der Paint-Palette wie bei der Welle im August. Der Text: Die Prüfung der Einkommensteuererklärung für das Veranlagungsjahr 2025 sei abgeschlossen, das Steuerkonto veranlagt. Dann eine Box mit 462,48 €. Und dann der Haken:

Gemäß den gesetzlichen Bestimmungen der Abgabenordnung (AO) und des Einkommensteuergesetzes (EStG) wird die Auszahlung nach erfolgreicher Verifizierung Ihrer Kontodaten oder Ihrer registrierten Zahlungskarte veranlasst.

Zwei Gesetze, kein einziger Paragraf. Die Juni- und August-Wellen hatten wenigstens noch falsche Paragrafenzahlen drin, das wirkte immerhin amtlich. Hier steht nur noch „irgendwas mit Steuerrecht".

Die „registrierte Zahlungskarte" ist der eigentliche Punkt. Das Finanzamt erstattet per Überweisung auf ein Bankkonto; eine Kreditkarte ist dort nicht hinterlegt, weil es sie im Besteuerungsverfahren nicht gibt. Aber Kartendaten sind sofort zu Geld zu machen, eine IBAN nicht - deshalb das „oder".

Unterschrieben ist mit „Ihr Finanzamt / ELSTER Verwaltung", einer Stelle, die es nicht gibt. Und wie schon im August: kein Countdown, keine Frist, keine Sperrandrohung. Zeitdruck ist inzwischen selbst ein Warnsignal, und diese Kampagne weiß das.

Warum die Mail ankam

Im Posteingang steht als Absender „ELSTER". Die tatsächliche Adresse lautet newsletter[@]rci.com - eine reale US-Konzerndomain aus der Reise-Branche, seit 1996 registriert. Mit der deutschen Steuerverwaltung hat sie nichts zu tun, und kompromittiert ist sie auch nicht. Sie wurde einfach gespooft. Der empfangende Server hat das gesehen:

X-Received-SPF: softfail ( mx11.ispgateway.de: transitioning domain of
  rci.com does not designate 209.227.239.72 as permitted sender )

Eine DKIM-Signatur gibt es nicht - der Header fehlt komplett, er ist nicht etwa ungültig. SPF nicht aligned, kein DKIM: DMARC-Fail auf ganzer Linie. Und trotzdem ist die Zustellung diesmal völlig korrekt gewesen. Denn rci.com veröffentlicht das hier:

v=DMARC1; p=none; fo=1; rua=mailto:dmarcreports@rci.com; aspf=s; adkim=s

p=none heißt: „Prüf ruhig, aber tu nichts." Strikte Alignment-Vorgaben, vollständiges Reporting - und am Ende keine Anweisung, irgendetwas abzulehnen. Auch ein Postfach, das DMARC durchsetzt, hätte diese Mail zugestellt.

Genau das ist die Weiterentwicklung gegenüber August. Damals wurde elster.de direkt gespooft, eine Domain mit p=reject. Ankommen konnte die Mail nur bei Empfängern, die die Policy nicht durchsetzen, so wie mein Analyse-Postfach, das absichtlich alles annimmt. Auf solche Empfänger ist der Angreifer jetzt nicht mehr angewiesen. Er hat sich einfach eine Absenderdomain gesucht, deren eigene Policy die Zustellung erlaubt. Davon gibt es Millionen.

Korrektur: Diese Deutung hat sich nicht bestätigt - siehe Nachtrag am Ende.

Verschickt wurde von 209[.]227[.]239[.]72 - AS31034, Aruba S.p.A., ein gemieteter Dedicated Server in Rom. Kein gekapertes Postfach, kein offenes Relay. Gekaufte Infrastruktur statt gestohlener.

Die Domain war 18 Stunden alt

Der Button „Erstattung anfordern" zeigt auf hxxps://www[.]eportalelster[.]de/index.html. Es ist der einzige Link in der ganzen Mail.

Kein Homoglyph, kein Tippfehler. Der Markenname steckt einfach drin: „e" + „portal" + „elster". Wer den Standardtipp befolgt und nach dem Markennamen in der Adresszeile sucht, findet ihn. Das Präfix ist gut gewählt, weil Behörden tatsächlich reihenweise Dinge betreiben, die „Serviceportal" oder „E-Portal" heißen. Die DENIC sagt zum Alter:

Domain:   eportalelster.de
Nserver:  lana.ns.cloudflare.com
Changed:  2026-09-14T06:55:13+02:00

Zonenänderung am 14. September um 06:55 Uhr. Versand am 15. September um 01:15 Uhr. Achtzehn Stunden. Registrieren, Cloudflare davorhängen, Seite hochladen, abschicken.

Dabei ist .de nicht die bequeme Wahl: Die DENIC verlangt einen administrativen Ansprechpartner mit ladungsfähiger Anschrift in Deutschland. Aufwendiger als eine .xyz für zwei Euro - und beim Opfer erheblich glaubwürdiger. Der Aufwand ist Absicht.

Auflösen tut übrigens nur www., der Apex ist leer - ein Scanner, der nur die nackte Domain prüft, sieht nichts. Auf VirusTotal ist die URL 1 von 90 (Fortinet, „suspicious/spam"), die Domain selbst 0 von 89, die Versand-IP ebenfalls 0 von 89.

Der VirusTotal-Crawler kam anderthalb Stunden nach dem Versand vorbei und bekam einen Cloudflare-Fehler 520: Der Server dahinter antwortete nicht mehr. Ob zurückgebaut, ob Scanner ausgesperrt, ob einfach kaputt - von außen nicht zu entscheiden. Heißt aber auch: Wie das Formular aussieht, habe ich nicht gesehen. Das bleibt eine begründete Annahme aus dem Mailtext, kein Befund.

Woran man's erkannt hätte

Am einfachsten an der gelben Box, in der steht, dass es eine Testnachricht ist - sie sitzt genau auf dem Weg zum Button. Danach der Betreff, der mitten im Satz aufhört. Dann der Absender, sobald man ihn ausklappt: „ELSTER" heißt eben nicht rci.com. Auf dem Handy ist das leider genau der Klick, den niemand macht.

Und der inhaltliche Klopfer, für den man nichts Technisches wissen muss: Das Finanzamt schickt keine Steuerbescheide per Mail mit Auszahlungs-Link. Bescheide kommen per Post oder liegen im ELSTER-Postfach, das man selbst aufruft.

Was ihr tun könnt

Setzt die DMARC-Policy eurer eigenen Domain auf p=quarantine, später p=reject. Genau diese Welle lebt davon, dass irgendwo eine Domain p=none stehen hat. Solange das so ist, darf jeder in eurem Namen schreiben - auch an eure Kunden. Erst SPF und DKIM sauber setzen, zwei bis vier Wochen mit rua-Reporting beobachten, dann hochziehen.

Fragt euren Mailprovider, ob er DMARC durchsetzt oder nur auswertet. Die August-Welle hätte ein durchsetzendes Postfach abgewiesen. Ein X-Received-SPF-Header allein ist keine Durchsetzung: Mein Analyse-Postfach schreibt ihn auch und stellt trotzdem zu, mit Absicht. Schaut außerdem nach, ob euer Spamfilter wirklich prüft. Steht im X-Spam-Status required=9999.0, ist die Bewertung faktisch aus.

Verankert eine Regel, für die niemand Header lesen muss: Behördenpost kommt nie per Link-Mail. Im Zweifel elster.de von Hand tippen und im echten Postfach nachsehen. Dauert dreißig Sekunden und erledigt jede Variante dieser Masche auf einmal.

Stellt die Mailclients auf die vollständige Absenderadresse in der Nachrichtenliste um, nicht nur den Display-Name. Outlook, Thunderbird und die gängigen Webmailer können das.

Und klärt vorher, wem man einen Fehlklick meldet. Die realistische Annahme ist nicht „niemand klickt je", sondern „irgendwann klickt jemand". Wer Angst vor der Meldung hat, meldet später - und später ist teurer. Virenscanner helfen hier übrigens nicht: Die Mail lädt nichts herunter und führt nichts aus.

Fazit

Infrastruktur und Ausführung passen nicht zusammen. Der Absender-Trick ist die sauberste Lösung, die diese Serie bisher gefunden hat - kein gekapertes Postfach, keine Abhängigkeit von Empfängern, die DMARC ignorieren, nur eine fremde Domain mit p=none und ein gemieteter Server in Rom. Das ist gedacht, nicht geraten. (Korrektur: Das war zu früh geurteilt - siehe Nachtrag.)

Und dann geht dieselbe Mail mit unbefülltem Betreff und dem eigenen Testvermerk im Text raus, und anderthalb Stunden später antwortet die Phishing-Seite schon nicht mehr. Wer immer hier den Versand angeworfen hat, hat das Template nicht selbst gebaut.

Nachtrag, 16. September 2026

Die These oben, der Angreifer fasse elster.de nicht mehr an und suche sich gezielt Absenderdomains mit p=none, hält nicht. 41 Minuten nach der hier beschriebenen Mail, um 01:56 Uhr, kam dieselbe Mail noch einmal an, diesmal an eine andere Adresse derselben Domain. Gleicher Server in Rom (209[.]227[.]239[.]72), gleiches Ziel eportalelster[.]de, der Mailtext Byte für Byte identisch, Testvermerk inklusive. Nur der Absender war wieder direkt eportal[@]elster[.]de.

elster.de steht auf p=reject. SPF softfail, kein DKIM, DMARC-Fail: Ein Postfach, das DMARC durchsetzt, hätte sie abgewiesen, wie schon im August. Bei mir kam sie über mx07.ispgateway.de trotzdem an, weil mein Analyse-Postfach absichtlich alles annimmt.

Belegt ist damit nur, dass der Angreifer die Absenderdomain wechselt, und zwar im selben Lauf zwischen Fremddomain und Marke. Dass er dabei gezielt nach DMARC-Policy auswählt, ist nicht belegt. Genauso gut probiert er einfach aus, was ankommt, und bei Empfängern ohne DMARC-Durchsetzung kommt beides an. Die Abschnitte „Warum die Mail ankam" und „Fazit" sind in diesem Punkt überholt. Die Kurzbeschreibung des Artikels habe ich angepasst.

Für die Empfehlungen heißt das: Die eigene DMARC-Policy hochzuziehen bleibt richtig, denn sie schützt eure Kunden vor Mails in eurem Namen. Vor dieser Welle schützt euch aber vor allem ein Mailprovider, der p=reject auch durchsetzt. Von den beiden Punkten ist das der wichtigere.

Nebenbei: In der zweiten Mail war der Betreff repariert („Ihr Finanzamt informiert: Steuererstattung 2025 liegt vor"). Den Testvermerk im Text hat in den 41 Minuten niemand bemerkt. Wer den Versand betreut, hat sich den Betreff angesehen, den Text nicht.

---

Korrigiert am 16. September 2026: Eine frühere Fassung stellte die Zustellung als Fehler des empfangenden Postfachs dar. Das Postfach nimmt absichtlich alles an, damit Mails wie diese analysiert werden können.