Mit der Domain beginnen, nicht mit der Seite

Phishing-Infrastruktur umfasst in der Regel mehrere Schichten: die Domain im Link, den Server, der die Seite hostet, das Mailsystem, das die Köder-Mail zugestellt hat, und manchmal eine zweite Domain, die nur zur Erfassung von Zugangsdaten verwendet wird. Bevor der Seiteninhalt geprüft wird, sollten die registrierbare Domain, ihr RDAP-Registrierungsdatensatz, DNS-Antworten und alle damit verbundenen Zertifikate gesammelt werden. Dies schafft einen stabilen Referenzrahmen, der nicht davon abhängt, dass die Seite noch online ist.

Erfassung des Erstellungsdatums, des Registrars, der Nameserver und des aktuellen Status aus RDAP. Eine Domain, die wenige Tage vor Beginn einer Kampagne registriert wurde, einen Datenschutzdienst nutzt und auf Nameserver verweist, die nicht mit einer legitimen Marke in Verbindung stehen, ist ein häufiges, aber nicht universelles Muster. Behandeln Sie jeden dieser Punkte als einen Datenpunkt und nicht als schlüssigen Beweis.

Hosting- und Netzwerkkontext

Lösen Sie den Hostnamen in seine A/AAAA-Einträge auf und ermitteln Sie den Netzwerkinhaber für jede IP über das relevante Regionale Internet Register (RIR) mittels RDAP. Phishing-Kits werden häufig auf kompromittierten legitimen Servern, billigem Massenhosting oder hinter einem Content Delivery Network gehostet, das den Ursprung verschleiert. Die Identifizierung des tatsächlichen Netzwerkinhabers zeigt Ihnen, welches "Abuse Desk" die Seite realistischerweise offline nehmen kann.

Befindet sich die Website hinter einem CDN oder Reverse-Proxy, gehört die sichtbare IP zu diesem Anbieter, nicht zum Betreiber. Dies ist explizit im Bericht zu vermerken, anstatt das CDN als den für den Inhalt verantwortlichen Host zu benennen.

Zertifikate und zugehörige Hostnamen

Certificate Transparency Logs, die über Dienste wie crt.sh durchsucht werden können, zeichnen jedes öffentlich vertrauenswürdige Zertifikat auf, das für einen Namen ausgestellt wurde. Die Suche nach der Apex-Domain und gängigen Präfixen kann verwandte Hostnamen wie Login-, Secure-, Mail- oder Pay-Subdomains aufdecken, die für dieselbe Kampagne vorbereitet wurden, aber noch nicht auf andere Weise verknüpft wurden. Das Protokoll zeigt auch das früheste Ausstellungsdatum, das die Registrierungszeittafel bestätigen oder widerlegen kann.

Mehrere, scheinbar unabhängige Domains, die dasselbe Zertifikatsausstellungsmuster, denselben Registrar und denselben Registrierungstag teilen, sind ein nützlicher Anhaltspunkt zur Identifizierung einer umfassenderen Kampagne, aber eine gemeinsame Infrastruktur allein begründet keine gemeinsame Eigentümerschaft.

Nachweis der E-Mail-Zustellung

Wenn die Phishing-Masche per E-Mail ankam, liefern die Nachrichtenheader und die MX-, SPF- und DMARC-Konfiguration der Domain eine separate Beweislinie. Eine Domain mit konfigurierten MX-Einträgen und einer permissiven oder fehlenden SPF/DMARC-Richtlinie ist bereit, E-Mails zu senden und zu empfangen, was relevant ist, wenn die Kampagne Social Engineering auf Antwortbasis beinhaltet und nicht nur einen Link.

Bewahren Sie die Original-E-Mail-Datei intakt auf. Authentifizierungsergebnisse sollten von Ihrer eigenen vertrauenswürdigen Empfangsinfrastruktur abgelesen und nicht nachträglich neu berechnet werden, da sich DNS-Einträge nach dem Vorfall ändern können.

Zusammenstellung des Berichts

Ein nützlicher Phishing-Infrastrukturbericht trennt das Beobachtete (DNS-Antworten, RDAP-Felder, Zertifikatseinträge, E-Mail-Header) von dem, was abgeleitet wird (wahrscheinliche Kampagnenbeziehungen, wahrscheinliche Absicht). Jede Beobachtung sollte ihre Quelle und einen UTC-Zeitstempel enthalten. Versiegeln Sie die gesammelten Beweise mit einem kryptografischen Hash, damit deren Unversehrtheit später nachgewiesen werden kann, und reichen Sie dann präzise, beweisgestützte Missbrauchsmeldungen beim Registrar, Host und jedem beteiligten CDN ein.

  • Registrierbare Domain, RDAP-Erstellungsdatum, Registrar und Status.
  • DNS: A/AAAA, NS, MX, TXT, SOA mit Erfassungszeitstempeln.
  • IP-Netzwerkinhaber für jede aufgelöste Adresse, unter Hinweis auf die CDN-Nutzung.
  • Certificate Transparency Suche für die Domain und gängige Subdomains.
  • SPF/DMARC-Haltung und, falls zutreffend, die archivierte Original-E-Mail.
  • Versiegelter, gehashter Bericht vor dem Einreichen von Missbrauchsmeldungen.

Quellen und weiterführende Literatur

CISA, Phishing erkennen und meldencrt.sh, Transparenzsuche für ZertifikateICANN, Missbrauchskontakte der RegistrareM3AAWG, Best Practices gegen Phishing
Diese Ressource unterstützt die Priorisierung von Untersuchungen. Sie ist weder Rechtsberatung, eine Attributionsfeststellung noch eine Zertifizierung, dass eine Website sicher ist.