Bösartige MCP-Server und E-Mail-Sicherheit: Die neue Bedrohung für die Lieferkette

Im September 2025 erschütterte eine einzige Zeile versteckten Codes in einer Open-Source-npm-Bibliothek unsere Annahmen hinsichtlich der Sicherheit in der Lieferkette. Damit rückte die böswillige E-Mail-Sicherheit von MCP-Servern als gefährliche neue Bedrohungsklasse in den Fokus.

Das Paket „postmark-mcp“ leitete über eine Woche lang täglich zwischen 3.000 und 15.000 Unternehmens-E-Mails an einen Angreifer weiter. Dabei kam kein spektakulärer Zero-Day-Exploit zum Einsatz, sondern lediglich eine einfache, versteckteBCC-Regel(Blind Carbon Copy), die mit vollständigen Administratorrechten ausgeführt wurde. Die Folgen waren verheerend: Passwörter, interne Rechnungen, Kundendaten und aktive Authentifizierungstoken gelangten in falsche Hände.

Dies ist der erste dokumentierte Fall eines böswilligen Angriffs auf einen MCP-Server in der Praxis. Da autonome KI-Agenten zunehmend in Unternehmenspipelines eingesetzt werden, entstehen dadurch erhebliche Sicherheitslücken. Herkömmliche Schutzmaßnahmen wie SPF, DKIM und DMARC wurden für eine Ära vorhersehbarer, von Menschen gesteuerter E-Mail-Weiterleitung entwickelt. Das Paradigma des Model Context Protocol (MCP) stellt diese Sicherheitslage völlig auf den Kopf und führt eine Ebene innerbetrieblicher Bedrohungen ein, die herkömmliche Perimeterfilter schlichtweg nicht abfangen können.

Was geschah – Der „Postmark-mcp“-Vorfall

Postmark (betrieben von ActiveCampaign) ist ein beliebter Dienst für Transaktions-E-Mails, den Tausende von Unternehmen nutzen, um wichtige automatisierte Benachrichtigungen wie Passwort-Zurücksetzungen und Bestellbestätigungen zu versenden. Um den Boom im Bereich der generativen KI zu unterstützen, wurde auf GitHub ein offizielles Open-Source-Repository eingerichtet, das es Entwicklern ermöglicht, den KI-Assistenten „Claude“ von Anthropic über das Model Context Protocol direkt mit der Infrastruktur von Postmark zu verknüpfen.

Ein böswilliger Akteur erkannte eine einfache Schwachstelle und veröffentlichte ein Paket mit dem Namen „postmark-mcp“, das dem Original zum Verwechseln ähnlich sah. Dabei handelte es sich nicht um einen kleinen Tippfehler, sondern um eine exakte Namensübereinstimmung, die darauf abzielte, Entwickler zu täuschen, die nach einer schnellen „npm install“-Lösung suchten.

Das langfristige Ziel: Vertrauen aufbauen

Der Angreifer verfolgte eine wohlüberlegte Langzeitstrategie. Über fünfzehn aufeinanderfolgende Versionsveröffentlichungen hinweg (von 1.0.0 bis 1.0.15) lief das Paket einwandfrei. Es entsprach dem Code des offiziellen Repositorys, führte API-Aufrufe fehlerfrei aus und löste keinerlei Warnmeldungen aus. Dadurch gelang es ihm, automatisierte Sandbox-Prüfungen zu umgehen und sich das grundlegende Vertrauen der Sicherheitsüberwachungssysteme zu sichern.

Aktivieren der Nutzlast

Am 17. September 2025 wurde mit der Version 1.0.16 erheblicher Schaden angerichtet. Tief im Inneren der Datei „index.js“ fügte der Herausgeber in Zeile 231 eine einzige Codezeile hinzu. Diese Änderung fügte jeder einzelnen E-Mail-Nachricht, die den Server durchlief, eine versteckte BCC-Adresse hinzu und leitete Kopien an eine vom Angreifer kontrollierte Domain [giftshop.club] weiter.

Da sich dieses Modul innerhalb der validierten Anwendungsschicht befand, verfügte es bereits über autorisierten Zugriff auf aktive API-Schlüssel. Der Angriff erforderte keine ausgefallenen Methoden zur Rechteausweitung. Er funktionierte, weil der Code innerhalb einer vertrauenswürdigen Unternehmenspipeline ausgeführt wurde. Der Datenleck dauerte bis zum 25. September 2025 an, als die Risiko-Engine von Koi Security ungewöhnliche Verhaltensmuster aus der Bibliothek meldete.

Die Auswirkungen

Nachträgliche Überprüfungen durch Koi Security und Snyk ergaben, dass das Paket rund 1.643 Downloads verzeichnete, was etwa 1.500 aktiven Installationen pro Woche entsprach, bei denen täglich Daten verloren gingen.

Als der Fehler entdeckt wurde, löschte der Herausgeber das Paket aus npm. Doch hier liegt das eigentliche Problem bei der Bereinigung: Das Entfernen eines Pakets aus einem öffentlichen Repository löscht es nicht aus aktiven Umgebungen. Jeder aktive Cloud-Cluster oder jede Container-Pipeline, auf der Version 1.0.16 lief, gab weiterhin Daten preis, bis die Teams das Problem aufspürten und manuell beseitigten. Postmark gab umgehend eine Erklärung heraus, in der klargestellt wurde, dass das Unternehmen das Paket weder entwickelt noch autorisiert oder gewartet habe. Da es sich hierbei eher um eine Verhaltens-Backdoor als um einen Codefehler handelte, wurde keine offizielle Common Vulnerabilities and Exposures-Kennung vergeben, was eine einzigartige, unbestätigte Spur eines MCP-Server-Supply-Chain-Angriffs hinterlässt.

Sollten Sie vermuten, dass Ihr Team dieses Paket jemals eingesetzt hat, behandeln Sie dies als aktuellen Vorfall: Deinstallieren Sie es unverzüglich aus allen Umgebungen, ändern Sie alle Anmeldedaten und API-Schlüssel, die jemals damit in Berührung gekommen sind, und durchsuchen Sie Ihre E-Mail-Protokolle nach BCC-Verkehr an die markierte Domain. Es lohnt sich auch, den Rest des Kontos des Herausgebers zu überprüfen; derselbe Autor hat etwa 31 weitere Pakete verwaltet, von denen jedes das gleiche Risiko bergen könnte.

Warum sind MCP-Server ein besonders attraktives Ziel für E-Mail-Angriffe?

Das Model Context Protocol (MCP) entwickelt sich rasch zum Standard-Integrationsrahmen für KI in Unternehmen. Gartner prognostiziert, dass bis Ende 2026 75 % der Anbieter von API-Gateways native MCP-Tools integriert haben werden, um die E-Mail-Sicherheit durch agentische KI zu steuern.

Was genau ist eine Model Context Protocol-Integration? Stellen Sie sich einen MCP-Server als eine sichere API-Brücke vor, die einen KI-Assistenten (wie Claude) mit externen Datenspeichern, Entwicklungsumgebungen und Tools von Drittanbietern verbindet. Anstatt ein unübersichtliches Geflecht aus benutzerdefinierten APIs zu verwalten, nutzt ein KI-Agent dieses einheitliche Protokoll, um Datenbanken abzufragen, CRMs zu überprüfen oder E-Mail-Pipelines selbstständig zu koordinieren.

Die grundlegende Schwachstelle: bedingungsloses Vertrauen

Um sinnvoll eingesetzt werden zu können, benötigt ein MCP-Server umfassende, langfristige Zugriffsrechte. Wenn Sie einen KI-Agenten mit einem E-Mail-Gateway verbinden, um die Terminplanung oder den Kundensupport zu automatisieren, gewähren Sie ihm vollständigen Lese- und Schreibzugriff. Er verhält sich wie ein Mitarbeiter mit umfassenden Befugnissen.

Wie Idan Dardikman, CTO von Koi Security, es formulierte, übertragen Unternehmen im Grunde genommen Administratorrechte mit uneingeschränkten Zugriffsrechten an Backend-Tools, die von nicht verifizierten, nicht vertrauenswürdigen externen Entwicklern erstellt wurden.

Im Gegensatz zu herkömmlichen Angriffen auf die Software-Lieferkette (wie SolarWinds), die auf die tiefliegende Infrastruktur abzielen, erfordern Risiken durch MCP-Server von Drittanbietern keinerlei Hacking der Infrastruktur. Angreifer müssen Sie lediglich dazu verleiten, das Modul zu installieren, und der KI-Agent führt es dann selbstständig aus. Da kein Mensch in den Prozess eingebunden ist, um einen automatisierten Arbeitsablauf zu überprüfen, kann eine kompromittierte Bibliothek tagelang sensible Daten abziehen, ohne dass auch nur ein einziger Alarm ausgelöst wird.

Die Lücke bei der E-Mail-Authentifizierung – Was DMARC schützen kann und was nicht

Während Sicherheitsteams sich bemühen, sich gegen diese E-Mail-Bedrohungen durch KI-gestützte Angriffe auf die Lieferkette zu wappnen, gehen viele davon aus, dass Protokolle wie SPF, DKIM und DMARC das Problem lösen werden. Wir müssen uns jedoch genau ansehen, was diese Kontrollmechanismen tatsächlich leisten und wo die Lücken liegen.

Was DMARC, SPF und DKIM verhindern sollen

Die Kernfunktionen von SPF, DKIM und DMARC wurden entwickelt, um Domain-Spoofing zu verhindern und zu verhindern, dass Kriminelle unter Ausnutzung Ihrer Markenidentität E-Mail-Spoofing- oder BEC-Kampagnen durchführen.

• SPF überprüft, ob die IP-Adresse des sendenden Mail-Servers in Ihren DNS-Einträgen autorisiert ist.
• DKIM fügt dem Header eine eindeutige digitale Signatur hinzu, um nachzuweisen, dass eine Nachricht während der Übertragung nicht verändert wurde.
• DMARC verbindet diese Elemente miteinander und legt fest, wie empfangende Server mit Fehlern umgehen sollen.

Beim „Postmark-mcp“-Exploit wurden diese Sicherheitskontrollen nicht umgangen; sie waren schlichtweg irrelevant. Da das schädliche Paket in eine legitime Unternehmensanwendung eingebettet war, nutzte es gültige API-Schlüssel, um Nachrichten über autorisierte Postmark-Server weiterzuleiten. Jede gestohlene E-Mail wies eine einwandfreie DKIM-Signatur auf und bestand die SPF-Prüfungen ohne Probleme. Das hat eine bittere Ironie: Diese gültige DKIM-Signatur half sogar dem eigenen Empfangsserver des Angreifers dabei, die Echtheit der gestohlenen Nachrichten zu bestätigen.

In welchen Fällen die E-Mail-Authentifizierung teilweise hilft

Was E-Mail-Authentifizierung hier leisten kann und was nicht

DMARC, SPF und DKIM wurden zur Bekämpfung von Spoofing entwickelt, nicht zur Verhinderung von Datenabfluss durch Insider

Die Aussagekraft von DMARC-Berichten

Auch wenn eine ausgereifte E-Mail-Authentifizierung die ursprüngliche Code-Einschleusung nicht verhindert, bietet sie doch entscheidende forensische Einblicke. Dies wird durch detaillierte DMARC-Berichte (RUA/RUF) ermöglicht.

Bei korrekter Konfiguration liefern Ihnen diese Datensätze einen detaillierten Überblick über alle IP-Adressen und Versanddienste, die auf Ihrer Domain aktiv sind. Aggregierte (RUA-)Berichte fassen das Versandvolumen nach Quelle zusammen, während forensische (RUF-)Berichte Einzelheiten zu einzelnen Fehlern erfassen. Wenn Ihr SecOps-Team diese Datenströme kontinuierlich überwacht, kann es plötzliche, unerklärliche Spitzen im ausgehenden Transaktionsvolumen erkennen. Die Verfolgung dieser Anomalien fungiert als eine Art Rauchmelder, der darauf hinweist, dass bei einer Integration Daten verloren gehen.

Schaffung eines Sicherheitsnetzes mit strikter Durchsetzung

Die Umstellung Ihrer Domain auf eine strenge DMARC-Richtlinie mit dem Wert „p=reject“ bietet einen wichtigen Schutz vor sekundären Folgen. Dies verhindert zwar nicht, dass ein interner MCP-Server Daten per BCC versendet, schützt jedoch vor Angreifern, die gestohlene Daten für ihre Zwecke missbrauchen. Eine „Reject“-Richtlinie verhindert, dass Angreifer durchgesickerte Rechnungen oder Kundendaten nutzen, um unter Verwendung Ihrer tatsächlichen Domain gezielte Phishing-Kampagnen gegen Ihre Kunden und Partner zu starten.

Die wahre Lücke – Hygiene bei Zugangsdaten und Berechtigungen

Im Kern handelte es sich bei dieser Sicherheitslücke um einen Fehler im Bereich der Identitäts- und Zugriffsverwaltung und nicht um ein Problem mit dem Authentifizierungsprotokoll. Der Angriff war erfolgreich, weil eine nicht verifizierte Software Zugriff auf einen legitimen API-Schlüssel mit weitreichenden Berechtigungen hatte.

Ihre wichtigste Verteidigungsmaßnahme sind hier die Überprüfung von Code-Abhängigkeiten und die ordnungsgemäße Verwaltung von Anmeldedaten. Der Einsatz autonomer KI-Tools ohne eine aktive Überwachungsebene lässt Sie jedoch völlig im Dunkeln tappen. Eine kontinuierliche DMARC-Überwachung schafft das aktive Sicherheitsnetz, das erforderlich ist, um Verhaltensanomalien zu erkennen, die auf einen aktiven Angriff hindeuten.

So schützen Sie Ihr Unternehmen vor böswilligen MCP-E-Mail-Angriffen

Die Absicherung des MCP-Servers vor böswilligen E-Mails erfordert operative Maßnahmen wie die folgenden:

1. Überprüfen Sie die Serverpräsenz Ihres MCP

Was Sie nicht im Blick haben, können Sie auch nicht sichern. Erstellen Sie eine detaillierte Bestandsliste aller aktiven Integrationen, Plug-ins oder Verbindungspunkte, die mit Ihrer E-Mail-Konfiguration verknüpft sind.

• Überprüfen Sie, ob die Integration aus einem offiziellen Anbieter-Repository stammt oder aus einem nicht verifizierten Community-Paket auf npm oder PyPI.
• Protokollieren Sie ausdrücklich, auf welche Daten und Endpunkte jede Integration zugreifen kann.
• Verwenden Sie Open-Source-Sicherheitstools wie mcp-scan, um Ihre Umgebung zu erfassen und auf Verhaltensabweichungen zu analysieren.

2. Wenden Sie das Prinzip der geringstmöglichen Berechtigungen auf KI-E-Mail-Integrationen an

Verleihen Sie automatisierten Tools keinen uneingeschränkten Administratorzugriff mehr.

• Schränken Sie die API-Schlüssel so ein, dass sie nur genau die erforderlichen Aktionen zulassen (z. B. das Senden von Benachrichtigungen), während der vollständige Lese- und Schreibzugriff auf das Postfach ausdrücklich gesperrt wird.
• Halten Sie strenge Zeitpläne für die Rotation von API-Schlüsseln ein und widerrufen Sie Zugangsdaten sofort, sobald eine Abhängigkeit eine Warnung auslöst.
• Verwenden Sie Firewall- und Netzwerksicherheitsrichtlinien, um ausgehende Verbindungen von MCP-Servern einzuschränken, und lassen Sie nur bekannte E-Mail-API-Endpunkte des Unternehmens auf der Whitelist zu.

3. DMARC-Berichterstellung aktivieren und auf Anomalien überwachen

Wenn Sie aggregierte DMARC-Daten nicht aktiv auswerten, haben Sie eine erhebliche Lücke in Ihrer Betriebsüberwachung. Die Einrichtung eines speziellen DMARC-Analyzers verschafft Ihrem Team kontinuierliche Transparenz, sodass Sie Datenströme verfolgen, Volumen-Baselines ermitteln und bei plötzlichen Spitzen im ausgehenden Transaktionsverkehr benachrichtigt werden können, bevor schwerwiegende Schäden entstehen.

4. DMARC mit p=reject durchsetzen

Wenn Sie Ihre Domain in einer schwachen „p=none“-Konfiguration belassen, bietet dies keinen wirklichen Schutz. Durch die Umstellung auf eine strenge „p=reject“-Sicherheitsstufe wird sichergestellt, dass ein Angreifer, selbst wenn es ihm gelingt, E-Mail-Inhalte über eine kompromittierte Schnittstelle abzugreifen, diese gestohlenen Informationen niemals dazu nutzen kann, gefälschte Kampagnen zu starten, die Ihre offizielle Markendomain imitieren.

5. MCP-Server vor der Bereitstellung überprüfen

Behandeln Sie jedes MCP-Servermodul mit genau derselben Sorgfalt wie jeden anderen privilegierten Bestandteil der Unternehmensinfrastruktur. Überprüfen Sie die Historie des Herausgebers, vergleichen Sie die Pakete mit den offiziellen Herstellerunterlagen und prüfen Sie den zugrunde liegenden Quellcode, bevor Sie das Modul in die Produktion übernehmen.

Um Risiken zu minimieren, sollten Sie unverifizierte Community-Pakete meiden und sich an zertifizierte, vom Anbieter geprüfte Integrationen halten. Für Teams, die Automatisierungslösungen einsetzen, gewährleistet die Prüfung verifizierter Anbieteroptionen wie des PowerDMARC MCP Servers eine sichere, authentifizierte Integrationsschicht, die speziell für den sicheren Unternehmensbetrieb entwickelt wurde.

Das große Ganze – MCP-Sicherheit wird die nächste Phase der E-Mail-Bedrohungen bestimmen

Der Angriff auf die Postmark-MCP-Bibliothek war bewusst einfach gehalten: ein Entwickler, ein einfacher Trick zum Abgleichen von Namen und eine einzige Zeile versteckten Codes. Dennoch führte er zu einer weitreichenden Datenpanne. Da Unternehmen zunehmend autonome KI-Tools einsetzen und MCP in Softwarearchitekturen zum Standard wird, werden Cyberkriminelle unweigerlich weitaus ausgefeiltere Angriffe starten.

Sicherheitsteams müssen sich auf verschiedene neue Bedrohungsvektoren vorbereiten:

• Indirekte Eingabe von Befehlen: Angreifer versenden bösartige E-Mails, die darauf abzielen, einen KI-Agenten zu manipulieren, der den Posteingang überwacht, und ihn dazu zu verleiten, sensible Daten fehlzuleiten oder interne Schlüssel preiszugeben.
• Bösartige Workflow-Tools: Angreifer veröffentlichen scheinbar nützliche KI-Produktivitäts-Tools, die im Hintergrund heimlich Zugangsdaten und Tokens sammeln.
• Hochwertige Lookalikes: Raffinierte Typosquatting-Kampagnen, die auf CRM-, HR- und Finanzintegrationen in Unternehmen abzielen und über Netzwerke für Entwicklerpakete verbreitet werden.

E-Mails sind besonders anfällig, da sie an der Schnittstelle zwischen Unternehmenskommunikation, Identitätsprüfung (Passwortzurücksetzungen) und kritischen Geschäftsdaten stehen. MCP-Server, die KI mit dieser Infrastruktur verbinden, haben Zugriff auf alle drei Bereiche.

Schlussfolgerung

Die Bedrohungslage im E-Mail-Bereich hat sich weit über einfaches externes Phishing hinaus entwickelt. Der Postmark-MCP-Vorfall zeigt, dass Unternehmen mittlerweile mit KI-gestützten Bedrohungen in der Lieferkette konfrontiert sind, die unbemerkt in vertrauenswürdigen internen Umgebungen operieren. Diese Integrationsangriffe nutzen gültige Anmeldedaten, um herkömmliche Filter zu umgehen – genau aus diesem Grund muss die E-Mail-Sicherheit in Bezug auf bösartige MCP-Server nun auf der Agenda jedes CISO stehen.

Um Ihr Unternehmen zu schützen, müssen Sie strenge Zugriffskontrollen mit einer kontinuierlichen Datenüberwachung in Einklang bringen. Durch die Kombination strenger Durchsetzungsrichtlinien mit detaillierten Berichten können Sie ungewöhnliche Versandvolumina aufdecken und unzulässige Integrationen erkennen, bevor Daten unwiederbringlich verloren gehen.

Lassen Sie Ihre automatisierten Systeme nicht unbeaufsichtigt. Schützen Sie Ihre Domain noch heute vor versteckten Bedrohungen auf Anwendungsebene. Erhalten Sie einen Überblick über alle Absender, die E-Mails im Namen Ihrer Domain versenden, und starten Sie die Überwachung mit dem DMARC Analyzer von PowerDMARC.

Häufig gestellte Fragen

Moment mal, wenn meine E-Mails die SPF- und DKIM-Prüfung bestehen, wie kann es sich dann um einen Exploit handeln?

Denn der Aufruf kommt aus dem Inneren des Hauses. Das bösartige Paket fälscht Ihre Domain nicht von einem beliebigen betrügerischen Server aus. Es befindet sich direkt in Ihrer vertrauenswürdigen Anwendungsumgebung und missbraucht Ihre echten, legitimen API-Schlüssel. Für den Rest der Welt hat Ihr Server diese E-Mail rechtmäßig versendet, weshalb kryptografische Perimeter-Protokolle ihr grünes Licht geben. Es handelt sich um ein Problem der Datenexfiltration, nicht um ein Problem der Server-Fälschung.

Wenn DMARC das Durchsickern von Daten nicht verhindern kann, warum sollte ich es dann aktivieren?

Stellen Sie sich die aggregierten DMARC-Berichte von RUA als den Rauchmelder Ihres Netzwerks vor. Wenn ein MCP-Server unbemerkt beginnt, Tausende von operativen E-Mails per BCC an einen Posteingang eines Drittanbieters zu senden, wird Ihr Transaktions-E-Mail-Aufkommen dramatisch ansteigen. Wenn Sie Ihre DMARC-Datenfeeds aktiv überwachen, fällt diese plötzliche Volumenveränderung sofort ins Auge und gibt Ihrem SecOps-Team eine frühzeitige Warnung, um aktive Code-Abhängigkeiten zu überprüfen.

Unser Team benötigt KI-Tools zur Bearbeitung von Support-E-Mails. Wie können wir dies sicher bewerkstelligen, ohne die Integrationen komplett zu deaktivieren?

Sie müssen die KI-Automatisierung nicht blockieren, sondern lediglich Grenzen setzen. Behandeln Sie MCP-Server zunächst wie Infrastrukturkomponenten mit hohem Risiko: Installieren Sie niemals unüberprüfte Community-Skripte ohne vorherige Codeüberprüfung. Legen Sie zweitens den Umfang Ihrer API-Schlüssel mit äußerst spezifischen, detaillierten Berechtigungen fest; wenn ein Agent lediglich Support-Antworten versenden muss, sperren Sie dessen API-Token so, dass es physisch unmöglich ist, Massenabfragen von Daten, die Erstellung von Konten oder BCC-Regeln auszuführen. Halten Sie sich schließlich an verifizierte Anbieterintegrationen wie den PowerDMARC MCP Server, anstatt auf unverifizierte Community-Klone zurückzugreifen.

Wie kann ich überprüfen, ob mein Entwicklerteam versehentlich einen bösartigen MCP-Server installiert hat?

Der erste Schritt besteht darin, einen SCA-Scan (Software Composition Analysis) durchzuführen oder Open-Source-Tools wie mcp-scan zu nutzen, um Ihre aktive Umgebung zu erfassen. Durchsuchen Sie öffentliche Paketregister wie npm und PyPI sorgfältig nach nicht verifizierten Community-Bibliotheken von Drittanbietern, die Ihre Kommunikationspipelines verarbeiten. Wenn eine Bibliothek nicht direkt von einem verifizierten Unternehmensanbieter veröffentlicht und signiert wurde – wie das offizielle Postmark-Repository oder der sichere PowerDMARC MCP Server –, betrachten Sie sie als Risiko, bis der Code manuell geprüft wurde.

• Über
• Neueste Beiträge

Milena Baghdasaryan

Inhaltsspezialist bei PowerDMARC

Milena ist eine erfahrene Autorin und Inhaltserstellerin mit mehr als 7 Jahren Erfahrung in der Erstellung ansprechender Inhalte über IT, Cybersicherheit, virtuelle Veranstaltungen und mehr. Sie hat eine nachgewiesene Erfolgsbilanz bei der Erstellung hochwertiger Arbeiten für internationale Magazine und ist Absolventin renommierter Institutionen wie der New York University Abu Dhabi, UWC China und dem College of Europe.

Neueste Beiträge von Milena Baghdasaryan (alle anzeigen)

• Bösartige MCP-Server und E-Mail-Sicherheit: Die neue Bedrohung für die Lieferkette – 9. Juni 2026
• So richten Sie die E-Mail-Authentifizierung für eine neu registrierte Domain ein – 2. Juni 2026
• Was ist ein Phishing-Link? – 19. Mai 2026