Rspamd gegen Phishing und Markenmissbrauch härten

SPF, DKIM und DMARC sind wichtige Bestandteile einer sicheren E-Mail-Infrastruktur. Sie reichen jedoch nicht aus, um moderne Phishing-Mails zuverlässig zu erkennen. In der Praxis werden zunehmend echte oder kompromittierte Mailkonten, regulär registrierte Domains und korrekt konfigurierte Versandserver verwendet. Eine Phishing-Mail kann deshalb technisch sauber aussehen, über authentifiziertes SMTP verschickt werden und sogar SPF oder DKIM bestehen, obwohl sich der sichtbare Absender als ELSTER, Microsoft, DHL, PayPal oder eine Bank ausgibt.

Genau hier liegt die Schwäche einer rein auf Mailauthentifizierung ausgerichteten Prüfung. SPF bestätigt, ob ein Server für die tatsächlich verwendete Envelope-Domain senden darf. DKIM bestätigt eine kryptografische Signatur für eine Domain. DMARC prüft unter anderem die Ausrichtung dieser Identitäten zur sichtbaren From-Domain. Keine dieser Prüfungen beantwortet jedoch direkt die Frage, ob ein Anzeigename wie „ELSTER Bestätigung“ überhaupt zur tatsächlich verwendeten Domain gehört.

Bei meinem Rspamd-Setup habe ich deshalb die lokale Phishing-Erkennung schrittweise um eine eigenständige Brand-Impersonation-Logik erweitert. Ausgangspunkt waren zunächst Bank-Phishing-Mails. Inzwischen ist die Erkennung bewusst allgemeiner aufgebaut und trennt generischen Markenmissbrauch von bankenspezifischen Regeln.

Ein realer ELSTER-Phishing-Fall hat dabei noch einen Konfigurationsfehler offengelegt, der besonders interessant war: Die Brand-Map enthielt bereits reguläre Ausdrücke, die Multimap-Regel wertete diese aber zunächst nicht als Regex aus. Die Konfiguration war syntaktisch gültig, fachlich funktionierte die Schutzschicht jedoch nicht. Erst ein reproduzierbarer Test mit einer echten Nachricht machte das Problem sichtbar.

1. Warum SPF, DKIM und DMARC allein nicht genügen

Bei modernen Phishing-Kampagnen muss die Absenderdomain nicht einmal gefälscht sein. Ein Angreifer kann ein kompromittiertes Postfach verwenden oder einen legitimen Hostinganbieter missbrauchen und beispielsweise folgende Nachricht verschicken:

From: "ELSTER Bestätigung" <cesar@fremde-domain.example>
Subject: ELSTER: Wichtiger Hinweis zu Ihren Steuerdaten

Die technische Domain kann dabei tatsächlich autorisiert sein, über den verwendeten Mailserver zu senden. SPF kann deshalb völlig korrekt mit pass antworten. Auch eine gültige DKIM-Signatur würde zunächst nur beweisen, dass die Nachricht tatsächlich von einer Infrastruktur signiert wurde, die für diese fremde Domain einen passenden Schlüssel besitzt.

Das bedeutet aber nicht, dass ELSTER der Absender ist.

Das gleiche Prinzip gilt beispielsweise für:

From: "N26App" <support@fremde-domain.example>
From: "Consorsbank IT-Koordination" <user@fremde-domain.example>

oder:

From: "Volksbank SecureGO-Alarmdienst" <account@fremde-domain.example>

Die zentrale Frage lautet deshalb nicht nur:

Ist die verwendete Absenderdomain technisch authentifiziert?

sondern zusätzlich:

Passt die sichtbare Marke zur tatsächlichen Absenderidentität?

Die lokale Härtung kombiniert deshalb mehrere voneinander unabhängige Signale: Marken im sichtbaren Anzeigenamen, tatsächliche Absenderdomain, DMARC-Situation, typische Phishingformulierungen, verdächtige Funktionsbezeichnungen, IP- und URL-Reputation, Bayes sowie bereits bekannte schädliche Absender.

Rspamd eignet sich dafür gut, weil Multimap-Regeln einzelne Merkmale erkennen und Composite-Regeln daraus eine kontextabhängige Bewertung bilden können. Regexp-Maps müssen dabei ausdrücklich als solche konfiguriert werden.

Die ursprüngliche Konfiguration war stark auf Banken zugeschnitten. Das funktionierte zunächst, wurde aber spätestens dann unsauber, als auch PayPal, Amazon, DHL oder ELSTER in derselben Markenliste auftauchten.

2. Zielarchitektur

Ein Symbol wie:

FAKE_BANK_BRAND

ist für eine gefälschte ELSTER-Mail offensichtlich fachlich falsch.

Deshalb besteht die aktuelle Architektur aus zwei Ebenen.

Die erste Ebene erkennt allgemeinen Markenmissbrauch:

BRAND_SPOOF_DISPLAY
        +
FROM_NEQ_ENVFROM / DMARC_NA
        |
        v
BRAND_IMPERSONATION

Die zweite Ebene behandelt bankspezifisches Phishing:

BANK_BRAND_DISPLAY
        +
LEGIT_BANK_SENDER
        +
BANK_PHISH_WORDS_*
        |
        v
FAKE_BANK_*

Damit können beispielsweise ELSTER, Microsoft, DHL oder Amazon als Markenimitation erkannt werden, ohne dass sie durch eine Bankregel laufen.

Für meine lokale Konfiguration sind insbesondere folgende Dateien relevant:

/etc/rspamd/local.d/multimap.conf
/etc/rspamd/local.d/composites.conf

/etc/rspamd/maps.d/brand_spoof.map
/etc/rspamd/maps.d/bank_brand.map
/etc/rspamd/maps.d/bank_phish_words.map
/etc/rspamd/maps.d/bank_it_display.map
/etc/rspamd/maps.d/legit_bank_domains.map
/etc/rspamd/maps.d/sender_domain_blacklist.map

Die Trennung ist bewusst gewählt. multimap.conf definiert, wie einzelne Merkmale erkannt werden. composites.conf legt fest, wie diese Merkmale miteinander kombiniert werden. Die Dateien unter maps.d enthalten dagegen die veränderlichen Daten wie Marken, Domains oder Textmuster.

Neue Marken können dadurch ergänzt werden, ohne die Entscheidungslogik jedes Mal neu schreiben zu müssen.

3. Generische Marken im From-Displaynamen erkennen

Die zentrale Multimap-Regel sieht inzwischen so aus:

BRAND_SPOOF_DISPLAY {
   type = "header";
   header = "From";
   filter = "email:name";
   map = "/etc/rspamd/maps.d/brand_spoof.map";
   regexp = true;
   score = 6.0;
}

Der wichtige Teil ist:

filter = "email:name";

Damit wird aus:

From: "ELSTER Bestätigung" <cesar@fremde-domain.example>

der sichtbare Name:

ELSTER Bestätigung

für die Map-Prüfung verwendet.

Ebenso entscheidend ist:

regexp = true;

Meine brand_spoof.map verwendet Muster in dieser Form:

/ELSTER/i
/PayPal/i
/Amazon/i
/DHL/i

Rspamd muss daher wissen, dass diese Map reguläre Ausdrücke enthält. Genau das wird durch regexp = true festgelegt.

Dieser kleine Parameter war in meinem Fall entscheidend.

4. Der Fehler: Regex-Map vorhanden, aber nicht aktiv

Der reale ELSTER-Fall wurde zunächst nur mit generischen technischen Merkmalen erkannt.

Der ursprüngliche Scan lag bei:

Score: 5.63 / 15.00
Action: greylist

Rspamd erkannte unter anderem:

DMARC_NA                  +2.50
HFILTER_HOSTNAME_UNKNOWN  +2.50
RCPT_COUNT_ONE            +0.50
MANY_INVISIBLE_PARTS      +0.20
RCVD_NO_TLS_LAST          +0.10

Obwohl der Absender sichtbar:

ELSTER Bestätigung

hieß, erschien kein:

BRAND_SPOOF_DISPLAY

Die Ursache lag nicht in der Bewertung und auch nicht in Bayes. Die Brand-Map enthielt bereits Einträge wie:

/paypal/i
/amazon/i
/dhl/i
/sparkasse/i
/N26/i
/ING/i
/DKB/i

Die zugehörige Multimap-Regel hatte aber ursprünglich keinen aktivierten Regex-Modus.

Nach dem Ergänzen von:

regexp = true;

funktionierte die gesamte bisherige Map erstmals wie vorgesehen.

Das war damit kein ELSTER-spezifischer Fehler. Potenziell waren auch die bereits vorhandenen Marken von dem Problem betroffen.

Besonders tückisch ist: Ein normaler

rspamadm configtest

kann trotzdem erfolgreich sein. Die Konfiguration ist syntaktisch korrekt. Sie tut lediglich fachlich nicht das, was man erwartet.

Deshalb gehört für mich inzwischen zu jeder relevanten Rspamd-Regeländerung auch ein echter Nachrichtentest.

5. Die generische Brand-Map

Die Datei:

/etc/rspamd/maps.d/brand_spoof.map

ist inzwischen nicht mehr als reine Bankenliste gedacht.

Sinnvolle Gruppen sind beispielsweise Behörden und öffentliche Dienste:

/\bELSTER\b/i
/\bMein ELSTER\b/i
/\bFinanzamt\b/i
/\bBundeszentralamt für Steuern\b/i
/\bBZSt\b/i
/\bBundID\b/i

Finanz- und Zahlungsdienste:

/\bPayPal\b/i
/\bKlarna\b/i
/\bTrade Republic\b/i
/\bRevolut\b/i
/\bWise\b/i

Banken:

/\bSparkasse\b/i
/\bN26\b/i
/\bING\b/i
/\bDKB\b/i
/\bCommerzbank\b/i
/\bDeutsche Bank\b/i
/\bPostbank\b/i
/\bConsorsbank\b/i
/\bConsorbank\b/i
/\bVolksbank\b/i
/\bVR[- ]?Bank\b/i
/\bVR Banking\b/i
/\bSecureGO\b/i
/\bSecureGO plus\b/i
/\bSantander\b/i
/\bTARGOBANK\b/i
/\bComdirect\b/i

Paketdienste und Logistik:

/\bDHL\b/i
/\bDeutsche Post\b/i
/\bHermes\b/i
/\bDPD\b/i
/\bGLS\b/i
/\bUPS\b/i
/\bFedEx\b/i

E-Commerce:

/\bAmazon\b/i
/\beBay\b/i
/\bOTTO\b/i
/\bZalando\b/i
/\bTemu\b/i
/\bAliExpress\b/i

Microsoft und Cloud:

/\bMicrosoft\b/i
/\bMicrosoft 365\b/i
/\bOffice 365\b/i
/\bOneDrive\b/i
/\bSharePoint\b/i
/\bMicrosoft Teams\b/i
/\bOutlook\b/i
/\bAzure\b/i

Apple und Google:

/\bApple\b/i
/\biCloud\b/i
/\bApple ID\b/i
/\bApp Store\b/i

/\bGoogle\b/i
/\bGmail\b/i
/\bGoogle Drive\b/i
/\bGoogle Workspace\b/i

Social Media und Messenger:

/\bFacebook\b/i
/\bInstagram\b/i
/\bWhatsApp\b/i
/\bMeta\b/i
/\bLinkedIn\b/i
/\bTikTok\b/i
/\bTelegram\b/i

Streaming:

/\bNetflix\b/i
/\bSpotify\b/i
/\bDisney\+?\b/i
/\bPrime Video\b/i

Telekommunikation:

/\bTelekom\b/i
/\bDeutsche Telekom\b/i
/\bVodafone\b/i
/\bO2\b/i
/\b1&1\b/i

Hosting und Internetdienste:

/\bIONOS\b/i
/\bStrato\b/i
/\bCloudflare\b/i
/\bGoDaddy\b/i

Die Map sollte trotzdem nicht zu einem allgemeinen Unternehmensverzeichnis werden. Jeder zusätzliche Begriff erhöht die Wahrscheinlichkeit, dass auch legitime Nachrichten einen Brand-Treffer erhalten.

Der Treffer selbst ist deshalb noch keine vollständige Phishingentscheidung. Die eigentliche Bewertung erfolgt erst im Kontext.

6. Warum Wortgrenzen sinnvoll sind

Ein einfaches Muster wie:

/Amazon/i

funktioniert, kann aber auch innerhalb größerer Zeichenketten matchen.

Sauberer ist für viele Marken:

/\bAmazon\b/i

oder:

/\bMicrosoft\b/i

Die Wortgrenzen reduzieren unbeabsichtigte Teiltreffer.

Sie sind allerdings ebenfalls kein universelles Mittel. Produktnamen, Bindestriche, Sonderzeichen oder unterschiedliche Schreibweisen müssen jeweils berücksichtigt werden.

Ein Beispiel ist:

/VR[- ]?Bank/i

Damit werden sowohl:

VR-Bank

als auch:

VR Bank

erfasst.

Auch absichtliche oder häufig beobachtete Schreibvarianten können sinnvoll sein:

/Consorsbank/i
/Consorbank/i

Solche Varianten sollten jedoch gezielt auf Basis realer Nachrichten ergänzt werden und nicht durch beliebige Tippfehlergeneratoren entstehen.

7. Bankmarken separat halten

Für bankenspezifische Regeln verwende ich zusätzlich:

/etc/rspamd/maps.d/bank_brand.map

Diese Map enthält bewusst nur Finanz- und Bankmarken.

Die zugehörige Multimap-Regel lautet:

BANK_BRAND_DISPLAY {
   type = "header";
   header = "From";
   filter = "email:name";
   map = "/etc/rspamd/maps.d/bank_brand.map";
   regexp = true;
   score = 0.0;
}

Der Score steht hier bewusst auf:

0.0

weil das Symbol primär als Eingangssignal für stärkere Composite-Regeln dient.

Beispielhafte Einträge:

/\bPayPal\b/i
/\bTrade Republic\b/i
/\bN26\b/i
/\bING\b/i
/\bDKB\b/i
/\bSparkasse\b/i
/\bVolksbank\b/i
/\bVR[- ]?Bank\b/i
/\bVR Banking\b/i
/\bSecureGO\b/i
/\bSecureGO plus\b/i
/\bCommerzbank\b/i
/\bDeutsche Bank\b/i
/\bPostbank\b/i
/\bConsorsbank\b/i
/\bConsorbank\b/i

Damit kann die generische Map breit bleiben, ohne dass jede erkannte Marke automatisch in die Bankenlogik gelangt.

8. Phishingtypische Formulierungen erkennen

Neben der Marke selbst prüfe ich bei Banken typische Formulierungen.

Datei:

/etc/rspamd/maps.d/bank_phish_words.map

Beispiele:

/Adresse.*aktualisieren/i
/persönliche Referenznummer/i
/Unzustellbarkeit/i
/Ihre letzte Adresse/i
/Konto.*gesperrt/i
/Zugang.*eingeschränkt/i
/SecureGO.*reaktivieren/i
/reaktivieren.*Deadline/i
/Deadline.*nicht.*verpassen/i
/Zugang.*reaktivieren/i
/Banking.*reaktivieren/i
/Sicherheitsverfahren.*reaktivieren/i
/Alarmdienst/i

Dazu gehören zwei Multimap-Regeln.

Für den Betreff:

BANK_PHISH_WORDS_SUBJECT {
   type = "header";
   header = "Subject";
   map = "/etc/rspamd/maps.d/bank_phish_words.map";
   regexp = true;
   score = 3.0;
}

Für den Inhalt:

BANK_PHISH_WORDS_BODY {
   type = "content";
   map = "/etc/rspamd/maps.d/bank_phish_words.map";
   regexp = true;
   score = 1.5;
}

Wichtig ist, nicht zu allgemeine Wörter zu verwenden.

Problematisch wären beispielsweise:

Login
Portal
Bestätigung
TAN
verifizieren

Solche Begriffe kommen auch in völlig legitimer Kommunikation regelmäßig vor.

Besser sind Kombinationen wie:

/Konto.*gesperrt/i

oder:

/SecureGO.*reaktivieren/i

Die Regel lautet deshalb: Je allgemeiner das Wort, desto weniger eignet es sich als eigenständiger Phishingindikator.

9. Verdächtige IT- und Sicherheitsrollen

Ein weiteres Muster aus realen Phishing-Mails sind vermeintlich offizielle Funktionsbezeichnungen.

Beispielsweise:

Consorbank IT-Koordination

oder:

Volksbank SecureGO-Alarmdienst

Dafür dient:

/etc/rspamd/maps.d/bank_it_display.map

mit Einträgen wie:

/\bIT[- ]?(Koordination|Support|Service|Sicherheit)\b/i
/\bKundenservice\b/i
/\bSicherheitsabteilung\b/i
/\bTechnischer Support\b/i
/\bSystemwartung\b/i
/\bAlarmdienst\b/i

Die Multimap-Regel:

BANK_IT_DISPLAY {
   type = "header";
   header = "From";
   map = "/etc/rspamd/maps.d/bank_it_display.map";
   regexp = true;
   score = 1.5;
}

Ein Begriff wie „IT-Support“ darf alleine natürlich keine Nachricht blockieren. Erst in Kombination mit einer bekannten Bankmarke und einer unpassenden Absenderidentität entsteht ein stärkeres Signal.

10. Legitime Bankdomains

Für die Banklogik existiert weiterhin:

/etc/rspamd/maps.d/legit_bank_domains.map

In meinem Setup enthält diese Map beispielsweise:

n26.com
n26.de
ing.de
dkb.de
paypal.com
paypal.de
sparkasse.de
commerzbank.de
deutsche-bank.de
postbank.de
consorsbank.de
consorsbanking.de
vr.de
volksbank.de

Die zugehörige Regel:

LEGIT_BANK_SENDER {
   type = "from";
   filter = "email:domain";
   map = "/etc/rspamd/maps.d/legit_bank_domains.map";
   score = -6.0;
}

Eine Domain sollte nur aufgenommen werden, wenn ihre Zugehörigkeit wirklich verifiziert wurde.

Nicht ausreichend ist:

SPF hat bestanden

oder:

DKIM hat bestanden

Das beweist lediglich, dass die Nachricht technisch zur verwendeten Domain passt.

Ebenso wenig sollte eine Domain allein deshalb aufgenommen werden, weil sie in einer scheinbar legitimen Mail auftaucht.

11. Die Einschränkung globaler Domain-Allowlisten

Auch die bestehende Bank-Allowlist besitzt eine konzeptionelle Schwäche.

Angenommen, sowohl PayPal als auch eine Volksbank befinden sich in den Brand-Maps und paypal.com ist eine legitime Domain. Dann wäre theoretisch folgende Nachricht denkbar:

From: "Volksbank Sicherheit" <service@paypal.com>

Eine globale Domainprüfung kann erkennen:

paypal.com ist grundsätzlich legitim

Sie beantwortet jedoch nicht:

Gehört paypal.com zur Marke Volksbank?

Für eine strengere Architektur wäre langfristig eine direkte Zuordnung sinnvoll:

PayPal
  -> paypal.com
  -> paypal.de

N26
  -> n26.com
  -> n26.de

Consorsbank
  -> consorsbank.de
  -> consorsbanking.de

Bei einer wachsenden Regelbasis wäre dafür eine Lua-Regel oder eine strukturierte Brand-Domain-Zuordnung sauberer als eine einzige globale Allowlist.

Für die generische BRAND_IMPERSONATION-Erkennung verwende ich deshalb bewusst nicht einfach eine pauschale Liste aller vermeintlich legitimen Amazon-, Microsoft-, DHL-, Apple- oder Google-Versanddomains. Gerade große Anbieter verwenden verschiedene Versandplattformen, Subdomains und Dienstleister. Eine unvollständige Allowlist kann sehr schnell neue False Positives oder blinde Flecken erzeugen.

12. Generische Brand-Impersonation

Der Kern der neuen Architektur steckt in:

/etc/rspamd/local.d/composites.conf

Die generische Regel lautet:

BRAND_IMPERSONATION {
  expression = "(FROM_NEQ_ENVFROM | DMARC_NA) & BRAND_SPOOF_DISPLAY";
  score = 8.0;
  policy = "leave";
}

Damit sind zwei Ebenen erforderlich.

Erstens muss eine geschützte Marke im Anzeigenamen erkannt werden:

BRAND_SPOOF_DISPLAY

Zweitens muss zusätzlich eine Auffälligkeit in der Absenderstruktur bestehen:

FROM_NEQ_ENVFROM

oder:

DMARC_NA

Aus:

Marke
+
auffällige Absenderlage

wird:

BRAND_IMPERSONATION

Das ist wesentlich allgemeiner als die frühere FAKE_BANK_BRAND-Regel.

policy = "leave" ist hier ebenfalls bewusst gesetzt. Damit bleiben die beteiligten Einzelsymbole beziehungsweise ihre Scores erhalten, statt vollständig durch das Composite ersetzt zu werden. Rspamd bietet über Composite-Policies genau diese Steuerungsmöglichkeit.

13. PHISH_CORE von Brand-Impersonation trennen

Vor der Umstellung sah meine Logik sinngemäß so aus:

PHISH_CORE {
  expression = "(FROM_NEQ_ENVFROM | DMARC_NA) &
                (BRAND_SPOOF_DISPLAY | RECEIVED_SPAMHAUS_XBL)";
  score = 8.0;
}

Damit waren zwei unterschiedliche Dinge in derselben Regel vermischt:

Markenmissbrauch

und:

IP-Reputation

Nach dem Refactoring ist PHISH_CORE enger:

PHISH_CORE {
  expression = "(FROM_NEQ_ENVFROM | DMARC_NA) &
                RECEIVED_SPAMHAUS_XBL";
  score = 8.0;
}

Die Brand-Erkennung läuft separat über:

BRAND_IMPERSONATION

Das macht die Ergebnisse verständlicher und erleichtert spätere Analysen.

Eine ELSTER-Mail soll als:

BRAND_IMPERSONATION

erscheinen und nicht zufällig über eine Bank- oder IP-Regel erklärt werden.

14. Bankregeln bleiben separat

Für das eigentliche Bank-Phishing existieren weiterhin stärkere Regeln.

Eine verdächtige IT- oder Sicherheitsrolle:

FAKE_BANK_IT_SENDER {
  expression = "BANK_BRAND_DISPLAY &
                !LEGIT_BANK_SENDER &
                BANK_IT_DISPLAY";
  score = 8.0;
}

Phishingtypische Formulierungen:

FAKE_BANK_PHISHING {
  expression = "BANK_BRAND_DISPLAY &
                !LEGIT_BANK_SENDER &
                (BANK_PHISH_WORDS_SUBJECT |
                 BANK_PHISH_WORDS_BODY)";
  score = 12.0;
}

Eine bereits bekannte schädliche Absenderdomain in Verbindung mit Phishingtext:

KNOWN_BAD_SENDER_WITH_PHISH_WORDS {
  expression = "SENDER_DOMAIN_LOCAL_BLACKLIST &
                (BANK_PHISH_WORDS_SUBJECT |
                 BANK_PHISH_WORDS_BODY)";
  score = 15.0;
}

Der wichtige Unterschied zum alten Aufbau ist:

BANK_BRAND_DISPLAY

statt:

BRAND_SPOOF_DISPLAY

Dadurch kann eine ELSTER-, Amazon- oder DHL-Mail diese Bankregeln nicht mehr allein deshalb auslösen, weil die Marke in der allgemeinen Brand-Map steht.

15. Bekannte schädliche Absenderdomains

Zusätzlich pflege ich:

/etc/rspamd/maps.d/sender_domain_blacklist.map

Dort gehören nur tatsächlich untersuchte beziehungsweise ausreichend eindeutig schädliche Domains hinein.

Eine ganze Domain sollte nicht vorschnell gesperrt werden. Gerade bei kompromittierten Benutzerkonten ist durchaus möglich, dass nur ein einzelnes Postfach missbraucht wurde, während die übrige Domain legitime Kommunikation versendet.

Vor einer dauerhaften Sperre prüfe ich deshalb insbesondere:

  • Wurde bereits mehrfach Spam oder Phishing von der Domain beobachtet?
  • Ist legitime Kommunikation mit dieser Organisation zu erwarten?
  • Handelt es sich nur um ein kompromittiertes Benutzerkonto?
  • Reicht eine Absenderadresse statt einer vollständigen Domain?
  • Gibt es weitere unabhängige Reputationsergebnisse?

Eine Domain-Blacklist ist ein nützlicher zusätzlicher Layer. Sie ersetzt jedoch keine generische Brand-Erkennung, weil Angreifer Domains jederzeit wechseln können.

16. Ein realer ELSTER-Fall

Der konkrete Anlass für die Erweiterung war folgende Nachricht:

From: "ELSTER Bestätigung"
      <cesar@multiverseaerospacepartners.com>

Subject:
ELSTER: Wichtiger Hinweis zu Ihren Steuerdaten

Die Nachricht wurde über ein authentifiziertes SMTP-Konto verschickt.

Im Header tauchte unter anderem auf:

X-Authenticated-UID:
cesar@multiverseaerospacepartners.com

sowie:

RCVD_VIA_SMTP_AUTH

Der Absender verwendete also nicht einfach nur einen gefälschten MIME-From-Header. Die Nachricht lief über eine tatsächlich authentifizierte Mailinfrastruktur.

Beim ersten Scan ergab sich:

Action: greylist
Spam: false
Score: 5.63 / 15.00

mit:

DMARC_NA                  2.50
HFILTER_HOSTNAME_UNKNOWN  2.50
RCPT_COUNT_ONE            0.50
MANY_INVISIBLE_PARTS      0.20
RCVD_NO_TLS_LAST          0.10

Es fehlte:

BRAND_SPOOF_DISPLAY

Nach Aktivierung von:

regexp = true;

funktionierte die bestehende Brand-Map.

Zunächst löste die Nachricht dadurch allerdings noch die alte:

FAKE_BANK_BRAND

aus.

Das war zwar technisch effektiv, aber fachlich offensichtlich falsch. Daraufhin wurde die Brand-Logik von der Bankenlogik getrennt.

17. Ergebnis nach dem Refactoring

Der gleiche gespeicherte ELSTER-Fall ergab nach der Umstellung:

Action: reject
Spam: true
Score: 29.18 / 15.00

Entscheidend waren nun:

BRAND_SPOOF_DISPLAY (6.00)[ELSTER Bestätigung]
BRAND_IMPERSONATION (8.00)
DMARC_NA (2.50)

Zusätzlich hatte sich inzwischen auch der statistische Klassifikator eindeutig positioniert:

BAYES_SPAM (7.98)[99.97%]

Die Regressionstests bestätigten:

[OK] Action = reject
[OK] BRAND_IMPERSONATION feuert
[OK] FAKE_BANK_BRAND entfernt
[OK] ELSTER läuft nicht mehr über PHISH_CORE

Damit entspricht auch die Symbolik wieder der tatsächlichen Ursache.

Die Mail wird nicht abgelehnt, weil sie angeblich eine gefälschte Bank wäre. Sie wird abgelehnt, weil eine bekannte Marke im sichtbaren Absender mit einer auffälligen technischen Absenderlage kombiniert wird.

18. Die vorhandenen Action-Schwellen berücksichtigen

Rspamd berechnet zunächst einen Score und leitet daraus anhand der konfigurierten Actions die gewünschte Behandlung ab.

In meinem hier getesteten Setup liegt die Reject-Grenze bei:

15.00

Der ursprüngliche ELSTER-Scan:

5.63 / 15.00

reichte deshalb nicht aus.

Nach der Brand-Erkennung:

29.18 / 15.00

war der Fall eindeutig.

Die konkreten Schwellenwerte sollte man allerdings niemals aus einem Blogbeitrag blind übernehmen. Entscheidend ist die eigene:

/etc/rspamd/local.d/actions.conf

beziehungsweise die tatsächlich aktive Konfiguration.

Die richtige Höhe hängt stark von den übrigen Symbolgewichten, der Art des Mailverkehrs und der gewünschten Behandlung zwischen Greylisting, Header-Markierung, Spamordner und Reject ab.

19. Bayes ist ein zusätzliches Signal, kein Ersatz für Regeln

Beim ursprünglichen ELSTER-Test erkannte Bayes die Nachricht zunächst sogar leicht als Ham:

BAYES_HAM (-0.07)[60.65%]

Später lag der gleiche Fall bei:

BAYES_SPAM (7.98)[99.97%]

Das zeigt gut, warum statistische Verfahren nicht die einzige Schutzschicht sein sollten.

Ein Klassifikator kann durch Trainingsdaten, neue Kampagnen oder bisher unbekannte Nachrichtentypen falsch liegen. Die Brand-Regel funktioniert dagegen deterministisch:

ELSTER im Displaynamen
+
auffällige Absenderlage
=
BRAND_IMPERSONATION

Eine eindeutig als Spam identifizierte Nachricht kann mit Rspamd nachtrainiert werden:

rspamc learn_spam < phishing.eml

Eine legitime Nachricht, die fälschlicherweise gelernt wurde:

rspamc learn_ham < legitime-mail.eml

Bei einer Dovecot-Integration kann dieses Feedback auch automatisiert an Benutzeraktionen wie das Verschieben in oder aus dem Spamordner gekoppelt werden. Rspamd unterstützt entsprechende Lernoperationen über rspamc.

20. RBL-, URL- und Reputationsergebnisse

Brand-Impersonation darf nicht bedeuten, dass andere Rspamd-Mechanismen unwichtig werden.

Bei verdächtigen Nachrichten sind weiterhin interessant:

  • Absender-IP-Reputation
  • Spamhaus und andere DNSBLs
  • URL-Reputation
  • Phishingfeeds
  • Redirector-Erkennung
  • Fuzzy-Hashes
  • Pyzor
  • MIME-Anomalien
  • versteckte HTML-Elemente
  • ungewöhnliche Header
  • SMTP-AUTH-Herkunft
  • Bayes
  • Neural-Ergebnisse

Beim untersuchten ELSTER-Fall enthielt die Nachricht beispielsweise URLs wie:

fonts.googleapis.com

und:

narrows-tuck-doric-glossy-vb-673adb8d.s3.us-east-2.amazonaws.com

Ein Amazon-S3-Host ist alleine natürlich kein Phishingbeweis. Cloudspeicher und CDN-Infrastrukturen werden sowohl legitim als auch missbräuchlich verwendet.

Gerade deshalb ist die Kombination mehrerer unabhängiger Merkmale so wichtig.

21. Greylisting ist kein ausreichender Phishing-Schutz

Der ursprüngliche ELSTER-Scan endete bei:

Action: greylist

Greylisting kann gegen einfache Bots und schlecht konfigurierte Spaminfrastruktur hilfreich sein. Gegen kompromittierte beziehungsweise reguläre Mailkonten ist seine Wirkung jedoch begrenzt.

Ein echter Hostinganbieter oder normaler MTA versucht eine Nachricht nach einem temporären SMTP-Fehler erneut zuzustellen.

Damit erfüllt der Angreifer genau das Verhalten, das Greylisting von einem legitimen Sender erwartet.

Greylisting bleibt deshalb eine zusätzliche Schicht. Es ersetzt weder Brand-Impersonation noch URL-, Reputation- oder Inhaltsanalyse.

22. Konfiguration immer testen

Nach Änderungen an strukturellen Rspamd-Dateien führe ich grundsätzlich zunächst aus:

rspamadm configtest

Nur wenn:

syntax OK

zurückkommt, wird die aktive Konfiguration geladen:

systemctl reload rspamd

Das reicht alleine jedoch nicht.

Der heutige Regex-Fehler hat gerade gezeigt, dass:

syntax OK

nicht automatisch bedeutet:

Regel funktioniert fachlich wie erwartet

Deshalb folgt anschließend ein echter Rescan.

23. Nachrichten direkt aus Dovecot testen

Auf meinem System liegt der relevante Maildir unter:

/var/vmail/mailboxes/okami.de/okami/mail

Eine Nachricht kann beispielsweise über ihre Message-ID gesucht werden:

grep -RIl \
'a5992d8672a4919abd87ce6590e4cfd69601ff@multiverseaerospacepartners.com' \
/var/vmail/mailboxes/okami.de/okami/mail

Der konkrete ELSTER-Testfall lag unter:

/var/vmail/mailboxes/okami.de/okami/mail/cur/

Eine gefundene Datei kann dann direkt gegen den normalen Rspamd-Worker getestet werden:

FILE='/var/vmail/mailboxes/okami.de/okami/mail/cur/<maildatei>'

rspamc -h 127.0.0.1:11333 symbols < "$FILE"

Das ist besonders hilfreich, weil exakt dieselbe reale Nachricht nach jeder Änderung erneut ausgewertet werden kann.

Damit entsteht aus einem einmaligen Phishingvorfall ein dauerhafter Regressionstest.

24. Sinnvolle Regressionstests

Nach Änderungen an Brand-Maps oder Composites sollten nicht nur bekannte Phishing-Mails getestet werden.

Mindestens folgende Fälle sind sinnvoll.

Legitime normale Mail

Erwartung:

kein BRAND_SPOOF_DISPLAY
kein BRAND_IMPERSONATION
keine FAKE_BANK-Regel

Generische bekannte Marke von auffälligem Absender

Beispiel:

From: "ELSTER Bestätigung" <test@fremde-domain.example>

bei entsprechender technischer Auffälligkeit.

Erwartung:

BRAND_SPOOF_DISPLAY
BRAND_IMPERSONATION

Bankmarke mit Phishingtext

Beispiel:

From: "Volksbank Sicherheit" <test@fremde-domain.example>
Subject: SecureGO reaktivieren – Deadline nicht verpassen

Erwartete Signale können sein:

BRAND_SPOOF_DISPLAY
BANK_BRAND_DISPLAY
BANK_PHISH_WORDS_SUBJECT
FAKE_BANK_PHISHING

Supportbegriff ohne Bankmarke

Beispiel:

From: "IT-Support" <support@firma.example>

Hier darf ein möglicherweise vorhandenes:

BANK_IT_DISPLAY

nicht automatisch zu:

FAKE_BANK_IT_SENDER

führen.

Bekannte Marke in legitimer Kommunikation

Gerade nach einer deutlichen Erweiterung von brand_spoof.map müssen echte Microsoft-, Amazon-, DHL-, PayPal-, Apple- oder Google-Mails beobachtet werden.

Ein:

BRAND_SPOOF_DISPLAY

ist bei einer solchen Mail nicht automatisch ein Fehler. Entscheidend ist, ob das nachfolgende Composite ebenfalls auslöst und ob die Gesamtbewertung plausibel bleibt.

25. Dateirechte

Für lokale Map-Dateien reichen üblicherweise Leserechte für Rspamd und Schreibrechte nur für den Administrator.

Beispielsweise:

chmod 644 /etc/rspamd/maps.d/brand_spoof.map
chmod 644 /etc/rspamd/maps.d/bank_brand.map
chmod 644 /etc/rspamd/maps.d/bank_phish_words.map
chmod 644 /etc/rspamd/maps.d/bank_it_display.map
chmod 644 /etc/rspamd/maps.d/legit_bank_domains.map
chmod 644 /etc/rspamd/maps.d/sender_domain_blacklist.map

Der Besitzer kann beispielsweise:

chown root:root /etc/rspamd/maps.d/*.map

sein.

Entscheidend ist, dass der Rspamd-Prozess die Dateien lesen kann und unprivilegierte Benutzer sie nicht verändern dürfen.

26. Änderungen automatisieren und Backups erzeugen

Bei größeren Umbauten ändere ich die Dateien inzwischen nicht mehr manuell ohne Sicherung.

Vor strukturellen Änderungen werden die betroffenen Konfigurationen in ein zeitgestempeltes Verzeichnis kopiert, beispielsweise:

/root/rspamd-brand-architecture-20260920-093433

Erst danach werden Maps und Composites verändert.

Der Ablauf ist grundsätzlich:

Backup
  ↓
Änderung
  ↓
rspamadm configtest
  ↓
Reload
  ↓
configdump prüfen
  ↓
echte Mail erneut scannen
  ↓
Regressionsergebnis kontrollieren

Bei einem fehlgeschlagenen configtest kann automatisiert auf die vorher gesicherten Dateien zurückgerollt werden.

Gerade bei einem Mailserver ist das wesentlich sinnvoller als mehrere Änderungen gleichzeitig manuell vorzunehmen und anschließend nicht mehr eindeutig nachvollziehen zu können, welcher Schritt einen Fehler verursacht hat.

27. Aktive Konfiguration kontrollieren

Nach dem Reload sollte nicht nur die Datei auf der Festplatte betrachtet werden.

Mit:

rspamadm configdump multimap

kann geprüft werden, ob Rspamd beispielsweise tatsächlich Folgendes geladen hat:

BRAND_SPOOF_DISPLAY {
    type = "header";
    header = "From";
    filter = "email:name";
    map = "/etc/rspamd/maps.d/brand_spoof.map";
    regexp = true;
    score = 6.0;
}

und:

BANK_BRAND_DISPLAY {
    type = "header";
    header = "From";
    filter = "email:name";
    map = "/etc/rspamd/maps.d/bank_brand.map";
    regexp = true;
    score = 0.0;
}

Entsprechend lassen sich die aktiven Composites prüfen:

rspamadm configdump composites

Dort sollten unter anderem die gewünschte:

BRAND_IMPERSONATION

und die getrennten Bankregeln erscheinen.

Damit lässt sich unterscheiden zwischen:

Datei wurde geändert

und:

Rspamd verwendet die Änderung tatsächlich

28. Typische Fehler

Regex-Muster ohne Regex-Modus

Das war der wichtigste Fund aus dem realen Betrieb.

Eine Map enthält:

/ELSTER/i
/Amazon/i
/DHL/i

aber die Multimap besitzt kein:

regexp = true;

Die Konfiguration kann trotzdem syntaktisch gültig sein.

Deshalb immer einen echten Match testen.

Zu allgemeine Begriffe

Schlecht:

/Login/i
/Portal/i
/Bestätigung/i
/TAN/i

Besser:

/Konto.*gesperrt/i
/SecureGO.*reaktivieren/i
/Adresse.*aktualisieren/i

Einzelne Merkmale überbewerten

Ein Supportbegriff oder eine Marke alleine sollte nicht ohne Kontext sofort einen extremen Score erzeugen.

Hohe Bewertungen gehören auf Kombinationen.

SPF als Vertrauenssignal für die sichtbare Marke interpretieren

Ein:

R_SPF_ALLOW

bedeutet nicht:

ELSTER ist der Absender

Es bedeutet nur, dass der sendende Server zur tatsächlich geprüften SPF-Domain passt.

DKIM überbewerten

Das gleiche gilt für DKIM.

Ein gültiges DKIM-Signaturergebnis bestätigt die signierende Domain, nicht automatisch den sichtbaren Markennamen.

Eine globale Domain-Allowlist als Markenbeziehung interpretieren

paypal.com

kann eine legitime PayPal-Domain sein.

Das bedeutet nicht, dass:

"Volksbank Sicherheit" <service@paypal.com>

plötzlich plausibel ist.

Bayes blind vertrauen

Auch ein eindeutiger Phishing-Fall kann zunächst:

BAYES_HAM

bekommen.

Statistische Modelle sind ein zusätzlicher Layer, keine Wahrheit.

Ganze Domains sofort blockieren

Ein kompromittiertes Konto macht nicht zwangsläufig jede Mail derselben Domain bösartig.

29. Pflegeprozess

Eine lokale Phishing-Regelbasis muss gepflegt werden, sollte aber nicht für jede einzelne Spam-Mail um eine neue Spezialregel wachsen.

Bei neuen Fällen prüfe ich zunächst:

  1. Welcher sichtbare Anzeigename wurde verwendet?
  2. Welche Marke wird imitiert?
  3. Welche tatsächliche From-Domain wurde verwendet?
  4. Wie lautet der Envelope-From?
  5. Welche SPF-, DKIM- und DMARC-Ergebnisse liegen vor?
  6. Wurde SMTP AUTH verwendet?
  7. Welche Systeme stehen in der Received-Kette?
  8. Welche URLs enthält die Nachricht?
  9. Welche Rspamd-Symbole wurden ausgelöst?
  10. Wie bewertet Bayes die Nachricht?
  11. Existiert die Marke bereits in der Brand-Map?
  12. Fehlt tatsächlich eine generische Regel oder nur ein einzelnes Sample?

Danach kann entschieden werden, ob:

eine Marke ergänzt
ein spezifisches Textmuster ergänzt
eine schädliche Domain aufgenommen
Bayes nachtrainiert

oder:

überhaupt nichts geändert

werden sollte.

Nicht jeder Spam braucht eine eigene Regel. Ziel ist eine kleine Zahl sinnvoll generalisierender Mechanismen.

30. Was die erweiterte Brand-Liste verändert

Mit der Ausweitung auf ELSTER, Microsoft, DHL, Amazon, Apple, Google, Paketdienste, Telekommunikationsanbieter und weitere häufig imitierte Marken steigt zwangsläufig auch die Bedeutung von False-Positive-Tests.

Eine große Marke kann legitimerweise im Anzeigenamen auftauchen.

Das ist sogar der Normalfall.

Deshalb lautet die Regel eben nicht:

Microsoft im From
=
Spam

sondern:

Microsoft im From
+
auffällige Absenderkonstellation
=
verdächtig

Die Trennung zwischen:

BRAND_SPOOF_DISPLAY

und:

BRAND_IMPERSONATION

ist daher besonders wichtig.

Das erste Symbol beschreibt eine Beobachtung.

Das zweite beschreibt eine Kombination, die als Sicherheitsindikator verwendet wird.

31. Nächste sinnvolle Ausbaustufe: Brand-Domain-Zuordnung

Die aktuelle Architektur verbessert die Erkennung deutlich, ist aber noch nicht das theoretisch präziseste Modell.

Der nächste Schritt wäre eine direkte Zuordnung:

ELSTER
  -> elster.de

PayPal
  -> paypal.com
  -> paypal.de

N26
  -> n26.com
  -> n26.de

und entsprechend für weitere Marken.

Dann könnte die Logik tatsächlich sagen:

Brand = ELSTER
From-Domain = elster.de
=> plausibel

beziehungsweise:

Brand = ELSTER
From-Domain = multiverseaerospacepartners.com
=> nicht passend

Das wäre präziser als eine globale Legit-Domain-Liste.

Bei wenigen Marken ließe sich dies über separate Multimaps lösen. Bei einer größeren Sammlung wäre eine Lua-basierte Lookup-Struktur vermutlich besser wartbar.

Wichtig ist dabei weiterhin: Nur verifizierte Domainbeziehungen eintragen. Keine Vermutungen, keine aus einzelnen Mails abgeleiteten Versanddomains und keine automatisch aus SPF erzeugten Allowlists.

32. Weitere sinnvolle Härtung

Nach der Brand-Architektur bieten sich weitere Ausbaustufen an.

Interessant sind insbesondere eine kontrollierte Brand-Domain-Zuordnung, automatisierte Regressionstests, Dovecot-/IMAPSieve-Feedback für Bayes, systematische URL- und Redirect-Auswertung sowie die Beobachtung realer False Positives.

Auch Neural- und andere statistische Klassifikatoren sollten nicht isoliert betrachtet werden. Entscheidend bleibt der Vergleich mit realen Nachrichten.

Für besonders präzise Kombinationen können später auch erzwungene Actions interessant sein. Solche Regeln sollten aber nur dann eingesetzt werden, wenn die False-Positive-Wahrscheinlichkeit durch ausreichend viele Tests praktisch ausgeschlossen wurde.

Fazit

Moderne Phishing-Mails sind häufig technisch wesentlich sauberer als klassische Spam-Nachrichten. Ein Angreifer muss SPF nicht umgehen, wenn er ein echtes Konto oder einen regulären Mailserver verwenden kann. Er muss DKIM nicht brechen, wenn seine eigene oder eine kompromittierte Domain korrekt signieren kann. Und auch eine technisch unauffällige Mail kann trotzdem versuchen, sich im sichtbaren Anzeigenamen als ELSTER, Microsoft, DHL, PayPal oder eine Bank auszugeben.

Deshalb reicht es nicht, ausschließlich zu fragen, ob die technische Absenderdomain authentifiziert wurde. Zusätzlich muss geprüft werden, welche Identität der Benutzer tatsächlich angezeigt bekommt.

Die generische Erkennung folgt inzwischen diesem Prinzip:

bekannte Marke im sichtbaren Anzeigenamen
+
auffällige technische Absenderkonstellation
=
BRAND_IMPERSONATION

Banken erhalten darüber hinaus eigene Prüfungen für bekannte Bankmarken, legitime Domains, verdächtige Funktionsbezeichnungen und phishingtypische Texte.

Der wichtigste praktische Fund bei der Umsetzung war dabei kein spektakulärer Angriff, sondern ein unscheinbarer Konfigurationsparameter. Die Brand-Map enthielt bereits reguläre Ausdrücke, regexp = true fehlte jedoch in der Multimap-Regel. Die Konfiguration war syntaktisch gültig und die vermeintliche Schutzschicht vorhanden – sie matchte nur nicht.

Der reale ELSTER-Test machte diesen Fehler sichtbar. Nach der Korrektur und der anschließenden Trennung von generischer Brand-Impersonation und Bank-Phishing stieg derselbe Testfall von:

5.63 / 15.00
Action: greylist

auf:

29.18 / 15.00
Action: reject

mit:

BRAND_SPOOF_DISPLAY (6.00)[ELSTER Bestätigung]
BRAND_IMPERSONATION (8.00)

Genau deshalb besteht Mailserver-Härtung für mich nicht nur aus dem Schreiben von Regeln. Sie besteht aus Regeln, nachvollziehbaren Maps, Backups, configtest, Kontrolle der tatsächlich geladenen Konfiguration und reproduzierbaren Tests mit echten Nachrichten.

Eine Regel, die auf dem Papier richtig aussieht, ist erst dann eine funktionierende Schutzmaßnahme, wenn ein realer Test nachweist, dass sie tatsächlich auslöst.

Schlagwörter