Click-Hijacking ist eine betr\u00fcgerische Form von Klickbetrug, bei der echte Benutzerklicks abgefangen oder umgeleitet werden, um dem Betr\u00fcger zu n\u00fctzen (z.B. Affiliate-Provision, Conversion-Zuordnung, Kosten f\u00fcr den Werbetreibenden).<\/p>\n
Die beim Click-Hijacking verwendeten Techniken umfassen versteckte iFrames und unsichtbare Schaltfl\u00e4chen, Overlays, Weiterleitungen, Cookie-Stuffing und die Manipulation von Postbacks.<\/p>\n
Transparente Elemente (iFrame, Schaltfl\u00e4chen) werden \u00fcber die sichtbare Oberfl\u00e4che gelegt. Ein Klick, obwohl der Benutzer denkt, er sei an der richtigen Stelle, geht an das versteckte Element, nicht an den erwarteten CTA. Overlays und mobile Overlay-Angriffe funktionieren \u00e4hnlich. In mobilen Anwendungen \u00e4ndern b\u00f6sartige Overlays (gef\u00e4lschte Eingabeaufforderungen) oder Ad-Stacking den Ort der Klickzuordnung.<\/p>\n
Dies geschieht durch b\u00f6sartigen Code auf der Website des Publishers — der Publisher oder ein kompromittierter Werbetreibender f\u00fcgt direkt ein Overlay\/iFrame ein. Anzeigenformate auf Websites werden ebenfalls zu diesem Zweck verwendet. Anzeigen-Creatives k\u00f6nnen beim Laden Schichten oder Weiterleitungen injizieren, ohne dass der Benutzer etwas installieren muss. Eine andere Methode ist Cross-Site-Scripting (XSS) — eine Schwachstelle auf der Website erm\u00f6glicht das Injizieren eines Skripts, das ein Overlay erstellt. Programmatische Anzeigen und Partner-Tags\/Skripte von Partnern\/SSP\/DSP k\u00f6nnen dynamisch Elemente zur Seite hinzuf\u00fcgen. Auch ein Webview in einer App kann von einem SDK oder einer b\u00f6sartigen Bibliothek manipuliert werden, ohne dass der Benutzer Erweiterungen installiert.<\/p>\n
Das \u00dcberlagern von Elementen (Overlay, versteckte iFrames, unsichtbare Schaltfl\u00e4chen) zur Durchf\u00fchrung von Click-Hijacking erfordert daher nicht immer, dass der Benutzer beispielsweise ein Add-on installiert. Viele Click-Hijacking-Overlays funktionieren direkt im Browser mit regul\u00e4rem JavaScript, das von externen Skripten\/Anzeigen oder einem infizierten Server geladen wird — ohne jegliche Erweiterung.<\/p>\n
Solche Skripte k\u00f6nnen den Traffic sofort auf eine Affiliate- oder Tracking-URL umleiten und die Zuordnung \u00fcbernehmen.<\/p>\n
Cookie-Stuffing und Postback-Manipulation sind in der Regel ausgefeilter, technisch schwieriger auszuf\u00fchren und schwerer zu erkennende Angriffe als einfache Overlays.<\/p>\n
Cookie-Stuffing erfordert die pr\u00e4zise Injektion von Affiliate-Cookies im richtigen Format und Timing (oft durch eine Kette von Weiterleitungen, Skripten oder b\u00f6sartigen Ressourcen), sodass eine sp\u00e4tere Conversion dem Betr\u00fcger zugeschrieben wird, obwohl der Benutzer keinen absichtlichen Klick gemacht hat. Cookie-Stuffing kann den Benutzer \u00fcber viele Sitzungen hinweg beeinflussen (das Cookie bleibt bestehen) und bietet Betr\u00fcgern langfristige Gewinne.<\/p>\n
Wenn die Zuordnungslogik nur die erste Zuweisung akzeptiert (First-Click) oder eine Conversion-Deduplizierungsregel verwendet (z.B. eine Zuweisung pro Benutzer\/Ger\u00e4t\/Sitzung), werden viele F\u00e4lle von Cookie-Stuffing, bei denen ein gef\u00e4lschtes Cookie versucht, die Conversion mehrfach zuzuweisen, neutralisiert. Cookie-Stuffing funktioniert jedoch oft so, dass das gef\u00e4lschte Cookie vor dem echten Klick\/der echten Quelle gesetzt wird, sodass der Betr\u00fcger bei Verwendung der First-Click-Zuordnung eine dauerhafte Zuweisung als „Erster“ erhalten kann. Die Deduplizierung wird diese einmal zugewiesene Conversion nicht entfernen.<\/p>\n
Manipulierte Postbacks hingegen beinhalten das F\u00e4lschen von Servernachrichten (Postbacks), die an Affiliate-Plattformen gesendet werden — oft erfordert dies Kenntnisse \u00fcber Partner-APIs, HMAC\/Zeitstempel und das Umgehen von Verifizierungsmechanismen. Gef\u00e4lschte Postbacks erm\u00f6glichen die Massenberichterstattung von Conversions ohne tats\u00e4chliche Client-seitige Ereignisse und skalieren den Betrug ohne Benutzerinteraktion.<\/p>\n
Beide Angriffe k\u00f6nnen in Berichten als „g\u00fcltige“ Klicks\/Conversions erscheinen (korrekte Zuordnungszuweisung, korrekte UTM-Parameter), sodass die Erkennung die Korrelation mehrerer Signale erfordert: Zeit-Anomalien, Diskrepanzen zwischen Client-seitigen und Server-seitigen Protokollen, Fingerabdruck-Unstimmigkeiten, unnat\u00fcrliche Partner-Muster.<\/p>\n
Beide Techniken sind langfristig ausgefeilter und effektiver, da sie Zuordnungssysteme und Server-Kommunikationskan\u00e4le manipulieren — die Verteidigung erfordert fortgeschrittene Validierung, Protokollkorrelation und serverseitige Sicherheitsma\u00dfnahmen.<\/p>\n
Unabh\u00e4ngige On-Site-Analytik von einem Tool-Anbieter hilft erheblich, Anomalien zu erkennen und Identifikatoren zu korrelieren, vorausgesetzt, die Integration ist korrekt gestaltet. On-Site-Tracking zeichnet Klicks, Sitzungen und Referrer direkt auf der Website\/App auf — und liefert Prim\u00e4rdaten, die mit Partnerdaten verglichen werden k\u00f6nnen.<\/p>\n
Der Vergleich von Client-seitigen IDs (device_id, cookie_id, click_id, click_timestamp, referrer_chain, transaction_id, device_fingerprint, IP, UA, landing_page, campaign_params\/UTM) mit Server-seitigen Postbacks zeigt alle Diskrepanzen und Spoofing auf.<\/p>\n