SDK Spoofing – gefälschte App-Messereignisse

SDK Spoofing bezeichnet die Nachahmung von Nachrichten, die normalerweise ein Software Development Kit (SDK) einer mobilen Anwendung an einen Analyse- oder Attributionsdienst übermittelt. Angreifer versuchen, künstliche Installationen oder In-App-Ereignisse so erscheinen zu lassen, als seien sie durch die echte App entstanden. Der Begriff wird auch im Zusammenhang mit Attribution Spoofing verwendet.

Eine solche Manipulation muss nicht bedeuten, dass das echte SDK selbst gehackt wurde. AppsFlyer beschreibt in seiner technischen Dokumentation ausdrücklich Varianten, bei denen Netzwerk-Anfragen nachgeahmt werden, ohne dass die Original-App auf einem wirklichen Gerät ausgeführt wird. Für die Einordnung ist daher wichtig, ob eine echte Installation, eine falsche Ereignisnachricht oder eine unzutreffende Zuordnung vorliegt.

Welche Aufgabe hat ein Mobile-SDK?

Ein SDK stellt einer App vorgefertigte Funktionen zur Verfügung. Im Mobile Marketing kann es beispielsweise erfassen, wann die Anwendung erstmals startet oder bestimmte Nutzeraktionen stattfinden. Diese Ereignisse werden nach den Vorgaben des eingebundenen Messsystems an einen Dienstleister übermittelt.

Ein Attributionsanbieter versucht anhand dieser Daten zu erkennen, welcher Werbekanal eine Installation oder eine andere Aktion vermittelt hat. Bei einer Vergütung pro Installation oder Conversion können die Messereignisse wirtschaftlich bedeutsam sein.

Wenn das Messsystem nicht ausreichend feststellen kann, ob eine Nachricht tatsächlich aus der vorgesehenen App stammt, können gefälschte Ereignisse unter Umständen wie reguläre Meldungen behandelt werden. Daraus folgt nicht, dass jede SDK-Kommunikation grundsätzlich unsicher ist. Entscheidend sind die eingesetzten Authentifizierungs- und Prüfmechanismen.

Welche Formen von SDK Spoofing gibt es?

Vorgetäuschte Installationssignale

Ein Betrugsversuch kann Installationsereignisse melden, die keiner tatsächlichen App-Installation entsprechen. Das Ziel kann darin liegen, eine CPI-Provision für eine nicht erbrachte Werbeleistung zu erhalten. Solche Ereignisse sind von tatsächlichen Installationen mit falscher Werbezuordnung zu unterscheiden.

Gefälschte In-App-Ereignisse

Auch Registrierungen, Abonnements oder Käufe können als scheinbare SDK-Ereignisse übermittelt werden. Wenn diese Aktionen in Wirklichkeit nicht stattgefunden haben, kann ein Fall von Fake In-App Events vorliegen. Die technische Nachricht ersetzt keinen bestätigten Geschäftsdatensatz.

Missbrauch der Attribution

Ein Angriff kann sich auf die Zuordnung eines Ereignisses zu einem Werbepartner richten. Wird beispielsweise eine künstliche Installation einem bezahlten Kanal zugeschrieben, kann ein unberechtigter Vergütungsanspruch entstehen. Die tatsächlich bezahlten und bereits gefilterten Ereignisse müssen dabei getrennt betrachtet werden.

Veränderung oder Nachahmung von Geräteangaben

Bestimmte betrügerische Meldungen können unzutreffende Geräte- oder App-Informationen enthalten. Diese Daten sind für die Plausibilitätsprüfung hilfreich, dürfen aber nicht ohne zusätzliche Prüfung als eindeutiger Nachweis verwendet werden. Auch echte Geräte können unterschiedliche Kennungen und eingeschränkte Messinformationen besitzen.

SDK Spoofing von Emulator Fraud unterscheiden

Bei Emulator Fraud wird eine virtuelle Geräteumgebung verwendet, um App-Abläufe nachzubilden. Beim SDK Spoofing kann dagegen die Ereignisübermittlung selbst nachgeahmt werden, ohne dass eine vollständige virtuelle App-Umgebung benötigt wird.

Beide Verfahren können zusammen auftreten. Ein technischer Bericht sollte deshalb nicht allein aus einer ungewöhnlichen Gerätekennung auf den konkreten Angriffspfad schließen. Die tatsächlichen Netzwerk- und SDK-Signale müssen untersucht werden.

Click Injection betrifft dagegen oft die falsche Werbeklick-Zuordnung bei einer echten Installation. Das zugrunde liegende Installationsereignis kann dabei tatsächlich erfolgt sein.

Welche wirtschaftlichen Folgen können entstehen?

Wenn ein Attributionsdienst gefälschte Installations- oder Kaufmeldungen akzeptiert, kann ein Werbetreibender Provisionen für nicht stattgefundene Ereignisse bezahlen. Auch die automatische Kampagnensteuerung kann auf falschen Daten beruhen.

Die Höhe des Schadens lässt sich nicht aus der Anzahl verdächtiger SDK-Anfragen allein ableiten. Moderne Messanbieter können unzulässige Meldungen herausfiltern oder die Attribution ablehnen. Solche bereits abgelehnten Ereignisse sollten nicht erneut als bezahlte Installationen gerechnet werden.

Auch eine legitime technische Fehlkonfiguration kann überzählige Events erzeugen. Deshalb muss zwischen einem unbeabsichtigten Trackingfehler und einer absichtlichen Manipulation unterschieden werden.

Fiktives Beispiel einer App-Kampagne

Ein App-Anbieter meldet in seinem Attributionssystem deutlich mehr neue Installationen als in den Berichten des App-Stores. Außerdem erscheinen angebliche Registrierungen, die keine passenden Benutzerkonten in der eigenen Datenbank besitzen.

Das Team prüft zunächst, ob unterschiedliche Zählzeitpunkte die Abweichung erklären. Ein App-Store zählt Downloads teilweise anders als ein Mobile-Messdienst, der den ersten App-Start auswertet. Danach werden SDK-Versionen, Ereigniskennungen und vorhandene Integritätsinformationen verglichen.

Die Prüfung zeigt Hinweise darauf, dass bestimmte Meldungen nicht aus dem regulären App-Betrieb stammen. Der Attributionsanbieter wird eingebunden, um die verdächtigen Nachrichten und mögliche Filterentscheidungen zu untersuchen. Eine Täteridentifikation folgt daraus noch nicht automatisch.

Welche Warnsignale können auf SDK Spoofing hindeuten?

AppsFlyer beschreibt ungewöhnliche Installationsdaten und auffällige SDK-Informationen als mögliche Hinweise. Ein Messanbieter kann beispielsweise feststellen, dass angebliche Ereignisse zu einer SDK-Version gehören, die im eigenen Veröffentlichungsstand gar nicht eingesetzt wird.

  • Unbekannte SDK-Versionen: Ereignisse werden mit Versionsangaben gemeldet, die nicht zur veröffentlichten App passen.
  • Fehlende reale Installation: Eine vergütete Installation besitzt keinen nachvollziehbaren Bezug zu einem tatsächlichen App-Nutzer.
  • Unplausible Eventfolgen: Angebliche Käufe oder Registrierungen erscheinen ohne entsprechende Geschäftsdatensätze.
  • Auffällige Quellen: Eine Werbequelle meldet besonders viele schwer erklärbare Ereignisse.
  • Integritätsprüfungen: Vorhandene technische Signale passen nicht zu einem echten App- oder SDK-Ablauf.
  • Filtermeldungen: Der Attributionsanbieter kennzeichnet Ereignisse bereits als mögliche Spoofing-Versuche.

Eine Abweichung ist zunächst ein Anlass zur Prüfung. Auch fehlerhafte Updates, Testumgebungen und die besondere Zählweise der Plattformen können ungewöhnliche Daten erzeugen.

Wie wird ein Verdacht untersucht?

Der erste Schritt ist die Dokumentation, welche App-Versionen und SDK-Versionen tatsächlich veröffentlicht sind. Anschließend werden die Ereignisse des Messdienstleisters mit Daten aus Store, App-Backend und Geschäftsprozessen verglichen. Vorhandene kryptografische oder andere Integritätsnachweise können bei der Herkunftsprüfung helfen.

AppsFlyer bietet unter anderem Schutzfunktionen, die gefälschte Installations- und Eventmeldungen im Attributionsprozess erkennen sollen. Die konkrete Verfügbarkeit hängt von der Plattform, dem gebuchten Produkt und den technischen Voraussetzungen ab. Ein automatisches Prüfergebnis muss im Einzelfall hinsichtlich seiner Aussagekraft bewertet werden.

Für die Abrechnungsprüfung sollten verdächtige, abgelehnte und tatsächlich vergütete Ereignisse getrennt erfasst werden.

Welche technischen Schutzmaßnahmen sind sinnvoll?

Ein wichtiger Bestandteil ist eine zuverlässige Authentifizierung der SDK-Nachrichten. Ein Anbieter kann geeignete Signaturen oder andere Prüfmechanismen einsetzen, um gefälschte Nachrichten zu erkennen. Die App sollte solche Verfahren entsprechend der offiziellen Dokumentation integrieren.

  • Die verwendeten SDK-Versionen und Signaturen dokumentieren.
  • Vorhandene SDK-Authentifizierungs- und Anti-Spoofing-Funktionen nach den Anbieterbedingungen aktivieren.
  • Wertvolle Geschäftsereignisse mit tatsächlichen Backend-Daten abgleichen.
  • Unplausible Werbequellen und Geräteinformationen gesondert untersuchen.
  • Abrechnungsrelevante Events mit bereits gefilterten Meldungen vergleichen.
  • Die technischen Prüfregeln nach Änderungen an App und Attributionssystem erneut kontrollieren.

Ein sicherer Kommunikationskanal verhindert nicht automatisch, dass die App selbst ein falsches Ereignis erzeugt. Daher müssen die Herkunft einer Nachricht und die tatsächliche Geschäftsaktion getrennt validiert werden.

Welche rechtlichen Fragen stellen sich?

Eine absichtliche Täuschung über vergütungspflichtige Installationen oder Nutzerereignisse kann je nach konkretem Ablauf § 263 StGB oder Vorschriften des Wettbewerbsrechts betreffen. Ein technisch auffälliges SDK-Ereignis ist für sich noch kein Beweis für eine strafbare Handlung.

Bei der Untersuchung gerätebezogener und personenbezogener Daten müssen zudem die anwendbaren Datenschutzanforderungen berücksichtigt werden. Die Betrugsprüfung rechtfertigt keine uneingeschränkte Speicherung sämtlicher Gerätedaten.

Häufige Fragen zu SDK Spoofing

Muss das echte App-SDK gehackt worden sein?

Nein. Bestimmte Angriffe ahmen SDK-Netzwerknachrichten nach, ohne dass das Original-SDK unmittelbar verändert wurde.

Kann SDK Spoofing falsche Käufe melden?

Ja, wenn ein Messsystem künstliche In-App-Ereignisse akzeptiert. Ein solcher Event ist jedoch kein Nachweis für eine tatsächliche Zahlung.

Ist jede Differenz zwischen Store und Attributionsdienst Betrug?

Nein. Unterschiedliche Messzeitpunkte und Ereignisdefinitionen sind normale Ursachen für abweichende Zahlen.

Wo können betroffene Unternehmen Hilfe erhalten?

Bei verdächtigen SDK-Events sollten App-Betreiber zunächst den Attributionsdienstleister und das eigene Entwicklungsteam einbeziehen. BRANDPROTECTIONNOW begleitet Unternehmen bei der Analyse möglicher SDK-Spoofing-Muster, der Dokumentation falsch gemeldeter Conversions und der Abstimmung geeigneter Kontroll- und Schutzmaßnahmen. Für die wirtschaftliche Bewertung werden tatsächlich vergütete Ereignisse von bereits abgelehnten Meldungen getrennt. Weitere Informationen: BRANDPROTECTIONNOW zum Werbebetrug.

Fachquellen