Combien de cas de fraude votre fournisseur de bots laisse-t-il passer ? Une plateforme de jeux d’argent l’a découvert à ses dépens

Une plateforme de jeux en ligne d’argent réel en pleine expansion ne prenait pas la sécurité à la légère. Avec des millions de transactions en argent réel transitant quotidiennement par ses applications mobiles, elle avait mis en place ce qui semblait être une véritable forteresse :

couche 1: solution de gestion des bots basée sur un CDN ;

couche 2 : un fournisseur de gestion des bots (que nous appellerons “Fournisseur X”) déployé en mode de protection complète ;

couche 3: examen manuel des cas de fraude par son équipe de sécurité, complétant la détection automatisée par des règles personnalisées.

Elle disposait de trois systèmes de défense indépendants avec blocage en temps réel activé, et pourtant, des fraudes parvenaient à passer entre les mailles du filet.

Quand votre prestataire de paiement vous alerte d’un problème de sécurité

Le premier signe que quelque chose n’allait pas est venu d’une source inattendue : leur prestataire de paiement, qui a signalé plus de 1 000 comptes victimes d’account takeover, ce qui signifie que les comptes avaient été consultés par quelqu’un d’autre que leur véritable propriétaire.

L’enquête menée par le client a révélé que ces comptes n’avaient été détectés par aucune des solutions existantes avant l’alerte du processeur de paiement.

La fraude n’était pas subtile. En creusant davantage, ils ont trouvé :

• des attaques de credential stuffing utilisant des réseaux de proxy résidentiels ;
• des account takeover et de la fraude au paiement ; 
• des réseaux d’abus promotionnels exploitant les bonus d’inscription et les crédits de parrainage ;
• des opérations de scraping de données récoltant des données de plateforme propriétaires à des fins d’arbitrage concurrentiel.

L’équipe de sécurité détectait les fraudes manuellement, en créant des règles personnalisées pour combler les lacunes. Mais cette approche n’était pas évolutive. Et cela soulevait une question dérangeante : pourquoi sommes-nous toujours confrontés à ce problème ?

La preuve de concept

Lorsque la plateforme a accepté d’évaluer DataDome, elle ne pouvait pas prendre le risque de perturber son infrastructure de sécurité en production. Elle a donc positionné DataDome en aval de sa solution de gestion des bots du CDN et du fournisseur X.

Cela signifiait que DataDome n’analysait qu’environ 75 % du trafic que la solution CDN et Fournisseur X avaient déjà autorisé à passer.

L’équipe de sécurité a testé cette configuration pendant deux semaines. L’objectif était de déterminer si DataDome pouvait identifier une activité suspecte après que les contrôles existants avaient déjà autorisé le trafic.

Résultat : 27 à 37 fois plus de fraudes détectées par DataDome

Détection de la fraude à l’inscription

DataDome a détecté près de 2 fois plus de fraudes que le fournisseur X et la vérification manuelle combinés, bien qu’il n’ait examiné que le trafic approuvé par le fournisseur X.

Détection de la fraude aux dépôts

DataDome a identifié 27 fois plus de tentatives de dépôt frauduleuses que Fournisseur X, à partir d’une fraction seulement du trafic total.

Détection de la fraude aux retraits

DataDome a détecté 37 fois plus de tentatives de retrait frauduleuses que Fournisseur X.

Ce qui passait entre les mailles du filet

Les journaux de l’équipe de sécurité ont révélé des opérations de fraude sophistiquées et à plusieurs niveaux qui avaient été autorisées par Fournisseur X. Voici ce que DataDome a détecté et comment.

1. Credential stuffing avec proxy résidentiel

Les fraudeurs utilisaient des réseaux de proxy résidentiels pour faire tourner des milliers d’identifiants volés. Les IP résidentielles ressemblent à des utilisateurs légitimes – vrais appareils, vrais FAI, pas d’historique de fraude – ce qui les rend difficiles à attraper en se basant uniquement sur la réputation des adresses IP.

Comment DataDome l’a détecté : par analyse comportementale. Même avec des IP tournantes, le schéma d’attaque était cohérent : tentatives de connexion immédiates après le lancement de l’application sans navigation préalable, empreintes digitales d’appareils identiques apparaissant sur différentes IP, et haute vélocité à travers les sous-réseaux IP. Les modèles d’IA de DataDome ont détecté l’intention comportementale derrière le schéma, pas seulement la source de la requête.

2. Abus promotionnel liés aux fermes d’appareils

Des réseaux de fraude coordonnés utilisaient des marques d’appareils mobiles fortement associées aux fermes d’appareils pour créer des comptes avec des codes de parrainage, passer des commandes en utilisant des crédits promotionnels gratuits, déposer le montant minimum requis, et retirer immédiatement, encaissant les bonus avec le dépôt.

L’équipe de sécurité a noté que les opérateurs de fraude étaient devenus très efficaces pour exploiter les systèmes promotionnels, et a exprimé sa frustration que des schémas qu’elle considérait comme évidents dans ses propres journaux n’étaient pas détectés par le fournisseur en place.

Comment DataDome l’a détecté : par intégration de champs personnalisés. DataDome a ingéré les données du fabricant d’appareils que le client collectait déjà et a déployé des règles de détection correspondant à leur propre intelligence de fraude : signalement des marques d’appareils fortement associées aux fermes d’appareils, recoupement avec les schémas d’abus de codes de parrainage, et identification des séquences rapides de dépôt suivi d’un retrait dans les heures suivant la création du compte.

3. Bots d’inscription contournant la validation

La création automatisée de comptes ciblait directement les points de terminaison d’inscription, sautant les étapes de validation obligatoires que les utilisateurs légitimes complètent via l’application.

Comment DataDome l’a détecté : le client a fourni le parcours-type de ses utilisateurs légitimes. L’équipe Galileo Threat Research de DataDome a construit des règles pour l’appliquer, en remettant en cause la création de comptes qui sautait les étapes de validation requises ou qui complétait l’inscription dans un délai incroyablement court.

4. Fraude au paiement avec usurpation de localisation

Les fraudeurs utilisaient un appareil pour passer la vérification de géolocalisation, puis transmettaient le jeton d’authentification approuvé à un autre appareil pour le traitement du paiement. Un identifiant d’appareil différent, une autre adresse IP, et une session entièrement différente.

Comment DataDome l’a détecté : sur la base des observations du client, les ID d’appareil envoyés à Fournisseur X en tant que paramètre personnalisé ne semblaient pas être utilisés pour la corrélation. DataDome a ingéré les mêmes données et a signalé les incohérences entre l’appareil utilisé pour la vérification de géolocalisation et l’appareil utilisé pour le paiement. 

5. Scraping de données à des fins de veille concurrentielle

Plus de 400 000 requêtes visaient des données propriétaires de la plateforme, avec des schémas caractéristiques d’un scraping automatisé : requêtes sans cookies, en-têtes de requête mal formés et génériques, et comportement de pagination anormal. Ces éléments correspondaient à des opérations de collecte de données destinées à l’analyse concurrentielle.

Comment DataDome l’a détecté : en déployant des règles ciblant les requêtes sans cookie sur les points de terminaison de données sensibles, les valeurs Accept-Language mal formées, les en-têtes « Accept: */* » et les modèles d’en-têtes de langue régionale présentant un timing anormal.

L’approche de DataDome : IA comportementale et assistance proactive

Pour les cinq types d’attaques, le fil conducteur était le même. Sur la base des observations du client, les contrôles existants semblaient analyser les requêtes isolément, se basant largement sur des signatures connues et des signaux de réputation. Les attaquants sophistiqués avaient déjà appris à les contourner.

DataDome s’est concentré sur l’intention comportementale : apprendre à quoi ressemblaient les parcours utilisateurs légitimes et signaler les écarts, corréler les signaux à travers les appareils et les sessions, et exploiter les propres informations de détection de la fraude du client pour les transformer en règles de détection automatisées.

Au-delà de la détection, le modèle de support différait significativement. D’après l’expérience du client, l’assistance du fournisseur en place était réactive : le client identifiait la fraude, puis soumettait des tickets. DataDome a affecté un analyste spécialisé dans la recherche sur les menaces pour toute la durée du POC, qui traquait activement les menaces et déployait des règles personnalisées, souvent le jour même.

Ce que cela signifie pour votre plateforme

Cette plateforme n’avait pas une mauvaise stratégie de sécurité. Elle comptait trois niveaux de protection, une équipe dédiée à l’analyse des fraudes et un prestataire qu’elle rémunérait pour assurer sa sécurité. Le problème ne résidait pas dans le manque d’efforts, mais dans le fait que l’un de ces niveaux ne fonctionnait pas comme prévu.

L’écart de détection de 27 à 37 fois n’est apparu que parce qu’ils ont osé se poser une question dérangeante : « Et si notre prestataire actuel passait à côté de quelque chose ? »

Si vous traitez des millions de transactions en temps réel et que vous avez déjà eu une fraude signalée par votre processeur de paiement avant que votre fournisseur de bots ne l’attrape – ou que vous avez remarqué que votre équipe rédigeait des règles manuelles pour combler des lacunes qui auraient déjà dû être comblées – cela vaut la peine de vous poser la même question.

Nous proposons une démonstration de faisabilité sans interruption, identique à celle réalisée par cette plateforme, dans laquelle DataDome surveille le trafic déjà approuvé par votre solution existante. Vous n’avez rien à modifier pour voir ce qui passe entre les mailles du filet.

Contactez-nous aujourd’hui pour une démonstration, et notre équipe sera heureuse de réaliser une POC contre votre fournisseur actuel.