Dans cet exemple, nous allons analyser une campagne de hameçonnage qui se fait passer pour Netflix et utilise un système de contrôle en temps réel de la victime. Il ne s’agit pas d’un simple formulaire HTML statique, mais d’un véritable service de hameçonnage : l’utilisateur passe par plusieurs étapes, et l’opérateur décide depuis le panneau de contrôle où le diriger ensuite — vers la saisie de son identifiant, de ses coordonnées bancaires, d’un code SMS, d’un code PIN ou d’une confirmation dans l’application.
Nous avons par ailleurs confirmé ce mécanisme en accédant au panneau de contrôle de ce site de hameçonnage et en l’étudiant.
Dans cet article, nous ne décrivons pas la méthode permettant d’accéder au panneau de contrôle, mais nous utilisons le simple fait de son existence comme confirmation du modèle opérationnel : l’attaque était gérée manuellement ou de manière semi-automatique via une interface backend.
0. L'appât
La première chose que reçoit l’utilisateur est un e-mail recourant à une tactique classique d’ingénierie sociale pour l’inciter à agir. Les attaquants espèrent attirer l’attention de l’utilisateur en lui faisant croire que le visionnage de ses séries préférées risque d’être suspendu. Pour contourner les filtres de messagerie et masquer le domaine de phishing final, les cybercriminels utilisent un lien raccourci via l’infrastructure du réseau social X : https://t.co/XXXXXXX
À première vue, il s’agit d’un lien classique via t.co, ce qui la rend moins suspecte tant pour l’utilisateur que pour certains filtres automatiques.
Après avoir cliqué, l’utilisateur n’est pas immédiatement redirigé vers la page principale de hameçonnage. Il est d’abord redirigé vers une ressource intermédiaire.
1. Un compartiment S3 public comme redirecteur intermédiaire
Le lien mène à un bucket S3 public : https://access-authority-2faXXXXX.s3.eu-north-1.amazonaws.com/index.html
Cette étape fait office de filtre et de redirecteur.
index.html Elle intègre un filtrage par pays et par adresses IP connues à l’avance. Cela permet de ne pas dévoiler le véritable site de hameçonnage aux chercheurs, aux scanners automatiques, aux bacs à sable et aux systèmes de protection.
Une fois le filtre passé, l’utilisateur reçoit une simple redirection HTML :
<meta http-equiv="refresh" content="1;url=https://www.XXXXX.help/index.html">
Le domaine se fait passer pour un service de résolution de CAPTCHA. C’est une couverture pratique : l’utilisateur voit un nom technique et peut penser qu’il s’agit d’une vérification intermédiaire du navigateur, d’un CAPTCHA ou d’une validation de sécurité.
En réalité, il s’agit d’une infrastructure de hameçonnage.
Dès cette étape, l’empreinte digitale de l’appareil est relevée. Le code collecte les événements utilisateur :
- mousemove
- touchmove
- keyup
- Backspace
- deviceorientation
Le script analyse non seulement la survenue des événements, mais aussi leurs paramètres :
- la vitesse de déplacement ;
- les intervalles entre les événements ;
- les coordonnées normalisées ;
- la brusquerie du changement de direction ;
- le comportement du clavier ;
- l'orientation de l'appareil ;
- profil tactile/souris.
Ces données sont utilisées pour déterminer si le visiteur est une personne réelle.
Obfuscation et « chiffrement » des données télémétriques
Une partie des données télémétriques est chiffrée à l’aide de l’algorithme AES-CBC avant d’être envoyée : crypto.subtle.encrypt({ name: 'AES-CBC', iv: ... }, key, data)
Le code contient une logique anti-débogage. Le script extrait un mot debugger à partir d’un tableau de nombres et l’appelle via new Function(). Si l’exécution est retardée, la page envoie une requête « beacon » à /misc/index.php?r=<random> avec le paramètre bcl
Cela ressemble à une tentative de déterminer si l’utilisateur a ouvert DevTools ou si l’exécution du JavaScript a été interrompue par un point d’arrêt ; le backend peut alors modifier le comportement, masquer le flux réel et afficher une erreur, ou rediriger l’utilisateur vers le site légitime de Netflix.
Une fois le « captcha » réussi, une redirection vers main/prepare.php
2. Première phase : collecte de l’identifiant et du mot de passe
La première étape réelle de l’attaque n’implique ni carte bancaire ni SMS. L’utilisateur est d’abord redirigé vers une page imitant la page de connexion à Netflix.
À ce stade, les cybercriminels récupèrent l’adresse e-mail et le mot de passe.
C’est important : l’attaque commence par la compromission du compte, puis passe aux données de paiement.
Une fois le formulaire POST envoyé, la page redirige l’utilisateur vers l’étape suivante : la « vérification de la carte bancaire ».
Ainsi, même si les étapes de paiement suivantes ne sont pas menées à bien, les cybercriminels obtiennent déjà un résultat précieux : l’accès au compte.
3. Deuxième phase : saisie des données de la carte
Après avoir saisi son identifiant et son mot de passe, l’utilisateur est redirigé vers la page de vérification du paiement.
À ce stade, le scénario simule la nécessité de valider la carte associée à Netflix. L’utilisateur voit une interface similaire à celle d’un processus de facturation légitime et saisit ses informations de paiement.
L'objectif de cette étape est de collecter :
- le nom du titulaire de la carte
- le numéro de carte
- la date d'expiration
- le code CVV/CVC
Tout au long du processus, des données de télémétrie sont transmises en continu :
4. Troisième phase : écran de chargement et attente de l'opérateur
Une fois la carte saisie, l’utilisateur est redirigé vers une page d’attente. C’est précisément ce code HTML que l’on retrouve dans l’artefact étudié.
La page indique :
Une validation supplémentaire est nécessaire pour finaliser la vérification de votre carte
Vous recevrez un SMS sur votre téléphone portable...
Visuellement, cela ressemble à une attente classique de confirmation bancaire. Mais techniquement, il ne s’agit pas simplement d’un « écran d’attente », c’est le moment où l’utilisateur reste connecté à la session pendant que le backend ou l’opérateur décide de la prochaine étape à afficher.
5. Gestion en temps réel via WebSocket
Le principal mécanisme de gestion est le WebSocket. On peut remarquer une wss:// en bas des requêtes. La page se connecte au WebSocket et attend une commande du backend. La logique est intégrée dans le code HTML, ce qui permet à l’opérateur de rediriger l’utilisateur vers différents écrans :
| Code | Chemin | Description |
|---|---|---|
| 1 | ./app.php | Page de demande de confirmation dans l'application bancaire |
| 2 | ./payment.php | Nouvelle demande de saisie des informations de la carte en cas d'erreur |
| 3 | ./sms.php | Page de saisie du code reçu par SMS |
| 4 | ./pin.php | Page de saisie du code PIN de la carte |
| 5 | https://netflix.com | Redirection vers le véritable site Netflix |
La carte saisie par l’utilisateur, de manière automatique ou semi-automatique, commence à être utilisée pour effectuer des paiements dans différents magasins. Il s’agit très probablement de commerçants contrôlés par des cybercriminels.
C’est précisément là que la composante « en temps réel » devient particulièrement dangereuse. L’opérateur peut voir quel type de confirmation a été demandé par le système de paiement et adapter la page de hameçonnage au moment précis de l’attaque. Il peut ainsi demander tantôt une confirmation dans l’application, tantôt un code reçu par SMS ou encore le code PIN de la carte.
6. Confirmation via le panneau d’administration
Après avoir étudié le fonctionnement du site de hameçonnage, nous avons décidé de rechercher des vulnérabilités dans ce panneau d’administration. Ce faisant, nous avons découvert des « easter eggs » assez étranges laissés par le créateur de ce panneau.
D’après les journaux, on peut affirmer qu’en 24 heures, au moins 4 administrateurs différents se sont connectés au panneau d’administration à des intervalles de 4 à 7 heures.
Nous avons également découvert des ports supplémentaires ouverts sur le panneau (2082, 2095, 8880, 1010), ce qui nous a permis de déterminer l’adresse IP réelle, car le site des escrocs est masqué derrière CloudFlare.
Les fournisseurs d’accès ont été informés.
7. Indicateurs de compromission
Domaines
*.solvecaptcha.help
8. Conclusion
Cette campagne montre comment les services de phishing modernes transforment une simple page de connexion en une opération gérée en temps réel.
Les cybercriminels obtiennent d’abord l’identifiant et le mot de passe, puis les données de paiement, avant de bloquer l’utilisateur sur un écran de chargement. À ce moment-là, l’opérateur, depuis le backend ou le panneau d’administration, décide de l’étape suivante à afficher : un code SMS, un code PIN, une confirmation dans l’application ou une redirection finale vers le véritable site Netflix.
La principale caractéristique technique de ce stratagème est le contrôle via WebSocket. C’est précisément ce qui rend l’attaque interactive et permet aux opérateurs d’adapter le scénario à une victime et à un parcours bancaire spécifiques.
Il ne s’agit plus d’une « page de phishing ». Il s’agit d’une opération de phishing en direct.