Avant d’aborder les attaques dites « sans fichiers », il est nécessaire de clarifier ce que recouvre réellement cette notion. Il ne s’agit pas d’attaques dépourvues de toute trace, ni de techniques magiques échappant à toute observation. Il s’agit d’opérations malveillantes qui ne reposent plus sur l’introduction d’un binaire identifiable ou d’un fichier exécutable persistant sur le système ciblé. Elles exploitent au contraire des composants déjà présents, légitimes et autorisés dans l’environnement : interpréteurs de scripts, outils d’administration, navigateurs, API, mécanismes d’automatisation ou chaînes CI/CD. L’attaque ne s’ajoute pas au système, elle s’y confond.
« Ce qui ne laisse pas de fichier n’est pas invisible, mais observé avec de mauvais repères. »
Depuis des années, une grande partie de la détection repose sur une logique matérialisée de la menace. On cherche un objet anormal : un exécutable inconnu, un hash suspect, un fichier déposé dans un répertoire inhabituel. Cette approche a longtemps été efficace, car elle correspondait à la manière dont les attaques se manifestaient. Mais elle atteint aujourd’hui ses limites face à des modes opératoires qui ne produisent plus ces artefacts.
Les attaques dites Living off the Land en sont une illustration emblématique. En s’appuyant sur PowerShell, WMI, des outils de gestion à distance ou des fonctions natives du système, l’attaquant n’introduit rien de nouveau. Il détourne des capacités existantes, souvent indispensables à l’administration quotidienne. Le problème n’est pas l’outil utilisé, mais l’usage qui en est fait. Or distinguer un usage légitime d’un usage malveillant nécessite autre chose qu’une simple comparaison de signatures.
Cette évolution ne concerne pas uniquement les postes de travail ou les serveurs. Les navigateurs web, devenus des plateformes d’exécution à part entière, permettent l’exécution de logiques complexes via du JavaScript obfusqué, du HTML dynamique ou des chargements conditionnels. Là encore, aucun fichier n’est déposé durablement sur l’endpoint. L’attaque vit dans le flux, dans la session, dans l’enchaînement des actions.
Dans ces conditions, parler de « menaces invisibles » est trompeur. Les signaux existent : appels inhabituels, séquences d’actions incohérentes, détournements de fonctions, comportements hors norme. Ce qui fait défaut, ce n’est pas la donnée, mais le cadre d’interprétation.
« La détection moderne échoue moins par manque de signaux que par rigidité de ses modèles. »
L’un des effets les plus marquants des attaques sans fichiers est la mise en défaut des modèles de sécurité hérités. Beaucoup d’outils restent structurés autour de la détection d’objets : fichiers, processus, exécutables. Même lorsqu’ils intègrent des capacités comportementales, celles-ci sont souvent pensées comme un complément, non comme le cœur du raisonnement.
Or les attaques sans fichiers déplacent précisément le centre de gravité. Elles ne cherchent pas à se cacher, mais à se fondre dans le fonctionnement normal du système. Un script PowerShell n’est pas suspect en soi. Un appel API n’est pas anormal par nature. Un pipeline CI/CD qui télécharge une dépendance externe n’est pas un incident. Ce qui devient critique, c’est la combinaison, le contexte, la finalité.
Ce changement expose une tension profonde entre la complexité des environnements modernes et la manière dont la sécurité les observe. Les systèmes d’information sont désormais largement automatisés, distribués, interconnectés. Les flux chiffrés sont la norme. Les dépendances tierces se multiplient. Dans ce contexte, la frontière entre activité légitime et activité malveillante devient plus floue, non parce que l’attaque est plus subtile, mais parce que le système est plus permissif par conception.
Les environnements de développement et de déploiement illustrent bien cette dérive. Les pipelines CI/CD accélèrent la mise en production, mais reposent sur des mécanismes d’exécution automatique, des scripts, des dépendances externes et des accès privilégiés. Lorsqu’un code malveillant ou une dépendance compromise s’insère dans cette chaîne, il n’a pas besoin de déposer un fichier suspect sur un poste utilisateur. Il est exécuté là où il est attendu, par des mécanismes considérés comme de confiance.
Dans ce contexte, la détection basée sur l’objet devient largement insuffisante. Elle ne permet pas de répondre à une question pourtant essentielle : est-ce que ce comportement correspond à ce que ce système est censé faire, dans ce contexte précis ?
« Sans compréhension des usages, le comportement devient indiscernable. »
Les attaques sans fichiers forcent à déplacer le regard. Elles imposent une approche centrée sur le comportement, le contexte et la normalité opérationnelle. Cela suppose de connaître les usages attendus : quels scripts sont exécutés, par qui, à quel moment, avec quels privilèges ; quels flux sont normaux dans un pipeline ; quels appels API sont légitimes dans une application donnée.
Ce déplacement n’est pas uniquement technique. Il met en jeu la gouvernance du système d’information. Observer un comportement anormal n’a de sens que si l’on sait ce qui est normal. Or cette normalité est rarement formalisée. Les scripts se multiplient, les accès s’empilent, les automatisations évoluent sans être documentées de manière exhaustive. Dans ce contexte, la détection comportementale risque de produire du bruit si elle n’est pas adossée à une compréhension claire des usages réels.
Cela explique pourquoi les attaques sans fichiers ne se traduisent pas systématiquement par des alertes exploitables. Les signaux sont là, mais ils ne s’inscrivent pas dans un cadre décisionnel clair. Un accès valide utilisé de manière détournée reste un accès valide. Une commande administrative exécutée par un compte autorisé reste, techniquement, conforme aux règles.
La réponse à ce défi ne réside pas dans l’ajout d’un outil supplémentaire, mais dans un repositionnement de la détection. Il ne s’agit plus seulement de surveiller ce qui entre dans le système, mais de comprendre comment il est utilisé. Cette approche nécessite une journalisation cohérente, une visibilité sur les identités, une maîtrise des privilèges et une capacité à relier les événements entre eux.
Elle suppose également d’accepter une part d’incertitude. Les attaques sans fichiers ne se détectent pas toujours par un indicateur isolé, mais par une accumulation de signaux faibles. Leur identification repose sur la capacité à corréler, à contextualiser et à arbitrer, plus que sur la reconnaissance immédiate d’un artefact malveillant.
Enfin, ces attaques posent une question souvent évitée : celle de la confiance accordée aux outils et aux flux internes. Pendant longtemps, ce qui provenait de l’intérieur du système était considéré comme sûr par défaut. Les attaques sans fichiers montrent que cette frontière n’est plus pertinente. Le risque ne vient pas seulement de l’extérieur, mais de l’abus de mécanismes légitimes.
L’enjeu n’est donc pas de rendre visibles des menaces prétendument invisibles, mais de revoir les hypothèses sur lesquelles repose la détection. Tant que la sécurité restera focalisée sur l’objet plutôt que sur l’usage, les attaques sans fichiers continueront de prospérer dans les interstices du fonctionnement normal.
Ces attaques ne marquent pas une rupture technologique brutale. Elles prolongent une tendance de fond : celle d’un système d’information de plus en plus programmable, automatisé et interconnecté. Les comprendre, c’est accepter que la sécurité ne peut plus se limiter à identifier ce qui n’a pas le droit d’exister, mais doit apprendre à questionner ce qui existe déjà et la manière dont cela est utilisé.
