🙋♂️Introduction
Cette semaine encore, l’actualité cybersécurité illustre l’évolution rapide des menaces, qui dépassent désormais largement le cadre traditionnel des systèmes informatiques d’entreprise. Ransomware, extorsion de données, attaques contre les prestataires et chaînes d’approvisionnement montrent que la surface d’attaque s’étend désormais à l’ensemble de l’écosystème numérique.
En France, plusieurs affaires retiennent particulièrement l’attention. LockBit 5.0 revendique de nouvelles victimes, dont Actua, avec la menace de publier des documents personnels concernant potentiellement plus de 100 000 personnes. La Protection Civile a quant à elle confirmé une cyberattaque ayant entraîné le vol de données issues de sa plateforme de gestion des bénévoles, avec potentiellement plus de 500 000 profils présents dans les données exfiltrées.
Cette semaine marque également une étape importante pour la réglementation européenne. Le Cyber Resilience Act approche de sa première échéance opérationnelle majeure : dès le 11 septembre 2026, les fabricants concernés devront notamment signaler certaines vulnérabilités activement exploitées et certains incidents graves.
À l’international, ShinyHunters menace Logitech et Streamlabs, tandis qu’une cyberattaque contre CEVA Logistics démontre comment la compromission d’un prestataire peut indirectement exposer les clients de grandes marques comme Pokémon Center.
Enfin, des chercheurs ont identifié une chaîne d’infection permettant de transformer certains systèmes multimédias Android automobiles en nœuds d’un botnet de proxies. Un exemple révélateur de l’élargissement de la surface d’attaque aux objets connectés et aux systèmes embarqués.
Entre extorsion, fuites de données, risques liés aux fournisseurs, réglementation et détournement d’équipements connectés, cette semaine confirme donc une tendance de fond : la cybersécurité devient une problématique systémique, où la sécurité d’une organisation dépend également de celle de son écosystème.
🗼Zoom France
1- LockBit 5.0 revendique une attaque contre Actua : plus de 100 000 personnes potentiellement concernées
Une nouvelle cible française pour LockBit 5.0
Le groupe de ransomware LockBit 5.0 revendique une cyberattaque contre Actua, groupe français spécialisé dans le recrutement et le travail temporaire.
L’organisation, fondée en 1991 et basée à Strasbourg, dispose d’un réseau de 37 agences et travaille avec plus de 1 800 entreprises partenaires. Son activité implique par nature le traitement d’un volume important de données personnelles liées aux candidats, intérimaires et salariés : CV, justificatifs administratifs, diplômes, pièces d’identité ou encore documents nécessaires à la constitution des dossiers de recrutement.
Le 16 août 2026, le domaine actua.fr est apparu sur le site de divulgation de LockBit 5.0. La présence de ce domaine est également enregistrée par RansomLook, qui référence l’inscription d’Actua parmi les victimes publiées par Lockbit5 à cette date.
Cette publication constitue toutefois une revendication du groupe cybercriminel et non une preuve indépendante de compromission.
À ce stade, aucun élément public ne permet de déterminer avec certitude comment les attaquants auraient pénétré dans les systèmes d’Actua, quelles données auraient effectivement été exfiltrées ou si l’ensemble des informations revendiquées provient réellement de l’entreprise.
Plus de 100 000 personnes potentiellement concernées
La revendication est particulièrement préoccupante par la nature et le volume des données évoqués.
LockBit 5.0 affirme détenir des documents concernant plus de 100 000 personnes. Parmi les catégories de documents citées figurent notamment :
- des passeports
- des CV
- des diplômes
- des attestations d’assurance
- des documents administratifs liés aux personnes recrutées
La présence de pièces d’identité parmi les données potentiellement dérobées constitue évidemment un élément particulièrement sensible.
Contrairement à une simple fuite d’adresses électroniques ou de coordonnées professionnelles, des documents tels que des passeports ou des justificatifs administratifs peuvent contenir plusieurs informations permettant de caractériser ou d’usurper l’identité d’une personne.
Il convient cependant de conserver une distinction essentielle entre données revendiquées et données dont la fuite est effectivement démontrée.
Le chiffre de 100 000 personnes correspond à la revendication associée à l’attaque. Il ne doit donc pas être présenté comme un nombre définitif de victimes tant que l’existence et le contenu de la fuite n’ont pas été vérifiés.
Un risque particulièrement important dans le secteur du recrutement
Le cas d’Actua illustre parfaitement pourquoi les entreprises de recrutement constituent des cibles particulièrement intéressantes pour les groupes d’extorsion.
Une entreprise d’intérim ne traite pas uniquement les informations nécessaires à la gestion de ses propres salariés. Elle collecte également de nombreux documents auprès de candidats et de travailleurs afin de permettre leur recrutement et leur affectation chez des entreprises clientes.
Un dossier peut ainsi contenir une combinaison particulièrement riche d’informations comme identité, coordonnées, parcours professionnel, justificatifs et documents administratifs.
Pour un cybercriminel, cette concentration de données peut présenter une valeur supérieure à celle d’une base contenant uniquement des identifiants ou des adresses électroniques.
Elle peut également alimenter différentes formes de fraude : usurpation d’identité, phishing extrêmement ciblé, fraude documentaire ou escroqueries utilisant les informations professionnelles de la victime.
C’est donc moins le nombre brut de personnes annoncé qui constitue le principal sujet d’inquiétude que la nature des documents potentiellement concernés.
Une revendication qui reste à vérifier
Plusieurs éléments doivent inciter à la prudence.
La page publiée par LockBit 5.0 établit que le groupe revendique Actua comme victime. Des sources indépendantes de surveillance des sites de fuite confirment que actua.fr figure bien parmi les publications de Lockbit5 du 16 août.
Mais cela ne permet pas de répondre aux questions essentielles :
- les systèmes d’Actua ont-ils réellement été compromis ?
- les attaquants ont-ils obtenu un accès aux données internes ?
- les données ont-elles réellement été exfiltrées ?
- les passeports et autres documents mentionnés proviennent-ils bien d’Actua ?
- combien de personnes sont réellement concernées ?
- quelle quantité de données a été dérobée ?
- les données ont-elles été obtenues lors de cette attaque ou proviennent-elles d’une autre source ?
Ces interrogations sont importantes car les sites de fuite des groupes de ransomware sont avant tout des outils d’extorsion et de pression.
Une inscription sur un tel site constitue un signal de sécurité sérieux qui justifie une investigation, mais elle ne suffit pas à elle seule à établir la réalité et l’étendue d’une intrusion.
Des services de veille qui ont suivi spécifiquement l’inscription d’Actua la qualifient d’ailleurs explicitement de revendication non vérifiée, sans confirmation publique d’une compromission par l’entreprise à ce stade.
Le compte à rebours comme outil de pression
La mécanique employée par LockBit 5.0 s’inscrit dans le fonctionnement classique des opérations modernes d’extorsion.
Après avoir ajouté une organisation à son site de fuite, le groupe peut afficher un compte à rebours destiné à faire pression sur la victime.
L’objectif est double :
- pousser l’entreprise à entrer en négociation avec les attaquants
- créer une menace publique crédible de divulgation des données
Cette stratégie transforme le site de fuite en véritable outil de communication.
Les cybercriminels ne cherchent plus seulement à chiffrer les fichiers d’une victime. Ils cherchent également à exploiter la peur de la publication, la réputation de l’entreprise et les conséquences potentielles pour ses clients, salariés et partenaires.
Dans le cas d’une société de recrutement, cette pression peut être particulièrement importante : la publication de documents personnels concernant des candidats pourrait provoquer des conséquences importantes pour les personnes concernées et générer une forte pression médiatique et réglementaire.
LockBit 5.0 est-il réellement de retour ?
L’attaque revendiquée contre Actua s’inscrit dans la reprise d’activité de l’écosystème LockBit après le démantèlement de son infrastructure historique lors de l’opération Cronos.
Le LockBit historique avait subi un coup majeur en février 2024 lorsque les autorités internationales avaient saisi une partie de son infrastructure.
Pour autant, la disparition du groupe original n’a pas signifié la disparition du modèle économique.
Une nouvelle génération identifiée sous le nom LockBit 5.0 a émergé en 2025 et s’appuie de nouveau sur un modèle de Ransomware-as-a-Service (RaaS), dans lequel les opérateurs fournissent l’infrastructure et le malware tandis que des affiliés réalisent les intrusions.
Les analyses de Check Point montrent d’ailleurs une remontée importante de l’activité attribuée à LockBit au premier trimestre 2026 : 163 victimes ont été publiées durant cette période, soit une hausse de 106 % par rapport au trimestre précédent. LockBit est ainsi remonté à la quatrième place des groupes de ransomware les plus actifs sur la période étudiée.
Cette évolution montre que les opérations judiciaires contre l’ancien LockBit n’ont pas suffi à faire disparaître durablement la marque ou son modèle économique.
Un ransomware désormais multiplateforme
LockBit 5.0 ne se contente par ailleurs pas de reprendre le modèle économique de ses prédécesseurs.
La nouvelle génération du rançongiciel a été conçue pour cibler plusieurs environnements, notamment :
- Windows
- Linux
- VMware ESXi
- environnements de virtualisation
Cette capacité multiplateforme augmente considérablement la surface d’attaque potentielle d’une entreprise.
Les analyses techniques disponibles décrivent également plusieurs mécanismes destinés à compliquer la détection et l’analyse du malware : techniques d’anti-analyse, chiffrement optimisé, extensions de fichiers aléatoires et différentes méthodes destinées à réduire les traces laissées sur les systèmes compromis.
L’objectif est clair : réduire le temps nécessaire pour chiffrer ou exfiltrer les données tout en compliquant la réponse des équipes de sécurité.
Une activité qui s’accélère en France
La revendication visant Actua n’est pas un cas isolé.
Le même jour, LockBit 5.0 a fait apparaître plusieurs organisations sur son site de fuite. RansomLook répertorie notamment, le 16 août, Actua, Dupouy et Associés – Crowe Horwath, Galbusera, TECOSIM et Verbandsgemeinde Rhein-Nahe.
Dans le cas français, Dupouy et Associés – Crowe Horwath a également fait l’objet d’une revendication distincte de LockBit 5.0, là encore sans confirmation indépendante de la compromission ou de l’étendue des données.
Cette concentration de revendications montre que le nouveau LockBit cherche activement à reconstruire un portefeuille de victimes et à démontrer sa capacité opérationnelle.
Une stratégie qui rappelle le fonctionnement historique de LockBit
Cette logique est cohérente avec le fonctionnement historique du groupe.
LockBit s’est développé autour du modèle Ransomware-as-a-Service : les opérateurs développent le malware et les infrastructures tandis que des affiliés réalisent les attaques.
Le modèle permet de multiplier les opérations sans que les principaux développeurs aient nécessairement à conduire directement chaque intrusion.
Le CERT-FR décrivait déjà LockBit comme un RaaS et soulignait son importance dans les incidents de ransomware observés en France. Le groupe était alors le rançongiciel le plus fréquemment impliqué dans les incidents signalés à l’ANSSI en 2022.
Le retour de LockBit 5.0 montre donc davantage une reconstruction de l’écosystème qu’une simple évolution technique du malware.
Que risque-t-il de se passer si la fuite est confirmée ?
Si les affirmations de LockBit 5.0 sont confirmées, les conséquences pourraient être importantes.
La première concerne évidemment les personnes dont les documents auraient été dérobés.
La publication de passeports ou de documents équivalents pourrait faciliter :
- des tentatives d’usurpation d’identité
- des campagnes de phishing personnalisées
- des fraudes documentaires
- des escroqueries utilisant des informations professionnelles réelles
- des attaques ciblées contre les victimes ou leurs employeurs
La deuxième conséquence concerne Actua elle-même.
Une entreprise spécialisée dans le recrutement doit pouvoir démontrer qu’elle maîtrise correctement les données qui lui sont confiées. Une fuite massive pourrait donc avoir des conséquences juridiques, réglementaires, commerciales et réputationnelles.
Enfin, les entreprises clientes d’Actua pourraient elles aussi être concernées indirectement si les informations dérobées permettent d’identifier des salariés, des missions ou des relations commerciales.
Les utilisateurs doivent-ils changer leurs mots de passe ?
Il est encore trop tôt pour demander à toutes les personnes ayant été en contact avec Actua de considérer leurs données comme définitivement compromises.
En revanche, dans le cas où une personne dispose d’un compte en ligne associé à Actua, il est raisonnable de prendre des précautions :
- modifier le mot de passe concerné
- utiliser un mot de passe unique
- modifier immédiatement tout mot de passe réutilisé sur un autre service
- activer l’authentification multifacteur lorsque celle-ci est disponible
- rester particulièrement attentif aux campagnes de phishing
La vigilance concernant le phishing est probablement l’une des mesures les plus importantes.
Si une fuite contenant réellement des CV, passeports et documents administratifs était publiée, les attaquants disposeraient potentiellement d’informations permettant de construire des messages extrêmement crédibles.
Un courriel contenant le nom de l’entreprise, le métier recherché, une ancienne candidature ou un document administratif réel peut être beaucoup plus convaincant qu’un phishing générique.
Un risque supplémentaire : les fausses alertes
L’affaire montre également un autre danger.
Dès qu’une cyberattaque devient publique, les cybercriminels opportunistes peuvent exploiter l’événement pour lancer de nouvelles campagnes.
Des victimes peuvent ainsi recevoir de faux messages prétendant provenir d’Actua, d’un service informatique, d’une administration ou même d’un cabinet chargé de gérer l’incident.
Le message peut par exemple demander de :
- confirmer son identité
- télécharger un document
- modifier son mot de passe
- fournir une pièce d’identité
- communiquer un code reçu par SMS
- contacter un numéro présenté comme celui du support
Une cyberattaque médiatisée devient donc parfois le prétexte d’une deuxième vague d’attaques.
Une affaire à surveiller dans les prochains jours
La revendication du 16 août constitue surtout le début d’une période de surveillance.
La question centrale est désormais de savoir si LockBit 5.0 publiera effectivement les données annoncées.
Une publication accompagnée de documents authentifiables permettrait de confirmer au moins partiellement la compromission. À l’inverse, une disparition de la revendication ou l’expiration du délai sans publication ne permettrait pas automatiquement de conclure à un faux : les négociations peuvent se poursuivre hors de la visibilité publique du site de fuite.
Il faudra donc surveiller plusieurs indicateurs :
- éventuelle publication de fichiers par LockBit
- communication officielle d’Actua
- notification éventuelle des personnes concernées
- intervention d’une autorité ou d’un prestataire spécialisé
- apparition de données attribuables à Actua sur d’autres plateformes
- modification ou disparition de la fiche LockBit
En bref
L’affaire Actua illustre une nouvelle fois la puissance du modèle d’extorsion des groupes de ransomware.
LockBit 5.0 revendique une attaque contre une entreprise française de recrutement et affirme détenir des documents concernant plus de 100 000 personnes. Les données citées sont particulièrement sensibles, puisqu’elles comprendraient notamment des passeports, CV, diplômes et attestations d’assurance.
Mais une précaution journalistique est indispensable : ces informations sont, à ce stade, des données revendiquées par les attaquants.
La présence d’Actua sur le site de fuite de LockBit 5.0 est bien corroborée par des services indépendants de suivi des ransomwares, mais cela ne suffit pas à démontrer que l’ensemble des données annoncées existe réellement ou qu’elles proviennent toutes d’une compromission récente d’Actua.
Cette affaire constitue néanmoins un signal important.
Elle montre que LockBit 5.0 poursuit sa reconstruction après le démantèlement de l’ancien groupe, que son activité connaît une nouvelle accélération en 2026 et que les organisations françaises restent clairement dans le viseur des opérateurs de ransomware.
Pour les personnes potentiellement concernées, la priorité est donc de rester vigilantes sans céder à la panique : changer les mots de passe réutilisés, activer la MFA, surveiller les communications suspectes et attendre une éventuelle confirmation officielle avant de considérer comme avérées les données annoncées par LockBit.
(sources : zataz.com, frenchbreaches.com, ransomlook.io, research.checkpoint.com)
2- La Protection Civile victime d’une cyberattaque : des centaines de milliers de profils potentiellement exposés
Une cyberattaque révélée plusieurs mois après les faits
La Fédération nationale de Protection Civile (FNPC) a confirmé le 21 août 2026 avoir été victime d’une cyberattaque ayant entraîné le vol de données personnelles.
L’attaque aurait été menée au mois de mars 2026, mais sa découverte n’est intervenue que plusieurs mois plus tard, le 17 août. La confirmation publique est intervenue après la publication d’informations faisant état d’une importante extraction de données provenant de la plateforme eProtec, utilisée par la Protection Civile pour gérer une partie de ses activités liées aux bénévoles.
L’incident est particulièrement sensible en raison de la nature de l’organisation concernée. La Protection Civile repose sur un vaste réseau de bénévoles intervenant notamment dans les secours, l’assistance aux populations, les dispositifs prévisionnels de secours et les opérations humanitaires.
Une compromission de ses outils internes expose donc potentiellement des informations permettant d’identifier une partie de ses membres et de comprendre l’organisation de ses équipes.
La FNPC a toutefois précisé que les données des personnes secourues ne sont pas concernées par cette fuite, le périmètre identifié étant celui de la plateforme de gestion des bénévoles.
eProtec au cœur de l’incident
La plateforme compromise est eProtec, un outil utilisé par la Protection Civile pour gérer différents aspects de son organisation.
Elle sert notamment à la gestion des bénévoles, des plannings et des formations.
Ce type de plateforme centralise naturellement une quantité importante d’informations personnelles et organisationnelles.
La compromission d’un tel système peut donc présenter un double intérêt pour un attaquant :
- récupérer des données personnelles exploitables
- obtenir une vision de l’organisation interne de l’association
Dans le cas présent, les informations publiquement communiquées font état notamment de données d’état civil, de numéros de téléphone et de photographies de profil.
Des informations concernant des personnes mineures, notamment des jeunes inscrits comme « cadets », seraient également présentes dans les données concernées.
Cette dernière catégorie est particulièrement sensible puisqu’elle concerne des personnes bénéficiant d’une protection renforcée en matière de données personnelles.
Quelles informations ont été dérobées ?
La FNPC indique que les données susceptibles d’avoir été concernées comprennent notamment :
- noms et informations d’état civil
- dates de naissance
- numéros de téléphone
- photographies de profil
- informations relatives aux bénévoles
- données concernant certains mineurs
La présence de photographies ajoute une dimension supplémentaire à l’incident.
Une base combinant identité + date de naissance + numéro de téléphone + photographie peut être particulièrement intéressante pour des opérations d’ingénierie sociale.
Les attaquants pourraient notamment utiliser ces informations pour construire des scénarios de phishing beaucoup plus crédibles qu’une campagne générique.
À ce stade, les informations disponibles ne signalent en revanche pas de compromission des mots de passe ou des coordonnées bancaires. La FNPC a également indiqué que les personnes secourues n’étaient pas concernées par l’incident.
Le chiffre de 525 000 profils fait débat
L’un des éléments les plus spectaculaires de cette affaire concerne le volume de données potentiellement exfiltrées.
Les informations publiées autour de la fuite font état de plus de 525 000 profils présents dans les données récupérées, cependant ce chiffre doit être interprété avec prudence puisque la Protection Civile ne confirme pas que 525 000 personnes distinctes sont concernées.
L’association indique notamment que les fichiers comporteraient de nombreux doublons. Un même individu peut apparaître plusieurs fois dans une base informatique pour différentes raisons :
- changement d’antenne
- changement de statut
- réinscription
- changement de coordonnées
- migration d’une ancienne base
- comptes historiques
- erreurs ou doublons administratifs
Un fichier contenant 525 000 lignes ne signifie donc pas nécessairement que 525 000 personnes uniques ont été victimes.
La FNPC poursuit justement ses investigations afin de déterminer le nombre réel de personnes concernées.
Pourquoi un volume aussi important alors que la Protection Civile compte beaucoup moins de bénévoles ?
Cette question est importante pour comprendre la controverse autour des chiffres.
La Protection Civile compte environ 32 000 bénévoles actifs.
Un fichier comportant plusieurs centaines de milliers de profils ne peut donc pas être interprété simplement comme une photographie du nombre actuel de bénévoles.
Les données pourraient notamment inclure :
- d’anciens bénévoles
- des personnes ayant quitté l’association
- plusieurs enregistrements d’une même personne
- des profils historiques
- des personnes inscrites à différentes périodes
- des personnes extérieures à l’organisation
Cette situation explique pourquoi le nombre de lignes présentes dans une base peut être très supérieur au nombre de membres actuellement actifs.
Il serait donc incorrect d’écrire que « 525 000 bénévoles de la Protection Civile ont été piratés ».
Une formulation plus rigoureuse serait :
Une fuite contenant plus de 525 000 profils est revendiquée, mais le nombre réel de personnes concernées reste à déterminer.
Une attaque datant de mars, découverte en août
La chronologie de l’incident constitue également un élément important.
Mars 2026
L’intrusion et l’exfiltration de données auraient eu lieu au cours du mois de mars.
17 août 2026
La Protection Civile indique avoir découvert l’incident plusieurs mois après l’attaque.
21 août 2026
La FNPC confirme publiquement la cyberattaque et le vol de données.
Cette chronologie représente donc un délai de plusieurs mois entre la compromission et sa découverte.
Il faut cependant éviter d’en déduire immédiatement une absence de surveillance ou une négligence particulière.
Dans une attaque visant une base de données, l’exfiltration peut être réalisée sans provoquer d’interruption de service visible. Les attaquants peuvent également chercher à rester discrets afin de maximiser la durée pendant laquelle ils disposent d’un accès.
Une compromission peut ainsi rester inconnue pendant plusieurs mois avant d’être détectée à la suite d’une analyse de journaux, d’une alerte externe ou de la découverte d’une base de données dans des circuits clandestins.
Une attaque révélée après l’apparition des données
La séquence de révélation est également intéressante : la Protection Civile n’a pas annoncé spontanément l’incident en mars.
La confirmation publique est intervenue après que des informations sur la fuite ont commencé à circuler, et cette situation illustre un phénomène devenu fréquent dans les incidents de cybersécurité : l’organisation victime peut apprendre ou confirmer l’existence d’une compromission à la suite de la découverte de données sur des plateformes clandestines.
Cela complique considérablement la gestion de crise car l’organisation doit alors déterminer rapidement :
- si les données sont authentiques
- quelle est leur provenance
- quand elles ont été exfiltrées
- combien de personnes sont concernées
- quelles catégories de données sont présentes
- si les données ont été modifiées
- si les attaquants disposent encore d’un accès
- quelles personnes doivent être informées
Les risques pour les bénévoles
Le principal risque immédiat pour les personnes concernées est probablement l’ingénierie sociale.
Un attaquant disposant du nom d’un bénévole, de sa date de naissance et de son numéro de téléphone peut construire un message beaucoup plus crédible, il pourrait par exemple se faire passer pour :
- un responsable de la Protection Civile
- un administrateur informatique
- un responsable départemental
- un organisme de formation
- une autre association
- un service administratif
Le contexte de la Protection Civile peut également rendre certaines demandes particulièrement crédibles.
Un faux message pourrait par exemple prétendre concerner une formation, un changement de planning, une mission, une convocation, une mise à jour administrative, une activation en urgence voire une modification du compte bénévole.
Le caractère professionnel et associatif des informations rend donc cette fuite particulièrement intéressante pour des campagnes de spear-phishing.
Les mineurs représentent une catégorie particulièrement sensible
La présence de données relatives à des mineurs mérite une attention particulière.
La Protection Civile accueille notamment des jeunes dans le cadre de ses activités de formation et de bénévolat.
Si des profils de mineurs figurent effectivement dans les données exfiltrées, leur exposition peut entraîner des risques spécifiques.
La combinaison de nom + date de naissance + téléphone + photographie constitue une quantité importante d’informations personnelles.
Elle pourrait être utilisée pour des tentatives d’usurpation, de manipulation ou de contact frauduleux.
Il est donc important que les communications adressées aux personnes concernées expliquent clairement les données exposées et les comportements à adopter.
Les personnes secourues ne sont pas concernées
Un élément permet toutefois de circonscrire l’incident.
La FNPC indique que les données des personnes ayant bénéficié des secours de la Protection Civile ne sont pas concernées.
La fuite porte sur l’environnement eProtec utilisé pour la gestion des bénévoles et non sur les données des personnes secourues lors des interventions.
Cette distinction est particulièrement importante pour une organisation de sécurité civile.
Une compromission de données médicales ou de données relatives à des victimes aurait représenté un risque nettement différent, notamment en raison du caractère extrêmement sensible de certaines informations pouvant être collectées dans le cadre d’une intervention.
À ce stade, rien ne permet d’affirmer qu’un tel périmètre a été compromis.
Un risque pour l’organisation interne
La fuite ne doit pas être analysée uniquement sous l’angle de la vie privée.
Une base de bénévoles peut également fournir des informations sur la structure opérationnelle de l’organisation.
Selon les informations présentes dans les fichiers, un attaquant pourrait potentiellement identifier :
- des responsables
- des bénévoles
- des fonctions
- des numéros de téléphone
- des antennes
- des personnes ayant des responsabilités particulières
- l’existence de certains groupes ou équipes
Ce type d’information peut être utilisé pour réaliser une attaque ciblée contre l’organisation elle-même.
Par exemple, un attaquant pourrait envoyer un message à un bénévole en se faisant passer pour un responsable qu’il connaît réellement.
La fuite devient alors un outil permettant de renforcer une campagne de social engineering.
Une menace qui dépasse la simple fuite
L’une des principales erreurs serait de considérer cette affaire uniquement comme une publication de données personnelles.
Une base de données volée peut avoir une durée de vie extrêmement longue.
Même si les données ne sont jamais publiées intégralement, elles peuvent être :
- revendues
- échangées
- enrichies avec d’autres bases
- utilisées pour créer des profils
- exploitées dans des campagnes de phishing
- utilisées pour identifier de nouvelles cibles
Les informations personnelles ont donc une valeur qui dépasse largement la date de l’incident.
Une personne peut être confrontée à des tentatives de fraude plusieurs mois ou plusieurs années après une fuite.
Un contexte français particulièrement actif
L’incident intervient dans une période où les cyberattaques et les fuites de données visant des organisations françaises se multiplient.
La Protection Civile indique elle-même que l’attaque s’inscrit dans une série d’incidents ayant également concerné d’autres fédérations et organisations françaises.
Cette tendance montre que les attaquants ne se limitent plus aux grandes entreprises disposant de données commerciales très importantes.
Les associations et fédérations disposent elles aussi de bases de données conséquentes, souvent constituées sur plusieurs années.
Elles peuvent contenir des informations personnelles particulièrement intéressantes pour les cybercriminels.
Les associations constituent des cibles intéressantes
Les associations disposent parfois de moyens informatiques plus limités que les grandes entreprises.
Elles peuvent également utiliser :
- des logiciels spécialisés
- des plateformes SaaS
- des outils développés par des prestataires
- des bases historiques
- des comptes administrateurs partagés
- des infrastructures anciennes
Cette dépendance à des outils tiers constitue une surface d’attaque supplémentaire.
L’affaire eProtec rappelle ainsi qu’un système utilisé pour gérer des bénévoles doit être considéré comme un système d’information critique, même s’il n’est pas directement lié aux opérations de secours.
Une base contenant plusieurs dizaines de milliers de personnes représente une quantité importante de données à protéger.
Les conséquences réglementaires
Une violation de données personnelles implique également des obligations réglementaires.
Dans le cadre du RGPD, une organisation qui détermine les finalités et les moyens du traitement doit notamment évaluer la gravité de l’incident et, lorsque les conditions sont réunies, notifier la violation à l’autorité compétente dans les délais prévus par le règlement.
Lorsque la violation est susceptible d’engendrer un risque élevé pour les personnes concernées, celles-ci doivent également être informées dans les conditions prévues par le RGPD.
La présence potentielle de données concernant des mineurs, de numéros de téléphone et de données d’identité peut naturellement augmenter le niveau de risque à évaluer.
Il appartiendra toutefois à la FNPC et aux autorités compétentes de déterminer précisément le périmètre et les obligations applicables.
Que doivent faire les personnes potentiellement concernées ?
Les bénévoles et anciens bénévoles qui pourraient figurer dans les données doivent surtout rester attentifs aux communications inhabituelles.
Quelques précautions sont particulièrement pertinentes :
- ne jamais communiquer un code reçu par SMS à une personne qui le demande
- vérifier l’adresse réelle de l’expéditeur d’un courriel
- ne pas cliquer directement sur un lien contenu dans un message inattendu
- contacter l’association via ses coordonnées officielles en cas de doute
- utiliser des mots de passe uniques pour les services en ligne
- activer l’authentification multifacteur lorsque cela est possible
- surveiller les tentatives de connexion inhabituelles
- être particulièrement méfiant face aux appels ou SMS utilisant des informations personnelles exactes
Cette dernière recommandation est essentielle.
Le fait qu’un interlocuteur connaisse le nom, le numéro de téléphone ou la date de naissance d’un bénévole ne prouve absolument pas qu’il est légitime.
Au contraire, ces informations peuvent précisément provenir de la fuite.
Une fuite qui pourrait être utilisée pour de futures attaques
L’exploitation des données pourrait également se faire progressivement.
Un attaquant peut par exemple commencer par utiliser une liste de numéros de téléphone pour envoyer des SMS frauduleux.
Les victimes qui répondent peuvent ensuite être enrichies avec d’autres informations.
Cette méthode permet de transformer progressivement une simple base de données en profils détaillés.
La fuite peut donc servir de matière première pour plusieurs campagnes criminelles successives.
C’est l’une des raisons pour lesquelles les personnes concernées doivent rester vigilantes même après la résolution technique de l’incident.
La question de l’origine de l’attaque reste ouverte
Les informations disponibles ne permettent pas encore d’établir précisément le mode opératoire.
On ne sait notamment pas publiquement si l’accès initial a été obtenu par :
- exploitation d’une vulnérabilité
- identifiants compromis
- attaque contre un compte administrateur
- compromission d’un prestataire
- mauvaise configuration
- autre technique d’intrusion
De même, l’identité des attaquants n’est pas publiquement établie.
Il est donc préférable de ne pas attribuer cette attaque à un groupe de ransomware ou à un groupe cybercriminel particulier sans éléments supplémentaires.
Un problème de gouvernance des données
L’affaire pose également une question plus fondamentale : combien de données une organisation conserve-t-elle réellement ?
La présence potentielle de centaines de milliers de profils dans une base associée à une organisation comptant beaucoup moins de bénévoles actifs montre l’importance de la gestion du cycle de vie des données.
Les organisations devraient régulièrement se demander :
- quelles données sont réellement nécessaires
- combien de temps elles doivent être conservées
- pourquoi les anciens profils sont toujours présents
- si les doublons peuvent être supprimés
- qui peut accéder aux données
- quelles informations doivent être archivées
- lesquelles doivent être définitivement supprimées
Une base ancienne contenant plusieurs générations de bénévoles augmente mécaniquement l’impact potentiel d’une compromission.
Ce que cette affaire révèle sur les données « oubliées »
Les doublons évoqués par la Protection Civile constituent un détail technique qui mérite finalement beaucoup d’attention.
Dans de nombreux systèmes d’information, les bases historiques grossissent au fil des années.
Un ancien bénévole peut rester présent dans plusieurs tables.
Une ancienne adresse peut rester associée à un compte.
Une ancienne photographie peut rester accessible.
Un profil créé lors d’une ancienne campagne peut ne jamais être supprimé.
Individuellement, ces informations semblent peu importantes.
Mais lorsqu’elles sont agrégées dans une base centrale, elles peuvent représenter une quantité considérable de données personnelles.
La cybersécurité ne consiste donc pas seulement à protéger les données « actives ».
Elle consiste également à réduire la quantité de données inutiles conservées.
Une attaque révélatrice pour le secteur associatif
L’incident de la Protection Civile rappelle que la cybersécurité concerne toutes les organisations qui manipulent des données personnelles.
Une association de sécurité civile peut sembler moins intéressante pour un attaquant qu’une banque ou un grand groupe industriel.
Pourtant, elle peut disposer de bases contenant :
- des dizaines de milliers de personnes
- des coordonnées téléphoniques
- des dates de naissance
- des photographies
- des informations professionnelles
- des informations organisationnelles
Pour un cybercriminel spécialisé dans la fraude et l’ingénierie sociale, cette combinaison peut être particulièrement rentable.
Ce qu’il faut retenir
La Fédération nationale de Protection Civile confirme avoir subi en mars 2026 une cyberattaque ayant conduit au vol de données depuis la plateforme eProtec. L’incident n’a été découvert que le 17 août, avant d’être rendu public le 21 août.
Les informations potentiellement exposées comprennent notamment :
- des données d’état civil
- des dates de naissance
- des numéros de téléphone
- des photographies de profil
- des informations relatives aux bénévoles
- des données concernant certains mineurs
Le chiffre de 525 000 profils a été avancé à propos des données exfiltrées, mais il ne correspond pas nécessairement à 525 000 personnes uniques. La Protection Civile évoque notamment la présence de doublons et poursuit ses investigations pour déterminer le nombre réel de personnes concernées.
L’association affirme par ailleurs que les données des personnes secourues ne sont pas concernées.
Le principal risque pour les personnes dont les informations auraient été exposées réside désormais dans les campagnes de phishing, de smishing, d’appels frauduleux et d’ingénierie sociale.
Cette affaire rappelle enfin une règle essentielle : une plateforme destinée à gérer des bénévoles peut contenir suffisamment de données personnelles pour devenir une cible de choix pour les cybercriminels.
Et elle illustre également un autre problème souvent sous-estimé : le nombre de lignes présentes dans une base de données ne correspond pas nécessairement au nombre de personnes réellement concernées. Les historiques, doublons et anciens comptes peuvent considérablement gonfler les chiffres annoncés lors d’une fuite.
(sources : frenchbreaches.com, cyberfaille.net, actu.orange.fr)
3- Cyber Resilience Act : les premières obligations entrent en application en septembre 2026
Après plusieurs années de préparation, le Cyber Resilience Act (CRA) entre désormais dans sa phase opérationnelle. Le règlement européen, destiné à renforcer la cybersécurité des produits comportant des éléments numériques, va franchir une première étape majeure le 11 septembre 2026, avec l’entrée en application de ses obligations de signalement des vulnérabilités et incidents.
Il ne s’agit toutefois pas encore de l’application complète du règlement. Celle-ci interviendra progressivement jusqu’en décembre 2027.
Une première échéance dès le 11 septembre 2026
À partir du 11 septembre 2026, les fabricants de produits comportant des éléments numériques devront signaler certaines vulnérabilités et incidents de sécurité.
Sont notamment concernés :
- les vulnérabilités activement exploitées
- les incidents graves ayant un impact sur la sécurité du produit
Le dispositif impose des délais particulièrement courts.
Lorsqu’un fabricant prend connaissance d’une vulnérabilité activement exploitée ou d’un incident grave, il devra notamment transmettre une alerte précoce dans les 24 heures, suivie d’une notification plus complète dans les 72 heures. Un rapport final devra ensuite être fourni selon des délais dépendant de la nature de l’événement.
Cette obligation constitue un changement important pour les fabricants de logiciels et d’équipements connectés.
Jusqu’à présent, la gestion et la divulgation des vulnérabilités pouvaient varier considérablement d’un éditeur à l’autre. Le CRA introduit désormais un cadre européen commun imposant une véritable responsabilité de suivi de la sécurité pendant le cycle de vie du produit.
L’obligation de signalement s’appliquera d’ailleurs aux produits numériques déjà disponibles sur le marché, et pas uniquement aux nouveaux produits commercialisés après décembre 2027.
Une réglementation qui dépasse largement les seuls objets connectés
Le Cyber Resilience Act adopte une définition particulièrement large des « produits comportant des éléments numériques ».
Il concerne aussi bien des produits matériels que logiciels dès lors qu’ils présentent un élément numérique et, selon les cas, leurs composants de traitement de données à distance.
Cela peut notamment englober :
- objets connectés
- équipements réseau
- systèmes embarqués
- logiciels
- applications
- appareils électroménagers connectés
- équipements industriels
- systèmes de sécurité
- produits automobiles connectés
- composants électroniques disposant de fonctionnalités numériques
L’objectif est de faire évoluer le modèle traditionnel dans lequel la cybersécurité était parfois traitée principalement après la commercialisation.
Avec le CRA, la sécurité doit être prise en compte dès la conception et pendant toute la durée de vie du produit. La Commission européenne présente ainsi le règlement comme introduisant notamment une obligation de sécurité « by design » et « by default ».
Un règlement né de plusieurs années de travaux
Le Cyber Resilience Act s’inscrit dans une évolution plus large de la politique européenne de cybersécurité.
La Commission européenne a présenté sa proposition de CRA en septembre 2022. L’objectif était alors de créer, pour la première fois au niveau européen, des exigences horizontales de cybersécurité applicables aux produits comportant des éléments numériques.
Le projet répondait à un constat simple : alors que les produits numériques occupent une place croissante dans la vie quotidienne et dans les entreprises, leur niveau de sécurité n’était pas soumis à un cadre européen suffisamment homogène.
Le règlement devait notamment répondre à plusieurs problèmes :
- multiplication des vulnérabilités dans les produits connectés
- absence de suivi de sécurité après commercialisation
- mises à jour insuffisantes
- produits commercialisés avec des configurations par défaut peu sécurisées
- manque de transparence sur les vulnérabilités
- responsabilités parfois difficiles à identifier entre fabricant, importateur et distributeur
Après les négociations entre les institutions européennes, le texte a été définitivement adopté en octobre 2024 sous la forme du règlement (UE) 2024/2847.
Il a ensuite été publié au Journal officiel de l’Union européenne le 20 novembre 2024 et est entré en vigueur le 10 décembre 2024.
L’entrée en vigueur ne signifiait cependant pas que les entreprises devaient immédiatement appliquer l’ensemble de ses dispositions.
Le législateur européen a prévu une période de transition relativement longue afin de permettre aux fabricants et aux autres acteurs concernés d’adapter leurs produits, leurs processus de développement et leurs systèmes de gestion des vulnérabilités.
2026 : le CRA commence réellement à produire ses effets
L’année 2026 constitue donc un tournant.
Une première étape a déjà été franchie le 11 juin 2026, avec l’entrée en application des dispositions relatives à la notification des organismes d’évaluation de la conformité.
La prochaine échéance, beaucoup plus importante pour les fabricants, est celle du 11 septembre 2026.
À cette date, les mécanismes de signalement des vulnérabilités et incidents deviennent obligatoires.
La Commission européenne a par ailleurs publié le 27 juillet 2026 une première série de lignes directrices destinées à aider les entreprises à préparer leur mise en conformité. Ces documents apportent notamment des précisions pratiques sur l’application du règlement, même s’ils ne remplacent pas les obligations juridiquement contraignantes du CRA.
La standardisation constitue également un chantier majeur. Les normes harmonisées doivent traduire les exigences générales du règlement en spécifications techniques concrètes. Les produits conformes à ces normes pourront bénéficier d’une présomption de conformité aux exigences essentielles correspondantes.
Les prochains grands jalons
Le calendrier du Cyber Resilience Act peut être résumé ainsi :
| Date | Échéance |
|---|---|
| 10 décembre 2024 | Entrée en vigueur du CRA |
| 11 juin 2026 | Application des dispositions relatives aux organismes d’évaluation de la conformité |
| 11 septembre 2026 | Début des obligations de notification des vulnérabilités exploitées et incidents graves |
| Q3 2026 | Premiers livrables de normalisation |
| Q4 2026 | Acte délégué concernant la présomption de conformité liée à l’EUCC |
| 11 décembre 2026 | Notification d’un nombre suffisant d’organismes d’évaluation de la conformité |
| 30 octobre 2027 | Nouveaux livrables de normalisation |
| 11 décembre 2027 | Application complète du Cyber Resilience Act |
Le 11 décembre 2027 constitue donc la véritable échéance majeure. À partir de cette date, l’essentiel des obligations du règlement deviendra applicable.
Les fabricants devront notamment être en mesure de démontrer que leurs produits ont été conçus, développés et produits conformément aux exigences de cybersécurité du CRA, mais également assurer la gestion des vulnérabilités pendant la durée de support prévue.
Les produits concernés devront également passer par la procédure d’évaluation de conformité appropriée avant leur mise sur le marché et porter, lorsque les conditions sont remplies, le marquage CE attestant leur conformité.
Un changement profond pour les fabricants
Le CRA ne doit donc pas être considéré comme une simple nouvelle obligation documentaire.
Pour les fabricants, il implique potentiellement une transformation de l’ensemble du cycle de développement :
Conception → développement sécurisé → analyse des risques → tests → évaluation de conformité → commercialisation → surveillance → gestion des vulnérabilités → mises à jour → fin de support
La cybersécurité devient ainsi une responsabilité permanente.
Un fabricant qui découvre une vulnérabilité critique plusieurs années après la commercialisation de son produit ne pourra plus nécessairement considérer que le problème appartient uniquement au passé : le règlement impose justement une approche couvrant le cycle de vie du produit.
Pour les entreprises qui ne l’ont pas encore fait, 2026 doit donc être considérée comme une année de préparation active, et non comme une période d’attente jusqu’au 11 décembre 2027.
La première échéance réglementaire est désormais imminente : dans quelques semaines, les obligations de reporting du Cyber Resilience Act seront une réalité pour les fabricants concernés.
(sources : digital-strategy.ec.europa.eu, digital-strategy.ec.europa.eu, cyberstand.eu)
🌍Zoom International
1- ShinyHunters menace Logitech et Streamlabs : une revendication d’extorsion encore non confirmée
Une nouvelle cible de premier plan pour ShinyHunters
Le 18 août 2026, le groupe cybercriminel ShinyHunters a ajouté deux noms particulièrement connus à son site de fuite : Logitech et Streamlabs.
Le groupe affirme avoir compromis l’environnement de l’entreprise et menace désormais de publier les données qu’il aurait dérobées. Un ultimatum a été fixé au 21 août 2026, avec un message présenté comme un « dernier avertissement » : sans prise de contact, les attaquants menacent de divulguer les données et de provoquer plusieurs « problèmes numériques » supplémentaires.
Cette annonce a rapidement attiré l’attention en raison du profil des deux entreprises concernées. Logitech est un acteur mondial majeur des périphériques informatiques, tandis que Streamlabs occupe une place importante dans l’écosystème du streaming et de la création de contenu.
Il convient toutefois de faire une distinction essentielle : la présence de Logitech et Streamlabs sur le site de ShinyHunters ne constitue pas, à elle seule, la preuve qu’une intrusion a effectivement eu lieu. À ce stade, aucune compromission n’a été publiquement confirmée par Logitech, aucune donnée n’a été rendue disponible pour analyse et aucun élément technique permettant de déterminer le mode opératoire des attaquants n’a été communiqué.
Un ultimatum sans montant de rançon
Le fonctionnement de cette opération est particulièrement révélateur.
Dans son message publié le 18 août, ShinyHunters ne fournit ni montant de rançon, ni description précise des données supposément volées, ni détail concernant une éventuelle vulnérabilité exploitée. Le groupe demande simplement à Logitech de prendre contact avant le 21 août, faute de quoi les données seraient publiées.
Cette méthode correspond à une mécanique désormais classique de l’extorsion par la donnée : créer suffisamment d’incertitude pour contraindre la victime à entrer en négociation avant même que la réalité de la compromission puisse être établie.
L’absence de preuve est ici un élément important. Les publications disponibles ne mentionnent notamment :
- aucun échantillon de fichiers
- aucune capture d’écran permettant d’identifier les systèmes compromis
- aucun volume de données précis
- aucune liste de fichiers
- aucune méthode d’accès initial
- aucune vulnérabilité exploitée
- aucun indicateur technique permettant de relier l’incident à une infrastructure connue
- aucun montant de rançon
Autrement dit, ShinyHunters affirme disposer de données, mais ne fournit pas publiquement les éléments permettant de vérifier cette affirmation.
Logitech et Streamlabs : pourquoi la cible est intéressante
Le choix de Logitech n’est évidemment pas anodin.
L’entreprise commercialise des périphériques informatiques, notamment des souris, claviers, webcams, équipements audio et produits destinés aux joueurs. Elle dispose également d’un important écosystème logiciel et de services en ligne.
Streamlabs constitue une cible particulièrement intéressante dans ce contexte. La plateforme fournit des outils destinés aux créateurs de contenu et aux streamers, notamment pour la diffusion en direct. Streamlabs a été racheté par Logitech en 2019 et est désormais intégré à l’activité gaming et streaming du groupe.
L’entreprise développait encore récemment de nouvelles fonctionnalités cloud et mobiles. Début août 2026, Logitech annonçait notamment Streamlabs Network Boost, une fonctionnalité destinée à améliorer la fiabilité des retransmissions IRL en combinant plusieurs connexions réseau.
Une compromission avérée pourrait donc potentiellement concerner plusieurs catégories d’informations : données internes, informations commerciales, données relatives aux comptes utilisateurs, informations liées aux créateurs de contenu ou encore éléments techniques associés aux plateformes et services.
Il ne faut toutefois pas transformer ces possibilités en faits. Rien ne permet actuellement d’affirmer que ces catégories de données ont effectivement été dérobées.
Une différence importante entre ransomware et extorsion de données
La qualification de « ransomware » mérite également d’être nuancée, et il faut savoir que ShinyHunters est généralement associé à un modèle d’extorsion fondé sur le vol de données, qui peut être accompagné ou non d’un chiffrement des systèmes. Dans un scénario classique de double extorsion, l’attaquant vole d’abord des informations sensibles puis menace de les publier, éventuellement après avoir chiffré les systèmes de la victime.
Dans le cas Logitech/Streamlabs, rien ne permet actuellement d’affirmer qu’un ransomware a été déployé dans l’infrastructure de l’entreprise.
Le seul élément public est une revendication publiée sur le site de fuite du groupe, accompagnée d’une menace de publication. Une source de renseignement cyber rappelle d’ailleurs que la date du 18 août correspond à la date de publication de la revendication et ne permet pas de déterminer la date réelle d’une éventuelle compromission.
Il serait donc plus rigoureux de parler, à ce stade, de revendication de compromission et de tentative d’extorsion, plutôt que d’affirmer qu’un ransomware a effectivement infecté Logitech.
Une revendication qui reste non vérifiée
Plusieurs éléments convergent actuellement vers le même constat : l’incident n’est pas confirmé indépendamment.
Les publications spécialisées qui ont analysé l’affaire ne disposent d’aucun échantillon permettant de confirmer la compromission. Logitech et Streamlabs n’ont pas publié de confirmation de l’attaque dans les informations disponibles publiquement.
La page de statut de Logitech ne faisait par ailleurs apparaître aucun incident le 18 août et indiquait ses services comme opérationnels. Cela ne permet évidemment pas d’exclure une compromission silencieuse ou un vol de données sans interruption de service, mais aucun impact opérationnel public n’est actuellement associé à cette revendication.
Cette nuance est fondamentale : une attaque peut parfaitement se produire sans provoquer immédiatement d’indisponibilité. À l’inverse, l’absence d’incident visible ne permet pas de confirmer qu’une revendication est fausse.
Il faut donc rester dans une position intermédiaire : ni considérer l’affirmation de ShinyHunters comme un fait établi, ni conclure prématurément à un simple bluff.
ShinyHunters : un groupe habitué à l’extorsion à grande échelle
ShinyHunters est actif depuis plusieurs années et s’est fait connaître par des opérations de vol massif de données et d’extorsion visant de grandes organisations.
Le groupe a notamment été associé à plusieurs opérations très médiatisées, dont des compromissions impliquant Ticketmaster et PowerSchool. En 2025, l’écosystème ShinyHunters a également évolué vers un modèle de type Ransomware-as-a-Service, notamment autour de l’offre baptisée « shinysp1d3r ». Plusieurs membres liés au groupe ont par ailleurs été arrêtés par les autorités françaises en 2025.
Cette histoire explique pourquoi les revendications du groupe sont prises au sérieux par les équipes de sécurité. Mais elle constitue également une raison supplémentaire de ne pas confondre automatiquement revendication criminelle et compromission démontrée.
Le FBI rappelle d’ailleurs que ShinyHunters est spécialisé dans les opérations de vol de données et d’extorsion à grande échelle et que les acteurs associés au groupe peuvent utiliser des affirmations réelles ou exagérées concernant leur accès à des informations sensibles afin d’obtenir un paiement. Les techniques de pression peuvent également dépasser la simple publication sur un site de fuite et inclure des messages, appels ou autres formes de harcèlement.
Une stratégie fondée sur la pression psychologique
L’intérêt de ce type de revendication réside précisément dans l’incertitude qu’elle crée.
Pour l’entreprise visée, attendre la publication d’un échantillon peut être risqué. Si la compromission est réelle, chaque jour supplémentaire peut permettre aux attaquants de préparer une publication, d’exploiter les données dérobées ou de contacter des partenaires et des clients.
À l’inverse, prendre immédiatement contact avec les cybercriminels peut donner à une revendication éventuellement mensongère une crédibilité et une valeur qu’elle n’avait pas.
L’attaquant cherche donc à placer la victime dans une situation où le coût de l’incertitude devient supérieur au coût potentiel de la négociation.
Le choix d’une entreprise mondialement connue renforce encore cette mécanique. Le simple fait que Logitech soit présenté comme victime suffit à générer une couverture médiatique, à attirer l’attention des clients et à provoquer des vérifications internes.
C’est précisément ce qui fait de l’extorsion moderne une opération à la fois technique, financière et psychologique.
Le précédent des autres revendications de ShinyHunters
Cette affaire intervient alors que ShinyHunters mène une campagne particulièrement active.
Au début du mois d’août, le groupe avait notamment revendiqué une attaque contre Questel SAS, en affirmant avoir dérobé plus de 21 millions d’enregistrements CRM ainsi que plus de 147 Go de données internes. Là encore, les éléments publiquement disponibles ne permettaient pas de confirmer indépendamment l’étendue de la compromission.
D’autres revendications récentes ont également utilisé le même principe : publication du nom d’une organisation, menace de divulgation, échéance courte et absence initiale d’éléments techniques permettant de vérifier immédiatement l’attaque.
Cette stratégie permet aux opérateurs de multiplier les cibles tout en faisant peser une pression considérable sur les organisations concernées.
Que s’est-il passé après le 21 août ?
L’ultimatum fixé par ShinyHunters arrivait à échéance le 21 août 2026.
À la date du 22 août, les informations publiques disponibles ne permettent toujours pas d’établir qu’une fuite de données Logitech ou Streamlabs a été publiée et authentifiée. Les sources de veille continuent de qualifier l’incident de revendication non vérifiée.
Cela ne signifie pas nécessairement que l’affaire est terminée. ShinyHunters peut encore publier ultérieurement des données ou fournir de nouveaux éléments. À l’inverse, l’absence persistante de publication pourrait également renforcer l’hypothèse d’une revendication destinée principalement à faire pression sur la victime.
La situation doit donc être considérée comme évolutive.
Quels risques pour les utilisateurs de Logitech et Streamlabs ?
Pour les utilisateurs, la première conséquence est surtout l’incertitude.
Il serait prématuré de demander à l’ensemble des utilisateurs de considérer leurs données comme compromises. En revanche, l’événement constitue une bonne occasion de rappeler plusieurs mesures de sécurité essentielles.
Les utilisateurs de Logitech ou Streamlabs doivent notamment :
- utiliser un mot de passe unique pour chaque service
- activer l’authentification multifacteur lorsqu’elle est disponible
- se méfier des messages prétendant provenir de Logitech ou Streamlabs et faisant référence à une prétendue fuite
- ne pas cliquer sur des liens reçus par courrier électronique ou messagerie sous prétexte de « vérifier » leur compte après l’incident
- surveiller les notifications de connexion inhabituelles
- ne jamais communiquer un code MFA à une personne qui le demande
Ce dernier point est particulièrement important. Une fuite réellement confirmée peut rapidement devenir le prétexte à une seconde phase d’attaque, notamment par phishing ou ingénierie sociale.
Même lorsqu’une revendication est fausse, les cybercriminels peuvent exploiter sa médiatisation pour fabriquer de fausses communications de sécurité.
Une menace potentiellement plus large qu’une simple fuite
Le cas Logitech/Streamlabs illustre également un problème plus général : la compromission potentielle d’un fournisseur technologique peut avoir des conséquences qui dépassent largement l’organisation initialement ciblée.
Logitech fournit des produits et services utilisés par des millions de personnes et Streamlabs se situe au cœur de l’écosystème des créateurs de contenu.
Une compromission réelle pourrait donc potentiellement intéresser non seulement les données internes de l’entreprise, mais également les comptes, intégrations, infrastructures ou informations liées à des utilisateurs et partenaires.
Cela explique pourquoi les entreprises technologiques constituent des cibles particulièrement intéressantes pour les groupes d’extorsion : elles concentrent à la fois des données à forte valeur, des actifs techniques et un important réseau de tiers.
Ce qu’il faut retenir
L’affaire Logitech/Streamlabs illustre parfaitement la difficulté actuelle à distinguer une cyberattaque avérée d’une simple revendication d’extorsion.
Ce que l’on sait :
- ShinyHunters a publié le 18 août 2026 une revendication visant Logitech et Streamlabs
- le groupe a présenté cette publication comme un « dernier avertissement »
- une échéance a été fixée au 21 août
- aucune somme de rançon n’a été rendue publique
- aucun mode opératoire n’a été communiqué
- aucune preuve technique permettant de confirmer la compromission n’a été publiée dans les sources analysées
- aucune confirmation publique de la compromission n’a été identifiée
- au 22 août, la publication d’une fuite authentifiée n’est pas établie
Ce que l’on ne sait pas :
- si ShinyHunters a réellement obtenu un accès aux systèmes de Logitech ou Streamlabs
- si des données ont effectivement été exfiltrées
- quelles données seraient concernées
- quelle quantité de données aurait été dérobée
- comment un éventuel accès aurait été obtenu
- si un ransomware a réellement été exécuté
- si des données seront finalement publiées
La prudence est donc de mise. Présenter cette affaire comme un « piratage de Logitech » ou une « attaque ransomware contre Streamlabs » serait, à ce stade, aller au-delà des éléments vérifiables.
Le terme le plus exact est celui de revendication de compromission accompagnée d’une tentative d’extorsion.
Et c’est précisément ce qui rend cette affaire intéressante : dans l’écosystème actuel de la cybercriminalité, la menace de publication peut devenir une arme à part entière, même avant qu’une compromission ne soit publiquement démontrée.
(sources : zataz.com, cypro.co.uk, cyberdaily.au)
2- Pokémon Center : une cyberattaque chez son prestataire logistique expose les données de clients
Une cyberattaque qui dépasse largement Pokémon Center
Le Pokémon Center a informé certains de ses clients européens qu’une cyberattaque avait compromis des informations relatives à leurs commandes.
Contrairement à ce que pourrait laisser penser l’intitulé de l’incident, l’infrastructure de Pokémon Center n’est pas à l’origine de la compromission. L’attaque a visé CEVA Logistics, le prestataire chargé notamment de l’expédition des produits commandés sur PokémonCenter.com au Royaume-Uni et en Allemagne.
L’incident constitue ainsi un nouvel exemple concret du risque posé par les attaques visant les chaînes d’approvisionnement numériques et logistiques : une entreprise peut voir les données de ses clients exposées alors même que ses propres systèmes n’ont pas été compromis.
CEVA avait déjà été victime d’une cyberattaque à partir du 29 juillet 2026, avec un impact opérationnel sur huit de ses entrepôts européens. L’entreprise avait commencé à informer les clients concernés le 1er août. Plusieurs sociétés utilisant ses services ont ensuite confirmé que des données de leurs propres clients pouvaient avoir été exposées.
CEVA Logistics au cœur de l’incident
CEVA Logistics est une filiale du groupe CMA CGM et constitue l’un des acteurs majeurs de la logistique mondiale.
Son rôle consiste notamment à assurer des opérations de stockage, de préparation et d’expédition pour le compte d’autres entreprises.
Cette position fait de l’entreprise un point de concentration particulièrement intéressant pour les cybercriminels.
Au lieu d’attaquer séparément plusieurs dizaines d’entreprises, une intrusion dans un prestataire logistique peut potentiellement donner accès à des informations provenant de nombreux clients différents.
C’est précisément ce qui semble s’être produit dans cette affaire.
L’attaque a touché au moins huit entrepôts européens et a provoqué des perturbations dans les opérations logistiques. CEVA a indiqué que l’impact opérationnel était limité à ces installations et qu’aucun autre système mondial de l’entreprise n’avait été affecté.
Les détails techniques de l’intrusion restent toutefois inconnus publiquement. Aucun groupe cybercriminel n’a revendiqué l’attaque et CEVA n’a pas publiquement confirmé la présence d’un ransomware.
Une attaque commencée fin juillet
Les informations communiquées aux clients permettent de reconstituer une chronologie approximative.
L’intrusion aurait débuté autour du 29 juillet 2026. Les communications adressées aux clients indiquent de leur côté que l’attaque affectant les opérations Pokémon Center a commencé le 30 juillet.
Le 1er août, CEVA a commencé à prévenir les entreprises clientes concernées par la perturbation de ses opérations européennes.
Dans les jours suivants, plusieurs sociétés ont commencé à communiquer à leur tour avec leurs propres clients.
L’incident est ainsi devenu progressivement visible, non pas à travers une communication initiale de CEVA destinée au grand public, mais par l’intermédiaire des entreprises qui dépendaient de ses services.
Cette chronologie est caractéristique des attaques touchant les prestataires : l’entreprise compromise n’est pas nécessairement la première à révéler les conséquences de l’incident.
Quelles données Pokémon Center ont été exposées ?
Dans les notifications adressées aux clients, Pokémon Center indique que des personnes non autorisées pourraient avoir obtenu plusieurs catégories d’informations associées aux commandes.
Les données potentiellement concernées comprennent :
- le nom complet
- l’adresse postale
- le numéro de téléphone
- l’adresse électronique
- les informations relatives au contenu des commandes passées sur PokémonCenter.com
Autrement dit, l’attaquant pourrait disposer d’un ensemble de données permettant de relier directement une personne à une adresse, un moyen de contact et à des produits qu’elle a commandés.
Pokémon Center précise en revanche que les données de carte bancaire n’étaient pas accessibles à CEVA et ne font donc pas partie des informations exposées dans cet incident. L’entreprise indique également que les autres informations relatives aux clients et aux commandes n’ont pas été affectées.
Cette distinction est importante : il ne s’agit donc pas d’une fuite généralisée de l’ensemble des données détenues par Pokémon Center.
Une fuite particulièrement intéressante pour le phishing
La nature des données exposées constitue néanmoins un risque important.
Une adresse électronique ou un numéro de téléphone pris isolément peut déjà être exploité pour lancer une campagne de phishing.
Mais lorsqu’il est possible d’associer ces informations à un nom, une adresse postale, un téléphone, une commandes ainsi que son contenu, les possibilités d’ingénierie sociale deviennent beaucoup plus importantes.
Un attaquant pourrait par exemple envoyer un faux message indiquant :
Votre commande Pokémon Center n°XXXX nécessite une confirmation de livraison.
Le message pourrait ensuite contenir une référence réelle à un produit effectivement commandé.
La victime aurait alors beaucoup plus de raisons de considérer le message comme légitime.
C’est l’une des conséquences les plus importantes de ce type de fuite : les données volées peuvent servir non seulement à une fraude immédiate, mais également à préparer des attaques beaucoup plus crédibles dans les semaines ou mois suivants.
Des analystes en cybersécurité ont précisément souligné le risque que ces informations de commande soient utilisées pour élaborer des campagnes de phishing personnalisées.
Les données bancaires ne sont pas concernées
Un point particulièrement important dans les communications de Pokémon Center concerne les informations financières.
CEVA n’avait pas accès aux données de cartes bancaires utilisées pour les achats.
La compromission ne signifie donc pas que les cybercriminels disposent des numéros de carte bancaire des clients concernés.
De même, les informations d’authentification des comptes Pokémon Center ne sont pas indiquées comme ayant été compromises.
Cela limite considérablement le risque d’une compromission directe des comptes ou d’une utilisation immédiate des moyens de paiement.
Le danger est plutôt situé du côté de l’usurpation, du phishing et de l’ingénierie sociale.
Des commandes annulées à la suite de l’attaque
L’incident n’a pas uniquement des conséquences en matière de protection des données.
Certains clients Pokémon Center ont également reçu des notifications leur indiquant que leurs commandes avaient été annulées.
Dans les messages envoyés aux clients, Pokémon Center évoque initialement un problème de traitement ou de fulfillment.
La société a ensuite précisé que cette situation était liée à l’incident touchant son prestataire logistique.
Parallèlement, le site Pokémon Center UK affichait un avertissement indiquant que le traitement et l’expédition de certaines commandes subissaient des retards.
Les annulations ont notamment concerné certaines commandes très attendues liées aux produits du 30e anniversaire du Pokémon Trading Card Game, dont certaines précommandes étaient particulièrement recherchées.
Des clients ont toutefois signalé que les annulations ne concernaient pas uniquement ces produits : d’autres articles ont également été affectés.
Pourquoi une cyberattaque entraîne-t-elle l’annulation de commandes ?
La raison exacte des annulations n’a pas été publiquement détaillée, et c’est un point intéressant de l’incident, car une perturbation logistique peut normalement provoquer un retard de livraison sans nécessiter l’annulation d’une commande.
Dans ce cas, plusieurs hypothèses sont possibles : indisponibilité des systèmes utilisés pour préparer les commandes, impossibilité de vérifier certaines informations, perte de visibilité sur les stocks ou nécessité de reconstruire certaines données après l’incident.
Mais il serait spéculatif d’affirmer laquelle de ces hypothèses est la bonne.
Le fait établi est simplement que l’attaque contre CEVA a perturbé le traitement logistique et conduit Pokémon Center à annuler certaines commandes.
Un incident qui touche également les clients de Valve
Le cas Pokémon Center n’est pas isolé.
CEVA Logistics fournit également des services à d’autres grandes entreprises.
L’une des victimes connues de l’incident est Valve, notamment pour la logistique de certains produits matériels Steam en Europe.
Valve a informé des clients européens que certaines données liées à leurs commandes pouvaient avoir été compromises.
Les informations concernées étaient similaires : noms, adresses, numéros de téléphone, adresses électroniques et informations relatives aux produits commandés.
Le parallèle est particulièrement intéressant : une même compromission d’un prestataire permet potentiellement d’affecter plusieurs marques qui n’ont, elles-mêmes, pas été piratées.
L’incident concerne donc beaucoup plus largement la chaîne logistique européenne que le seul univers Pokémon.
Au moins huit entrepôts européens affectés
L’impact opérationnel de l’attaque a été relativement important, et CEVA a en effet indiqué que huit entrepôts européens avaient été affectés.
Les marchandises stockées dans ces installations ont subi des retards d’expédition, ce qui a mécaniquement perturbé les activités des entreprises clientes.
Plusieurs organisations européennes ont ainsi signalé des problèmes liés à leurs commandes ou à leurs opérations logistiques.
Parmi les entreprises dont l’impact a été rapporté figurent notamment des acteurs du commerce électronique, de la banque, de la distribution et du secteur technologique.
L’incident démontre donc que l’impact d’une cyberattaque ne se limite pas nécessairement à l’informatique.
Une attaque contre un système informatique peut rapidement devenir un problème physique de logistique : marchandises immobilisées, commandes bloquées, livraisons retardées et stocks difficiles à traiter.
Une attaque de supply chain dans le monde réel
L’affaire Pokémon Center est particulièrement intéressante du point de vue de la cybersécurité car elle illustre une forme de supply chain attack qui ne correspond pas nécessairement au scénario traditionnel d’une attaque logicielle.
On parle souvent de supply chain lorsqu’un attaquant compromet un logiciel ou une bibliothèque utilisée par de nombreuses organisations.
Ici, la logique est différente puisque le cybercriminel s’en prend à un prestataire de services centralisé, et ce dernier possède :
- des accès aux systèmes de ses clients
- des informations sur leurs commandes
- des adresses de livraison
- des coordonnées personnelles
- des informations sur les produits
- des systèmes permettant de gérer les flux logistiques
Une seule compromission peut donc produire un effet de cascade.
Le modèle peut être résumé ainsi :
Cette chaîne montre que la sécurité d’une entreprise dépend de plus en plus de la sécurité de son écosystème de fournisseurs.
Un problème de concentration des données
L’incident soulève également une question importante concernant la centralisation des informations.
Chaque entreprise cliente peut considérer que les informations confiées à son prestataire logistique sont relativement limitées.
Mais lorsqu’un même prestataire travaille pour des dizaines ou des centaines d’entreprises, ces informations sont regroupées dans une infrastructure commune.
Pour l’attaquant, cette concentration devient extrêmement intéressante.
Une intrusion dans le système d’un fournisseur peut permettre d’obtenir des données issues de secteurs totalement différents.
Dans le cas de CEVA, les conséquences touchent ainsi des clients issus de domaines très différents : commerce électronique, banque, jeux vidéo, distribution ou encore produits de consommation.
Une enquête toujours en cours
Les circonstances techniques exactes de l’attaque restent encore largement inconnues.
CEVA a indiqué avoir activé ses protocoles de sécurité et lancé une enquête.
L’entreprise travaille également avec les autorités compétentes.
Aux Pays-Bas, l’autorité de protection des données a indiqué avoir reçu plusieurs notifications d’incidents provenant d’organisations affectées par l’attaque. À un stade précoce de l’enquête, au moins dix organisations avaient signalé un incident en lien avec cette compromission.
Il n’est donc pas possible, à ce stade, de dresser une liste définitive des victimes ni de déterminer précisément le volume total de données potentiellement exposées.
Aucun groupe cybercriminel revendiqué
Un autre élément mérite d’être souligné : aucun groupe cybercriminel n’a publiquement revendiqué l’attaque dans les informations disponibles.
Il n’est donc pas possible d’attribuer l’incident à un groupe ransomware précis.
De même, les éléments actuellement publics ne permettent pas de confirmer que l’attaque était motivée par une demande de rançon.
Certaines analyses ont évoqué l’hypothèse d’un ransomware ou d’un malware destructeur compte tenu des perturbations observées, mais cette qualification reste hypothétique tant que CEVA n’a pas communiqué davantage d’informations techniques.
Il est donc préférable de parler simplement de cyberattaque contre CEVA Logistics.
Un rappel sur le risque fournisseur
Cette affaire illustre une faiblesse fondamentale de nombreux systèmes d’information modernes.
Une entreprise peut disposer d’une authentification forte, d’un EDR performant, d’un SOC, de sauvegardes, d’une segmentation réseau ainsi que d’une politique de sécurité mature et malgré tout être affectée par la compromission d’un fournisseur.
La cybersécurité ne peut donc plus être limitée au périmètre informatique directement contrôlé par l’entreprise mais il faut également penser à évaluer :
- les fournisseurs critiques
- les prestataires logistiques
- les plateformes SaaS
- les hébergeurs
- les prestataires de paiement
- les fournisseurs de support
- les sous-traitants ayant accès aux données personnelles
Dans le cas présent, Pokémon Center semble avoir correctement limité les informations transmises à son prestataire logistique, puisque les données de paiement et les informations d’authentification ne sont pas concernées.
Cela n’a toutefois pas empêché une exposition de données personnelles suffisamment détaillées pour représenter un risque réel.
Quelles précautions pour les clients ?
Les personnes ayant reçu une notification de Pokémon Center doivent surtout être attentives aux tentatives de phishing.
Il faut notamment se méfier des messages :
- faisant référence à une commande récente
- mentionnant un produit effectivement acheté
- demandant de confirmer une adresse
- demandant de payer des frais de livraison
- proposant un remboursement
- demandant de modifier le mot de passe
- demandant une pièce d’identité
- contenant un lien vers un prétendu site Pokémon Center
Le fait qu’un message contienne des informations exactes sur une commande ne constitue plus une garantie de légitimité si ces informations ont potentiellement été exposées.
C’est précisément ce qui rend ce type de fuite particulièrement dangereux.
Un incident qui dépasse Pokémon
L’affaire Pokémon Center peut facilement être perçue comme un incident isolé touchant une boutique en ligne.
Elle est en réalité beaucoup plus représentative d’une tendance majeure de la cybersécurité : l’exploitation des interdépendances entre entreprises.
Le fournisseur compromis devient le point d’entrée permettant d’atteindre indirectement plusieurs organisations.
Et lorsque ce fournisseur assure une fonction physique essentielle, les conséquences peuvent dépasser très largement la sphère numérique.
Dans cette affaire, une attaque informatique contre un prestataire logistique a ainsi provoqué simultanément :
- une exposition potentielle de données personnelles
- des retards de livraison
- des commandes annulées
- des perturbations commerciales
- des notifications de clients
- des investigations réglementaires
Les point clés
L’incident Pokémon Center n’est pas, à proprement parler, un piratage direct de Pokémon Center.
Le point d’entrée est CEVA Logistics, son prestataire logistique pour les clients du Royaume-Uni et d’Allemagne.
L’attaque, qui a débuté fin juillet 2026, a affecté huit entrepôts européens et plusieurs entreprises clientes de CEVA.
Pour les clients Pokémon Center concernés, les informations potentiellement exposées comprennent notamment :
- nom complet
- adresse postale
- numéro de téléphone
- adresse électronique
- contenu des commandes
En revanche, les données de carte bancaire ne sont pas concernées, CEVA n’y ayant pas accès.
L’incident a également eu des conséquences opérationnelles, avec des retards et l’annulation de certaines commandes, notamment au Royaume-Uni et en Allemagne.
Mais la leçon la plus importante est ailleurs.
Cette attaque démontre qu’une entreprise peut être indirectement victime d’une cyberattaque parce qu’un fournisseur possède les données nécessaires à son activité.
La sécurité de la chaîne d’approvisionnement ne concerne donc pas uniquement les logiciels : elle concerne également les prestataires, les infrastructures logistiques et toutes les organisations auxquelles des données sont confiées.
Dans un environnement économique toujours plus interconnecté, la sécurité du fournisseur devient ainsi une composante à part entière de la sécurité de l’entreprise.
(sources : bleepingcomputer.com, gbhackers.com, zataz.com)
3- Des autoradios Android transformés en nœuds d’un botnet : le malware qui détourne les mises à jour automobiles
Une nouvelle menace pour les systèmes multimédias automobiles
Les systèmes multimédias modernes sont devenus de véritables ordinateurs embarqués.
Navigation GPS, Bluetooth, Wi-Fi, applications multimédias, accès à Internet, commandes vocales ou encore téléchargement automatique de mises à jour : les head units automobiles fonctionnant sous Android disposent aujourd’hui de nombreuses fonctionnalités traditionnellement associées aux smartphones et aux ordinateurs.
Cette évolution apporte de nouvelles possibilités, mais également une nouvelle surface d’attaque.
En juin 2026, des chercheurs en cybersécurité ont découvert une campagne malveillante visant spécifiquement certains systèmes multimédias automobiles fonctionnant sous Android. Le malware ne se contente pas d’infecter un smartphone ou une box Android : il est distribué directement aux systèmes embarqués de certains véhicules par l’intermédiaire de leur mécanisme de mise à jour.
L’objectif des attaquants n’est toutefois pas, à ce stade, de prendre le contrôle du véhicule ou de ses fonctions critiques, mais les systèmes compromis sont principalement utilisés pour la fraude publicitaire et la constitution d’un botnet de proxies résidentiels.
Autrement dit, un autoradio Android infecté peut être transformé en machine contrôlée à distance et servir de relais pour le trafic Internet d’autres personnes.
Kaspersky considère cette campagne comme le premier cas documenté d’une chaîne d’infection conçue spécifiquement pour cibler des head units automobiles.
Des systèmes développés par DoFun concernés
La campagne ne touche pas indistinctement tous les véhicules équipés d’Android.
Les chercheurs ont identifié une cible beaucoup plus précise : les systèmes utilisant des logiciels développés par DoFun, un fournisseur chinois spécialisé dans les systèmes multimédias automobiles.
DoFun développe notamment :
- des firmwares Android
- des applications
- des services cloud
- des systèmes multimédias
- des équipements destinés aux véhicules
Selon les informations communiquées par Kaspersky, les solutions DoFun seraient utilisées par plus de 30 millions de propriétaires de véhicules dans le monde, mais il faut toutefois éviter de conclure que ces dizaines de millions de véhicules sont infectés.
La campagne exploite une chaîne d’infection particulière et les observations disponibles ne permettent pas d’établir combien de véhicules ont effectivement été compromis.
Le risque potentiel est néanmoins important en raison du nombre d’appareils utilisant cet écosystème logiciel.
Une attaque de supply chain particulièrement intéressante
Le mécanisme utilisé est l’un des aspects les plus préoccupants de cette campagne.
Les utilisateurs n’ont pas nécessairement besoin d’installer une application douteuse.
Les attaquants exploitent une application système légitime appelée TWCore.
Cette application est normalement utilisée pour :
- collecter certaines informations analytiques
- communiquer avec l’infrastructure cloud du fournisseur
- rechercher les mises à jour disponibles
- télécharger des fichiers
- installer les mises à jour sur le head unit
Le problème vient du fonctionnement de cette dernière fonctionnalité.
TWCore peut recevoir depuis son infrastructure de gestion des informations indiquant qu’un APK doit être téléchargé et installé.
Plus particulièrement, son protocole prévoit un paramètre appelé installNotExists.
Lorsque ce paramètre est activé, l’application peut installer une application qui n’était pas présente auparavant sur le système.
Cette fonctionnalité légitime devient ainsi un mécanisme extrêmement puissant pour les attaquants.
Ils n’ont pas besoin de convaincre le conducteur d’installer une application malveillante : le système d’administration du véhicule peut lui-même être utilisé pour pousser le malware.
Le détournement du système de mise à jour
La chaîne d’infection peut être résumée de la manière suivante :
Cette architecture en plusieurs étapes permet aux attaquants de séparer les différentes fonctions du malware.
Le premier composant est relativement petit et sert principalement à installer ou charger la suite de la chaîne, les fonctionnalités les plus importantes sont ensuite téléchargées dynamiquement.
Cette architecture rend également l’analyse et la détection plus difficiles.
Étape 1 : JarService
Le premier malware identifié dans la chaîne porte le nom de JarService.
Il s’agit d’un dropper, c’est-à-dire d’un programme dont le rôle principal est de préparer l’exécution d’autres composants malveillants.
JarService ne possède notamment pas d’interface graphique destinée à l’utilisateur.
Son code contient des blocs de données chiffrés qui sont déchiffrés à l’exécution.
Ces données contiennent notamment :
- des informations sur la version du payload
- le point d’entrée à exécuter
- le code nécessaire au chargement de l’étape suivante
Le malware utilise notamment un mécanisme XOR pour protéger les différentes parties de son contenu.
Cette technique n’est pas particulièrement sophistiquée en elle-même, mais elle permet de rendre le contenu du fichier moins immédiatement identifiable lors d’une analyse statique.
Étape 2 : un loader chargé dynamiquement
JarService lance ensuite un second composant.
Celui-ci fonctionne comme un loader : son rôle est de contacter l’infrastructure de commande et de contrôle afin de récupérer les éléments nécessaires à la poursuite de l’infection.
Le malware transmet notamment des informations permettant d’identifier l’implant.
Les communications observées contiennent des informations telles que :
- l’identifiant du dispositif
- la version du payload
- le type de payload
- le canal
- le nom du package
- la version de l’application
- le nom de l’application
Le serveur C2 peut ensuite répondre avec une URL permettant de télécharger la prochaine étape.
Cette architecture donne aux opérateurs une grande souplesse qui leur permet notamment de modifier les composants distribués sans devoir nécessairement remplacer l’intégralité de l’application initialement installée.
Étape 3 : un clicker malveillant
La troisième étape constitue l’un des objectifs de la campagne.
Le malware fonctionne notamment comme un clicker, une catégorie de logiciels malveillants utilisée pour générer artificiellement des impressions ou des clics publicitaires.
Le système compromis peut effectuer des requêtes HTTP et charger des pages Web contrôlées par les attaquants, l’objectif étant de générer artificiellement de l’activité publicitaire.
Pour les opérateurs, chaque véhicule infecté devient donc une ressource permettant de générer des revenus frauduleux, mais la fraude publicitaire n’est qu’une partie du problème.
Le malware possède également des capacités permettant de charger des modules supplémentaires.
C’est cette fonctionnalité qui conduit finalement à la création du botnet de proxies.
Les informations collectées sur le véhicule
Le malware contacte périodiquement son infrastructure de commande et de contrôle.
Les observations de Kaspersky montrent notamment que les informations envoyées peuvent inclure :
- le modèle du périphérique
- la résolution de l’écran
- l’adresse MAC
- des informations sur le réseau Wi-Fi
- des informations concernant la configuration du malware
- différents paramètres permettant d’identifier et de gérer l’implant
Les communications sont effectuées périodiquement.
Dans l’une des configurations observées, le malware contactait le serveur environ toutes les 90 minutes.
Le serveur peut alors fournir une configuration mise à jour et différentes instructions.
Cette architecture transforme le head unit en un véritable endpoint administré à distance par les attaquants.
Le module zhima transforme les voitures en proxies
La partie la plus intéressante de l’opération concerne le module baptisé zhima.
Il s’agit d’un composant de type reverse proxy, qui, une fois installé, permet aux attaquants de faire transiter du trafic Internet à travers le véhicule compromis.
Le fonctionnement est similaire à celui d’un réseau de proxies résidentiels : un client utilisant le service de proxy peut faire passer une connexion Internet par l’adresse IP publique du véhicule infecté.
Pour le site ou le serveur distant, le trafic semble alors provenir de cette connexion résidentielle plutôt que de l’infrastructure réelle de l’attaquant.
Le véhicule devient donc, sans que son propriétaire en ait conscience, une sorte de relais Internet clandestin.
Pourquoi créer un réseau de proxies ?
Les réseaux de proxies résidentiels constituent une ressource particulièrement recherchée dans la cybercriminalité.
Ils permettent notamment de :
- masquer l’origine réelle de certaines connexions
- contourner certaines restrictions géographiques
- automatiser des opérations
- effectuer du scraping
- créer de faux comptes
- mener des campagnes frauduleuses
- contourner certains systèmes de détection
- distribuer du trafic provenant de nombreuses adresses IP
Le modèle est également très intéressant financièrement car les opérateurs peuvent monétiser l’accès à leur botnet en vendant la capacité de proxy à des clients.
Kaspersky a identifié des liens entre l’infrastructure observée et des services de proxies résidentiels tels que PXYEDGE et ProxyForU.
Les véhicules infectés deviennent ainsi des ressources commerciales exploitées par les cybercriminels.
Un lien avec le botnet BADBOX
L’analyse de l’infrastructure et du code a permis aux chercheurs d’établir un lien avec BADBOX, un écosystème malveillant déjà connu pour compromettre des appareils Android.
Kaspersky attribue avec un niveau de confiance élevé cette opération au MoYu Group, un acteur précédemment associé à BADBOX.
Les chercheurs ont notamment identifié des similitudes dans :
- le code
- l’infrastructure
- les mécanismes de chargement
- les serveurs utilisés
- les services de proxy associés
Le fonctionnement général correspond également au modèle économique observé dans l’écosystème BADBOX : infecter des appareils Android afin d’exploiter leurs ressources et de les transformer en infrastructures permettant différentes activités frauduleuses.
BADBOX : un problème qui dépasse les smartphones
Cette affaire est particulièrement intéressante car elle montre l’expansion progressive des menaces associées à BADBOX.
L’écosystème avait déjà été observé sur différentes catégories d’appareils Android, notamment des téléviseurs connectés, des boîtiers TV et d’autres équipements grand public.
Le principe reste généralement le même : un appareil Android connecté est transformé en ressource contrôlée par les attaquants.
Dans le cas présent, le même modèle économique est appliqué à une nouvelle catégorie d’équipements : les systèmes multimédias automobiles.
Cette évolution montre que les cybercriminels ne considèrent plus nécessairement les appareils connectés comme des cibles uniquement pour leurs données.
Ils peuvent également être intéressés par leur puissance de calcul, leur connexion Internet, leur adresse IP mais également par leur disponibilité permanente.
Une attaque qui ne semble pas viser les fonctions de conduite
Un élément doit cependant être clairement distingué.
Les recherches disponibles ne montrent pas que les attaquants cherchent à prendre le contrôle de la conduite du véhicule.
Le malware semble principalement destiné à :
- la fraude publicitaire
- le chargement de nouveaux modules
- la création d’un réseau de proxies
- la monétisation des ressources réseau des appareils compromis
Les chercheurs indiquent que le malware ne semble pas interférer avec les systèmes critiques de conduite.
Il ne faut donc pas présenter cette campagne comme un scénario dans lequel un attaquant pourrait actuellement prendre le contrôle du volant à distance.
Cela ne signifie évidemment pas que la situation est anodine.
Un système embarqué compromis constitue une violation importante de la sécurité du véhicule et peut potentiellement devenir un point d’entrée vers d’autres composants si l’architecture réseau du véhicule présente des faiblesses.
Mais aucun élément public de cette campagne ne permet d’affirmer une compromission des fonctions de conduite.
Le véritable danger : la supply chain
La particularité de cette attaque réside donc moins dans la sophistication intrinsèque du malware que dans le vecteur de distribution.
L’attaquant n’a pas besoin de :
- convaincre le propriétaire d’installer une application pirate
- exploiter directement une vulnérabilité du téléphone
- envoyer un SMS malveillant
- persuader l’utilisateur de cliquer sur un lien
Il profite d’une fonction qui doit normalement renforcer la sécurité : la mise à jour automatique.
C’est un excellent exemple de risque de supply chain car le mécanisme de mise à jour est normalement considéré comme un élément de confiance, et lorsqu’il est compromis ou détourné, il devient au contraire un canal privilégié permettant de distribuer du code à grande échelle.
Une attaque difficile à détecter pour l’utilisateur
Pour le propriétaire du véhicule, l’infection peut être quasiment invisible.
Le malware ne nécessite pas nécessairement d’interaction utilisateur et n’a pas besoin d’afficher une fausse alerte ou une fenêtre demandant l’installation d’une application.
L’utilisateur peut simplement constater que son système fonctionne normalement.
Pendant ce temps, en arrière-plan, le head unit peut :
- communiquer avec un serveur C2
- envoyer des informations sur l’appareil
- télécharger des modules
- effectuer des requêtes Web
- participer à des opérations de fraude publicitaire
- servir de proxy pour des tiers
C’est précisément ce caractère silencieux qui rend ce type d’attaque particulièrement problématique.
Pourquoi les head units Android sont intéressants pour les attaquants
L’utilisation d’Android dans les systèmes automobiles présente plusieurs avantages pour les fabricants.
Le système est connu, flexible et dispose d’un important écosystème logiciel.
Les développeurs peuvent adapter l’interface, intégrer des applications et utiliser des composants existants, mais cette standardisation a également un revers : les attaquants connaissent déjà Android.
Ils disposent donc d’un important corpus d’outils, de techniques et de malwares pouvant potentiellement être adaptés à ces nouveaux appareils.
Un head unit Android peut ainsi présenter plusieurs caractéristiques particulièrement intéressantes :
- connexion permanente à Internet
- matériel relativement puissant
- stockage local
- Wi-Fi
- Bluetooth
- système d’exploitation complet
- mécanisme de mise à jour
- fonctionnement pendant de longues périodes
Pour un opérateur de botnet, cela représente une ressource intéressante.
Une tendance déjà visible sur d’autres appareils Android
La campagne automobile s’inscrit dans une tendance plus large.
Les chercheurs en sécurité ont récemment observé plusieurs familles de malware Android utilisant des méthodes de distribution particulièrement difficiles à détecter, notamment des infections préinstallées dans les firmwares ou intégrées à des applications système.
En 2025, Kaspersky avait par exemple documenté une variante de Triada intégrée directement au firmware de smartphones Android contrefaits.
Plus récemment, Keenadu a également été observé dans des firmwares et applications système Android, avec notamment des capacités de fraude publicitaire.
Le point commun est important : plus le malware se rapproche du niveau système, plus il devient difficile pour l’utilisateur de distinguer le logiciel malveillant d’un composant légitime.
L’affaire des head units représente une nouvelle déclinaison de cette tendance.
Le problème des équipements Android génériques
Les head units Android concernés peuvent notamment être des équipements ajoutés après l’achat du véhicule.
Ce marché comprend de nombreux systèmes multimédias Android génériques ou aftermarket, et cela pose un problème particulier en matière de cybersécurité car contrairement aux véhicules produits par les grands constructeurs, certains équipements aftermarket peuvent disposer de cycles de mise à jour, de mécanismes de sécurité et de chaînes d’approvisionnement beaucoup moins transparents.
L’utilisateur peut parfois ne pas savoir précisément :
- qui développe le firmware
- qui exploite l’infrastructure cloud
- qui signe les mises à jour
- comment les mises à jour sont vérifiées
- quels serveurs sont contactés
- quelles applications système disposent de privilèges élevés
La sécurité dépend donc non seulement du fabricant du véhicule, mais également de toute la chaîne de fournisseurs du système multimédia.
Le mécanisme de mise à jour doit devenir un élément critique de sécurité
Cette affaire pose une question fondamentale :
comment garantir qu’une mise à jour automatique est réellement digne de confiance ?
Un système de mise à jour sécurisé devrait notamment reposer sur :
- une signature cryptographique des paquets
- une vérification stricte de la signature avant installation
- une authentification forte des serveurs
- une infrastructure de distribution sécurisée
- une séparation des rôles
- une journalisation des mises à jour
- la possibilité de détecter une modification inattendue du firmware
- des mécanismes permettant de révoquer rapidement une version compromise
La simple utilisation d’une connexion HTTPS ou d’un serveur officiel ne suffit pas nécessairement.
Si le serveur légitime est compromis ou si son mécanisme de distribution est détourné, une connexion techniquement sécurisée peut tout de même distribuer un fichier malveillant.
DoFun a été informé
Kaspersky indique avoir informé DoFun de la découverte.
Selon les informations communiquées par les chercheurs, l’entreprise chinoise a répondu avoir corrigé le problème.
Cette information est importante, mais elle ne permet pas de déterminer précisément :
- comment l’attaque initiale a été rendue possible
- combien de systèmes ont été infectés
- pendant combien de temps
- combien de versions compromises ont été distribuées
- si toutes les infrastructures concernées ont été nettoyées
Une correction côté fournisseur ne signifie pas automatiquement que tous les appareils déjà compromis sont désinfectés.
Il existe une différence majeure entre « empêcher de nouvelles infections », et « nettoyer les systèmes déjà infectés ».
Un risque particulier pour les véhicules déjà compromis
Un head unit infecté peut conserver son malware même après correction de l’infrastructure de distribution.
Si un appareil a déjà reçu JarService, le loader ou zhima, la suppression de la source de distribution ne garantit pas nécessairement la suppression des composants présents sur l’appareil.
Dans une situation idéale, un correctif devrait donc être accompagné d’un mécanisme permettant :
- d’identifier les versions compromises
- de vérifier l’état des appareils
- de supprimer les composants malveillants
- d’installer un firmware sain
- de révoquer les anciennes versions
- de surveiller les communications vers les anciennes infrastructures C2
Cette problématique est comparable à celle rencontrée dans les environnements d’entreprise après une compromission d’un serveur de mise à jour.
Un incident révélateur pour la cybersécurité automobile
Cette affaire ne constitue pas simplement une nouvelle histoire de malware Android.
Elle démontre que les véhicules deviennent progressivement des écosystèmes informatiques distribués.
Un véhicule moderne peut contenir :
- plusieurs calculateurs
- des systèmes Linux ou Android
- des interfaces réseau
- du Bluetooth
- du Wi-Fi
- des services cloud
- des applications mobiles
- des mécanismes de mise à jour à distance
Chaque composant ajoute potentiellement une nouvelle dépendance.
La cybersécurité automobile doit donc désormais intégrer des problématiques traditionnellement associées à l’informatique classique : gestion des identités, sécurité des mises à jour, supply chain, monitoring réseau, signature logicielle, gestion des vulnérabilités et réponse à incident.
Le scénario le plus inquiétant n’est pas forcément celui du contrôle du véhicule
L’imaginaire autour du hacking automobile se concentre souvent sur un scénario spectaculaire : un attaquant qui prendrait le contrôle du véhicule.
Cette affaire montre cependant qu’un attaquant peut poursuivre des objectifs beaucoup plus simples et immédiatement rentables, qu’il n’a pas besoin de contrôler le volant, et qu’il peut simplement transformer le véhicule en infrastructure criminelle.
Le propriétaire continue à conduire normalement tandis que son système multimédia :
- consomme sa connexion Internet
- expose son adresse IP
- participe à des requêtes automatisées
- génère éventuellement des clics frauduleux
- sert de relais pour le trafic d’autres personnes
Pour les criminels, c’est largement suffisant pour générer des revenus.
Ce que les propriétaires peuvent faire
Pour les propriétaires d’un véhicule équipé d’un head unit Android, plusieurs précautions sont pertinentes.
Il est recommandé de :
- vérifier régulièrement les mises à jour proposées par le fabricant
- privilégier les firmwares provenant directement du fabricant
- éviter les ROM ou APK provenant de sources inconnues
- ne pas installer d’applications piratées
- surveiller les comportements réseau inhabituels
- conserver les références exactes du modèle et du firmware
- vérifier auprès du fabricant si un correctif de sécurité est disponible
Pour les systèmes Android aftermarket, la prudence doit être encore plus importante, et avant d’acheter un équipement, il peut être utile de vérifier :
- la durée de support logiciel
- l’identité réelle du fabricant
- la fréquence des mises à jour
- le mécanisme de signature du firmware
- la politique de sécurité
- la possibilité de restaurer un firmware officiel
Un équipement moins cher mais dont le firmware n’est plus maintenu peut présenter un risque bien supérieur à son prix d’achat.
Ce qu’il faut retenir
Cette campagne constitue un signal important pour la cybersécurité automobile.
Des chercheurs ont identifié une chaîne d’infection ciblant des head units Android développés autour de l’écosystème DoFun.
Le malware exploite une application système légitime, TWCore, utilisée pour les mises à jour.
La chaîne commence par JarService, qui charge ensuite plusieurs composants malveillants. Le malware peut notamment effectuer de la fraude publicitaire et télécharger le module zhima, transformant alors le système embarqué en nœud d’un botnet de proxies résidentiels.
L’opération est attribuée avec un niveau de confiance élevé au MoYu Group, un acteur lié à l’écosystème BADBOX.
À ce stade, aucun élément ne montre que les attaquants ont pris le contrôle des fonctions critiques de conduite. L’objectif semble principalement financier : fraude publicitaire et monétisation des appareils infectés comme proxies.
La véritable nouveauté réside donc dans le vecteur d’infection.
Le malware n’est pas simplement installé par un utilisateur imprudent : il est distribué via le mécanisme de mise à jour d’un système automobile.
C’est une illustration particulièrement claire du risque de supply chain dans l’Internet des objets et dans l’automobile connectée.
À mesure que les véhicules intègrent davantage de logiciels, la question ne sera donc plus uniquement de savoir si une voiture peut être piratée.
Il faudra également se demander : « Qui contrôle les logiciels installés dans cette voiture, comment sont-ils mis à jour et que se passe-t-il si ce mécanisme de confiance est compromis ? »
(sources : bleepingcomputer.com, securelist.com, kaspersky.com, thehackernews.com)
🎯 Conclusion
L’actualité de cette semaine montre une nouvelle fois que les cybermenaces dépassent les frontières traditionnelles entre informatique, industrie, services et objets connectés.
En France, les revendications visant Actua et l’incident confirmé de la Protection Civile rappellent la persistance du risque lié au vol de données personnelles. Ces affaires soulignent également l’importance de distinguer les volumes revendiqués par les attaquants des éléments réellement vérifiés.
Le Cyber Resilience Act constitue quant à lui un changement structurel. L’échéance du 11 septembre approche et marquera le début des premières obligations concrètes pour les fabricants concernés, avant l’application complète du règlement en décembre 2027.
À l’international, les incidents de la semaine mettent surtout en évidence l’importance croissante de la supply chain. La revendication de ShinyHunters contre Logitech et Streamlabs rappelle le poids de l’extorsion par la menace de publication. L’affaire Pokémon Center montre quant à elle qu’une entreprise peut être indirectement touchée par la compromission d’un fournisseur, sans que ses propres infrastructures aient été directement attaquées.
Enfin, l’affaire des head units Android automobiles illustre l’évolution de la surface d’attaque. Un simple système multimédia peut disposer d’une connexion permanente à Internet et devenir, après compromission, une ressource exploitée par des cybercriminels.
Ces différents événements ont finalement un point commun : la confiance devient elle-même une surface d’attaque. Confiance dans une mise à jour, un fournisseur, une plateforme ou l’identité d’un interlocuteur.
Pour les entreprises comme pour les utilisateurs, la cybersécurité doit donc être pensée au-delà du périmètre interne : maîtrise des dépendances, surveillance des fournisseurs, protection des données et sécurisation des mécanismes de confiance deviennent désormais indispensables.
Plus notre environnement numérique devient interconnecté, plus la sécurité de chacun dépend de la solidité de l’ensemble de la chaîne.
