Une semaine après la publication de son premier rapport sur VoidLink, Check Point fait état de nouveaux éléments inquiétants. Des erreurs opérationnelles auraient exposé la manière dont le framework a été conçu, révélant un développement largement assisté par intelligence artificielle.
Lorsque Check Point a documenté VoidLink pour la première fois, le framework impressionnait déjà par sa maturité et son orientation cloud. Mais de nouveaux éléments publiés par les chercheurs viennent compléter le dossier. En analysant des artefacts laissés par son développeur, ils estiment désormais que l’outil aurait été conçu majoritairement à l’aide d’une intelligence artificielle, sous la supervision d’un seul individu. Une hypothèse étayée par des traces concrètes, et qui ouvre une réflexion plus large sur l’accélération du développement de malwares avancés.
Offre partenaire
Protection avancée des e-mails, des calendriers, des mots de passe, du réseau… de votre entreprise grâce à la suite d'applications professionnelles sécurisées.
Offre partenaire
Des artefacts qui trahissent un développement piloté par IA
Cette nouvelle analyse repose sur une série de failles de sécurité opérationnelles qui ont exposé une partie de l’environnement de développement de VoidLink. Les chercheurs expliquent en effet avoir identifié un répertoire ouvert sur un serveur utilisé par l’acteur malveillant, contenant non seulement du code source, mais aussi de la documentation interne, des plans de développement et des fichiers générés par l’IDE utilisé (environnement de développement intégré qui regroupe éditeur de code, outils de test et fonctions d’assistance).
Ces éléments décrivent un projet structuré autour d’une approche dite de Spec Driven Development, au cours de laquelle on formalise d’abord, très en amont, ce qui doit être construit, avec une architecture complète, des contraintes de développement, des standards de code et des critères de validation, avant de passer à une implémentation très progressive, guidée par cette documentation. Dans le cas de VoidLink, cette documentation, attribuée à un assistant IA intégré à l’IDE, aurait ensuite servi de feuille de route pour générer, tester et faire évoluer le code.
Check Point indique d’ailleurs avoir pu reproduire un flux de travail similaire à partir de cette documentation, confirmant qu’un agent IA est capable de produire un code structurellement très proche de celui de VoidLink lorsqu’il est guidé par des spécifications aussi détaillées.
Mais c’est surtout un point en particulier qui a retenu l’attention des chercheurs. Les documents décrivent un plan de développement étalé sur 30 semaines et réparti entre trois équipes distinctes. Or les artefacts temporels retrouvés, notamment des fichiers de test et des builds compilées, montrent qu’une version fonctionnelle de VoidLink existait déjà moins d’une semaine après le début supposé du projet, avec une base de code atteignant plusieurs dizaines de milliers de lignes.
En clair, ce calendrier « à trois équipes » ne décrit probablement pas un développement réel, mais un plan produit pour cadrer le travail, tandis que l’implémentation a été exécutée à marche forcée, très vraisemblablement par une seule personne épaulée par une IA, d’où ce saut de plusieurs mois théoriques à quelques jours de production.
Une transformation du modèle qui change la lecture du risque
L’intérêt de cette découverte ne tient pas à l’idée que l’IA puisse écrire du code malveillant, un phénomène déjà observé à plus petite échelle et souvent chez des acteurs peu expérimentés. Ce que VoidLink illustre ici, c’est la compression radicale des délais et des moyens nécessaires pour produire un framework avancé, à condition que l’acteur sache formuler les bonnes contraintes et piloter le processus.
On insistera toutefois sur le fait que le niveau technique observé dans VoidLink ne disparaît pas derrière l’IA. Il suppose toujours une compréhension fine des environnements Linux, du cloud et des mécanismes de furtivité.
Pour les équipes en charge de la sécurité des systèmes, il faudra surtout retenir que si ce mode de développement venait à se généraliser, alors des charges offensives complexes pourraient apparaître plus vite, évoluer plus souvent, et se décliner en variantes plus nombreuses, sans forcément s’appuyer sur une organisation lourde. La question n’est donc plus seulement celle des moyens financiers et humains d’un groupe, mais aussi celle de sa capacité à industrialiser une méthode de développement et de mise à jour.
Par conséquent, les solutions de sécurité trop dépendantes d’indicateurs figés perdent en fiabilité. Pour garder une longueur d’avance, il faut aussi miser sur des mesures moins sensibles aux changements de code, et donc de signatures ou d’empreintes, à l’aide de stratégies de surveillance orientées détection des comportements (connexions sortantes inhabituelles, tentatives de persistance sur le système, accès inattendus à des éléments sensibles, etc.) et conserver ses logs hors machine afin que les traces d’activité malveillantes soient déjà centralisées ailleurs lorsque le malware tente de les effacer en local.
Source : Check Point
