← Blog

Vorfallanalyse · DNS · E-Mail-Sicherheit

Kompromittierte STRATO-Kundenaccounts:
Phishing über manipulierte SPF- und DNS-Einträge.

Im August 2026 stieß FD-IX auf eine Serie von Phishing-Mails mit einem wiederkehrenden technischen Muster: kompromittierte STRATO-Kundenaccounts, nachträglich autorisierte Versand-IP-Adressen im SPF und neu angelegte MTA-Subdomains. Eine technische Analyse der Angriffskette – und konkrete Maßnahmen für Domaininhaber.

01 · Entdeckung

Der erste Hinweis kam aus den eigenen Spamtraps

Spamtraps sind speziell eingerichtete E-Mail-Adressen, die nicht für normale Korrespondenz verwendet werden. Treffen dort Nachrichten ein, können sie für die Erkennung und technische Analyse unerwünschter Mailströme genutzt werden. Genau darüber fiel FD-IX im August 2026 eine Serie von Phishing-Nachrichten auf.

Die Nachrichten wirkten zunächst wie viele andere Phishing-Mails. Auffällig wurde der Vorgang durch die technische Analyse des Versandwegs: Bei verschiedenen, voneinander unabhängigen Absenderdomains tauchte ein nahezu identisches Muster auf. Die Domains wurden bei STRATO verwaltet, in ihren DNS-Zonen waren neue MTA-Hostnamen angelegt worden und die zugehörigen externen IP-Adressen waren zusätzlich in die jeweiligen SPF-Einträge aufgenommen worden.

Die anschließende Prüfung bestätigte in den untersuchten Fällen den unberechtigten Zugriff auf die jeweiligen STRATO-Kundenaccounts. Wie die Zugangsdaten erlangt wurden, lässt sich aus den vorliegenden Daten nicht bestimmen. Insbesondere gibt es auf Grundlage dieser Beobachtungen keinen Nachweis für eine Sicherheitslücke in den Systemen von STRATO selbst.

02 · Phishing-Inhalt

Die Nachrichten gaben sich als N26 aus

Bei den beobachteten Nachrichten handelte es sich nicht um beliebigen Spam. Die Absender gaben sich als N26 Bank aus. Verwendet wurde unter anderem der Betreff:

Betreff: „Ihre Karte ist vorübergehend gesperrt – so reaktivieren Sie sie sicher“

Bereits dieser Betreff folgt einem typischen Phishing-Muster: Eine vermeintliche Kartensperrung erzeugt unmittelbaren Handlungsdruck, während die Formulierung einer „sicheren“ Reaktivierung Vertrauen schaffen soll.

Technisch besonders relevant war, dass für den Versand nicht lediglich eine fremde Domain als sichtbarer Absender vorgetäuscht wurde. In den untersuchten Fällen hatten die Angreifer zuvor Zugriff auf reale STRATO-Kundenaccounts erlangt und die DNS-Konfiguration der dort verwalteten Domains verändert. Dadurch konnten die kompromittierten Domains als Bestandteil der Versand-Infrastruktur eingesetzt werden.

03 · Angriffsmuster

DNS-Zugriff wird zur Grundlage für glaubwürdigeren Mailversand

Die untersuchten Fälle folgten demselben Grundprinzip. Die Angreifer beschränkten sich nicht darauf, eine Domain lediglich als sichtbaren Absender in einer Phishing-Mail einzutragen. Stattdessen veränderten sie die DNS-Konfiguration der betroffenen Domain so, dass ihre eigene Versand-Infrastruktur technisch autorisiert wurde.

  1. 01
    STRATO-Account wird kompromittiert

    Unbefugte erhalten Zugriff auf einen STRATO-Kundenaccount mit Berechtigung zur Verwaltung der Domain und ihrer DNS-Einträge. Der konkrete Weg, über den die Zugangsdaten erlangt wurden, ist nicht bekannt.

  2. 02
    SPF-Eintrag wird verändert

    In den bestehenden SPF-Record wird eine zusätzliche externe IPv4-Adresse aufgenommen. Damit erklärt die Domain diese Adresse gegenüber empfangenden Mailservern als zulässigen Versandweg für die vom SPF geprüften Identitäten.

  3. 03
    MTA-Subdomain wird angelegt

    Zusätzlich wird ein neuer Hostname nach dem Muster mta.domain.tld, mta2.domain.tld oder ähnlich angelegt. Der A-Record dieses Hosts verweist auf die für den Phishing-Versand verwendete externe IP-Adresse.

  4. 04
    Phishing-Versand startet

    Die Angreifer versenden über ihre eigene Infrastruktur Nachrichten unter Verwendung der kompromittierten Domain. Durch die vorherige SPF-Manipulation kann die verwendete Versand-IP bei passender Envelope-From- oder HELO-Identität eine SPF-Prüfung bestehen.

  5. 05
    Wiederkehrendes Muster wird sichtbar

    Phishing-Nachrichten erreichen die Spamtraps von FD-IX. Mailserver-Logs und DNS-Abfragen zeigen bei mehreren voneinander unabhängigen Domains dieselbe Kombination aus neuem MTA-Host und nachträglich autorisierter Versand-IP.

Die einzelnen Domainnamen und konkreten IP-Adressen veröffentlichen wir bewusst nicht. Für die technische Bewertung ist das Muster entscheidend: Ein Angreifer mit Zugriff auf die DNS-Verwaltung kann nicht nur sichtbare Hostnamen anlegen, sondern auch Mechanismen der E-Mail-Authentifizierung zu seinen Gunsten verändern.

04 · Einordnung

Automatisierung – und möglicherweise KI als Skalierungsfaktor

Die Zahl der beobachteten Fälle und das sehr ähnliche technische Vorgehen sprechen dafür, dass wesentliche Teile der Kampagne automatisiert oder zumindest stark standardisiert ablaufen. Wiederholt zeigt sich dieselbe Kette: Zugriff auf einen Hosting-Account, Manipulation der DNS-Zone, Ergänzung des SPF-Records, Anlage einer MTA-Subdomain und anschließender Phishing-Versand über externe Server-Infrastruktur.

Ob dabei tatsächlich KI-Systeme eingesetzt werden, lässt sich anhand der vorliegenden technischen Daten nicht belegen. Moderne Automatisierungs- und KI-Werkzeuge können solche Kampagnen jedoch erheblich skalierbarer machen – beispielsweise bei der Aufbereitung von Zielinformationen, der Erstellung und Variation von Phishing-Texten oder bei wiederkehrenden Arbeitsschritten rund um kompromittierte Accounts.

Für die Verteidigung ist dabei weniger entscheidend, ob hinter jedem einzelnen Schritt tatsächlich KI steckt. Entscheidend sind Geschwindigkeit und Skalierbarkeit: Ein erfolgreich kompromittierter Zugang kann sehr schnell zu einem Baustein einer größeren Phishing-Infrastruktur werden.

Die inzwischen beobachteten gleichartigen Manipulationen sollten deshalb nicht nur isoliert pro Domain betrachtet werden. Für die Erkennung solcher Kampagnen wird es zunehmend wichtig, wiederkehrende technische Merkmale über einzelne Nachrichten, Domains und Server hinweg zu korrelieren.

04 · SPF und DNS

Warum ein manipulierter SPF-Record so relevant ist

SPF, das Sender Policy Framework, wird im DNS der Absenderdomain veröffentlicht. Es beschreibt, welche Systeme für bestimmte SMTP-Identitäten E-Mails im Namen einer Domain versenden dürfen. Der SPF-Standard RFC 7208 sieht ausdrücklich vor, dass Domaininhaber darüber autorisierte Hosts festlegen.

Genau diese Eigenschaft wird bei einem kompromittierten DNS-Zugang zum Problem: Wer den SPF-Eintrag verändern kann, kann eine eigene Versand-IP hinzufügen. Für einen empfangenden Mailserver sieht diese IP anschließend nicht zwingend wie ein fremder Server aus, sondern kann – abhängig von der beim Versand verwendeten Identität – einen gültigen SPF-Treffer erzeugen.

SPF vorher:
example.tld  TXT  "v=spf1 [legitime Versandwege] ..."

SPF nach der Manipulation:
example.tld  TXT  "v=spf1 [legitime Versandwege] ip4:203.0.113.42 ..."

Zusätzlich angelegt:
mta4.example.tld  A  203.0.113.42

Das Beispiel ist bewusst schematisch und verwendet keine reale betroffene Domain oder Angreifer-IP. Entscheidend ist die Kombination: Die gleiche externe IP taucht als neuer Mailhost und als zusätzlicher, vom SPF autorisierter Versandweg auf.

Ein SPF-Pass allein beweist deshalb nicht, dass eine Nachricht vertrauenswürdig oder inhaltlich legitim ist. SPF beantwortet in erster Linie die technische Frage, ob die sendende IP für die geprüfte Domainidentität autorisiert ist. Wer die DNS-Zone kontrolliert, kann diese Autorisierung verändern. Genau deshalb müssen SPF, DKIM, DMARC, Reputation, Versandverhalten und weitere Signale gemeinsam bewertet werden.

05 · Technische Analyse

Wie das technische Muster sichtbar wurde

Ausgangspunkt der Analyse waren Phishing-Nachrichten, die an Spamtrap-Adressen von FD-IX eingingen. Bei der technischen Untersuchung zeigte sich in mehreren Fällen ein nahezu identisches Muster. Durch die Auswertung von Mailserver-Logs, DNS-Einträgen und öffentlich auflösbaren Konfigurationen ließ sich nachvollziehen, wie manipulierte SPF-Einträge und neu angelegte MTA-Subdomains für den Versand der Nachrichten genutzt wurden.

SpamtrapsUnerwünschte Nachrichten an Adressen, die nicht für reguläre Kommunikation verwendet werden
Mailserver-LogsZeitpunkt, Verbindungsdaten, sendende IP, SMTP-Identitäten und technische Verarbeitung der Spamtrap-Nachrichten
DNSNeu auffällige MTA-Hostnamen sowie SPF-Einträge, in denen die verwendeten Versand-IP-Adressen autorisiert wurden
KorrelationDasselbe Muster aus manipuliertem SPF, neuem MTA-Host und wiederkehrender Server-Infrastruktur machte eine zusammenhängende Kampagne erkennbar

Besonders aussagekräftig war nicht ein einzelner DNS-Eintrag, sondern die Kombination mehrerer Merkmale. Ein Hostname wie mta.example.tld ist für sich genommen völlig legitim. Auch ein einzelner ip4:-Mechanismus in einem SPF-Record ist nichts Ungewöhnliches. Wenn jedoch bei mehreren Domains gleichzeitig neue MTA-Hosts auf externe Adressen zeigen und exakt diese Adressen neu im SPF autorisiert werden, während von dort Phishing-Nachrichten in Spamtraps eintreffen, entsteht ein belastbares technisches Gesamtbild.

Ein weiteres gemeinsames Merkmal: Hetzner-Infrastruktur

Bei der Analyse zeigte sich eine weitere Übereinstimmung zwischen den untersuchten Fällen: Die IP-Adressen, auf die die neu angelegten MTA-Subdomains verwiesen, ließen sich der Infrastruktur von Hetzner zuordnen. Bei einer erneuten Reverse-DNS-Prüfung am 15. September 2026 lieferten alle 18 bis dahin dokumentierten IP-Adressen PTR-Hostnamen nach dem Schema static.[IP in umgekehrter Reihenfolge].clients.your-server.de.

Die Nutzung von Hetzner-Infrastruktur ist für sich genommen selbstverständlich kein Hinweis auf ein Fehlverhalten des Providers. Hosting-Infrastruktur kann von Kunden sowohl für legitime als auch für missbräuchliche Zwecke eingesetzt werden. Im Zusammenhang mit den übrigen übereinstimmenden Merkmalen ist die gemeinsame Infrastruktur jedoch ein zusätzliches technisches Korrelationsmerkmal.

Genau dieser Ansatz ist auch für die Spamabwehr wichtig: Einzelne Merkmale sollten nicht isoliert bewertet werden. Entscheidend ist die Korrelation aus Authentifizierung, DNS, Reputation, Infrastruktur, Verbindungsdaten und beobachtetem Versandverhalten.

Update · 15. September 2026

Dokumentierte Versand-Infrastruktur der Kampagne

Seit Veröffentlichung der ursprünglichen Analyse konnten weitere Fälle demselben technischen Muster zugeordnet werden. Bis zum 15. September 2026 wurden insgesamt 18 IP-Adressen im Zusammenhang mit der beschriebenen Kampagne dokumentiert.

Die wachsende Zahl der Funde unterstreicht die Skalierbarkeit des beobachteten Vorgehens. Die Liste erhebt jedoch keinen Anspruch auf Vollständigkeit: Weitere kompromittierte Domains und zusätzliche Versandserver können existieren. Gerade bei automatisierten oder stark standardisierten Kampagnen kann sich die verwendete Infrastruktur fortlaufend verändern und erweitern.

Die betroffenen Kundendomains und die dort angelegten MTA-Hostnamen werden weiterhin bewusst nicht veröffentlicht. Die folgende Tabelle dokumentiert ausschließlich die beobachteten IP-Adressen und die bei einer erneuten Reverse-DNS-Abfrage am 15. September 2026 ermittelten PTR-Hostnamen.

Historischer Stand: Reverse-DNS-Einträge können nachträglich geändert werden. Die PTR-Werte dokumentieren daher den Zustand zum Zeitpunkt der erneuten Prüfung und sind nicht als dauerhaft unveränderliche Zuordnung zu verstehen.

IP-Adresse PTR / Reverse DNS am 15.09.2026
2.28.5.90 static.90.5.28.2.clients.your-server.de
2.28.5.99 static.99.5.28.2.clients.your-server.de
2.28.8.248 static.248.8.28.2.clients.your-server.de
2.28.15.176 static.176.15.28.2.clients.your-server.de
2.28.37.65 static.65.37.28.2.clients.your-server.de
5.75.222.35 static.35.222.75.5.clients.your-server.de
5.75.245.106 static.106.245.75.5.clients.your-server.de
88.99.80.162 static.162.80.99.88.clients.your-server.de
116.202.182.227 static.227.182.202.116.clients.your-server.de
116.202.188.72 static.72.188.202.116.clients.your-server.de
116.202.189.1 static.1.189.202.116.clients.your-server.de
138.201.247.249 static.249.247.201.138.clients.your-server.de
167.233.226.199 static.199.226.233.167.clients.your-server.de
178.104.188.9 static.9.188.104.178.clients.your-server.de
178.105.13.236 static.236.13.105.178.clients.your-server.de
178.105.22.87 static.87.22.105.178.clients.your-server.de
178.105.198.101 static.101.198.105.178.clients.your-server.de
178.105.241.215 static.215.241.105.178.clients.your-server.de

Für Administratoren können diese IP-Adressen als historische Indicators of Compromise (IoCs) bei der rückwirkenden Prüfung von Mailserver-, Firewall- und DNS-Logs dienen. Besonders relevant ist eine Prüfung, ob eine der Adressen unerwartet in SPF-Einträgen eigener Domains auftaucht oder ob im gleichen Zeitraum unbekannte MTA-Subdomains angelegt wurden.

Eine IP-Adresse sollte jedoch nicht allein aufgrund ihrer Aufnahme in diese historische Liste dauerhaft oder pauschal blockiert werden. Server können bereinigt, neu vergeben oder zu einem späteren Zeitpunkt wieder für legitime Zwecke eingesetzt werden. Für die Bewertung sollte deshalb immer der zeitliche und technische Kontext berücksichtigt werden.

08 · Sofortmaßnahmen

Was tun, wenn ein STRATO-Kundenaccount gehackt oder kompromittiert wurde?

Bei unberechtigten DNS-Änderungen sollte nicht nur der sichtbare Eintrag korrigiert werden. Wenn ein Angreifer Zugriff auf den STRATO-Kundenaccount hatte, muss der gesamte Zugang als kompromittiert behandelt werden. Nur den falschen SPF- oder A-Record zu löschen, reicht nicht aus.

  • Beweise sichern: Vor Änderungen die verdächtigen DNS-Einträge, Zeitpunkte und weitere Auffälligkeiten dokumentieren. Das hilft bei der späteren Ursachenanalyse und bei Meldungen an Provider oder andere Stellen.
  • STRATO-Zugang absichern: Kundenpasswort und relevante Paketpasswörter unverzüglich ändern. Für das neue Passwort sollte ein starkes und ausschließlich für diesen Zugang verwendetes Passwort gewählt werden.
  • Wiederverwendete Passwörter überall ersetzen: Wurde dasselbe oder ein sehr ähnliches Passwort auch bei anderen Diensten verwendet, muss es dort ebenfalls als kompromittiert betrachtet und geändert werden. Das betrifft beispielsweise E-Mail-Konten, CMS-Systeme wie WordPress, Webhosting-Zugänge, soziale Netzwerke, Cloud-Dienste oder andere Kundenportale. Ein Passwortwechsel ausschließlich bei STRATO reicht bei mehrfach verwendeten Zugangsdaten nicht aus.
  • Zwei-Faktor-Authentifizierung aktivieren: Den STRATO Kunden-Login mit 2FA absichern. STRATO stellt dafür eine Zwei-Faktor-Authentifizierung per Authenticator-App bereit.
  • Komplette DNS-Zone prüfen: Nicht nur den bekannten A- und SPF-Eintrag kontrollieren, sondern auch A, AAAA, CNAME, MX, TXT, NS und weitere vorhandene Records auf unbekannte Änderungen untersuchen.
  • Manipulierten SPF bereinigen: Nicht autorisierte ip4:- oder include:-Einträge entfernen und prüfen, ob der verbleibende SPF-Record tatsächlich nur legitime Versandsysteme autorisiert.
  • Unbekannte Subdomains entfernen: Neu angelegte Hosts wie mta, mta2 oder andere nicht benötigte Subdomains löschen, sofern sie nicht zur eigenen Infrastruktur gehören.
  • DKIM und DMARC kontrollieren: Prüfen, ob auch DKIM-Schlüssel, DMARC-Policy oder weitere TXT-Einträge verändert wurden. Selbst wenn dort keine Manipulation sichtbar ist, sollte die gesamte E-Mail-Authentifizierung nach einem DNS-Vorfall verifiziert werden.
  • Weitere Konten und Zugangsdaten überprüfen: Aus einem kompromittierten STRATO-Kundenaccount folgt nicht automatisch, dass Angreifer auch Passwörter anderer Systeme kennen. Solange jedoch nicht geklärt ist, wie der STRATO-Zugang kompromittiert wurde, sollte ein weitergehender Zugriff nicht ausgeschlossen werden. Wurden Zugangsdaten beispielsweise über ein kompromittiertes Endgerät, Schadsoftware, den Browser oder einen Passwortspeicher abgegriffen, könnten auch Zugangsdaten zu weiteren Diensten betroffen sein.
  • E-Mail-, Web- und CMS-Zugänge kontrollieren: Insbesondere administrative WordPress- oder andere CMS-Konten, E-Mail-Postfächer, FTP/SFTP-Zugänge, Datenbanken, Hosting-Zugänge und weitere privilegierte Konten sollten auf unbekannte Anmeldungen, Änderungen oder neu angelegte Benutzer geprüft werden.
  • Endgeräte untersuchen: Wenn die Ursache des Account-Zugriffs unbekannt ist, sollten auch die Computer und mobilen Geräte geprüft werden, von denen aus normalerweise auf STRATO oder andere administrative Systeme zugegriffen wird. Erst wenn die Ursache der Kompromittierung geklärt oder ausreichend eingegrenzt wurde, lässt sich beurteilen, ob nur der STRATO-Zugang oder möglicherweise weitere Zugangsdaten betroffen waren.
  • Reputation beobachten: Prüfen, ob Domain oder legitime Mailserver infolge des Missbrauchs auf Blocklisten gelandet sind oder Zustellprobleme auftreten. Nach der Bereinigung kann gegebenenfalls eine gezielte Entlistung erforderlich sein.

STRATO beschreibt sowohl die Änderung von Kunden- und Paketpasswörtern als auch die Einrichtung der Zwei-Faktor-Authentifizierung in der eigenen Hilfe.

09 · Prävention

DNS ist ein sicherheitskritischer Teil der Mail-Infrastruktur

Domains werden häufig vor allem als Webadresse wahrgenommen. Tatsächlich entscheidet ihre DNS-Zone aber auch darüber, wohin E-Mails zugestellt werden, welche Server im Namen der Domain senden dürfen und welche Authentifizierungsregeln für den Mailverkehr gelten. Ein kompromittierter DNS-Zugang ist deshalb ein direkter Angriff auf die Vertrauensbasis der Domain.

Besonders wichtig ist ein mehrstufiger Schutz: starke und einzigartige Passwörter, Zwei-Faktor-Authentifizierung, eine möglichst kleine Zahl administrativer Zugänge und eine regelmäßige Kontrolle sicherheitsrelevanter DNS-Einträge. SPF, DKIM und DMARC sollten dokumentiert sein, damit unautorisierte Änderungen schneller auffallen.

Auch auf Empfängerseite zeigt dieser Vorfall, warum eine einzelne bestandene Authentifizierungsprüfung niemals als alleiniger Vertrauensbeweis genügen sollte. Wenn ein Angreifer die DNS-Konfiguration einer Domain kontrolliert, kann er technische Signale verändern, die normalerweise Vertrauen schaffen sollen. Gute Spam- und Phishing-Abwehr kombiniert deshalb mehrere voneinander unabhängige Ebenen.

Einordnung

Was dieser Vorfall über Phishing-Abwehr zeigt

Die beobachtete Kampagne ist ein gutes Beispiel dafür, dass moderner Phishing-Versand nicht immer mit offensichtlich gefälschten Absendern arbeitet. Wird ein echter Domainaccount kompromittiert und anschließend die DNS-Zone verändert, können Angreifer einen Teil der technischen Vertrauensmerkmale selbst beeinflussen.

Für Domaininhaber bedeutet das: DNS-Sicherheit ist E-Mail-Sicherheit. Für Mailprovider bedeutet es: Reputation, Authentifizierung, Infrastruktur, historische Beobachtungen und Inhaltsmerkmale müssen zusammen betrachtet werden. Genau diese Verbindung hat es in diesem Fall ermöglicht, das wiederkehrende technische Muster herauszuarbeiten.

10 · Ausblick

Warum dieses Angriffsmuster künftig noch relevanter werden könnte

Der beobachtete Fall zeigt eine Entwicklung, auf die sich Betreiber von Domains und Mailservern einstellen sollten: Phishing wird nicht nur inhaltlich professioneller, sondern technisch zunehmend leichter skalierbar.

Automatisierung und moderne KI-Werkzeuge können den Aufwand reduzieren, große Mengen variierter Nachrichten zu erzeugen, Informationen über potenzielle Ziele aufzubereiten und wiederkehrende Arbeitsschritte einer Angriffskampagne zu unterstützen. Ob und in welchem Umfang solche Werkzeuge bei der hier dokumentierten Kampagne tatsächlich eingesetzt wurden, ist nicht bekannt.

Für die Abwehr bedeutet das: Die Bewertung einer einzelnen Nachricht reicht immer weniger aus. Wichtiger wird die Korrelation vieler technischer Signale – beispielsweise neu auftauchender MTA-Hosts, ungewöhnlicher SPF-Änderungen, Versand-IP-Adressen, Reverse DNS, Authentifizierungsergebnisse und zeitlicher Muster.

Genau dort können wiederum Automatisierung und KI auf der Verteidigerseite helfen: Auffälligkeiten über große Mengen technischer Daten hinweg erkennen, Zusammenhänge herstellen und Administratoren frühzeitig auf Muster aufmerksam machen, die bei isolierter Betrachtung unscheinbar wirken.

Fazit

Ein geänderter SPF-Record kann das sichtbare Symptom eines größeren Vorfalls sein

In den untersuchten Fällen hatten Angreifer Zugriff auf STRATO-Kundenaccounts erlangt, zusätzliche Versand-IP-Adressen in SPF-Einträge aufgenommen und passende MTA-Subdomains angelegt. Anschließend wurden die betroffenen Domains für Phishing-Versand missbraucht. Das wiederkehrende Angriffsmuster konnte durch die Korrelation technischer Mailserver- und DNS-Daten nachvollzogen werden.

Wer eine unbekannte Versand-IP im SPF, eine unerwartete MTA-Subdomain oder andere nicht erklärbare DNS-Änderungen entdeckt, sollte deshalb nicht nur den einzelnen Record korrigieren, sondern von einer möglichen Account-Kompromittierung ausgehen und den gesamten Zugang überprüfen.

Besonders wichtig ist dabei die Ursachenanalyse: Ist nicht geklärt, wie der Zugriff auf den Hosting-Account möglich wurde, darf die Bereinigung nicht bei DNS und STRATO enden. Wiederverwendete Passwörter und möglicherweise ebenfalls betroffene administrative Zugänge müssen in die Untersuchung einbezogen werden.

Sie haben verdächtige DNS-Änderungen, ungewöhnlichen Mailversand oder Hinweise auf einen kompromittierten Hosting-Account entdeckt? FD-IX unterstützt bei der technischen Einordnung, Analyse der Mail- und DNS-Spuren und bei den nächsten Schritten zur Absicherung.

Cybersecurity-Vorfall mit FD-IX prüfen