Aller au contenu
Beveiligingsnieuws

Attaques PLC IA : récap de sécurité de la semaine

geautomatiseerde schorsingen Uber onder vuur

Cette semaine, l’ambiance est celle d’un couvercle qu’on croit bien fermé… jusqu’au premier signe. Des outils de confiance se transforment en vecteurs d’attaque, des failles anciennes reviennent avec des techniques plus efficaces, et l’usage de l’intelligence artificielle rend certains scénarios plus accessibles pour les attaquants. Résultat : beaucoup de pistes à traiter, et surtout une priorité à garder en tête—corriger vite et limiter l’exposition.

Voici un récapitulatif clair des éléments les plus marquants, avec un focus sur les Attaques PLC IA et sur les autres tendances qui doivent attirer l’attention des équipes sécurité.

Menace de la semaine : les Attaques PLC IA

Les autorités américaines ont alerté sur l’existence d’une menace d’Attaques PLC IA visant des automates Siemens S7. L’idée n’est pas nouvelle—des PLC exposés et mal segmentés restent une porte d’entrée—mais le constat change : des acteurs menacent des infrastructures critiques (eau, énergie, industrie) en s’appuyant sur des scripts générés par IA.

Le scénario décrit est progressif. D’abord, des services de scan légitimes sont utilisés pour repérer des PLC Siemens accessibles depuis Internet ou insuffisamment isolés. Ensuite, une fois la cible identifiée, des scripts produits par IA servent à tester l’exploitation. Les acteurs chercheraient aussi à renforcer leur savoir-faire en adaptant leurs méthodes à des modèles précis de PLC, afin d’améliorer leurs chances de compromission.

Les risques évoqués vont au-delà d’un simple incident technique : perturbations de processus industriels, incidents de sécurité, arrêts prolongés, dommages matériels, fuite de données sensibles et problèmes de conformité. En pratique, une compromission peut aussi provoquer un effet en chaîne entre systèmes connectés.

À ce stade, l’identité des auteurs n’est pas connue.

Ce que cela implique pour la défense

  • Réduire l’exposition : un PLC accessible publiquement n’est pas un “risque théorique”.
  • Segmenter et contrôler : l’isolation réseau limite la propagation et ralentit les actions après découverte.
  • Préparer la détection : la phase de reconnaissance (read access) peut signaler les étapes préparatoires d’une opération.

GitLab : une faille exploitée très vite

Parmi les informations “actualité exploitation”, une vulnérabilité récemment divulguée dans GitLab (référencée CVE-2026-19478, avec un score CVSS de 9,4) a fait l’objet d’une exploitation active en quelques jours seulement.

La faille est décrite comme une forme d’injection de code. Elle permet à un attaquant non authentifié de modifier ou supprimer des projets GitLab rendus accessibles publiquement, et de réécrire des données sous certaines conditions, sans exiger de credentials, d’interaction utilisateur ou de configuration complexe.

Pour une équipe de sécurité, le message est simple : quand une faille touche un produit largement déployé et qu’elle est déjà utilisée, le “délai de patch” devient un facteur critique.

npm : des paquets trojanisés livrent un implant IA

Autre alerte concernant la chaîne d’approvisionnement : quatorze paquets npm auraient été identifiés comme trojanisés. Ils prennent l’apparence d’utilitaires utiles (notamment liés à des fonctionnalités de calendrier ou de “streak”), tout en servant de relais discret.

Le mécanisme visé est la livraison d’un implant Linux baptisé RedC2 4.0, décrit comme “propulsé par IA”. Selon les éléments rapportés, l’outil offre des capacités de surveillance, de vol d’identifiants, de chargement de charge utile et d’opérations à grande échelle. Il est aussi présenté comme un framework de type “command-and-control” (C2/C&C) conçu pour l’évasion.

Cette fois encore, le problème n’est pas uniquement “une menace en production”, mais l’hypothèse implicite selon laquelle les dépendances externes sont neutres. Le bon réflexe consiste à auditer, surveiller les versions, et limiter la surface d’approvisionnement.

Paiement : une attaque “Zombie Card” sans preuve d’usage réel

Des chercheurs ont montré une technique de type “Zombie Card” permettant de contourner certaines vérifications cryptographiques afin de finaliser des paiements sans contact avec des cartes Visa physiquement expirées.

Le principe repose sur une chaîne de traitement qui utilise un montage relais via smartphone pour modifier la date d’expiration fournie au terminal de paiement, sans casser la cryptographie de la carte. Les transactions observées auraient fonctionné dans des banques en test, notamment lorsque l’équipe a modifié un indicateur spécifique (le drapeau CDCVM).

Important : les auteurs indiquent qu’il n’y a pas de preuve que cette méthode ait été exploitée dans la nature.

Espionnage : des workflows d’authentification légitimes détournés

Trois ensembles attribués à des acteurs russes présumés (UNC6293, UNC7005 et UNC5976) auraient recours à des workflows d’authentification “normaux” pour cibler des personnes dans des secteurs comme l’enseignement, l’aérospatial et la défense, ainsi que des administrations et des think tanks en Europe, et également dans certains cas aux États-Unis.

Le rapport évoque des campagnes de phishing persistantes et adaptatives, appuyées sur une ingénierie sociale avancée visant à compromettre des comptes personnels sur plusieurs plateformes. Pour le cluster UNC7005, il est aussi fait mention d’une attribution à CaptiveCrunch : un ciblage de portails Wi‑Fi captifs (hôtels, centres de conférence, aéroports) afin de rediriger les utilisateurs vers une infrastructure contrôlée par l’attaquant et de récupérer des informations d’identification.

Un élément supplémentaire concerne une possible compromission de fournisseurs de services gérés (MSP) via une attaque de type chaîne d’approvisionnement, utilisée pour détourner les portails captifs.

Cloud : attaque Spectre sur des Workers et fuite de jetons

Une étude décrit une attaque Spectre à distance contre des Cloudflare Workers. L’objectif : obtenir un JSON Web Token (JWT) depuis un Worker co‑localisé dans l’environnement de production.

Les chercheurs rapportent un débit de fuite allant jusqu’à 12 bits par seconde, soit une cadence nettement supérieure à une démonstration antérieure de 2021. L’approche combine des techniques d’amplification avec un serveur de timing distant.

Le message à retenir n’est pas seulement “spectre” : il s’agit de la réalité que certaines barrières d’isolation peuvent être mises à l’épreuve dans des contextes de multi‑tenance.

Windchill et FlexPLM : web shell sur mesure

Dans le registre des attaques orientées extorsion, une campagne de compromission de serveurs PTC Windchill et FlexPLM aurait abouti au déploiement d’une backdoor sous forme de web shell en pages JSP.

D’après les informations rapportées, ce web shell serait conçu pour les environnements d’entreprise liés au Product Lifecycle Management. Il intégrerait plusieurs capacités : cartographier des données sensibles, déchiffrer toutes les identifiants du coffre Windchill, puis exécuter du code additionnel via un chargeur de classe Java personnalisé.

Le texte souligne aussi que ce groupe aurait déjà utilisé des web shells spécifiques après d’autres exploitations de vulnérabilités, et que l’organisation de ransomware continuerait à cibler des “zero-days” dans des plateformes SaaS populaires.

Mobile : vulnérabilités Unisoc et élévation de privilèges

Côté mobile, des chercheurs ont rendu publique une faille non corrigée dans le firmware modem Unisoc T612. Combinée à une vulnérabilité RCE précédemment révélée (elle aussi non corrigée), elle pourrait permettre de récupérer des privilèges élevés dans le noyau Android sur les appareils concernés.

Le déroulé mentionné consiste à injecter d’abord une charge malveillante au modem via la vulnérabilité RCE, puis à passer par un appel vidéo où la victime doit répondre. Ensuite, des mécanismes liés à la désactivation de protections sur une région mémoire permettraient un accès en lecture/écriture étendu, ouvrant la voie à une élévation de privilèges locale.

Pour les équipes, l’enjeu est d’aligner le cycle de correction (quand il existe) et la gestion des appareils touchés, y compris par un suivi des mises à jour constructeur.

CVEs à surveiller : patcher avant que l’exploitation ne s’installe

La section “Trending CVEs” rappelle un constat constant : l’écart entre une correction publiée et une exploitation observée se réduit. Parmi les références citées, on retrouve par exemple CVE-2026-19478 (GitLab), CVE-2026-15748 (Forminator Forms), CVE-2026-73570 (Zimbra), CVE-2026-32475 (Elementor Pro), et CVE-2026-63093 (Cursor), entre autres.

L’idée opérationnelle : identifiez rapidement ce que vous utilisez réellement, mettez à jour en priorisant les cas “fortement diffusés” ou “déjà touchés”, et évitez de vous limiter à une lecture superficielle des avis de sécurité.

Autres sujets marquants autour de la cybersécurité

Plusieurs informations “à impact” méritent aussi votre attention cette semaine :

  • Fuite de clés Stripe : un ensemble de données publié sur un forum contiendrait des clés API “actives” pour 659 marchands, ainsi qu’environ 35 Go de données client et paiement récupérées.
  • Recommandations CISA : publication d’une architecture de référence pour améliorer les standards opérationnels, notamment autour de la journalisation (logging) et de la visibilité.
  • Attaque via ScreenConnect : des techniques combinant phishing, téléchargements détournés et redirections malveillantes seraient utilisées pour déployer ce logiciel via PowerShell et msiexec.
  • Inscriptions Find My : un chercheur affirme avoir trouvé une méthode pour inscrire une machine Linux dans le réseau Find My et accéder à des données de localisation partagées.
  • Clés AWS exposées : plusieurs clés d’accès attribuées à des environnements d’entreprise auraient été rendues publiques, avec certaines configurées pour un contrôle complet.

Conclusion : une question plus utile que “la prochaine grosse attaque”

La leçon la plus pratique de cette semaine tient en une phrase : les attaquants n’ont rarement besoin que d’une seule faille, d’un seul service exposé ou d’un seul raccourci de confiance. Une seule dépendance négligée, un seul composant insuffisamment segmenté, et le scénario bascule.

Au lieu de courir après “la prochaine menace”, posez-vous une question plus exigeante : qu’est-ce que nous continuons à considérer comme sûr, sans l’avoir réellement validé ? Souvent, c’est là que le problème apparaît en premier.

Source: https://thehackernews.com/2026/08/weekly-recap-ai-powered-plc-attacks.html