Nächste Evolutionsstufe von Ad Fraud – Worauf sich das Mobile Marketing in 2018 einstellen muss

Auch im Jahr 2018 entwickeln Betrüger immer neue Methoden, Daten und Einnahmen von Werbetreibenden zu stehlen. In diesem Jahr ist „SDK Spoofing“ die neueste Form des mobilen Ad Frauds, der das Budget eines Werbetreibenden anzapft, indem legitim aussehende Installationen generiert werden, ohne dass echte Installationen stattfinden.

SDK-Spoofing, auch Replay-Angriffe genannt, ist eine Form von Ad Fraud, die sich im Laufe des Jahres 2017 bereits rapide entwickelt und verbreitet hat. Sie nutzt dafür das Gerät eines Nutzers, ohne dass dieser es bemerkt, um eine App-Installation vorzutäuschen. Die Verbindung ist real, die Gerätedaten sind real, das Gerät ist real – das macht es so schwierig SDK Spoofing zu enttarnen.

Es ist schlimm genug, dass es keine Interaktion zwischen dem Nutzer und der Werbung für die beworbene App gibt, aber das noch größere Problem ist, dass es keine tatsächliche Installation gibt. Die Dimension des Schadens ist nur schwer abzuschätzen: Wir konnten in unterschiedlichen Kampagnen spoofed Installs zwischen 5% bis 80% beobachten – und das in unterschiedlichsten App-Kategorien weltweit. Wie immer gilt: die Werbetreibenden mit den größten Budgets und den höchsten Auszahlungen pro Install sehen den meisten Fraud.

Reale Gerätedaten als Quelle für Betrüger

Bislang waren der Bekanntheitsgrad und das Verständnis einer URL-Struktur in den frühen Phasen nur sehr gering, wodurch Spoofing-Versuche leichter erkannt und blockiert wurden. Fraud kam von Rechenzentren oder VPNs und Daten waren oft unsinnig oder die URL-Parameter wurden mit Daten gefüllt, die nicht dem beabsichtigten Zweck entsprachen. Mit der Zeit haben die Betrüger schließlich entdeckt, warum ihre gefälschten Installationen blockiert wurden und ihre Methoden entsprechend angepasst. Mit der Zeit haben sie es geschafft, die betrügerischen den realen Gerätedaten anzugleichen.

Die Betrüger sammeln seit 2017 reale Gerätedaten. Sie tun dies, indem sie ihre eigenen Apps verwenden oder indem sie jede App nutzen, über die sie Kontrolle erlangen können. Die Absicht ihrer Datensammlung ist bösartig, aber das bedeutet nicht, dass die App, die für Daten ausgenutzt wird, keinen Mehrwert für den Nutzer hat. Dieser Mehrwert ist sogar von Vorteil, denn je nützlicher die App ist, desto größer ist die Nutzerzahl und damit auch die verfügbare Datenmenge.

Eine Quelle, die reale Gerätedaten erzeugt, macht es für Betrüger sehr viel einfacher. Sie müssen nicht länger Daten randomisieren oder kuratieren, weil sie jetzt Zugriff auf die realen Daten haben. Da Betrüger die URLs für alle serverseitigen Verbindungen im Klartextformat lesen können, sind sie in der Lage nachzuvollziehen, welche URL-Aufrufe bestimmte Aktionen innerhalb der App darstellen, z.B. zuerst geöffnet, wiederholt geöffnet und sogar verschiedene In-App-Ereignisse wie Käufe etc. Sie untersuchen auch, welche Teile dieser URLs statisch und welche dynamisch sind.

Trial and Error bis zum Fraud

Dank Callbacks und nahezu Echtzeit-Kommunikation, die den Erfolg von Installationen und Ereignissen aufzeigen, können die Täter nun ihr Setup testen, indem sie einfach einen Klick und eine passende Installationssitzung erstellen. Wenn die Installation nicht ausgeführt wird, liegt ein Fehler in der URL-Logik vor. Wenn es erfolgreich getrackt wird, wissen sie, dass sie die Logik entschlüsselt haben. Einfach nach dem Prinzip Trial and Error, kann so mit nur ein paar Dutzend Variablen dieser Prozess leichter verstanden werden, je länger das Experiment dauert. Sobald eine Installation erfolgreich verfolgt wurde, haben die Betrüger eine URL-Einrichtung gefunden, die es ihnen ermöglicht, Installationen aus dem Nichts zu simulieren.

Erschwerend kommt hinzu, dass dieser riesige Sprung in der Evolution von Fraud mit einem zweiten und ebenso wirkungsvollen Schritt in der Raffinesse des SDK-Spoofings einhergeht. Die URLs werden nicht mehr von Rechenzentren abgerufen oder über VPNs. Stattdessen werden sie direkt durch die App weitergeleitet, auf die der Täter auf einem Gerät eines nichts ahnenden Nutzers Zugriff hat. Das bedeutet, dass der Server des Betrügers ein Skript ausführt, das automatisch eine URL erstellt, die eine Attribution-Firma wie Adjust dazu veranlasst, eine Installation oder ein anderes spezifisches Ereignis zu tracken. Anstatt diese URL direkt an Adjusts Server zu senden (oder über ein anonymisierendes Netzwerk), senden die Betrüger sie nun an eine spezielle App auf dem Gerät eines Benutzers. Diese App führt nun die URL auf dem Gerät des Nutzers aus.

Wie das Problem gelöst werden kann

Um Replay-Angriffe (SDK Spoofing) zu verhindern, mussten verschiedene Methoden getestet werden, bis endlich eine Lösung gefunden wurde. Ein Signatur-Hash, der nicht erraten oder gestohlen werden kann und nur einmal verwendet wird, erweitert die URL um einen neuen dynamischen Parameter. Der zusätzliche, gemeinsame Parameter muss für jede App, die gesichert werden soll, generiert werden. Hierfür müssen sich die Marketer mit den Attribution Firmen in Kontakt setzen, um gemeinsam die Lösung zu entwickeln. Die Chance, dass man selbst von SDK-Spoofing Fraud betroffen ist, steigt mit der Anzahl der Marketer, die sich vor der neuen Betrugsvariante schützen. Denn eins ist gewiss: Wenn Opportunitätskosten steigen, wird sich SDK-Spoofing weiter verbreiten und auch kleinere Budgets ins Visier nehmen. Es ist nur eine Frage der Zeit, bis wir im gesamten Markt hohe Raten von SDK-Spoofing Installs sehen.