Note importante : cette information circule et aurait été remontée aux autorités compétentes (CERT-FR). À ce stade BPCE n’a pas validé la compromission. L’analyse ci-dessous décrit un scénario crédible : une injection dans le formulaire d’authentification. Traitez l’alerte avec prudence mais considérez la possibilité d’un risque réel.
Source de l’alerte X
Mise à jour 18/10/2025 – 17h00

Update sur la BPCE : vous pouvez reprendre une activité normale Le trafic est « légitime » mais provient d’un truc qui n’aurait jamais du arriver là. Le trafic n’est pas normal mais ne conduit pas à une faille. Pas de compromission.
Mais quelque chose qui n'aurait jamais du se retrouver en prod...
Le domaine mis en cause n'est plus ...

OK, alerte levée — pas de compromission. Cool.
Quand on cumule un script obscur qui envoie des données vers un serveur AWS, un CNAME orphelin, et un suivi d’audience en cloud public… on n’est plus dans la maîtrise, on est dans la chance et on obtient un entonnoir à "lanceur d'alerte". 🎯
Et côté RGPD, faire transiter des données (même pseudonymisées) via une infra tierce non contractualisée ou hors EEE, c’est tout sauf anodin.
Pas de DPA clair ? Pas d’évaluation d’impact ? Pas d’info aux utilisateurs ? ➜ On coche déjà plusieurs cases d’incident de conformité.
Bref, pas de compromission technique, mais clairement un bon sujet de gouvernance et d’hygiène numérique. 😏

🚨 Update — BPCE : CNAME cloaking -> phishing sur domaine légitime.

Les enregistrements DNS d’un flux d’audience (hébergé chez AWS) sont restés actifs ; des VMs AWS répondent désormais avec des pages de phishing — certs ACME obtenus. INFO pas encore confirmée par BPCE. CERT-FR serait informé.

Prudence quand même : Ne vous connectez pas aux pages suspectes.

🔍 Contexte & hypothèse technique

Des signalements indiquent que certaines pages de connexion liées aux services en ligne du groupe BPCE pourraient afficher des contenus ou redirections malveillantes au moment de l’authentification. Le vecteur suspecté : injection côté formulaire d’authentification — autrement dit, un acteur malveillant exploiterait une vulnérabilité dans la page de login (injection HTML/JS, XSS stocké ou réfléchi, ou un formulaire manipulé côté serveur) pour intercepter les identifiants, afficher une fausse page de validation, ou rediriger la victime vers un collecteur d’identifiants.

Techniquement, ceci peut prendre plusieurs formes pratiques :

injection JavaScript (XSS) dans la page de login qui capture les champs et envoie les données à un serveur externe ;
remplacement / inclusion de scripts tiers compromis (cdnjs ou CDN détourné) ;
injection HTML via paramètres non filtrés (par ex. paramètres GET utilisés pour personnaliser la page) ;
compromission du dépôt web / déploiement permettant de modifier les templates de la page d’authentification.

🛠️ Impacts potentiels

Si la faille existe et est exploitée, les conséquences peuvent être lourdes :

Vol massif d’identifiants (login/mot de passe) pour des comptes bancaires ;
Usurpation de session si des tokens ou cookies sont exposés ;
Phishing ciblé (credential stuffing, social engineering) via données collectées ;
Perte de confiance client et retombées réglementaires (CNIL) si des données personnelles ou financières sont exfiltrées ;
Risques de fraude bancaire directs : virements, virements instantanés, services sensibles accessibles.

✅ Conclusion — prudence et transparence

L’hypothèse d’une injection dans le formulaire d’authentification est crédible techniquement et, si avérée, très critique. BPCE n’a pas encore confirmé; il est donc indispensable de rester factuel et prudent dans la diffusion publique. Pour les équipes techniques : priorisez la containment, la collecte forensique et la coordination CERT. Pour les utilisateurs : ne vous connectez pas via les pages suspectes et privilégiez les canaux officiels.

🛠️ Le scénario plausible :

➡️ BPCE utilisait un CNAME (ex : statxxxx.caisse-epargne.fr) pour suivre l’audience via une infra AWS.
➡️ Ces machines ont été décommissionnées, mais le DNS est resté.
➡️ Des attaquants ont juste relancé des VMs AWS jusqu’à tomber sur les IP réutilisées par ce vieux CNAME.

Résultat : le domaine officiel pointe désormais vers… des serveurs malveillants 😬

Et là, le coup de génie :
Les attaquants contrôlant le serveur HTTP, ils ont pu obtenir un certificat TLS valide via Let’s Encrypt ou un ACME-like.
👉 HTTPS vert, cadenas OK, domaine caisse-epargne.fr affiché.
Aucune alerte visible côté utilisateur.
Le phishing parfait.

Ça s’appelle du CNAME cloaking : on délègue un sous-domaine vers un prestataire (souvent pour analytics, CDN, ou tracking).
Sauf qu’ici, quand le prestataire supprime l’infra, le CNAME reste vivant.
Et dans le cloud public, les IP sont réattribuées.
Les attaquants ont juste attendu leur tour.

Ce genre de faille est rarement détectée :

les DNS TTL longs cachent les changements,
les flux “statistiques” passent sous le radar des SOC,
le certificat TLS valide renforce la confiance,
les utilisateurs n’ont aucun signe visible.

D’après l’alerte, le trafic “malware” observé sur le login BPCE serait en fait le flux d’audience résiduel qui continue à taper… sur un serveur phishing. 😅

En clair : le trafic légitime nourrit le maliciel.

➡️ BPCE n’a pas confirmé officiellement.
➡️ Les serveurs AWS compromis auraient été décommissionnés, mais le DNS reste actif.

Le problème est donc systémique, pas isolé :
tous les domaines utilisant des CNAME tiers sont concernés.

🎯 Leçons à retenir :

Supprimez les CNAME orphelins quand vous coupez un service.
Vérifiez vos DNS publics régulièrement (scan de sous-domaines).
Limitez les délégations externes (surtout pour analytics).
Surveillez les certificats récents émis pour vos domaines.

C’est un cas d’école :
🔸 pas de vulnérabilité de code,
🔸 pas de 0day,
🔸 juste une chaîne de négligences DNS + cloud exploitée avec méthode.
Les attaquants adorent ces angles morts.

Rappel pour tous :
➡️ Ne vous connectez pas via les pages web suspectes.
➡️ Préférez l’app mobile officielle.
➡️ Et si vous gérez un domaine : auditez vos DNS ce soir.

🎯 Bon j’en sais un peu plus :

Voici ce qui a donné l’alerte, du moins en partie, en tout cas ce qui paraît dangereux. Et, effectivement, c’est pas très propre
SI on regarde ce script JS :

script.txt Télécharger

Ce script est hautement suspect : c’est du JavaScript obfusqué conçu pour collecter et exfiltrer des données (tracking, voire injection malveillante).
Je fais le décryptage et l’analyse en clair 👇

🔍 1. Structure générale

Le script est encapsulé dans :

<script type="text/javascript">(function(){ ... })();

➡️ Typique des scripts de tracking dissimulés ou malwares injectés.
Tout le code est minifié et utilise des noms de variables aléatoires (bq, bF, bM, etc.) pour rendre la lecture humaine impossible.

🧩 2. Fonctions principales trouvées

a) `G`, `E`, `U`, `O`, `V`, `bv`

Ce sont des modules internes créés dans la fonction anonyme :

Module	Fonction	Détails
`G`	Parser JSON et sérialiseur personnalisé	Copie d’un parseur JSON complet, utilisé pour décoder des chaînes encodées
`O`	Base64 encodeur/décodeur	Permet de cacher du code ou des URLs
`bv`	SHA-256 implémentation maison	Sert à vérifier l’intégrité ou générer un identifiant de tracking unique
`E`	Communication inter-frame	Utilise `postMessage` pour communiquer avec une autre fenêtre (iframe)
`U`	Vérification de domaine	Vérifie si le script est autorisé sur certains domaines
`V`	Toolkit central	C’est là que tout se joue : redirections, envois XHR, gestion de window.name, etc.

🕵️‍♂️ 3. Ce que fait réellement le script

a) Il identifie le domaine parent

var bh = G._1("[\"ff16ecabd0...a93227\"]");

Ces chaînes sont des hachages SHA-256 de domaines autorisés.
Ça permet au script de valider s’il est injecté sur un site cible prévu.

b) Il récupère des paramètres d’URL

var X = bf(window.location.href, "#");

Extrait les fragments d’URL et notamment :

icid
sr
__tg
➡️ typique de tracking publicitaire ou d’injection depuis une iframe.

c) Il met en place une communication `postMessage` vers le parent

E._p({}, X.e, window.parent, E._i._B, bg)

C’est une exfiltration de données vers un domaine distant via postMessage.

d) Il envoie un XMLHttpRequest POST vers une URL externe

g.open("POST", k, true);
g.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");

Les données envoyées incluent :

L’URL d’origine (X.eu)
Des paramètres encodés (pd, qp, etc.)
Et potentiellement le contenu de window.name (souvent utilisé pour stocker des données inter-domaines)

L’URL cible est reconstruite à partir d’une chaîne encodée en Base64 :

aHR0cHM6Ly9zdGF0czAwbjRwM3IuY2Fpc3NlLWVwYXJnbmUuZnIvMjI0ODM3
→ https://stats00n4p3r.caisse-epargne.fr/224837

⚠️ Donc le script envoie des données vers un sous-domaine de caisse-epargne.fr hébergé chez AWS

ping stats00n4p3r.caisse-epargne.fr
PING prod-lb-7-718125029.eu-central-1.elb.amazonaws.com (18.192.74.120): 56 data bytes

Cela peut être légitime (tracking interne de la banque) ou une compromission de ce domaine.

⚠️ 4. Indices très suspects

Code extrêmement obfusqué et verbeux (des centaines de lignes inutiles) → classique pour dissimuler des actions malveillantes.
Appels réseau vers un domaine bancaire : stats00n4p3r.caisse-epargne.fr
Usage de window.name pour stocker et récupérer des données → souvent utilisé pour voler des informations de session entre sites.
Communication inter-frame (postMessage) → permet de faire passer des données depuis une iframe injectée dans une page d’un autre domaine.
Génération d’un SHA-256 local → souvent utilisée pour générer un identifiant de session unique ou vérifier une charge utile.

💣 5. Hypothèse réaliste

Ce script fait partie d’un outil de tracking bancaire ou d’un tag manager :

Il collecte des informations (URL, referrer, identifiant client)
Les envoie à un serveur distant via XHR
Peut potentiellement exécuter du code renvoyé par ce serveur

→ Risque : exfiltration de données ou injection cross-domain.

Pourquoi c’est un souci RGPD

Si des données à caractère personnel (identifiants, adresses IP, identifiants de sessions, cookies, etc.) transitent via des infrastructures tierces non maîtrisées, il y a un risque de transfert / traitement non autorisé.
Là où c’est critique : analytics + logs -> peuvent contenir des identifiants (userid, email encodé, token) ou permettre le retraçage d’un utilisateur.
Même si AWS est un sous-traitant réputé, il faut : contrat de sous-traitance clair, mentions dans la DP (registre des traitements), mesures techniques & organisationnelles, et évaluation d’impact si nécessaire.
En cas d’exfiltration avérée, obligation de notification (internes / CNIL / personnes concernées) selon l’ampleur et la nature des données.

⚠️ Mise à jour 18/10/2025 11h30

Une maintenance est prévu ce dimanche... " "parameterValue": "Pour des raisons de maintenance, l'accès à la banque à distance sera indisponible le 20/10/25 de 00h00 à 03h00. Veuillez nous excuser pour la gêne occasionnée.",

Bon, on laisse trois jours (ou plus) un truc pourri mais bon, faut passer par la case COMEX, alors on verra ça après le weekend

⚠️ Alerte sécurité — pages de connexion BPCE non compromise chez BPCE (Faux positif)

Partager cet article : Twitter LinkedIn WhatsApp

🖋️ Publié sur SecuSlice.com

Mise à jour 18/10/2025 – 17h00