Veille Cyber #5 : identités, secrets, services cloud

Des identifiants bien réels, deux fuites invisibles à la DGFiP#

Le 29 septembre , l’ANSSI publie le rapport d’une investigation menée à la demande du Premier ministre : reconstituer la chronologie des activités illégitimes de mai à août 2026 dans les systèmes de la DGFiP, impots.gouv.fr et le cadastre, et identifier les mesures qui auraient permis de les prévenir ou de les détecter. Remis le 24 septembre , ce rapport ne se limite donc pas à constater l’incident ; les revendications, elles, datent des 12 et 13 août . La cause n’est pas une faille exotique : des identifiants légitimes, volés sur des équipements personnels, ont servi à se connecter à des portails sensibles sans authentification forte (MFA, la vérification de l’identité par plusieurs facteurs).

Pourquoi ça compte ? Les deux vagues d’exfiltration (le vol de données vers l’extérieur du réseau) ont échappé à la détection, côté DGFiP comme côté ANSSI. L’investigation révèle aussi un problème plus large : les applications sensibles étaient exposées sur Internet ou accessibles depuis le Réseau interministériel de l’État (RIE) sans cloisonnement suffisant , et un rebond depuis l’Éducation nationale a effectivement eu lieu. Le risque dépasse donc le périmètre DGFiP : une latéralisation (le déplacement d’un attaquant depuis une ressource compromise vers d’autres ressources accessibles) entre ministères.

Honnêtement, ce qui me frappe, c’est que personne n’a eu besoin de casser quoi que ce soit. Une authentification réussie ne suffit jamais à innocenter une session : il faut aussi vérifier droits et contexte de connexion. Le MFA, la segmentation et la supervision répondent à trois problèmes différents, et c’est ce triptyque qui a manqué ici. Un plan correctif a été défini avec la DGFiP, avec des pistes pour la détection et la coordination interministérielle, sans indication sur leur déploiement effectif.

Source : ANSSI, synthèse officielle et accès au rapport, 29/09 ↗ ↗. Recoupement : Anadolu, 29/09 ↗ ↗.

Un secret publié reste une clé, même après coup#

Le 29 septembre 2026, Truffle Security a publié l’analyse de The Stack v3, un corpus de code public assemblé pour entraîner des modèles d’IA : 224 millions de dépôts GitHub et 58 milliards de fichiers, capturés en août 2025 et limités à la branche par défaut de chaque dépôt (sa version principale). Testés un par un auprès des services qui les avaient émis, les 27 et 28 juillet 2026, 543 699 identifiants fonctionnaient encore , près d’un an après la capture.

Clés Gemini, accès AWS, chaînes de connexion à des bases MongoDB : la moitié de ces secrets traînaient en public depuis plus de deux ans, le plus ancien depuis 2009. Et plus de la moitié (51,8 %) échappent au blocage automatique de GitHub .

Pourquoi ça compte ? Ce chiffre mesure une validité constatée lors des tests de juillet 2026, pas une validité garantie aujourd’hui, et il ne mesure ni victimes ni exploitations avérées. Il rappelle surtout qu’empêcher de nouveaux commits (les enregistrements de modifications dans un dépôt de code) ne révoque jamais les secrets déjà divulgués.

J’avoue que c’est le genre de chiffre à coller au-dessus de chaque terminal. Si vous retrouvez un secret dans un dépôt, la bonne réaction n’est pas d’effacer le fichier : c’est de le révoquer ou de le renouveler auprès de son émetteur, en invalidant l’ancien.

Source : Truffle Security, étude et méthode, 29/09 ↗ ↗. Recoupement : BleepingComputer, 30/09 ↗ ↗.

Antino : une porte dérobée pilotée via une messagerie Microsoft 365, mais pas la vôtre#

Avant le schéma : cette porte dérobée passe par Microsoft Graph, l’API (l’ensemble de règles qui fait communiquer deux logiciels) des services Microsoft 365, pas par votre boîte mail.

Le 30 septembre, Cisco Talos publie son analyse d’UAT-11587, une activité visant des organismes gouvernementaux en Asie, observée de septembre 2025 à juillet 2026, diffusée notamment par courriels ciblés. La porte dérobée qui en résulte, Antino, compilée en Rust (un langage de programmation) pour Windows, utilise cette API : une boîte Outlook contrôlée par l’attaquant pour recevoir les commandes, et OneDrive pour les transferts de fichiers.

Pourquoi ça compte ? Antino exécute des commandes, collecte des données, exfiltre des fichiers et reste actif durablement sur la machine, ce qu’on appelle la persistance. Talos recense au moins 16 environnements touchés ou ciblés dans huit pays, sans établir 16 compromissions confirmées. Le lien avec la Chine reste une évaluation à confiance élevée, pas une certitude ; cela ne démontre pas une compromission de Microsoft lui-même.

Ce qui me marque, c’est à quel point un domaine Microsoft autorisé peut endormir la vigilance : un flux vers graph.microsoft.com n’est pas bénin simplement parce qu’il va vers Microsoft.

Source : Cisco Talos, analyse Antino, 30/09 ↗ ↗. Recoupement : The Hacker News, 02/10 ↗ ↗.

Pourquoi on vous la pose : pour évaluer votre capacité à distinguer une identité authentifiée d’un comportement attendu, sans conclure à partir du seul nom de domaine.

Comment y répondre : précisez d’abord l’heure, le poste et le compte concernés. Corrélez ensuite les authentifications, le processus parent et les flux sortants.

Posez des hypothèses, puis cherchez ce qui les confirme ou les réfute. Si la compromission est étayée, proposez l’isolement du poste avec les responsables ; pour un secret exposé, coordonnez révocation et remplacement. Ne bloquez pas Microsoft 365 à l’aveugle : c’est une trame, pas un verdict.

À vendredi prochain. En attendant, un bon réflexe reste simple : avant de faire confiance à une connexion, vérifiez à qui elle appartient vraiment. Lénaïck