Shai-Hulud: vol de jetons supply chain — FIDO2 devient incontournable

Excerpt — Le 12 juin 2026, Zscaler a documenté la campagne « Shai‑Hulud »: compromission de comptes GitHub/npm/PyPI, détournement OIDC et IOCs publics. Voici comment une MFA anti‑phishing (FIDO2/WebAuthn) répond à l’article 32 RGPD et coupe l’accès aux assaillants.

Les faits

Le 12 juin 2026, l’équipe ThreatLabz de Zscaler a publié une analyse détaillée de « Shai‑Hulud », une campagne active qui cible la chaîne logicielle open source (npm et PyPI), avec plusieurs vagues confirmées en mars, mai et début juin 2026. Les opérateurs ont d’abord capturé des codes TOTP via du phishing Adversary‑in‑the‑Middle (AiTM), puis ont évolué vers l’abus de workflows CI/CD et de l’OpenID Connect (OIDC) « trusted publishing » pour publier des paquets malveillants avec une provenance SLSA apparemment valide. Entre le 1er et le 2 juin 2026, un compte GitHub d’un ingénieur Red Hat aurait été compromis, permettant la publication éclair de 32 paquets et 96 versions en quelques heures. Les chercheurs décrivent aussi une ruse réseau: un canal C2 camouflé derrière un chemin inexistant vers « api.anthropic.com/v1/api ».

Les indicateurs de compromission (IOCs) publics incluent notamment des fichiers et hachages faciles à vérifier côté défense : fichiers « .pth » persistants dans les « site‑packages » Python (par ex. « litellm_init.pth », « -setup.pth »), des scripts « _index.js » avec en‑têtes de prompt‑injection, et des SHA‑256 comme dc48b09b2a5954f7ff79ab8a2fd80202bd3b59c08c7cdbc6025aa923cb4c0efe et e1342a80d4b5e83d2c7c22e1e0aaa95f2d88e3dbf0d853a4994b180c93a4b17d pour des variantes « _index.js ». L’analyse insiste : les premières vagues ont exploité la 2FA basée sur OTP, interceptée en direct par phishing, alors que la bascule vers FIDO2/WebAuthn aurait bloqué cette étape d’entrée. Source : Zscaler ThreatLabz, 12 juin 2026.

Le cadre légal qui s’applique

Pour toute entité traitant des données personnelles dans l’UE, l’article 32 du RGPD impose des « mesures techniques et organisationnelles appropriées » compte tenu de l’état de l’art, des coûts, de la nature des traitements et des risques. La sécurité des comptes d’ingénierie, des dépôts de code et des pipelines CI/CD relève directement de cette obligation dès lors que des données personnelles (clients, employés, logs, jeux d’essai contenant des données, etc.) peuvent être touchées par une compromission amont. Référence : EDPB — Article 32 RGPD et CNPD LU — Chapitre IV (dont art. 32).

Côté sécurité publique et secteurs essentiels/importants, la NIS 2 (article 21(2)(j)) énumère explicitement l’usage de la multi‑factor authentication et des communications sécurisées comme mesure de base. Les orientations techniques d’ENISA rappellent que certaines méthodes (SMS/OTP) sont vulnérables aux détournements, et recommandent des facteurs résilients au phishing (FIDO2/WebAuthn) pour les accès sensibles (administration, CI/CD, gestion de secrets). Références : ENISA — NIS2 Security Measures et rappel du texte : NIS 2, art. 21.

La solution technique à déployer

MFA résistante au phishing (FIDO2/WebAuthn) pour les comptes à privilèges et les chaînes de build :

• Principe : authentification par clé publique liée au domaine (origin binding) ; aucun secret réutilisable ni code à saisir ; défi‑réponse local avec signature matérielle ou enclave sécurisée.
• En pratique : activer les passkeys FIDO2/WebAuthn sur GitHub, GitLab, npm, PyPI, registries cloud et accès VPN/SSO ; refuser TOTP/SMS pour les rôles CI/CD, owners d’orgs, comptes de publication, registries et consoles cloud.
• Contrôles associés : politiques de Conditional Access (enrôlement de clés, blocage de « legacy auth »), attestations d’authenticator quand disponible, re‑authentification pour actions sensibles (publication de paquets, rotation de secrets).

Ce que cela adresse face à Shai‑Hulud : les premières intrusions ont exploité l’interception en temps réel d’OTP (AiTM). Avec FIDO2/WebAuthn, une page de phishing ne peut pas valider le challenge car l’origin ne correspond pas. De plus, lier la publication à des clés FIDO2 sur des postes durcis réduit le risque de détournement OIDC par vol de session/token.

Standards de référence : ISO 27001:2022 — Annexe A.5.15 (accès), A.8.2 (gestion des identités), A.8.3 (droits d’accès), A.8.20 (sécurisation réseau logique) ; NIST CSF 2.0 — ID.AM, PR.AC ; CIS Controls v8 — IG1/IG2 sur IAM et MFA.

Comment Luxgap déploie cela

• Notre gouvernance ISO 27001 : cadrage des rôles à haut risque (publication, CI/CD, cloud root), politique MFA « phishing‑resistant by default », procédures d’enrôlement sécurisé (attestation/registre des clés, perte/rotation) et preuves de conformité (journaux d’authentification signés, revues trimestrielles).
• Notre SOC managé 24/7 : corrélation des événements IAM/SSO (enrôlements anormaux, tentatives d’auth hors horaires, échecs répétés FIDO2, appels OIDC inhabituels depuis runners), chasse aux IOCs de Shai‑Hulud dans les hôtes CI/dev (fichiers « .pth », « _index.js », chemins IDE : .vscode/tasks.json, .claude/settings.json), et blocage réseau des artefacts/C2 connus.
• Notre plateforme e‑learning : micro‑modules ciblés pour développeurs et release managers (AiTM, trusted publishing, hygiène des secrets, revue des droits sur pull_request_target), avec attestations utiles en audit RGPD/NIS 2.

Cas concret au Luxembourg ou en UE

Une société fintech établie au Luxembourg (soumise NIS 2 et au RGPD) opérait avec OTP applicatif pour GitHub/npm et autorisait la publication via OIDC depuis ses runners partagés. En six semaines, nous avons : (1) basculé tous les rôles « owner », « publish », « secrets‑admin » et « cloud‑admin » vers FIDO2/WebAuthn matériels ; (2) appliqué des règles de Conditional Access et l’interdiction d’authentification héritée ; (3) segmenté les runners et limité l’OIDC aux audiences prévues ; (4) intégré des détections SOC sur les IOCs Shai‑Hulud. Résultat : publication bloquée sans clé FIDO2 approuvée, traces d’audit complètes pour démontrer la mesure « appropriée » de l’article 32, et réduction documentée du risque d’accès illégitime aux dépôts et secrets.

Premiers pas concrets

1. Activer FIDO2/WebAuthn dès cette semaine pour tous les owners d’organisations GitHub/GitLab/npm/PyPI et pour l’accès aux consoles cloud. Interdire TOTP/SMS sur ces périmètres.
2. Durcir vos workflows OIDC : limiter les audiences et permissions, supprimer pull_request_target non justifiés, épingler versions d’outils CI, restreindre la sortie réseau des runners, et faire une rotation préventive des tokens/npm PATs.
3. Scanner vos postes CI/dev à la recherche des IOCs publiés (par ex. -setup.pth, litellm_init.pth, _index.js avec SHA‑256 listés par Zscaler) et des dossiers IDE suspects (.vscode, .claude, .cursor, .gemini).
4. Journaliser et conserver les événements d’authentification et de publication (qui, quoi, quand, d’où) ; paramétrer des alertes SOC sur enrôlements de clés, changements de facteurs et publications hors heures ouvrées.
5. Former les équipes : module de 30 min sur AiTM et bonnes pratiques de publication (vérification d’origin, signature, revue des secrets) pour développeurs et release ; inclure une session dédiée de sensibilisation cyber.

Sources officielles

• Actualité cyber et IOCs : Zscaler ThreatLabz — « Shai‑Hulud », 12 juin 2026.
• Cadre RGPD : EDPB — Article 32 (Sécurité du traitement) et CNPD Luxembourg — Chapitre IV (dont art. 32).
• Cadre NIS 2 : Texte de l’article 21 NIS 2 et présentation ENISA (mesures NIS 2, MFA incluse) : ENISA — Security Measures under NIS 2.