Einen Phishing-Angriff melden: von der Meldung zur Abschaltung

Den Hoster oder Registrar einer Phishing-Seite zu finden (siehe wer wirklich handeln kann und wie man dessen abuse@-Adresse findet) ist nur der halbe Weg. Man muss auch eine Meldung schreiben, die jemand in wenigen Minuten bearbeiten kann, verstehen, was nach dem Absenden passiert, und die Sache verfolgen, bis die Seite wirklich verschwindet. Dieser Ratgeber behandelt alle drei Punkte: richtig melden, wissen, was zu erwarten ist, und bis zur Abschaltung dranbleiben.

Anatomie einer verwertbaren Meldung

Eine Missbrauchsmeldung wird von einer Person bearbeitet, oft mit Dutzenden anderen am selben Tag. Je mehr sofort überprüfbare Angaben sie enthält, desto schneller steigt sie an die Spitze des Stapels. Sieben Angaben tauchen fast immer auf:

• Die genaue URL der Phishing-Seite, nicht nur der Domainname: unter derselben Adresse können Dutzende verschiedener Seiten liegen.
• Die betroffene Domain, für den Registrar.
• Die IP-Adresse des Servers, für den Hoster (siehe wie man sie bis zur abuse@-Adresse zurückverfolgt).
• Die vollständigen Kopfzeilen, falls der Weg eine E-Mail war: dort liegt die echte Spur, nicht im angezeigten Absender.
• Datum und Uhrzeit der Feststellung, in UTC oder mit angegebener Zeitzone, um jede Mehrdeutigkeit für jemanden zu vermeiden, der die Meldung aus einem anderen Land erhält.
• Einen Screenshot der Seite, nützlich falls sie verschwindet, bevor jemand sie überprüfen kann.
• Eine sachliche Beschreibung des Angriffs: was nachgeahmt wird, was vom Opfer verlangt wird (Zugangsdaten, Kartendaten…), ohne Vermutungen oder Vorwürfe.

Die häufigste Falle ist die zu vage Meldung: „diese Seite ist Phishing, bitte handeln“. Ohne genaue URL oder Zeitstempel muss die empfangende Person zunächst Informationen zusammensuchen, die der Melder bereits vor Augen hatte, was alles verzögert, oder die Meldung wird ohne weitere Bearbeitung abgelegt, wenn sie als zu ungenau zur Überprüfung gilt.

Genau das bereitet Baitback vor: ausgehend von einer E-Mail oder einem Link sammelt das Tool diese sieben Angaben automatisch und verfasst die versandfertige Nachricht, adressiert an den richtigen Empfänger.

Was passiert nach dem Absenden einer abuse@-Meldung?

Eine gut aufgebaute Meldung verschwindet selten im Nichts. Bei den meisten Hostern durchläuft sie einen recht ähnlichen Weg, auch wenn er nicht immer gleich endet.

Ein Hoster schaltet fast nie einen Server allein aufgrund der Meldung ab: er prüft zunächst die Beweise, identifiziert dann, welcher seiner Kunden betroffen ist (der Hoster vermietet die Maschine an einen Dritten; er ist fast nie selbst der Urheber der Seite). An diesen Kunden richtet sich zuerst die Aufforderung zur Entfernung oder Sperrung, mit einer Antwortfrist. Antwortet der Kunde nicht oder kooperiert er nicht, kann der Hoster selbst abschalten, gemäß seinen eigenen Nutzungsbedingungen.

Fehlalarme gibt es: eine fälschlich eingestufte legitime Seite, eine Testseite, ein Sicherheitswerkzeug, das für eine Bedrohung gehalten wird. Deshalb erfolgt die Prüfung vor jeder Maßnahme, und deshalb wird eine Meldung mit soliden Beweisen (Abbildung 1) schneller bearbeitet als ein bloßer Verdacht.

Manche Meldungen dauern länger als andere: ein Hoster, der eigentlich nur ein Reseller ist, muss die Anfrage an den tatsächlichen Betreiber weiterleiten; ein Ticket, das freitagabends eröffnet wird, wartet auf den nächsten Werktag; ein Hoster in einer entfernten Zeitzone antwortet mit entsprechender Verzögerung. Nichts davon bedeutet, dass die Meldung verloren gegangen ist: man prüft die URL erneut nach einigen Tagen und hakt höflich nach, falls das Ticket über die angekündigte Frist hinaus unbeantwortet bleibt.

Von der Meldung zur Abschaltung: eine Infrastruktur über die Zeit verfolgen

Eine einzelne Meldung ist manchmal nur ein Schritt. Eine Phishing-Infrastruktur kann eine erste Abschaltung überleben, indem sie umzieht: neue IP-Adresse, neue Domain, neuer Hoster. Die Arbeit endet also nicht mit dem Absenden.

Die Methode bleibt bei jedem Schritt gleich: die Domain identifizieren, die IP-Adresse des Servers identifizieren, den Betreiber identifizieren, der ihn verwaltet (siehe wer zwischen Registrar, Hoster und CDN was kontrolliert und die Kette IP → WHOIS/RDAP → ASN → abuse@), und dann jeden über das melden, was ihn betrifft.

Was tun, wenn die Seite aktiv bleibt?

Eine Frist von einigen Tagen ohne Veränderung bedeutet nicht, dass die Meldung gescheitert ist: man hakt beim bestehenden Ticket unter Angabe seiner Referenz nach, statt ein neues zu eröffnen. Hält das Schweigen über eine angemessene Frist hinaus an, bleibt eine offizielle Plattform (in Deutschland zum Beispiel das BSI; jedes Land hat seine eigene) oder ein nationales CERT eine ergänzende Möglichkeit.

Was tun, wenn die Domain die IP-Adresse wechselt?

Eine Domain, die plötzlich auf eine neue IP verweist, hat wahrscheinlich den Hoster gewechselt, absichtlich (um einer Meldung zu entgehen) oder nicht. Die Identifikationskette muss für diese neue IP komplett neu durchlaufen werden: neues WHOIS, neuer Betreiber, neue abuse@-Adresse. Die Domain selbst bleibt oft das stabilere Ziel: eine Meldung an den Registrar behält ihren Wert, auch wenn der Server umgezogen ist.

Was tun, wenn eine neue Domain auftaucht?

Aktive Kampagnen nutzen oft dieselbe Seitenvorlage wieder, manchmal denselben Hoster, unter einem neuen Domainnamen. Eine Familienähnlichkeit zu erkennen (gleiches Layout, gleicher Server, gleiche URL-Struktur) erlaubt es, das Weitere vorherzusehen, statt bei jeder neuen Variante wieder bei null anzufangen.

Baitback übernimmt jeden dieser Schritte: es bereitet eine vollständige, verwertbare Meldung vor, adressiert an den richtigen Akteur, sodass nur noch das Absenden übrig bleibt.

Um mehr zu erfahren: Registrar, Hoster, CDN: wer wirklich handeln kann, die abuse@-Adresse eines Hosters finden, oder Phishing von der Nachricht bis zur Infrastruktur analysieren.