Mis à jour : selon le FBI cité par Reuters, la fuite des données de milliers de ses agents, revendiquée par ShinyHunters, vient d’un correctif de sécurité non appliqué par un prestataire sur une plateforme tierce, Oracle PeopleSoft selon Reuters (The Hacker News, 6 octobre 2026). Plusieurs membres présumés du groupe ont depuis été arrêtés, notamment en Jordanie selon Reuters (BleepingComputer, 3 octobre 2026) et aux États-Unis (LeMagIT, 9 octobre 2026). Le lien précis entre la fuite du FBI et la technique décrite ci-dessous n’est pas établi publiquement.
Le groupe ShinyHunters a repris ses attaques contre des serveurs Oracle PeopleSoft non corrigés, mais « protégés » par une règle de pare-feu applicatif (WAF), en encodant une seule lettre de l’URL. Cette analyse s’adresse aux auditeurs, RSSI et responsables sécurité : mode opératoire, correspondance avec MITRE ATT&CK, pistes de recherche, questions d’audit ISO 27001 et pistes de sensibilisation. Nous nous appuyons sur l’article de BleepingComputer qui résume le rapport de Google/Mandiant, que nous n’avons pas lu directement ; aucune victime de cette nouvelle vague n’est nommée.
Pour une lecture orientée dirigeant, voir notre décryptage « Oracle PeopleSoft : quand la protection provisoire devient la porte d’entrée ».
Par précaution, nous ne reproduisons ni les chemins d’URL encodés ni les noms de fichiers malveillants. Ils figurent dans la source.
Contexte
- Acteur : ShinyHunters, groupe d’extorsion par vol de données, suivi par Google sous le nom UNC6240.
- Cible : serveurs Oracle PeopleSoft (progiciel RH, finance, scolarité) exposés sur Internet et non corrigés, mais « protégés » par une règle WAF qui bloque l’accès au composant vulnérable.
- Faille : CVE-2026-35273, exécution de code à distance sans authentification dans l’Environment Management Hub (PSEMHUB). Exploitée en zero-day en juin (vol de données chez environ 100 organisations selon BleepingComputer), corrigée par Oracle le lendemain de la première révélation.
- Secteurs de la nouvelle vague : enseignement supérieur, technologie, services informatiques, santé, agriculture, transport, administrations. Zone : mondiale.
- Date : rapport publié par Google et relayé le 26 septembre 2026. La date de début de la nouvelle vague n’est pas précisée.
- Revendication non vérifiée : ShinyHunters affirme avoir utilisé une « nouvelle faille inconnue » du même composant contre le FBI. Ce point n’est pas vérifié.
- Source : BleepingComputer, 26 septembre 2026.
Mode opératoire : ce qui est documenté et ce qui ne l’est pas
| Étape | Ce qui est rapporté | Correspondance MITRE ATT&CK (notre lecture) |
|---|---|---|
| Reconnaissance | 5 à 15 requêtes POST vers le composant PSEMHUB, avec des objets Java sérialisés. Sur un serveur vulnérable, la réponse renvoie des informations sur le système sans écrire de fichier ni perturber le service. | T1595.002 Vulnerability Scanning |
| Évasion du WAF | Encodage « pourcent » d’une lettre du chemin. Le WAF compare le chemin avant décodage ; WebLogic le décode, puis l’oriente vers le composant vulnérable. Google prévient que d’autres variantes sont possibles (autres encodages, casse mixte). | Pas de technique exacte ; au plus proche T1027 Obfuscated Files or Information |
| Accès initial | Exploitation de CVE-2026-35273 (désérialisation Java). | T1190 Exploit Public-Facing Application |
| Exécution | Commandes exécutées directement en mémoire, ou via des web shells JSP. | T1059 Command and Scripting Interpreter |
| Persistance | Web shells JSP (exécution de commandes, envoi de gros fichiers). Sur Linux : MeshAgent, un outil légitime d’administration à distance. | T1505.003 Web Shell, T1219 Remote Access Software |
| Déguisement | Sur Windows : un exécutable qui imite un installeur signé du lecteur multimédia Light Alloy et installe la porte dérobée SIDEEYE. | T1036 Masquerading |
| Vol d’identifiants | SIDEEYE vole des identifiants (méthode précise non détaillée), gère fichiers et processus, ouvre des shells inversés. | T1555 ou T1003 selon la méthode (non précisée) |
| Mouvement latéral | Neo-reGeorg : un proxy SOCKS5 tunnelé dans du HTTP ou HTTPS, pour rebondir du serveur PeopleSoft vers le réseau interne. | T1572 Protocol Tunneling, T1090 Proxy |
| Objectif | Vol de données en vue d’extorsion, le mode habituel du groupe. Les volumes et les méthodes d’exfiltration de cette vague ne sont pas détaillés. | TA0010 Exfiltration (non détaillée) |
La colonne MITRE est une lecture de notre part. Ce n’est pas une classification publiée par Mandiant.
Ce qui rend l’attaque efficace
L’attaquant ne cherche pas une nouvelle faille. Il exploite l’écart entre deux composants qui n’interprètent pas l’URL de la même façon : le WAF et le serveur d’application. C’est un problème classique de « normalisation » : tant que le WAF ne décode pas la requête comme le serveur final, une règle fondée sur un texte littéral peut être contournée.
Ce qu’on ne sait pas
La date de début de la vague, l’identité des victimes, les volumes volés et la réalité de la « nouvelle faille » revendiquée par ShinyHunters. Nous ne spéculons pas sur ces points.
Détection : pourquoi la règle WAF a donné une fausse assurance
- Qui a détecté : Mandiant/GTIG, dans le cadre de ses investigations et de son suivi de ShinyHunters. L’article ne précise pas comment les premières victimes de cette vague ont été repérées.
- Pourquoi pas plus tôt : les exploitants pensaient être protégés par leur règle WAF. La reconnaissance est discrète (pas de fichier écrit, pas de coupure de service). Et une règle WAF « verte » dans un tableau de bord ne dit pas si elle est contournée.
- Comment chercher chez soi (recommandation de Mandiant rapportée par BleepingComputer) : rechercher dans les journaux d’accès WebLogic, et pas seulement dans ceux du WAF, les requêtes vers le composant PSEMHUB et ses variantes encodées. Compléter par la recherche des web shells, des fichiers et des agents MeshAgent non prévus, à partir des indicateurs publiés dans le rapport.
- Remédiation principale : installer le correctif d’Oracle. Le WAF seul n’est pas une protection suffisante.
Questions d’audit ISO 27001:2022
- A.8.8 (gestion des vulnérabilités techniques) : « Quand une vulnérabilité est traitée par une mesure compensatoire (règle WAF, blocage réseau) au lieu du correctif, cette décision est-elle tracée, validée par le propriétaire du risque, et assortie d’une date d’échéance au-delà de laquelle le correctif doit être appliqué ? Montrez-moi la liste des correctifs virtuels actifs et leur âge. »
- A.8.29 et A.8.20 (tests de sécurité, sécurité des réseaux) : « Les règles WAF posées en urgence ont-elles été testées contre des contournements (encodage d’URL, casse, double encodage) ? Le WAF est-il configuré pour normaliser et décoder les requêtes avant de les comparer ? Quelle preuve de test pouvez-vous fournir ? »
- A.8.15 et A.8.16 (journalisation, surveillance) : « Les journaux du serveur d’application (ici WebLogic), et pas seulement ceux du WAF, sont-ils collectés dans le SIEM ? Pouvez-vous rechercher en moins de 24 heures un indicateur publié (chemin, nom de fichier) sur les 90 derniers jours ? »
- A.5.7 (renseignement sur les menaces) : « Quand un rapport de menace concerne un produit de votre inventaire (ici PeopleSoft), qui le lit, qui décide d’une recherche rétroactive, et comment la conclusion est-elle tracée ? Donnez un exemple récent. »
Pistes de sensibilisation
- Pour les équipes informatiques et d’exploitation : un atelier court, « Un patch virtuel n’est pas un patch ». En laboratoire, une règle WAF bloque un chemin d’administration ; on envoie la même requête avec une lettre encodée, et on montre que le serveur l’accepte. On explique ensuite la normalisation. Message à retenir : toute mesure compensatoire a une date de fin et un test de contournement.
- Pour les RSSI et les managers : un exercice sur table à partir de ce cas. « Votre ERP exposé est protégé par une règle WAF depuis juin. Un rapport Mandiant sort vendredi soir. Que faites-vous d’ici lundi ? » Objectif : faire émerger les rôles (qui lit le renseignement sur les menaces, qui décide de la recherche rétroactive, qui peut couper le service).
À lire aussi : notre décryptage pour les dirigeants, « Oracle PeopleSoft : quand la protection provisoire devient la porte d’entrée », et le bulletin de veille du 28 septembre 2026.
Analyse préparée avec l’aide d’une intelligence artificielle à partir de sources publiques, sous la responsabilité de KyNeo. Malgré nos contrôles, des erreurs peuvent subsister : en cas de doute, référez-vous aux sources citées. Les informations non confirmées sont signalées comme telles.