Bonjour à tous. Fin septembre, je prépare mon déplacement à Stockholm pour la 78e réunion du TF-CSIRT. Ma chambre à l’Hotel Birger Jarl est réservée et payée sur Booking.com. Puis un WhatsApp arrive : il connaît l’hôtel, mes dates et me presse de « vérifier » la réservation. J’ai ouvert le lien et il s’agissait d’une belle tentative de phishing hôtel sur WhatsApp.
L’hôtel m’a confirmé par email que le message était frauduleux. Il avertit aussi ses clients sur son site que des messages WhatsApp usurpent son identité pour réclamer un paiement. Le plus gênant, ici, c’est que l’expéditeur disposait d’assez de vraies informations pour rendre son histoire crédible.
Un message qui connaissait trop bien ma réservation
Le message invoquait une réservation à confirmer sous 24 heures. J’ai ressorti la confirmation et le reçu de Booking : la référence du WhatsApp a huit chiffres, sauf que la vraie en a dix (et les deux emails Booking.com donnent bien la même, évidemment). L’expéditeur connaissait mon séjour mais la référence qu’il utilisait n’était pas celle de ma réservation.
Même vérification pour l’argent : ma chambre était déjà intégralement payée en couronnes suédoises (SEK). Les 300 € affichés sur la fausse page ne correspondent à rien. Vraies dates, fausse référence, faux montant : c’est précisément ce mélange qui peut faire baisser la garde.
Dans son email de notification de breach, l’hôtel indique qu’un système lié à son programme de fidélité a subi un incident pouvant exposer des noms, coordonnées et dates de séjour. Il précise que les numéros de réservation et les informations de paiement n’ont pas été touchés. L’écart constaté avec ma vraie référence est cohérent avec cette explication, sans démontrer comment notre attaquant a obtenu les autres données (et je n’ai aucun élément établissant une compromission de Booking).
Le domaine dans le message WhatsApp, reserv-advanced2281488[.]com, apparaît dans le RDAP du registre .com avec une date de création au 25 septembre 2026 à 16 h 20 min 25 s UTC. Ma transcription situe le premier message au 25 septembre à 18 h 09 UTC ; notre attaquant ne perd donc pas de temps :).
Les deux premiers messages reprenaient exactement la même URL. Derrière le domaine, elle suit la forme /verify/<identifiant>/, où l’identifiant est composé de lettres minuscules, majuscules et chiffres. Cet identifiant opaque n’est d’ailleurs pas la fausse référence à huit chiffres affichée dans le WhatsApp. Mais il sert de fil conducteur au site : dans le HTML, le formulaire envoie vers /pay/<le même identifiant>.
Ce que la page collectait, et ce que son code préparait
Ma page de phishing imitait proprement une vérification de réservation en anglais : nom, email et téléphone, avec certains champs déjà remplis (sympa), mais aucun champ bancaire.
Le code source confirme la suite annoncée par l’URL : le formulaire de coordonnées utilise method="get" et cible ensuite /pay/<le même identifiant>. Un JavaScript bloque les emails ou téléphones invalides. Avec la méthode GET, le navigateur aurait ajouté les champs nom, email et téléphone aux paramètres de l’URL.
Un peu de JavaScript embarqué donne une idée du scénario prévu. L’onglet signale sa présence toutes les 25 secondes, consulte un chat et interroge une fenêtre de consignes dont le bouton « OK » reste bloqué cinq secondes. Le code peut demander l’autorisation d’afficher des notifications lorsque l’utilisateur clique ; dans cette copie, elles ne s’affichent que si l’onglet passe en arrière-plan. Il reconnaît aussi des chemins /pay/<identifiant>/sms, /push et /photo, sans que j’aie pu capturer ces écrans. Enfin, un message « This card is blocked. Please use a different card. » est prêt à pousser la victime à lâcher une autre carte (tant qu’on y est…).
Pwny a noté 31 lignes contenant du cyrillique dans les scripts du HTML conservé, et deux autres dans ses commentaires CSS. La plupart sont des commentaires de développeur en russe autour du chat et des notifications. L’un décrit l’alerte à l’arrivée d’un message de l’opérateur quand l’onglet est en arrière-plan.
Entre l’enregistrement de mon domaine le 25 septembre et la réponse HTTP que j’ai conservée le 26 septembre un peu avant 19 h UTC, il s’est écoulé moins de 27 heures. Quelques captures URLscan s’intercalent entre ces traces. Plus tard, la requête vers la racine a expiré depuis ma connexion Mullvad, et un scan URLscan du 27 septembre a reçu un 522.
Cela ne date pas l’arrêt définitif de l’infra. Le même décor de page de phishing circulait déjà sur un autre nom dès le 5 septembre. Mon domaine s’inscrit dans cette série de pages apparentées ; notre attaquant a juste eu la malchance de tomber sur moi…
Les archives montrent la suite du piège
Pour comprendre ce que pouvait cacher l’étape /pay/, j’ai commencé par regarder les scans URLscan publics. Une capture du 26 septembre à 00 h 42 UTC concerne exactement mon domaine. Elle montre l’Hôtel Cofortel, au Québec, avec les champs carte, expiration et CVC vides. L’interface est en allemand, alors que ma page Birger Jarl était en anglais. Un seul nom de domaine servait donc au moins deux hôtels et deux étapes du piège.
Ce premier changement d’hôtel m’a incité à chercher d’autres domaines sur le même motif reserv-advanced suivi de chiffres. La requête URLscan m’a donné des candidats. Sur reserv-advanced353890177[.]com, deux captures du 13 septembre montrent l’hôtel Summerbird en Indonésie puis Levi Nordic Star en Finlande, à 39 minutes d’écart. Même hôte, deux hôtels de plus.
Je voulais ensuite savoir si un lien personnalisé pouvait changer de domaine en cours de route. Deux fiches URLscan montrent ce scénario avec deux liens différents. Tous deux partent de reserv-advanced670647[.]com. Le premier aboutit sur reserv-advanced63647[.]com, qui usurpe le Coral Teide Mar (en espagnol, à 319,25 EUR) ; et le second finit sur reserv-advanced84632[.]com, avec The Gate Hotel Pyramids (en anglais, à 341,98 USD). Dans les résultats, URLscan appelle le domaine de départ task.domain et le domaine affiché à la fin page.domain. La différence entre les deux établit ici le rôle de relais du premier domaine vers deux pages d’hôtel.
Deux scans de la simple page d’accueil de reserv-advanced670647[.]com renvoient un 404. Les deux liens avec leurs identifiants personnalisés, eux, aboutissent sur d’autres domaines. URLscan conserve le domaine demandé au départ et celui de la page finale, sans établir ici le mécanisme exact de la redirection.
Une autre capture du 18 septembre montre une autre façon de pousser le visiteur à continuer. Sur reserv-advanced153528[.]com, la page affiche une fenêtre qui prétend qu’un paiement a été refusé par la banque, demande d’autoriser « PayZy(Magneta Pay) », puis de réessayer. Toujours sur un domaine du groupe « reserv-advanced » et toujours enregistré chez NiceNIC.
J’ai trouvé d’autres archives qui montrent encore Olive Hotel Kundalahalli en Inde et Sicily Luxury Suites en Italie, sur deux autres domaines du motif.
Le même décor sous d’autres noms
J’ai donc pivoté dans URLscan sur l’empreinte SHA-256 de l’icône Booking récupérée sur ma page (reminders). Résultat au 27 septembre : 36 scans sur 26 domaines, dont treize ne suivent pas ce format, avec des noms pas du tout suspects (non). L’icône est un logo copié, ce n’est pas une signature d’auteur, mais bon, on connaît nos fainéants d’attaquants.
Le tri par chemins rattache aussi au même phishing kit : 27 scans de cet ensemble arrivent sur /verify/ ou /pay/ avec un identifiant de 12 caractères, comme mon lien. Néanmoins, neuf utilisent 32 caractères sur trois domaines en .co : même habillage mais identifiant différent. J’ai également cherché les termes hb, poll et popup dans les URLs de requêtes indexées par URLscan, parce que mon JavaScript appelle ces fonctions. Ce filtre retrouve 34 des 36 scans basés sur l’icône (mais aussi quelques pages sans rapport).
Sur trois domaines en .com, on trouve Bytra Boutique Hotel, Resort Mare Nostrum et Garbí Costa Luz. Les captures montrent le même indicateur visuel et le process en trois étapes, avec les hôtels et une langue qui changent. Le RDAP les donne tous chez NiceNIC, pour ne pas changer.
C’est ainsi qu’on peut élargir une piste au-delà d’un nom bien reconnaissable (en gardant les pages avec un identifiant à 32 caractères dans une branche « variante » à vérifier séparément).
Trois formulaires carte, même code
Après l’icône, j’ai cherché une trace moins répandue : les fiches URLscan des pages de paiement par carte de l’Hôtel Cofortel et de ONE Chumphon Hotel, sur reserv-advanced353890187[.]com, listent des requêtes spécifiques. Même si les identifiants de lien diffèrent, les étapes /guest/<identifiant>/popup et /pay/<identifiant>/tds-status rendent des réponses JSON de 30 et 83 octets avec, chaque fois, la même empreinte SHA-256 sur les deux domaines :
popup 14dbc9b4d2340636a75523fe7801160fd908914b39e1104ff089f624b3a99d57
tds-status 4953cb75731705d33a619df116b5e2a6d9156bdc960271fb820ba7d7b049ad84URLscan indexe le SHA-256 des réponses HTTP (je vous ai déjà dit à quel point j’aime URLScan ?). Au 27 septembre, les recherches sur la réponse popup et la réponse de statut renvoient exactement ces deux scans chacune. Je classe donc ces deux pages carte dans une même branche technique : elles utilisent très probablement le même service ou phishing kit pour cette étape. Les empreintes des réponses HTTP de présence et de chat, elles, se retrouvent massivement ailleurs et ne permettent pas ce regroupement.
J’ai ensuite comparé le formulaire carte du Resort Mare Nostrum, sur guest-checkin-verify[.]com, à ces deux pages. Il appelle les mêmes routes de paiement, présence, chat, fenêtre et statut. Surtout, les trois pages chargeaient depuis leur propre domaine /static/booking/new-card.svg : chaque ressource répondait en HTTP 200, au format SVG, avec la même empreinte SHA-256 selon URLscan.
Au 28 septembre, la recherche sur cette empreinte renvoie exactement ces trois scans, alors que le nom du fichier seul, trop commun, donne des milliers de résultats. L’empreinte, croisée aux routes et aux pages d’hôtel, renforce fortement l’hypothèse d’une base technique commune pour ces trois formulaires carte.
J’ai pu aller plus loin avec le code des pages. À partir de ces trois scans déjà publics, j’ai récupéré leur réponse HTML originale via l’API URLscan, puis vérifié que chaque fichier décompressé avait bien l’empreinte SHA-256 indiquée dans le scan. Avant de comparer les scripts, j’ai remplacé l’identifiant de douze caractères propre à chaque lien /pay/ par le même marqueur.
Résultat : mon HTML Birger Jarl et les pages carte Cofortel et Resort Mare Nostrum contiennent tous le même script de 6 719 caractères, qui suit les étapes du parcours. Cofortel et Resort partagent trois autres scripts complets ; leurs deux derniers ne diffèrent que d’un caractère chacun. Le code d’ONE Chumphon est une variante proche, que les deux réponses JSON et le fichier carte communs rapprochent aussi de Cofortel.
Le lien entre mon domaine reçu sur WhatsApp et d’autres, comme guest-checkin-verify[.]com, repose donc bien sur les scripts des pages elles-mêmes.
Des domaines déposés par grappes
Une fois ces pages repérées, j’ai listé mes 62 noms de domaine trouvés, tous chez NiceNIC, d’après le RDAP Verisign, avec des créations du 13 au 26 septembre. S’ajoutent sept nouveaux noms en .com découverts par l’icône et enregistrés chez le même registrar.
Le 13 septembre, dix domaines du motif sont créés en 82 secondes. Quatre ont ensuite livré des pages d’hôtel dans URLscan : Summerbird et Levi Nordic Star, ONE Chumphon Hotel, Balcón del Pirineo et 8 Rooms Madrid apparaissent dans les captures examinées.
Mon domaine ouvre un autre lot de cinq noms en 55 secondes le 25 septembre. Hors du motif, on trouve stayprova[.]com, reservault[.]com et hostvouch[.]com qui ont été enregistrés en 36 secondes le 12 septembre ; et gueststay-verify[.]com et guest-checkin-verify[.]com à 21 secondes d’écart le 17/09. C’est une bonne cadence d’approvisionnement.
Jusqu’où va le lien entre ces pages ?
J’ai vérifié une autre piste, celle des certificats. Sur les deux lots de dix et cinq domaines du motif, les premières réponses Cert Spotter contiennent 26 émissions avec 26 empreintes de clés publiques différentes. Les sept nouveaux .com donnent onze autres empreintes, également distinctes et sans correspondance avec les 26 premières. Dans cet échantillon, aucune clé réutilisée ne relie ces noms ; ce n’est pas surprenant avec Let’s Encrypt et Cloudflare devant, mais c’est un contrôle utile, donc je vous le mets pour rappel.
À noter qu’au 27 septembre, 44 des 62 domaines numériques portaient le statut RDAP client hold, dont douze des treize domaines avec une page HTTP 200 archivée. Ce statut, posé par le registrar, empêche la publication du nom dans le DNS.
Mon domaine n’était pas dans cet état ; le code 522 observé ensuite indique un autre problème de disponibilité, sans en donner la cause, probablement que les pages de phishing ne sont rendues disponibles que pendant une durée limitée (ou l’infra de l’attaquant n’est pas stable aussi). Hors du format de ma page, six des sept .com supplémentaires sont aussi en client hold. hostvouch[.]com résolvait encore, mais la requête a expiré depuis mon accès Mullvad quand je l’ai testé.
À ce stade, quelques liens reposent sur des preuves concrètes : mon domaine a servi deux hôtels et une page carte ; un autre domaine proche a conduit à deux hôtels sur deux hôtes finaux ; un script JavaScript relie mon HTML à la page carte Resort Mare Nostrum, hors du motif numérique. ONE Chumphon utilise une variante proche, avec deux réponses JSON et un fichier carte en commun avec le formulaire de Cofortel.
Ces pages montrent une même base de phishing-kit, déclinée sur plusieurs hôtels et deux familles de domaines. Les noms vus seulement au registre restent des candidats probables. Mais ces éléments ne me donnent toujours ni le compte qui les déploie, ni le nom du Threat Actor (TA) derrière.
Et derrière les domaines ?
Les commentaires russes sont un indice sur l’origine ou la circulation du kit, pas une nationalité démontrée non plus, mais bon… NiceNIC est un registrar accrédité établi à Hong Kong… dont les chiffres d’abus sont élevés : Interisle y recense 272 696 domaines signalés pour phishing de mai 2025 à avril 2026, dont 235 255 jugés enregistrés volontairement pour frauder… Tout en se défendant d’être un registrar « Bulletproof », une simple recherche de registrar bulletproof vous listera NiceNIC (parmi beaucoup trop d’autres…). Sa présence dans nos lots en fait un bon pivot de veille, mais toujours sans identification du TA.
J’ai aussi essayé le RDAP de NiceNIC : le titulaire est masqué. Les coordonnées visibles sont même identiques à celles affichées pour nicenic.com. Une vraie fausse bonne piste pour retrouver le compte qui a enregistré ces domaines.
Ce mode opératoire décrit dans ce post rejoint les enquêtes de Bridewell et de Sekoia : informations de séjour détournées, sollicitation du voyageur sur WhatsApp et faux paiement. Leurs travaux éclairent la chaîne qui va de l’hôtel au voyageur.
Même si je n’ai pas de signature reliant directement leurs groupes nommés à mes pages, on est a minima sur des TTP proches. Bridewell suit BR-UNC-030 pour un kit visant les partenaires hôteliers. Les liens clients qu’il publie comptent notamment huit caractères et ses domaines étudiés sont chez Dynadot ; mon premier lien en compte douze et son domaine est chez NiceNIC. Je garde donc leurs IOC comme point de comparaison, sans reprendre leur nom de groupe.
Les domaines à surveiller
Arrêté au 27 septembre, le premier jeu d’IOC comprend 62 noms de domaine au motif reserv-advanced[0-9]+\.com, issus de 118 scans URLscan : 17 pages répondaient en HTTP 200, 86 avec un 404, 12 en 522 et 3 en 403. Parmi les 17 pages en 200, quinze finissent sur /verify/<identifiant> et deux sur /pay/<identifiant>. Un nom dans cette liste n’est donc pas automatiquement une page active confirmée, mais je considère qu’on est sur la piste de notre bad guy. S’il apparaît dans vos journaux DNS ou proxy, vérifiez qui l’a consulté, quand et avec quel résultat :
reserv-advanced1337228.com
reserv-advanced134886.com
reserv-advanced1457929.com
reserv-advanced153528.com
reserv-advanced1544928.com
reserv-advanced1557929.com
reserv-advanced157928.com
reserv-advanced158768.com
reserv-advanced1599766.com
reserv-advanced16528.com
reserv-advanced1667929.com
reserv-advanced1668929.com
reserv-advanced1669929.com
reserv-advanced2038768.com
reserv-advanced2281337.com
reserv-advanced2281488.com
reserv-advanced2284632.com
reserv-advanced2289768.com
reserv-advanced2292632.com
reserv-advanced2297623.com
reserv-advanced34890177.com
reserv-advanced3537477.com
reserv-advanced35385177.com
reserv-advanced353890177.com
reserv-advanced353890187.com
reserv-advanced353890677.com
reserv-advanced35389177.com
reserv-advanced3690177.com
reserv-advanced4749307.com
reserv-advanced555445.com
reserv-advanced565435.com
reserv-advanced573445.com
reserv-advanced5745307.com
reserv-advanced5749307.com
reserv-advanced5749314.com
reserv-advanced577886.com
reserv-advanced633647.com
reserv-advanced634647.com
reserv-advanced63647.com
reserv-advanced65237.com
reserv-advanced653890177.com
reserv-advanced664647.com
reserv-advanced670647.com
reserv-advanced670657.com
reserv-advanced67557.com
reserv-advanced6890177.com
reserv-advanced791029.com
reserv-advanced8438632.com
reserv-advanced84632.com
reserv-advanced8463992.com
reserv-advanced866438632.com
reserv-advanced8669307.com
reserv-advanced8746432.com
reserv-advanced8749307.com
reserv-advanced8993307.com
reserv-advanced94646332.com
reserv-advanced9499632.com
reserv-advanced967445.com
reserv-advanced9676442.com
reserv-advanced968277.com
reserv-advanced9846442.com
reserv-advanced994632.comLe pivot par l’icône ajoute treize noms hors du motif numérique. Sept .com indiquent NiceNIC dans le RDAP.
advanced-monitoring9378.co
advanced-reserv349209.com
fetch-status.com
guest-checkin-verify.com
gueststay-verify.com
hostvouch.com
hotel-stay-8873.co
hotel-today-1284.co
monitoring-reserv1829.co
myreserv-1823.co
reservault.com
stayprova.com
verifed-status-update.coChers amis des forces de l’ordre, ou juste le CERT chez Meta : c’est cadeau, vous avez du taf !
Repérer un domaine avant que sa page de phishing ne soit disponible
Le 28 septembre au matin, les trois derniers scans URLscan du motif reserv-advanced, datés de la veille, répondaient en 522. Pourtant, la recherche dans les certificats a fait ressortir un petit nouveau reserv-advanced133786[.]com, absent de ma première liste de 62 noms et sans scan URLscan public à cette heure. Le registre datait sa création du 26 septembre à 13 h 39 UTC. Sa racine HTTPS ne m’a pas répondu. Le certificat me donnait donc un nom à surveiller, pas encore un hôtel à prévenir : il fallait attendre une capture de la page et vérifier son contenu.
J’ai ensuite trouvé une trace de ce candidat dans OTX : une URL au format /verify/<12 caractères>, datée du 27 septembre par cet index, avec une réponse 522. Elle reprend la structure du lien que j’ai reçu, mais ne montre ni hôtel ni formulaire ; l’index ne dit pas non plus qui a soumis l’adresse. C’est un cran au-dessus du simple certificat, encore insuffisant pour parler d’une nouvelle victime ou d’une page active.
Peut-on retrouver une URL exploitable dès qu’on connaît son domaine ? J’ai vérifié les chemins dans mon HTML et dans trois pages carte archivées. Chaque page réutilise son identifiant de 12 caractères dans /pay/, /hb/, /chat/ et /guest/ ; il est déjà inscrit dans le HTML. Je peux donc reconnaître la forme des routes, mais pas calculer un lien valide à partir du domaine. Pour en retrouver un sans ouvrir de lien personnel, je consulte les URL déjà indexées par URLscan ou OTX, puis la capture et le code conservés.
Mais pour savoir quels voyageurs ont effectivement reçu un message, la capture publique ne suffit pas.
30 septembre : une relance et une nouvelle série de pages
Je m’apprêtais à publier cet article et voilà que je reçois un troisième WhatsApp…
Le nom affiché change. Cette fois, j’ai : « Mapfre Perú CNT ». Le message reprend la même fausse référence et les mêmes dates de séjour. Il promet qu’aucun montant ne sera débité, tout en me laissant 24 heures pour « confirmer » avec un numéro péruvien affiché pour un voyage en Suède…
Le lien change aussi : rtolk-aszjv21[.]com est suivi de deux lettres et six chiffres, sans le /verify/ de mon premier message. Bridewell décrit également des chemins de huit caractères. Le registre .com date ce domaine du 29 septembre à 13 h 22 UTC. Au 30 septembre, la seule capture publique que j’ai trouvée montre une erreur 404 sur la racine. Je n’ai pas ouvert mon nouveau lien personnel.
En repivotant sur ces nouvelles informations, mon relevé du 30 septembre fait apparaître 26 noms supplémentaires au motif reserv-advanced par rapport à la veille. Le RDAP en place 25 chez NiceNIC ; le dernier reprend seulement le motif, chez un autre registrar. Trois scans du même jour montrent de faux formulaires aux noms d’hôtels : fav Hida Takayama, HOTEL LiVEMAX Tokyo Shintomicho et First Cabin Shinbashi Atagoyama, tous au Japon. Un pivot notable : le fichier /include/handler.js tape à chaque fois le même SHA-256 : 8d53c01dc39167d563277c26624f494158d5c24df2a62dedb2357518fe9608b0. Il gère notamment les échanges du formulaire et du chat avec des routes sous le domaine visité.
Au 30 septembre, cette recherche URLscan par empreinte retrouve 146 scans publics, datés du 24 au 30, sur 13 domaines. Dix ne suivent même pas le motif reserv-advanced ; j’ai également retrouvé handler.js et lang.js à l’identique sur gardenstokyjp[.]com. Ces dix noms et les huit nouveaux noms numériques voisins partagent la paire de serveurs DNS Cloudflare RAZVAN/WANDA, malgré des registrars différents. Le code identique est une liaison technique bien plus nette que la ressemblance des noms. C’est une autre branche de code que celle de ma première page.
Dernier piège pour la veille : cinq autres noms du groupe reserv-advanced677... répondaient bien en HTTP 200, mais affichaient seulement « The website is no longer available ».
Suivre les pages sans deviner les liens
Bon, TL;DR : je peux repérer de nouveaux domaines et rapprocher des pages déjà archivées sur URLscan et compagnie ; je ne peux pas deviner le lien personnalisé des victimes. Je pars des certificats, puis je vérifie le registre, les captures et les scripts. Les liens entre domaines, scripts et hôtels comptent autant que les IOC eux-mêmes ; j’en parlais déjà dans mon billet sur OpenCTI. Voici les contrôles qui m’ont vraiment servi :
- Registre et certificats : cette recherche Certgrep prête à l’emploi cherche les nouveaux noms du motif
^reserv-advanced[0-9]+\.com$. Comparer chaque résultat au registre RDAP et aux certificats du domaine exact. Pour une veille continue, le même filtre peut s’appliquer à un flux CT. Il ne couvre pashostvouch.comni les variantes ; et Certgrep n’affiche qu’une partie des résultats sans compte. - Captures : dans URLscan, chercher le motif de domaine, puis l’empreinte
hash:060923d7318953e2e23f5974e4f9bb95c525d96bea583a581e63631e903fda5b. Cette image peut être réutilisée par plusieurs modèles : confirmer sur la capture, le domaine final et la forme du chemin. Noter l’UUID et l’heure, jamais le jeton ni les paramètres. - Relais entre domaines : ouvrir la fiche d’un scan URLscan et comparer l’hôte demandé au départ (
task.domain) avec celui de la page finale (page.domain). Deux liens distincts soumis surreserv-advanced670647[.]comont fini surreserv-advanced63647[.]cometreserv-advanced84632[.]com. Ces deux arrivées, avec leurs captures d’hôtels, montrent comment un domaine d’entrée peut distribuer plusieurs destinations. - Deuxième index : si URLscan ne connaît pas un domaine, regarder ses URL dans OTX.
- Étape carte : cette recherche URLscan prête à l’emploi a retrouvé les trois pages Cofortel, ONE Chumphon et Resort Mare Nostrum dans l’archive du dernier mois. Elle cherche des noms de ressources : ouvrez chaque fiche et contrôlez les routes et l’hôtel affiché.
- Nouveau script : la recherche de l’empreinte de
/include/handler.jsretrouve les treize hôtes du second lot, même hors du motif numérique. - Code et réponses : pour un nouvel UUID déjà public, l’API URLscan authentifiée peut fournir le HTML original. Vérifier son SHA-256, masquer l’identifiant du lien et comparer les scripts : celui de 6 719 caractères commun à mon HTML, Cofortel et Resort Mare Nostrum donne, après ce masquage,
098bf910cd785e90a690898fd7455f860a4fb68bd282c52198d57ee94b79f5eb. Rechercher aussi les deux empreintes de réponse et celle denew-card.svgdans URLscan. La capture, le domaine et les routes restent à vérifier avant de classer la page.
Voilà, j’espère que ça aidera les copains chez Booking ou Mews à chopper ce TA.
En conclusion : quelques rappels, juste au cas où…
Le piège fonctionne justement parce qu’une partie du message est vraie. Quand un paiement ou une validation bancaire surgit dans une conversation WhatsApp liée à un séjour, voici les réflexes qui évitent de laisser l’urgence décider à votre place :
- Ouvrez vous-même l’application de réservation ou le site officiel de l’hôtel. Vérifiez l’état du paiement et contactez l’établissement au numéro indiqué là, pas à celui du message.
- Comparez le numéro de réservation et la somme demandée avec vos documents d’origine. Dans mon cas, cette comparaison a révélé une fausse référence et des 300 € sans rapport avec la réservation déjà payée.
- Ne fournissez ni carte, ni code SMS, ni validation bancaire, ni photo d’identité depuis une page atteinte par le lien. Un cadenas HTTPS protège la transmission d’informations ; il ne garantit pas (plus ?) l’honnêteté du destinataire.
- Si vous avez seulement ouvert la page, vérifiez les permissions de notification du navigateur et conservez le message. Si vous avez saisi une carte ou approuvé une opération, contactez immédiatement votre banque par son canal habituel. Cybermalveillance.gouv.fr détaille les démarches à suivre après un hameçonnage bancaire.
Ce qui me reste en tête, c’est le WhatsApp avec mes vraies dates pour une chambre déjà payée. Les captures et le code m’ont permis de relier des formulaires sur plusieurs domaines et de retrouver d’autres hôtels imités. Ils ne me donnent pas la prochaine victime ni la liste des voyageurs contactés. Pour savoir qui a été contacté, il faudra aussi les signalements des voyageurs et les données dont disposent les hôtels ou Booking.
Moi, je garde mes références hors des IOC publics pour aider la commu. Bref, Geekez bien, mais geekez safe !
