Markenimitation & Digital Risk Protection

Angreifer registrieren ähnlich klingende Domains, klonen Webshops, veröffentlichen gefälschte Apps und betreiben gefälschte Support- oder Führungskräfte-Profile, um Kunden in Ihrem Namen zu betrügen. Digital Risk Protection (DRP) beobachtet das offene Internet nach solchen Objekten, trennt mithilfe visueller Ähnlichkeit und LLM-Klassifizierung echten Missbrauch von harmlosen Ähnlichkeiten und automatisiert den Takedown. Der Nutzen sind schnellere Entfernung (Stunden statt Tage) sowie weniger Kundenbetrug und Reputationsschäden.

Problem & Nutzen

• Heute: Marken- und Sicherheitsteams finden Missbrauch über Kundenbeschwerden, manuelle Google-Suchen und gelegentliche Domain-Watchlists. Takedowns werden einzeln per E-Mail an Registrare und Hoster geschickt, mit schleppender Nachverfolgung.
• KI-Nutzen: (1) Abdeckung: täglich Millionen neuer Registrierungen und Zertifikate werden geprüft; (2) Präzision: visuelle und Textmodelle trennen Phishing von geparkten oder legitimen Domains; (3) Tempo: Beweispakete und Takedown-Meldungen werden automatisch erzeugt und nachverfolgt; (4) aktuelle Erkenntnisse: bestätigter Missbrauch speist E-Mail- und Web-Blocklisten, bevor der erste Kunde betroffen ist.
• Regulatorischer Sog: Der EU Digital Services Act verpflichtet Plattformen zu Melde- und Abhilfeverfahren (Art. 16), und vertrauenswürdige Hinweisgeber werden vorrangig behandelt (Art. 22); das beschleunigt Takedowns bei Plattformen für gut belegte Meldungen [1]. NIS2 und DORA drängen Finanzwesen und kritische Sektoren zur Überwachung von Drittparteien und externen Bedrohungen [2].

Varianten

• KMU / Onlineshop: kleine Domain- und Social-Watchlist, Marktplatzüberwachung, Takedowns über die Shop-Plattform oder den markenrechtlichen Weg.
• Banken, Versicherungen, Telekommunikationsanbieter, Zahlungsdienstleister: hohes Phishing- und Fake-App-Aufkommen, 24/7-Takedown mit SLA, verzahnt mit SOC und Betrugsabwehr.
• Schutz von Führungskräften und VIPs: gefälschte Profile von Führungskräften für CEO-Betrug (ergänzt SEC-011 Deepfake-Erkennung).
• Handel und Marken: gefälschte Angebote und Fake-Webshops, Überwachung von Graumarkt-Marktplätzen.

So funktioniert es

Sammeln (neue Domains/Zone-Files, CT-Logs, Passive DNS, Crawler, App-Stores, Social Media, Marktplätze)
  -> Kandidatenerzeugung (Permutationen, Homoglyphen, Schlüsselwort- + Markenabgleich, Logo-/Bildtreffer)
  -> Anreicherung (WHOIS/RDAP, Hosting, MX-/Mail-Setup, TLS-Zertifikat, Seitenabruf + Screenshot)
  -> KI-Scoring (visuelle Ähnlichkeit von Logo und Layout, Text-/LLM-Klassifikation, Erkennung von Login-Formularen und Zahlung)
  -> Analystenprüfung unklarer Fälle (Human-in-the-Loop)
  -> Maßnahme (Takedown-Meldung, Plattformmeldung, Eskalation an Registrar/Hoster, Blocklisten-Push, Übergabe an die Rechtsabteilung)
  -> Wiederauftauchen überwachen und Zeit bis zum Takedown messen

• Kandidatenerzeugung: Domain-Permutationen (Tippfehler, Homoglyphen, ergänzte Schlüsselwörter, andere TLDs) plus Ströme neu registrierter Domains und Zertifikate (Certificate Transparency).
• Visuelle Ähnlichkeit: Embeddings von Screenshots, Favicons und Logos (CLIP-/SigLIP-Stil oder Perceptual Hashing) werden mit dem Markenmaterial verglichen; das erfasst Klone mit anderem Wortlaut.
• LLM-/VLM-Klassifizierung: Ein Vision-Language-Modell erhält Screenshot und extrahierten Text und liefert ein strukturiertes Urteil (Phishing, Fake-Shop, geparkt, legitimer Wiederverkäufer, Fanseite) mit Begründung. Cloaking und Geo-Fencing machen Crawler aus mehreren Regionen und browserähnliches Abrufen nötig.
• Mensch-in-der-Schleife (Human-in-the-Loop): Analysten bestätigen Grenzfälle, besonders Fanseiten, Wiederverkäufer, Parodien und markenrechtlich zulässige Nutzungen, und genehmigen Takedowns, die legitime Dritte treffen könnten. Die Rechtsabteilung entscheidet über Eskalationen im Markenrecht und nach UDRP/URS.
• Takedown-Automatisierung: vorlagenbasierte Meldungen an Abuse-Kontakte von Registraren, Hosting-Anbieter, CDN, App-Stores und Meldeformulare von Plattformen; Nachverfolgung bis zur Erledigung.

Datenaufbereitung

Die aufzubereitenden Daten sind gering und betreffen meist die eigene Marke, nicht Personen. Typische Quellen sind die Marketing- und Rechtsabteilung: eine Liste eigener Domains und Marken, Logos und Produktbilder (oft nur in Agenturordnern oder PDFs), Namen von Führungskräften und offizielle Social-Media-Konten sowie frühere Takedown-Fälle in E-Mails oder Tickets. Typische Lücken: kein zentrales Register eigener Domains, über Dateiablagen verstreutes Markenmaterial, keine Liste legitimer Partner- und Wiederverkäuferseiten (was Fehlalarme verursacht) und keine Aufzeichnung früherer Fälle.

Vorbereitungsschritte: 1. Ein Register eigener Domains, Marken und offizieller Konten aufbauen (PREP-001, PREP-004). 2. Logos, Produktbilder und den offiziellen Wortlaut in einem Ordner mit einfachen Tags sammeln (PREP-010, PREP-016). 3. Eine Positivliste legitimer Partner und Wiederverkäufer schreiben. 4. Frühere Takedown-Fälle in gelabelte Beispiele für den Klassifikator (PREP-020) und einen kleinen Testdatensatz (PREP-018) überführen. 5. Festlegen, wer einen Takedown beauftragen darf.

Werkzeuge: eine Tabelle oder kleine Liste, ein gemeinsamer Ordner für Medien. Die Datenaufbereitung macht nur etwa 10-15 Prozent des Gesamtaufwands aus; einen Schnellcheck bietet GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU — Weg A: DRP- und Domain-Monitoring-Dienste sind ausgereift und erschwinglich, und der Prozess gegen Markenmissbrauch ist Standard.
• Großunternehmen — Weg A: Standard-Überwachung mit Takedown-Netzwerken und Plattformbeziehungen, die schwer nachzubauen sind; B nur bei sehr speziellem Bedarf.
• Entwickler — Weg C: Open-Source-Überwachung von Domains und Certificate Transparency (z. B. dnstwister, certstream) plus ein kleines lokales Modell auf HW2 für die Triage.

Weg A — Kaufen (Standardsoftware) (für die meisten Organisationen empfohlen)

• DRP-/Takedown-Dienste: Netcraft (UK), Bolster, ZeroFox, Recorded Future, CrowdStrike Falcon Intelligence Recon, Check Point (Cyberint), MarkMonitor/Clarivate für markenrechtlich aufwendige Fälle. EU-Datenstandort und Unterauftragsverarbeiter jeweils prüfen.
• Prüfen: Abdeckung je Kanal (Domains, soziale Medien, App-Stores, Marktplätze), wer Takedowns ausführt (Managed Service vs. Self-Service), Takedown-SLA, Qualität der Belege, API/Feeds in SIEM und Gateways, AVV und Verarbeitung in der EU.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Feeds: Certificate Transparency (crt.sh, Feeds vom Typ CertStream), Feeds neu registrierter Domains (WhoisXML API, DomainTools, ICANN-CZDS-Zone-Dateien), Passive DNS, urlscan.io-API für Screenshots und Scandaten.
• Modelle: ein multimodales LLM mit strukturierter Ausgabe (Claude, Gemini, GPT, Mistral Pixtral/Medium als EU-Anbieter) für die Screenshot-Klassifizierung; ein Embedding-Modell für Ähnlichkeit; nur auf vorgefilterte Kandidaten anwenden, um die Kosten zu steuern.
• Orchestrierung: n8n oder ein Ticketsystem (Jira, TheHive) für Prüfung und Takedown-Nachverfolgung; RDAP-Abfragen, um Abuse-Kontakte zu finden.

Weg C — Selbst betreiben (Open Source)

• Erkennungswerkzeuge: dnstwist (Apache-2.0, Permutations-Engine) [3], Community-Feeds im Stil von OpenPhish oder PhishTank, headless Playwright-Crawler im Stil von URLScan, Forschungscode zum visuellen Markenabgleich im Stil von Phishpedia [4].
• Modelle: offene VLMs (Qwen-VL-Familie, Pixtral, Gemma-Vision-Varianten), betrieben mit vLLM oder Ollama; offene Embedding-Modelle wie SigLIP für Logo- und Screenshot-Ähnlichkeit; Vektorindex in pgvector oder Qdrant.
• Hardware: HW2 (eine GPU mit 24-32 GB) genügt für die Screenshot-Klassifizierung von Zehntausenden Kandidaten pro Tag; die Crawling-Infrastruktur mit wechselndem regionalem Ausgang ist der größere Betriebsanteil.

Weg D — Eigenes Training

Lohnt sich für große Banken oder Telekommunikationsanbieter: einen visuellen Markenabgleich oder Seitenklassifikator auf den eigenen bestätigten Fällen (Screenshots mit Label Phishing/harmlos) feintunen, um Fehlalarme zu senken und lokalsprachige Köder abzudecken. Meist braucht es einige tausend gelabelte Seiten; die Urteile der Analysten liefern sie laufend.

Stand der Technik (2026)

• Multimodale LLMs klassifizieren Screenshots und Seitentexte gut, auch mehrsprachige Köder, und haben handgeschriebene Regeln bei vielen Entscheidungen „ist das eine Phishing-Seite“ ersetzt; akademische Arbeiten zur referenzbasierten Phishing-Erkennung (Konsistenz von Logo und Domain) bleiben die Grundlage des Markenabgleichs [4].
• Gegenseite: KI-generierte Shop-Klone und Angebote lassen sich in Minuten erstellen; Angreifer nutzen Cloaking, kurzlebige Domains und den Missbrauch legitimer Hosting- und Link-Kürzungsdienste, sodass die Erkennungsfenster kurz sind.
• Grenzen: Fehlalarme (Fanseiten, Wiederverkäufer, Parodien) bergen rechtliche Risiken, wenn fälschlich abgeschaltet wird; die Takedown-Geschwindigkeit hängt von Dritten ab; die Abdeckung geschlossener Messenger (WhatsApp, Telegram-Gruppen) ist schwach; Angaben der Anbieter zur Takedown-Zeit werden nicht unabhängig geprüft.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack (vlm + web-scraping + embedding-text): SEC-002 Phishing- und E-Mail-Sicherheit (bestätigte Domains in Mail-Gateways einspeisen), SEC-011 Deepfake-Erkennung (gefälschte Profile und Stimmen von Führungskräften), VIS-035 Logo-Erkennung.
• Erkenntnisse: SEC-008 Verarbeitung von Threat Intelligence nutzt und reichert die Indikatoren an; SEC-001 SOC-Triage erhält Fälle mit hohem Schweregrad.
• Verwandt, aber anders: ANOM-004 behandelt gefälschte Konten innerhalb der eigenen Plattform; SEC-021 behandelt Objekte außerhalb davon. LANG-018 (Social Listening) teilt sich Crawling- und Klassifizierungs-Pipelines.

Aufwand, Kosten & Kennzahlen

• Weg B: 1-3 Monate; Hauptkosten sind Feed-Lizenzen, Crawling und Modellaufrufe auf gefilterten Kandidaten.
• Weg C: 2-4 Monate; Entwicklung des Crawlings und laufende Abstimmung, geringe Lizenzkosten.
• Kennzahlen: Zeit vom ersten Auftreten bis zur Erkennung, Zeit von der Erkennung bis zum Takedown, Anteil des bestätigten Missbrauchs, der abgeschaltet wurde, Fehlalarmquote bei der Analystenprüfung, Kundenmeldungen und Betrugsverluste im Zusammenhang mit Imitation, Vorlaufzeit der Blocklisten gegenüber dem ersten Kundenklick.

Menschen & Veränderung

Geschäftsleitung und Recht/Compliance entscheiden, wer Takedowns auslösen darf, denn falsche Takedowns können Haftung verursachen. Das Marketing (die Abteilungsleitung für die Marke) liefert Material und die Positivliste; IT und die Informationssicherheitsbeauftragte bzw. der Informationssicherheitsbeauftragte binden Blocklisten an Mail- und Web-Gateways an. Der Kundenservice sollte den Dienst kennen, damit Kundenmeldungen dort ankommen.

Betriebsrat: in der Regel nein. Das System durchsucht das öffentliche Internet und überwacht keine Beschäftigten, sodass §87 Abs. 1 Nr. 6 BetrVG normalerweise nicht ausgelöst wird; die Information nach §90 Abs. 1 Nr. 3 ist bei geänderten Abläufen dennoch gute Praxis. Werden Social-Media-Konten von Beschäftigten oder Namen von Beschäftigten überwacht, erneut prüfen und den Betriebsrat einbinden.

Datenschutz: Personenbezogene Daten fallen nur nebenbei an (WHOIS-Daten, Profilnamen), das Risiko ist daher gering, doch fragen Sie die oder den Datenschutzbeauftragte(n) nach der Rechtsgrundlage und schließen Sie mit dem Anbieter einen AVV (Art. 28 DSGVO). KI-Kompetenz (Art. 4 KI-Verordnung): Unterstützen Sie die wenigen Nutzenden mit einem kurzen Briefing zu Fehlalarmen und zu den für einen Takedown nötigen Belegen. Pilotieren Sie mit einer Marke und einer wöchentlichen Prüfung der wichtigsten Treffer. Typische Bedenken sind Fehlalarme und der Prüfaufwand; begegnen Sie ihnen, indem Sie Schwellenwerte mit der Positivliste abstimmen. Ein Mensch genehmigt jede Takedown-Anfrage. Siehe GUIDE-009, GUIDE-010 und GUIDE-013.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko bei einem typischen Einsatz; die Pflicht zur KI-Kompetenz (Art. 4) gilt. Es handelt sich nicht um biometrische Identifizierung: Erweitern Sie es nicht auf Gesichtserkennung von Personen in sozialen Medien, das fiele unter Art. 5 und Anhang III (das ungezielte Auslesen von Gesichtsbildern ist nach Art. 5 Abs. 1 lit. e verboten). Ein Logo abzugleichen ist in Ordnung; Gesichter von Personen abzugleichen ist ein anderer Anwendungsfall.
• DSGVO: Daten aus Fake-Profilen und WHOIS/RDAP können personenbezogene Daten der Kontoinhaber oder Registranten enthalten (oft der Angreifer, manchmal ein unbeteiligter Dritter); Rechtsgrundlage ist typischerweise das berechtigte Interesse (Art. 6 Abs. 1 lit. f) mit dokumentierter Interessenabwägung, Datenminimierung und kurzer Aufbewahrung; AVV mit Anbietern; kein Auslesen privater Profile.
• Plattformrecht: Melde- und Abhilfeverfahren nach dem DSA (Art. 16) verlangen begründete Meldungen; Missbrauch von Meldungen hat Folgen. Markenrechtliche Regeln (UDRP/URS, nationales Recht) regeln Domainstreitigkeiten [1][5].
• Gegenmaßnahmen: menschliche Freigabe bei nicht offensichtlichen Fällen, Beweisstandards, Vorlagen für die rechtliche Prüfung, klare Eskalation an die Strafverfolgung bei Betrug.

Erste Schritte

1. Die zu schützenden Objekte auflisten: Marken- und Produktnamen, wichtige Domains und TLDs, Logos, Führungskräfte, App-Namen, Social-Media-Kennungen.
2. dnstwist und eine Certificate-Transparency-Suche für Ihre Domains ausführen, um zu sehen, wie groß das Problem schon ist.
3. Einen oder zwei DRP-Anbieter mit einer 30-tägigen Testphase pilotieren; Erkennungsabdeckung und gemessene Zeit bis zum Takedown an echten Fällen vergleichen.
4. Mit Recht und Betrugsabwehr einen Takedown-Workflow vereinbaren (wer genehmigt, welche Meldungsvorlagen, SLAs) und bestätigte Domains an E-Mail- und Web-Gateways übergeben.
5. Monatlich berichten: Zeit bis zum Takedown, Wiederholungstäter, Kundenmeldungen; Schwellenwerte abstimmen.

Quellen

1. Regulation (EU) 2022/2065 (Digital Services Act) - https://eur-lex.europa.eu/eli/reg/2022/2065/oj
2. Directive (EU) 2022/2555 (NIS2) - https://eur-lex.europa.eu/eli/dir/2022/2555/oj
3. dnstwist project - https://github.com/elceef/dnstwist
4. Phishpedia (reference-based phishing detection, USENIX Security 2021) - https://github.com/lindsey98/Phishpedia
5. ICANN Uniform Domain-Name Dispute-Resolution Policy - https://www.icann.org/resources/pages/help/dndr/udrp-en
6. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Netcraft brand protection - https://www.netcraft.com/
8. crt.sh Certificate Transparency search - https://crt.sh/