Vers une exécution furtive : Peut-on vraiment attaquer sans mémoire ni API ?

Et si le code malveillant n’utilisait ni RAM ni API ? Ce scénario radical, encore théorique, redéfinit les limites de la détection. Bienvenue dans l’univers du Stealth Computing.

Un paradigme à contre-courant

La cybersécurité repose sur un principe fondamental : surveiller ce qui est observable. Mémoire, appels système, processus, accès disque — tout est logué, analysé, scoré. Mais que se passe-t-il si une charge malveillante parvient à s’exécuter sans jamais apparaître là où on l’attend ? C’est la promesse du Stealth Computing : un modèle d’exécution qui contourne à la fois la mémoire conventionnelle et les interfaces logicielles standards.

Il ne s’agit pas ici de packers ou de techniques d’obfuscation connues. On parle d’un code qui évite sciemment l’allocation de mémoire dans l’espace utilisateur, qui ne fait pas appel aux API Windows classiques, et qui peut — en théorie — vivre et mourir sans jamais laisser de trace exploitable pour un EDR moderne. Une chimère ? Peut-être. Une piste sérieuse pour la recherche défensive ? Assurément.

Et si le meilleur moyen de ne pas être détecté n’était pas de se cacher… mais de ne jamais exister aux yeux des outils de détection ?

Mémoire et API : angles morts des solutions actuelles

Les EDR et XDR modernes se basent principalement sur la télémétrie issue des appels système, des signatures comportementales, et des anomalies mémoire. Ces capteurs excellent dans la détection des techniques connues : injection de DLL, hollowing, shellcode, etc. Mais leur périmètre reste borné par des hypothèses implicites : que le code s’exécutera quelque part en mémoire, et qu’il fera appel à des fonctions traçables.

Cela ouvre une brèche conceptuelle : si une charge utile peut éviter toute interaction explicite avec ces surfaces observables, elle échappe par définition à ces modèles de détection. C’est là qu’intervient la recherche sur des modes d’exécution alternatifs : code éphémère dans les registres CPU, exécution à partir de structures existantes du noyau, ou utilisation de périphériques comme vecteurs d’instructions.

Des idées extrêmes, mais pas absurdes

L’idée d’une exécution sans mémoire peut sembler absurde au premier abord. Pourtant, des travaux en rétro-ingénierie, comme ceux portant sur l’utilisation des registres SIMD ou des buffers matériels pour stocker temporairement du code, montrent que des fragments d’exécution transitoires sont techniquement possibles. De même, l’abus de comportements non documentés dans certains microcontrôleurs ou chipsets ouvre la porte à des formes de persistence purement matérielles.

Certes, ces scénarios restent aujourd’hui plus proches du laboratoire que du terrain. Mais ils mettent en lumière une limite fondamentale : nos outils de sécurité sont majoritairement conçus pour surveiller des logiciels. Or, à mesure que l’attaque migre vers le firmware, les micro-architectures, voire les interactions physiques, cette vision devient insuffisante.

Et maintenant ? Vers une nouvelle génération de détection

Le Stealth Computing nous pousse à envisager des mécanismes de défense moins dépendants de la mémoire ou des API, et plus centrés sur le comportement global du système. Par exemple : corrélation fine entre activité CPU, latences anormales, interruptions déclenchées de manière non conventionnelle, ou empreintes énergétiques atypiques sur certains bus matériels.

Ce champ est encore jeune, mais il appelle à une collaboration entre disciplines : sécurité, architecture matérielle, systèmes embarqués. Les attaques sans trace ne sont pas encore une réalité massive, mais elles dessinent déjà les contours de la cybersécurité de demain : plus bas niveau, plus matérielle, et plus difficile à contourner. Il est temps de s’y préparer.