Gestern Nacht wurde mein Newsletter angegriffen. Mein Newsletter! 🤦 Und zwar nicht, um Spam zu verbreiten oder meine Webseite für illegale Zwecke zu missbrauchen, sondern ganz offensichtlich mit dem Ziel, mir zu schaden. Aber fangen wir von vorn an - Schritt für Schritt, auch für Nicht-Techniker verständlich. Bleib dran, es wird spannend!

Wie sah die Attacke aus?

Die erste verdächtige Aktivität begann am 07.04.2025 um 03:57 Uhr - eine Anmeldung zu meinem Newsletter. Die Double-Opt-In-Mail, die zur Verifizierung und Einholung der Einwilligung gemäß DSGVO und anderen Regulatorien erforderlich ist, wurde ganz normal verschickt. Der Bot, der sich anmeldete, gab sich als iPhone-Nutzer mit Safari aus. Solche Angaben lassen sich technisch leicht fälschen. Selbst gutartige Bots wie der Google-Crawler, der Webseiten für die Google-Suche aufbereitet, tarnen sich manchmal oder „lügen“, um zu erkennen, ob Webseitenbetreiber versuchen, das Ranking zu manipulieren.

Was ein verlässlicheres Indiz liefert, ist die IP-Adresse - sie ist quasi die „Postadresse“ im Internet und einem Internet-Teilnehmer zugeordnet. Ich bin sogar verpflichtet, diese zu speichern, um im Zweifel belegen zu können, wer sich angemeldet hat. Das Problem: Der Teilnehmer muss nicht gleichzeitig der Angreifer sein. Man wäre ganz schön dumm, jemanden vom eigenen Rechner oder einem selbst gemieteten Server aus anzugreifen - dann könnte man den Angreifer ja identifizieren. Außer natürlich, er sitzt irgendwo tief im Ausland - dann ist es ihm vermutlich egal. Etwas professionellere Angreifer nutzen hingegen geklaute Kreditkarten, fremde Webseiten und Geräte. Fremde Webseiten können zum Beispiel WordPress-basierte Seiten sein, die durch Sicherheitslücken dazu gebracht werden, andere Webseiten oder Dienste anzugreifen. Bei Geräten kann es sich um nahezu alles handeln, was mit dem Internet verbunden ist: eine smarte Zahnbürste, die Auswertungen in einer App bereitstellt, ein Auto oder ein autonomer Staubsauger.

Die E-Mail-Adresse, die der Angreifer verwendet hat, gehört zu einem Dienst für sogenannte „Wegwerf-E-Mail-Adressen“. Diese Dienste werden oft genutzt, wenn man irgendwo eine E-Mail-Adresse angeben muss, dies aber eigentlich nicht möchte. Dann lässt man sich eine temporäre Wegwerf-Adresse generieren und nutzt sie kurzzeitig. Vielleicht wollte der Angreifer nur mein druckbares Plakat zum Thema Geldverbrennung durch Produktfeatures haben, ohne sich für den Newsletter anzumelden. Das würde ich natürlich respektieren und hätte damit kein Problem. (Außerdem versende ich keinen Spam, verkaufe keine E-Mail-Adressen, und man kann sich jederzeit wieder abmelden - aber gut.)

Aber das war wohl nicht das Ziel. Die E-Mail wurde zwar empfangen, aber nicht verifiziert. Ich gehe davon aus, dass das ein Test war, ob der erstellte Angriffsbefehl grundsätzlich funktioniert.

Die zweite Angriffswelle

Fast genau 10 Stunden später startete die nächste Welle: Diverse fremde E-Mail-Adressen wurden automatisiert für meinen Newsletter registriert. Offenbar hatte der Angreifer seinen Befehl in der Zwischenzeit verfeinert und automatisiert. Ziel: Die automatischen Angriffserkennungssysteme zu umgehen. Dafür nutzte er drei Server und meldete verschiedene E-Mail-Adressen in zeitlichen Abständen zwischen 10 und 60 Minuten an. Das macht eine automatisierte Erkennung des Angriffs tatsächlich schwieriger. Denn es ist ja durchaus möglich, dass sich beispielsweise mehrere Mitarbeitende eines Unternehmens zeitnah anmelden - und da sie im gleichen Netzwerk sind, nach außen hin die gleiche IP-Adresse verwenden. Diese möchte man natürlich nicht blockieren.

Die nächste Problematik war, dass größtenteils echte E-Mail-Adressen verwendet wurden. Wenn zum Beispiel eine nicht existierende E-Mail-Adresse eingetragen wird, wird sie vom empfangenden Server mit einem sogenannten „Bounce“ abgelehnt - in diesem Fall einem Hard Bounce, da ein erneuter Versand nichts an der Situation ändern würde. Wenn hingegen zum Beispiel das E-Mail-Postfach voll ist, wird die E-Mail mit einem Soft Bounce abgelehnt, da es sein kann, dass der Empfänger sein Postfach aufräumt oder zusätzlichen Speicherplatz erwirbt.

Der erste Bounce ereignete sich dann um 23:09 Uhr. Doch dieser Bounce blieb unentdeckt. Denn es war kein gewöhnlicher Bounce - so etwas hatte ich bisher noch nicht gesehen. Die E-Mail wurde zunächst ganz normal vom Empfänger-Server angenommen... und dann, sieben Sekunden später, mit einem „transienten Bounce“ abgelehnt. Was? So etwas gibt es? Anscheinend behandelt mein Dienstleister, Amazon Web Services, diese Art von Bounce anders! Und deshalb erhielt ich keine Benachrichtigung per E-Mail. So blieb der Angriff unentdeckt, unter dem Radar...

Doch mein System war für alle Typen von Bounces ausgelegt, und so wurde die E-Mail-Adresse im System automatisch gesperrt, sodass keine weiteren E-Mails mehr an sie verschickt wurden.

Angriff, Mail für Mail, Stunde für Stunde

In dieser Zeit lief der Angriff fröhlich weiter. Mail für Mail, Stunde für Stunde. Bis sich am 08.04.2025 um 01:22 Uhr - also fast einen Tag nach Beginn des Angriffs - ein weiterer Bounce ereignete. Auch hier wurde die E-Mail-Adresse sofort gesperrt und eine Benachrichtigung an mich versendet. Doch diese kam nicht an. E-Mail ist eben ein asynchrones Medium. Oft funktioniert alles einwandfrei und man hat das Gefühl, E-Mails würden in Echtzeit zugestellt. Doch manchmal werden sie irgendwo zwischengespeichert oder vom E-Mail-Client nicht zeitnah abgeholt. Ergo: Der Angriff lief ungehindert weiter. Langsam, aber stetig. Auch ein weiterer Bounce um 01:40 Uhr kam zunächst nicht an. Erst kurz vor 2 Uhr trudelten die beiden letzten Bounces bei mir ein - und ich wurde endlich benachrichtigt!

Zuerst habe ich mir nichts dabei gedacht. Bei einem Newsletter ist eine etwas höhere Bounce-Rate durchaus normal - es wird ja oft irgendetwas eingetragen. Aus diesem Grund war Bounce-Handling bereits Bestandteil meines minimalistischen Newsletter-Projekts. Doch ich bin den Hinweisen nachgegangen...

Was habe ich nun vorgefunden?

Zunächst war ich sehr erfreut. Ich dachte: „Mega! Wahrscheinlich wurde mein Newsletter irgendwo empfohlen, und ich habe innerhalb von 24 Stunden ganze 34 neue Anmeldungen!“ Da ich meinen Newsletter zur Entwicklung hochperformanter Unternehmen aktuell ausschließlich organisch bewerbe, wäre das natürlich der Hammer für mich gewesen!

Doch schnell wurde ich skeptisch. Nicht so sehr wegen der drei Bounces, sondern weil lediglich zwei E-Mail-Adressen verifiziert wurden. Das ist eine außergewöhnlich schlechte Konversionsrate. Also habe ich stichprobenartig eine der Anmeldungen überprüft. Und direkt: BÄM - diese kam von cheapy.host, also keinem klassischen Internetprovider für Endkunden, sondern einem Server-Dienstleister! Darauf war ich nicht vorbereitet. Ich hatte mit verschiedenen Szenarien gerechnet, aber dass sich jemand die Mühe macht, automatisiert E-Mail-Adressen für meinen Newsletter einzutragen, ohne selbst direkt davon zu profitieren - nur, um mir zu schaden!?

Worin besteht der Schaden?

Der E-Mail-Versand selbst ist relativ günstig. Solange man keine Millionen E-Mails pro Tag verschickt, ist das finanziell kaum relevant. Und wenn man tatsächlich so viele Mails versendet, muss man ohnehin davon irgendwie profitieren.

Image-Schaden? Wohl kaum. Die Verifizierungs-E-Mails sind professionell und enthalten keine Werbung - das dürfen sie auch nicht. Selbst ein Logo ist nicht enthalten. Das wegzulassen war schmerzhaft für mich, aber notwendig.

Doch der Schaden ist subtiler: Alle E-Mail-Versanddienstleister leben von ihrer Reputation. Es ist eine Menge Arbeit, und wenn man nicht gerade ein Großkonzern ist, sollte man das nicht selbst tun. Ist die Reputation erst einmal beschädigt, werden über den Dienstleister verschickte E-Mails mit höherer Wahrscheinlichkeit als Spam klassifiziert - selbst wenn sie kein Spam sind. Besonders Amazon Web Services ist hier sehr streng: Jeder Bounce fließt in die Bewertung ein. Werden es zu viele, wird der Account gesperrt. Punkt.

Für mich besonders bitter: Bei einem Newsletter gibt es kaum eine Möglichkeit zum Ausgleich. In normalen Anwendungen beginnt man mit einer Registrierung, bei der eine gewisse Bounce-Rate normal ist. Danach werden aber nur noch E-Mails an verifizierte Adressen verschickt - mit nahezu null Bounces. Das gleicht sich aus. Beim Newsletter hingegen verschicke ich nach der Verifizierung zwar weitere Inhalte, aber bei weitem nicht in dem Umfang, der zur Kompensation ausreichen würde.

Aktueller Wert:

0,03% Bounce-Rate. Bei weitem kein Drama, aber als ehrlicher Anbieter möchte man so etwas trotzdem nicht haben.

Ein weiterer Schaden: Menschen, die plötzlich Verifizierungsmails bekommen, die sie nie angefordert haben - in einer Sprache, die sie womöglich nicht verstehen. Das kann zu Beschwerden oder gar rechtlichen Schritten führen. Ich bin zwar vorbereitet, aber man möchte das trotzdem vermeiden.

Zurück zum Angriff!

Es war klar: Ich musste sofort handeln. Am naheliegendsten wäre es gewesen, die IP-Adresse zu sperren. Aber ich hatte bereits den Verdacht, dass eine Sperre der IP-Adresse wenig bringt. Also fragte ich in der Datenbank ab, wie viele Newsletter-Anmeldungen von welcher IP-Adresse ausgingen. Ich lag richtig: Es waren drei IP-Adressen, die demselben Server-Provider zugeordnet waren. Wer eine IP-Adresse verwaltet, lässt sich ermitteln - und damit auch, welche weiteren IPs oder ganze Bereiche dazugehören.

Innerhalb weniger Minuten passte ich meine Newsletter-Software an und sperrte den entsprechenden IP-Bereich. Die neue Version wurde um 02:11 Uhr produktiv geschaltet. Heißt: Analyse, Umsetzung, Inbetriebsetzung - alles innerhalb von ca. 15 Minuten. Für mich ist das ein Maßstab professioneller Softwareentwicklung.

Innerhalb dieser 15 Minuten kam allerdings noch eine Anmeldung durch - die letzte bisher.

Der Druck lässt nach...

Puh, der Druck war raus. Zumindest vorerst. Danach prüfte ich, welche weiteren IP-Bereiche demselben Anbieter zugeordnet waren - auch diese wurden gesperrt. Insgesamt 4.096 IP-Adressen.

Doch die Aufarbeitung ging weiter. Besonders interessierten mich die zwei verifizierten E-Mail-Adressen. In beiden Fällen wurde die Verifizierung nicht durch einen Menschen durchgeführt! Es handelte sich um Systeme, die eingehende E-Mails automatisiert auf Schadsoftware prüfen - und dabei auch Links anklicken, um dahinterliegende Webseiten zu analysieren.

Für Marketing und - wie in meinem Fall - Newsletter ist das natürlich problematisch: Benutzer werden ohne ihr Wissen angemeldet. Viel schlimmer: Durch das automatische Anklicken von Links sehen Spammer, dass die E-Mail-Adresse tatsächlich existiert und verstärken die Spam-Flut. Für das Geschäftsmodell der Anbieter solcher Scanner-Dienste ein Gewinn. Denn wenn der Benutzer deren Service verlässt, bekommt er die ganze Wut der Spammer zu spüren - und kommt zurück. Bitterböse Geschäftsstrategie.

Was können wir aus dem Angriff lernen?

Kein System ist uninteressant.

Ich gehe grundsätzlich davon aus, dass Systeme angegriffen werden. Das sollte jedem CEO, CTO und CIO klar sein. Je größer das System, desto attraktiver ist es, angegriffen zu werden. Werden Kundendaten erbeutet, droht Erpressung oder Verkauf der Daten. Oder eben beides - nach Lösegeld kassieren, versteht sich.

Fast alle Angriffe laufen vollautomatisiert. Niemand sitzt da und klickt sich händisch durch eine Webseite. Das ist einer der Gründe, warum Sicherheitslücken in Standardsoftware wie WordPress oder Drupal so schnell massenhaft ausgenutzt werden. Nur besonders lohnenswerte Ziele werden halbautomatisch oder manuell angegriffen.

Hätte ich erwartet, dass mein Newsletter angegriffen wird? Ja.

Aber dass es dabei gar nicht um Daten, sondern ausschließlich darum ging, mir zu schaden - das war neu.

Kein System ist sicher.

Ich habe inzwischen weitere Maßnahmen umgesetzt. Trotzdem bin ich mir sicher: Einen Profi hält man damit nicht auf. Es ist und bleibt ein Katz-und-Maus-Spiel.

Doch es gibt Maßnahmen, die die Verteidigung in jedem Unternehmen deutlich stärken können:

• Mindset
  Das ist das Wichtigste - und gemeint ist nicht das Mindset der Mitarbeiter, sondern der Geschäftsführung. Nur wenn dort die Überzeugung besteht, dass keine Daten abfließen dürfen, dass DSGVO-Strafen verhindert werden müssen und dass Kunden es wert sind, geschützt zu werden, wird sich wirklich etwas ändern. Meine Kunden wissen, dass ich in puncto Sicherheit keine Kompromisse eingehe. Secure by default ist die Devise.
• Professionalität
  Ein Software-Entwicklungsprojekt muss professionell aufgesetzt werden: Produktmanagement, Prozesse, Prinzipien - und natürlich Technik. Das Produktmanagement muss mit entsprechenden fachlichen Kompetenzen ausgestattet sein. Auch die Entwickler müssen handlungsfähig bleiben und auf Ereignisse schnell reagieren können. Das können Angriffe sein, aber auch Fehler. Ich habe das kleine Newsletter-Projekt professionell aufgesetzt und konnte deshalb auf einen Angriff in Rekordzeit reagieren. In größeren Projekten habe ich Security-Audits begleitet - es hat sich immer gelohnt, wenn man einen guten Partner hat.
• Risikomanagement
  Das Management konzentriert sich oft nur auf Business-Risiken. Cyberangriffe stehen meist weit unten auf der Liste - wenn sie überhaupt auftauchen. Warum? Das liegt oft daran, dass sich das Management das nicht richtig vorstellen kann. Wie gehen Angreifer vor? Was können sie tun? Was ist der Schaden? All das wird in amerikanischen Filmen romantisiert. Im echten Business wird man ständig angegriffen, ständig wird nach Sicherheitslücken gesucht. 24/7. Vollautomatisiert. Und man hat auch ein Stück Vertrauen in die eigenen Mitarbeiter - „die werden schon wissen, was sie tun“. Und die tun üblicherweise das, worauf Wert gelegt wird. Spoiler: Sicherheit ist es oft nicht.
• Vorbereitung
  Ich war in vieler Hinsicht vorbereitet. Nicht auf alles. Doch ich habe investiert, um zu wissen, was in dem System vor sich geht - und dass das System auf bestimmte Vorfälle selbst reagiert. Das ist noch nicht die Nonplusultra-Lösung, doch für einen Newsletter ist das gut genug und hat mir massiv geholfen, den Angriff überhaupt festzustellen und abzuwehren. Wenn man sich nicht vorbereitet, bleiben die Angriffe oft unentdeckt.

Nun, in der nächsten Folge beschäftigen wir uns mit einem essenziell wichtigen Thema: Umsatz steigern und Kosten senken - aus mathematischer Perspektive. Die Auswirkungen können fatal sein. In diesem Sinne: Tue das Richtige richtig gut und nimm noch heute Kontakt mit mir auf! Melde dich auch direkt zu meinen Newsletter zum Thema Entwicklung hochperformanter Organisationen an.