Kontobetrug auf KI-APIs durch Geräte- und Netzwerksignale erkennen (DE)

Ein Konto ist eine Zeile in einer Datenbank. Ein Gerät ist ein physisches Objekt, das jemand bezahlt hat.

Diese Asymmetrie ist die gesamte Grundlage der missbräuchlichen Erkennung auf Geräteebene, und deshalb kann ein Farming-Betrieb, der 20.000 Konten kostenlos generieren kann, nicht 20.000 Geräte kostenlos generieren. Irgendwo unterhalb der Kontoebene gibt es einen endlichen Pool an echter Hardware, echten Netzwerkpfaden und eine Reihe von Tricks, die verwendet werden, um diesen kleinen Pool groß erscheinen zu lassen.

Diese Tricks haben Signaturen. Dieser Beitrag ist ein Überblick über die von Didits Geräte- und Netzwerkanalyse ausgegebenen Signale, was jedes einzelne tatsächlich bedeutet und wie man sie gewichtet – für 0,03 $ pro Überprüfung oder gebündelt in der vollständigen Verifizierung für 0,33 $.

Wichtige Erkenntnisse

• Farming-Operationen verwenden ein kleines physisches Substrat hinter einer großen Kontooberfläche. Die Wiederverwendung ist erkennbar.
• Drei Signalfamilien sind wichtig: Duplizierung (dasselbe Gerät oder dieselbe Adresse, mehr als einmal), Integrität (dies ist kein normaler Client) und Netzwerk (dieser Pfad ist nicht das, was er vorgibt zu sein).
• DEVICE_RECOVERED_HIGH_CONFIDENCE ist der wertvollste Einzelcode für dieses Problem – er erfasst ein Gerät, das nach einem Wipe zurückkehrt, was der Standard-Regenerationsschritt ist.
• Integritätscodes wie AUTOMATION_FRAMEWORK_DETECTED und DEVICE_EMULATOR_DETECTED sind für sich allein stark. Duplizierungscodes sind für sich allein schwach und benötigen eine Bestätigung.
• Warnaktionen sind pro Code konfigurierbar – ablehnen, überprüfen oder aufzeichnen – so dass die Eskalationsleiter Ihnen gehört.
• 0,03 $ pro Einzelprüfung; enthalten im 0,33 $ Verifizierungsbundle.

Die drei Signalfamilien

Duplizierung – Habe ich das schon einmal gesehen?

Code	Bedeutung
DUPLICATED_DEVICE_FINGERPRINT	Dasselbe Gerät erscheint hinter mehr als einer Verifizierung
DUPLICATED_IP_ADDRESS	Dasselbe Gerät erscheint hinter mehr als einer Verifizierung
DEVICE_RECOVERED_HIGH_CONFIDENCE	Ein zuvor gesehenes Gerät kehrt nach einem Reset oder einer Neuinstallation zurück
EXPECTED_IP_ADDRESS_MISMATCH	Die Adresse weicht von der für diese Sitzung erwarteten ab

Didit unterscheidet explizit zwischen einem duplizierten Gerät und einem wiederhergestellten Gerät, und der Unterschied ist der interessante Teil.

Ein dupliziertes Gerät sind zwei Verifizierungen vom selben Gerät – häufig, oft unschuldig. Ein Familien-Tablet. Ein gemeinsamer Arbeitsplatz. Ein Support-Mitarbeiter, der einen Benutzer durch einen Prozess führt.

Ein wiederhergestelltes Gerät ist ein Gerät, das gelöscht, zurückgesetzt oder dessen Anwendung neu installiert wurde und nun zurückgekehrt ist. Didit erkennt es immer noch.

Für das Account-Farming ist dieser zweite Fall das entscheidende Signal. Das Standardverfahren nach einem Bann ist, das Gerät zurückzusetzen und sich erneut zu registrieren – genau das lässt ein Hydra-Netzwerk schneller regenerieren, als es beschnitten wird. DEVICE_RECOVERED_HIGH_CONFIDENCE bei einem brandneuen Konto besagt: Diese Hardware war schon einmal hier, unter einem anderen Konto, und jemand hat sich die Mühe gemacht, dies zu löschen. Fast nichts Legitimes führt diese Kombination bei einer ersten Verifizierung hervor.

Integrität – Ist dies ein normaler Client?

Code	Bedeutung
AUTOMATION_FRAMEWORK_DETECTED	Der Client wird durch Automatisierung und nicht durch eine Person gesteuert
DEVICE_EMULATOR_DETECTED	Ein emuliertes Gerät anstelle von echter Hardware
DEVICE_ROOTED_OR_JAILBROKEN	Das Sicherheitsmodell des Betriebssystems wurde entfernt
DEVICE_RUNTIME_HOOKING_DETECTED	Laufzeitinstrumentierung ist an den Prozess angehängt
DEVICE_APP_TAMPERED	Die Anwendungsbinärdatei wurde modifiziert
DEVICE_DEBUGGER_ATTACHED	Ein Debugger ist angehängt
DEVICE_INTEGRITY_SIGNALS_MISSING	Erwartete Integritätssignale fehlen

Diese Familie unterscheidet sich qualitativ von der Duplizierung, und es ist wichtig, klar zu machen, warum: Diese Codes beschreiben die Absicht.

DUPLICATED_IP_ADDRESS kann jedem an einer Universität passieren. AUTOMATION_FRAMEWORK_DETECTED in einem Verifizierungsfluss bedeutet, dass jemand eine Identitätsprüfung mit einem Skript durchführt. DEVICE_EMULATOR_DETECTED bedeutet, dass das "Telefon", das Ihre Prüfung abschließt, Software ist, die auf einem Server läuft – die günstigste Art, eine Maschine wie hundert aussehen zu lassen. DEVICE_APP_TAMPERED bedeutet, dass die Client-Binärdatei modifiziert wurde, was man tut, wenn man möchte, dass sie Dinge meldet, die nicht wahr sind.

Emulator-Farmen und Automatisierungs-Frameworks sind die industriellen Werkzeuge des Account-Farmings. Wenn sie bei einer Verifizierung auftauchen, ist die unschuldige Erklärung dünn.

DEVICE_INTEGRITY_SIGNALS_MISSING ist der subtile Code. Er sagt nicht, dass etwas falsch ist – er sagt, dass die Signale, die Ihnen sagen würden, dass nichts falsch ist, nicht angekommen sind. Behandeln Sie das Fehlen eher als schwaches Negativ denn als neutral, denn die Unterdrückung von Telemetriedaten ist selbst eine Technik.

Netzwerk – Ist dieser Pfad das, was er vorgibt zu sein?

Code	Bedeutung
PRIVATE_NETWORK_DETECTED	Ein privater oder anonymisierender Netzwerkpfad
COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP	Die Geografie des Dokuments und des Netzwerks stimmen nicht überein
IP_LOCATION_NOT_ALLOWED	Der Standort liegt außerhalb Ihrer konfigurierten Richtlinie
IP_ADDRESS_IN_BLOCKLIST / IP_ADDRESS_IN_ALLOWLIST	Die Adresse stimmte mit einer Ihrer Listen überein
DEVICE_FINGERPRINT_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_ALLOWLIST	Das Gerät stimmte mit einer Ihrer Listen überein
LOCATION / NO_ACTION	Informatorisch

Netzwerksignale sind die schwächste Familie und sollten entsprechend gewichtet werden. Datenschutzbewusste Entwickler verwenden routinemäßig anonymisierende Netzwerke, und die Population einer KI-API ist technisch versierter als der Durchschnitt – eine höhere Grundrate der privaten Netzwerknutzung ist zu erwarten, nicht verdächtig.

COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP ist nützlicher als rohe Geografie, weil es ein Widerspruch und keine Ortsangabe ist. Menschen reisen und ziehen um, daher ist es für sich genommen nicht verurteilend, aber in Kombination mit einem Duplizierungssignal verschärft es sich erheblich.

Die Blacklist- und Whitelist-Codes sind die Durchsetzungshälfte – ausführlich behandelt im Beitrag über die Blacklist-Verbreitung.

Gewichtung: Was ist stark, was ist schwach

Der häufigste Implementierungsfehler besteht darin, jede Warnung als gleichwertig zu behandeln. Sie sind keineswegs gleichwertig.

Für sich allein stark – vernünftige Grundlage für Ablehnung oder strenge Überprüfung:

DEVICE_EMULATOR_DETECTED · AUTOMATION_FRAMEWORK_DETECTED · DEVICE_APP_TAMPERED · DEVICE_RUNTIME_HOOKING_DETECTED · IP_ADDRESS_IN_BLOCKLIST · DEVICE_FINGERPRINT_IN_BLOCKLIST

Im Kontext stark – Eskalation bei Kombination mit etwas anderem:

DEVICE_RECOVERED_HIGH_CONFIDENCE · DEVICE_ROOTED_OR_JAILBROKEN · COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP

Allein schwach – vor dem Handeln bestätigen:

DUPLICATED_IP_ADDRESS · PRIVATE_NETWORK_DETECTED · DUPLICATED_DEVICE_FINGERPRINT · DEVICE_INTEGRITY_SIGNALS_MISSING

Das Muster ist konsistent: Codes, die eine bewusste Manipulation des Clients beschreiben, sind stark; Codes, die gemeinsam genutzte Ressourcen beschreiben, sind schwach. Gemeinsam genutzte Ressourcen haben Tausende unschuldiger Erklärungen. Eine modifizierte Binärdatei nicht.

Konfiguration der Antwort

Warnaktionen sind pro Code konfigurierbar, sodass Sie eine echte Eskalationsleiter anstelle eines einzelnen Pass/Fail-Gates aufbauen können.

Eine praktikable Standardeinstellung für eine KI-API:

• Ablehnen bei DEVICE_APP_TAMPERED, DEVICE_EMULATOR_DETECTED, AUTOMATION_FRAMEWORK_DETECTED und jedem Blacklist-Treffer. Ein Blacklist-Treffer erzwingt standardmäßig eine Ablehnung.
• Überprüfen bei DEVICE_RECOVERED_HIGH_CONFIDENCE und bei DEVICE_ROOTED_OR_JAILBROKEN.
• Nur aufzeichnen bei DUPLICATED_IP_ADDRESS, PRIVATE_NETWORK_DETECTED und LOCATION – erfassen Sie sie zur Korrelation, aber handeln Sie niemals allein danach.

Die nur aufgezeichneten Codes sind nicht umsonst. Sie ermöglichen eine Untersuchung sechs Wochen später, wenn Ihre Traffic-Schicht ein Konto kennzeichnet und Sie wissen müssen, was es sonst noch berührt. Das Sammeln dieser Daten auf der günstigsten Stufe, wie in der risikogestuften Zugriffsarchitektur beschrieben, ermöglicht überhaupt eine spätere Korrelation.

Lesen der Signale in einer Sitzung

Geräte- und Netzwerkergebnisse kommen mit der Sitzungsentscheidung an:

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

Leiten Sie Warnungen weiter, nicht nur den Top-Level-Status. Eine genehmigte Sitzung mit DUPLICATED_DEVICE_FINGERPRINT und DEVICE_RECOVERED_HIGH_CONFIDENCE ist genehmigt und einen genaueren Blick wert – und wenn Sie nur den Status lesen, werden Sie es nie erfahren.

Didit zeigt auch sitzungsübergreifende Übereinstimmungen an, wodurch Sie von einer einzelnen Warnung zu den anderen Sitzungen gelangen, die dasselbe Gerät oder dieselbe Adresse teilen. Das ist der Dreh- und Angelpunkt von einem Konto zu einem Cluster.

Anwendungsfälle

KI-API-Plattformen erfassen Geräte- und Netzwerksignale auf der günstigsten kostenpflichtigen Stufe, damit Korrelationsdaten vorhanden sind, bevor sie benötigt werden.

Kostenlose Test- und Kreditprogramme, bei denen Emulatorfarmen der dominierende Missbrauchsvektor sind und DEVICE_EMULATOR_DETECTED allein den größten Teil des Volumens entfernt.

Marktplätze und Gig-Plattformen erkennen entfernte Verkäufer oder Kuriere, die auf gelöschter Hardware zurückkehren.

iGaming setzt Einzelkontoregeln und Selbstausschluss durch, wobei die Wiederherstellung von Geräten die Standardumgehung ist.

Häufig gestellte Fragen

Funktioniert dies im Web oder nur in mobilen Apps?

Beides. Die Tiefe der Integritätssignale ist auf nativen Mobilgeräten größer, wo das Betriebssystem mehr offenbart – Codes wie DEVICE_ROOTED_OR_JAILBROKEN und DEVICE_APP_TAMPERED sind Konzepte nativer Apps. Websitzungen erzeugen immer noch Netzwerk- und Gerätekorelationssignale.

Kann ein entschlossener Angreifer das Geräte-Fingerprinting besiegen?

Ja, teilweise – deshalb ist es eine Familie unter mehreren und nicht die ganze Antwort. Das Ziel ist nicht die perfekte Identifizierung, sondern die Kosten. Jede Schicht der Umgehung, die ein Betreiber hinzufügt, kostet ihn Geld und Ingenieurzeit, und Umgehungswerkzeuge selbst lösen Integritätscodes aus. Ein Angreifer, der das Geräte-Fingerprinting besiegt hat, ist normalerweise in einer der anderen Signalfamilien sichtbar.

Was genau kauft man für 0,03 $?

Eine IP- und Geräteanalyseprüfung für eine Sitzung, die den vollständigen Warnkatalog zurückgibt. Die Abrechnung erfolgt pro erfolgreicher Prüfung ohne Minimum, und sie ist bereits enthalten, wenn Sie das vollständige Verifizierungsbundle für 0,33 $ nutzen.

Ist ein privates Netzwerksignal ausreichend, um abzulehnen?

Nein, und eine Ablehnung aufgrund dessen wird Sie echte Entwickler kosten. Bei einem technischen Publikum sind anonymisierende Netzwerke normal. Zeichnen Sie es auf und verwenden Sie es als Bestätigung.

Wie verhält sich dies zur Erkennung von Destillation im Datenverkehr?

Es erkennt keine Destillation. Geräte- und Netzwerksignale informieren Sie über den Client und das Konto, niemals über den Inhalt Ihres API-Verkehrs. Die semantische Erkennung ist eine separate Schicht, die in Ihrem eigenen Stack lebt. Diese Signale sagen Ihnen, wie viele Konten ein Betreiber betreibt; Ihre Traffic-Schicht sagt Ihnen, was er damit macht.

Bereit zum Start?

Die Geräte- und Netzwerkanalyse ist eine einzelne Prüfung bei jeder Verifizierungssitzung.

• Lesen Sie die Dokumentation – Übersicht IP & Geräteanalyse und den vollständigen Warnkatalog.
• Sehen Sie sich das Produkt an – Benutzerverifizierung.
• Prüfen Sie die Preise – 0,03 $ pro Prüfung, im 0,33 $ Bundle enthalten, keine Mindestmengen.
• Kostenlos starten – business.didit.me, 500 KYC-Verifizierungen pro Monat kostenlos.