Archives par mot-clé : pentest

Entreprise

Pentest, audit de sécurité, SOC : quels contrôles auraient pu détecter une attaque comme celle de la DGFiP ?

Une attaque informatique ne commence pas toujours par l’exploitation spectaculaire d’une faille inconnue. Parfois, le pirate emprunte simplement une porte normalement réservée à une personne autorisée. Les accès illégitimes subis par la DGFiP en juin et juillet 2026 illustrent cette difficulté : les intrusions ont été repérées et interrompues, mais l’extraction de données n’a pas été identifiée immédiatement. Face à une telle attaque, le pentest, l’audit de sécurité et le SOC interviennent à des étapes différentes et remplissent chacun une fonction bien précise. Leur efficacité dépend surtout de la façon dont ils se complètent.

L’attaque de la DGFiP révèle plusieurs niveaux de détection

D’après les éléments rendus publics, des identifiants appartenant à un agent et à un tiers habilité ont été usurpés. Les accès obtenus ont permis de consulter et d’extraire des informations relatives à 678 000 particuliers et professionnels, parmi lesquelles figuraient des données fiscales, des coordonnées et certains renseignements cadastraux. Les espaces personnels des contribuables n’ont pas été compromis. Le détail de la méthode employée pour détourner les comptes n’étant pas connu, toute affirmation plus précise sur le point d’entrée resterait hypothétique.

L’incident met surtout en lumière la différence entre la détection d’un accès suspect et celle d’un vol de données. Une entreprise peut donc repérer un compte compromis sans mesurer immédiatement tout ce qu’il a réalisé. Pour évaluer ses propres angles morts, elle peut contacter une entreprise de cybersécurité comme Basom Consulting, qui examinera à la fois les protections préventives, les droits accordés aux utilisateurs et les moyens de surveillance. Cette analyse ne se limite pas à la manière dont un pirate pourrait entrer dans le système. Elle vérifie aussi jusqu’où un compte compromis donne accès aux données et si une activité inhabituelle serait repérée assez rapidement.

Le pentest teste les chemins qu’un attaquant pourrait emprunter

Un pentest, ou test d’intrusion, consiste à confier à des spécialistes la recherche encadrée de moyens permettant de pénétrer dans le système d’information. Ces professionnels se placent dans une situation proche de celle d’un pirate, avec des règles et un périmètre définis à l’avance. Ils essaient notamment de contourner un portail d’accès, d’exploiter une mauvaise configuration ou d’obtenir davantage de privilèges que prévu. Ce travail peut révéler qu’un compte ordinaire ouvre indirectement la voie vers une application sensible ou une base de données mal protégée.

Dans un scénario proche de celui de la DGFiP, le test devrait dépasser la simple recherche de vulnérabilités sur un site internet. Un pentest réalisé avec un compte d’agent ou de prestataire permettrait d’étudier ce qu’une personne malveillante peut accomplir après une connexion réussie. Peut-elle interroger des milliers de dossiers, exporter des fichiers ou passer d’une application à l’autre sans nouveau contrôle ? Le pentest pourrait faire apparaître ces possibilités. En revanche, il ne surveille pas le réseau toute l’année : il fournit une photographie offensive à un moment donné, sur le périmètre réellement testé.

L’audit de sécurité repère les faiblesses moins visibles

L’audit de sécurité couvre un champ plus large que le pentest. Il peut porter sur :

  • l’architecture informatique ;
  • la configuration des équipements ;
  • le code d’une application ;
  • la gestion des accès ;
  • l’organisation interne.

Concrètement, les auditeurs cherchent à savoir si les protections annoncées existent réellement, si elles sont correctement réglées et si les équipes les appliquent. Une politique de sécurité peut, par exemple, exiger la suppression rapide des anciens comptes, alors que plusieurs accès de prestataires restent actifs après la fin de leur mission.

Ce contrôle aurait aussi examiné la séparation entre les services, les applications et les bases de données. Lorsqu’un compte compromis donne accès à un ensemble trop vaste d’informations, le risque ne vient pas uniquement du vol de l’identifiant. Il tient également aux autorisations attachées à ce compte. Un audit des habilitations aurait pu signaler des droits trop étendus, des contrôles insuffisants avant un export ou l’absence de révision périodique des accès. Il aurait également vérifié la conservation des journaux techniques, indispensables pour retracer les consultations et déterminer quelles données ont quitté le système.

Le contrôle des identités doit continuer après la connexion

La double authentification ajoute une preuve au mot de passe, par exemple un code temporaire ou une validation sur un appareil. Elle réduit fortement le risque lié au vol d’un identifiant, sans le faire disparaître. Un faux site peut intercepter une validation en temps réel, une session déjà ouverte peut être détournée et un utilisateur peut approuver une demande trompeuse. C’est pourquoi l’accès ne devrait pas devenir automatiquement fiable dès que les deux étapes ont été franchies. La connexion ne représente que le début du contrôle.

Une protection plus fine tient compte du contexte. Un compte qui se connecte depuis un nouvel appareil, à un horaire inhabituel ou depuis une zone géographique incohérente mérite une vérification supplémentaire. Il en va de même lorsque son comportement change soudainement : recherches répétées, consultation rapide de nombreux dossiers ou téléchargement sans rapport avec ses missions habituelles. Des sessions plus courtes, une nouvelle authentification avant les opérations sensibles et des facteurs résistants à l’hameçonnage compliquent aussi la tâche du pirate. L’objectif consiste à ne jamais confondre identité présentée et confiance définitive.

Le SOC observe les comportements suspects en continu

Le SOC, pour centre opérationnel de sécurité, réunit des analystes, des procédures et des outils chargés de surveiller l’activité informatique. Il reçoit des alertes issues des postes de travail, des serveurs, des applications, des équipements réseau et des services d’authentification. Son intérêt apparaît surtout lorsqu’un attaquant utilise des identifiants valides. Une connexion isolée peut sembler normale. Plusieurs signaux rapprochés peuvent toutefois dessiner un scénario inquiétant, que l’équipe doit reconnaître assez tôt pour limiter les conséquences.

Lors d’une attaque comme celle de la DGFiP, un SOC correctement renseigné aurait pu rechercher des écarts entre l’usage attendu d’un compte et son activité réelle. Un agent consulte habituellement quelques dossiers liés à son service ; son compte en interroge soudain des milliers, avec une cadence inhabituelle. Ce type d’écart doit déclencher une alerte, une suspension temporaire ou une demande de confirmation. Encore faut-il définir les bonnes règles : accumuler des notifications sans priorité finit par masquer les événements véritablement dangereux.

La corrélation des journaux aide à reconnaître une extraction

Chaque composant du système conserve des traces, couramment appelées journaux ou logs. Elles indiquent qui s’est connecté, quelle ressource a été consultée, à quel moment et parfois quelle quantité de données a circulé. Pris séparément, ces éléments paraissent souvent anodins. Une plateforme de corrélation, généralement nommée SIEM, les rassemble afin de faire ressortir des enchaînements suspects. Une authentification inhabituelle, suivie de requêtes nombreuses puis d’un transfert volumineux, devient ainsi plus visible qu’une série d’événements dispersés entre plusieurs applications.

La qualité de ces traces compte davantage que leur simple existence. Si une application enregistre seulement la réussite d’une connexion, l’équipe ne peut pas savoir quels dossiers ont ensuite été ouverts ou exportés. Les journaux doivent donc couvrir les recherches, les téléchargements, les changements de droits et les volumes transmis. Une surveillance du réseau peut compléter cette vue en repérant des flux sortants inhabituels. Des solutions de prévention contre la fuite de données peuvent, quant à elles, bloquer ou signaler le départ d’informations sensibles, même si la personne à l’origine de l’action possède un compte reconnu.

Les habilitations et les quotas réduisent l’ampleur du vol

La détection ne doit pas compenser des droits d’accès excessifs. Le principe du moindre privilège consiste à n’accorder à chaque personne que les autorisations nécessaires à son travail. Il suppose aussi une révision régulière, car les fonctions évoluent, les prestataires changent et certains accès finissent par ne plus avoir de justification. Si un pirate compromet un compte limité, il atteint moins de données et rencontre davantage d’obstacles. Cette réduction du périmètre constitue déjà une protection, même lorsque l’alerte tarde à apparaître.

Des quotas peuvent également encadrer le nombre de dossiers consultés ou exportés sur une période donnée. Leur seuil doit correspondre aux réalités du métier afin de ne pas bloquer les équipes lors d’un pic légitime. Au-delà d’une certaine limite, le système peut ralentir la requête, exiger une validation ou prévenir le SOC. Les applications sensibles gagnent aussi à distinguer la consultation unitaire de l’extraction en masse. Une personne autorisée à vérifier un dossier n’a pas nécessairement besoin de télécharger une base complète. Cette nuance réduit directement les possibilités offertes par un compte usurpé.

L’affaire de la DGFiP rappelle qu’un accès reconnu par le système peut tout de même cacher une activité malveillante. Le véritable enjeu ne consiste donc pas uniquement à empêcher la connexion initiale. Il faut aussi limiter ce que chaque compte peut atteindre, reconnaître les comportements anormaux et conserver assez de traces pour comprendre rapidement l’incident. Le pentest et l’audit préparent le terrain ; le SOC maintient la vigilance au quotidien. Des quotas, des habilitations précises et des journaux exploitables réduisent encore le délai de réaction. La sécurité devient réellement plus solide lorsque ces mesures fonctionnent ensemble et font l’objet de vérifications régulières.

Cybersécurité, Entreprise, Espionnage Spy, Linux, Mise à jour, Securite informatique, Social engineering

ChocoPoC cible les chercheurs en vulnérabilités

Des chercheurs français en cybersécurité ont identifié une campagne sophistiquée utilisant de faux exploits CVE pour infecter les environnements des pentesters avec un cheval de Troie Python.

Une enquête menée par YesWeHack et Sekoia révèle une attaque de chaîne d’approvisionnement visant directement les chercheurs en vulnérabilités. Depuis fin 2025, des acteurs malveillants diffusent de faux dépôts GitHub proposant des preuves de concept pour des failles critiques. Sept dépôts piégés ont été identifiés. Leur installation déclenche des dépendances Python malveillantes capables de déployer ChocoPoC, un RAT conçu pour voler des fichiers, récupérer des identifiants et exécuter des commandes.

Des exploits CVE transformés en pièges

L’affaire débute le 25 juin 2026. Après la publication d’un modèle Nuclei consacré à Joomla JCE, l’équipe de YesWeHack reçoit une suggestion concernant deux preuves de concept associées à une vulnérabilité critique Joomla. L’un des dépôts, consacré à CVE-2026-48908, attire rapidement l’attention.

Son fichier de dépendances réclame un paquet Python inconnu nommé « frint ». Celui-ci installe à son tour « skytext », publié récemment sur PyPI. Le paquet se présente comme une bibliothèque destinée à produire rapidement des couleurs dans un terminal. Son contenu réel est beaucoup moins décoratif.

Skytext distribue des extensions compilées pour Linux et Windows. L’analyse de la version Windows révèle du code obfusqué, une exploration du Process Environment Block, des fonctions résolues dynamiquement et plusieurs blocs chiffrés. Le programme vérifie également son environnement avant d’exécuter son activité malveillante.

Cette précaution complique fortement l’analyse automatisée. Le code recherche notamment la présence d’un fichier portant un nom précis, comme « EXPLOIT_POC.py ». Sans ce contexte, aucune charge utile ne se déclenche. Un échantillon isolé dans un bac à sable peut ainsi sembler inoffensif.

Lorsque les conditions attendues sont réunies, l’extension déchiffre plusieurs composants et modifie l’environnement Python. Elle installe une version détournée du paquet _distutils_hack ainsi que des fichiers .pth. Ces éléments sont ensuite chargés lors du démarrage d’un nouvel interpréteur Python.

Cette persistance permet de lancer choco.py, le téléchargeur intermédiaire de ChocoPoC. Celui-ci récupère une nouvelle charge utile grâce à un jeu de données hébergé chez Mapbox. Les requêtes DNS peuvent passer par DNS-over-HTTPS, notamment via AliDNS ou Cloudflare, afin de contourner certains mécanismes locaux de filtrage.

Le trafic conserve par ailleurs l’apparence d’une connexion légitime vers l’API Mapbox. Cette infrastructure sert de point mort pour récupérer le RAT et échanger des informations, réduisant la visibilité du canal de commande.

Une campagne pensée pour les outils offensifs

Le dernier étage de l’infection est un RAT (logiciel espion) écrit en Python. ChocoPoC peut collecter des données issues de Chrome, Brave, Edge et Firefox, notamment les mots de passe, cookies, historiques et informations de remplissage automatique.

Il recherche également certains fichiers locaux, des bases de données, des historiques de commandes shell, des informations réseau et la liste des processus actifs. L’opérateur peut lancer des commandes système, exécuter dynamiquement du code Python, récupérer des fichiers ou modifier la fréquence des communications avec le serveur de contrôle.

L’enquête a permis d’identifier au moins sept dépôts GitHub malveillants associés à des vulnérabilités très médiatisées. Les leurres visaient notamment FortiWeb, React2Shell, MongoBleed, PAN-OS, Ivanti Sentry, Checkpoint VPN et Joomla SP Page Builder.

Deux chaînes de dépendances apparaissent. En 2025, plusieurs dépôts utilisaient les paquets « slogsec » et « logcrypt.cryptography ». En 2026, les opérateurs ont privilégié « frint » et « skytext ». Malgré ces changements, YesWeHack et Sekoia relèvent plusieurs caractéristiques communes, dont le même identifiant de fonctionnalité Mapbox, des contrôles environnementaux similaires et des mécanismes identiques contre les relances récursives.

Ces éléments conduisent les chercheurs à attribuer avec une forte confiance les deux périodes d’activité au même acteur. Selon leur analyse, l’opérateur aurait régulièrement changé de comptes GitHub, PyPI et Mapbox pour limiter les blocages et compliquer le suivi de son infrastructure.

Les adresses électroniques utilisées pour certaines publications semblent également liées à des comptes compromis. Des identifiants concernant deux des quatre adresses étudiées figuraient dans des bases de données de fuites, dont l’une probablement issue d’une infection par infostealer.

Les statistiques de téléchargement renforcent l’inquiétude sans démontrer, à elles seules, une compromission. Le paquet skytext aurait enregistré environ 2 400 téléchargements sur Linux et Windows, avec une majorité sous Linux. Plusieurs hausses coïncident avec la divulgation ou l’exploitation publique de vulnérabilités importantes.

Le risque dépasse donc la seule machine d’un chercheur. Un pentester compromis peut manipuler des identifiants clients, des rapports confidentiels, des données techniques sensibles ou des informations concernant des systèmes vulnérables.

ChocoPoC illustre ainsi une évolution préoccupante du renseignement cyber : le code visible peut rester crédible tandis que l’infection se déplace vers les dépendances, transformant l’urgence autour des nouvelles CVE en véritable surface d’attaque.

Cybersécurité, Entreprise

YesWeHack automatise le pentest par agents IA

YesWeHack lance un pentest piloté par IA agentique, capable de tester des actifs exposés et de livrer des résultats dans la journée.

L’IA agentique désigne des systèmes capables d’agir par étapes, avec un objectif, des outils et une part d’autonomie opérationnelle. Dans le cas de YesWeHack, ces agents ne se contentent pas de signaler une faiblesse théorique. Ils examinent des actifs accessibles, cherchent des vulnérabilités, évaluent leur exploitabilité et reconstituent des chemins d’attaque. Cette approche traduit une évolution majeure de la sécurité offensive : le test d’intrusion devient plus continu, plus rapide et plus industrialisé. L’humain reste toutefois nécessaire pour valider les alertes, traiter les cas complexes et guider la remédiation.

Une sécurité offensive à vitesse machine

YesWeHack a annoncé, le 25 juin 2026, le lancement de son Pentest Agentique, une offre qui mobilise des agents d’intelligence artificielle autonomes à la demande. L’objectif affiché est clair : tester les actifs exposés d’une organisation et fournir des résultats le jour même, à mesure que les vérifications avancent dans la plateforme.

Le terme IA agentique mérite d’être clarifié, car il est central dans cette annonce. Il ne s’agit pas d’une intelligence artificielle argentique, liée à l’image ou à la photographie, mais d’une IA agentique, c’est-à-dire orientée vers l’action. Un agent reçoit un but, suit des consignes, utilise des outils, observe les résultats, ajuste sa démarche et poursuit ses tests dans un cadre défini. Dans un contexte cyber, cela signifie qu’il peut enchaîner reconnaissance, détection, vérification et qualification d’une faille, sans attendre une instruction humaine à chaque étape.

La plateforme française applique cette logique aux applications web et mobiles, aux API et aux autres actifs visibles depuis Internet. Les tests peuvent être menés en boîte noire, grise ou blanche. En boîte noire, l’agent agit sans information interne. En boîte grise, il dispose d’éléments partiels. En boîte blanche, il travaille avec une connaissance plus complète du système. Ces trois modes couvrent différents niveaux de réalisme et de profondeur, selon les objectifs de sécurité.

YesWeHack indique que son offre cible les vulnérabilités à fort impact, dont le Top 10 de l’OWASP, ainsi qu’un ensemble plus large de vecteurs d’attaque. Les agents s’appuient sur les modèles les plus avancés disponibles pour les tests offensifs, y compris des modèles à poids ouverts. Cette précision compte pour les organisations soumises à des contraintes de souveraineté, d’hébergement ou de gouvernance. L’éditeur évoque ainsi la possibilité de recourir à des modèles développés ou hébergés en Union européenne ou en Asie-Pacifique, selon les besoins.

Cette automatisation répond à une pression croissante. Les attaquants utilisent eux aussi l’intelligence artificielle pour accélérer leurs recherches, adapter leurs scénarios et réduire le délai entre la divulgation d’une faille et son exploitation. La sécurité offensive suit donc le même mouvement que la défense : passer d’un rythme humain, souvent périodique, à un rythme machine, plus proche de l’exposition réelle.

Un complément, pas un remplacement de l’expert

Le Pentest Agentique fonctionne dans un cadre de règles fixé par YesWeHack, afin de préserver la confidentialité, l’intégrité et la disponibilité des systèmes testés. Cette limite est essentielle. Un test offensif automatisé doit produire du renseignement exploitable sans déstabiliser les environnements visés. La promesse porte sur la vitesse, la couverture et la capacité de passage à l’échelle, pas sur une liberté totale d’action.

L’éditeur maintient d’ailleurs ses Pentests Continus en parallèle. Cette distinction éclaire le positionnement du produit. Les agents traitent le volume, accélèrent le criblage et priorisent les failles exploitables. Les experts humains conservent leur rôle sur les vulnérabilités difficiles, les logiques métier subtiles et les chaînes d’exploitation sophistiquées. Autrement dit, l’IA agentique peut élargir le champ de détection, sans absorber toute la finesse de l’analyse offensive.

Les résultats sont intégrés dans la plateforme YesWeHack, aux côtés des autres services de l’éditeur : programmes de prime aux bogues, Pentests Continus, politiques de divulgation des vulnérabilités et points de contrôle liés aux CVE activement exploitées. Les équipes de sécurité peuvent aussi solliciter le triage de YesWeHack, disponible en continu, pour vérifier, reproduire et enrichir les rapports. L’éditeur présente cette validation humaine comme le moyen d’éviter les faux positifs.

Guillaume Vassault-Houlière, PDG et cofondateur de YesWeHack, inscrit ce lancement dans une stratégie élargie. Selon lui, « Le Pentest Agentique est plus rapide et plus simple à mettre en place et à exécuter que les pentests traditionnels menés par des humains, tout en offrant une couverture plus large, la capacité de passer à l’échelle et des coûts réduits« . Il ajoute sur Linkedin qu’une stratégie offensive doit rester diversifiée, avec les programmes de prime aux bogues et l’expertise de la communauté comme piliers d’une posture proactive.

Pour un RSSI, l’enjeu dépasse l’ajout d’un outil. Un agent qui classe les vulnérabilités selon leur exploitabilité réelle participe à la priorisation du risque. Cette délégation change le pilotage opérationnel : la machine produit une lecture du danger, que l’équipe doit comprendre, contester ou transformer en plan d’action. Le responsable sécurité gagne en fréquence de contrôle, avec une visibilité plus rapide sur les actifs exposés, mais il doit aussi surveiller la dépendance à une plateforme et à ses modèles.

Le modèle économique évolue lui aussi. Le pentest n’est plus seulement une mission ponctuelle, encadrée dans le temps, facturée comme une prestation isolée. Il devient une fonction permanente de gestion de l’exposition. Cette continuité apporte une réponse aux équipes saturées par l’élargissement de leur surface d’attaque. Elle ne remplace toutefois pas l’audit indépendant, encore requis dans plusieurs démarches de conformité.