Relancé avec de solides promesses en matière de sécurité, Windows Recall fait à nouveau la une des journaux… et pas forcément pour de bonnes raisons. Un chercheur en cybersécurité vient de démontrer qu’il est possible d’exploiter le fonctionnement de la fonctionnalité pour récupérer les données qu’elle enregistre, alors même qu’elles sont censées être protégées.
De son côté, Microsoft se veut rassurant et parle de comportement attendu. Mais cette nouvelle démonstration relance clairement le débat autour de cette fonctionnalité aussi controversée que sensible.
Un outil capable d’exploiter le fonctionnement du Recall
Pour comprendre le problème, il faut d’abord rappeler ce que Rappel Windows (ou « Retrouver » en français). Introduite en mai 2024 avec les PC Copilot+, cette fonctionnalité prend des captures d’écran de votre activité toutes les quelques secondes, analyse leur contenu via OCR et intelligence artificielle, puis stocke le tout dans une base de données cryptée. L’objectif est de pouvoir retrouver n’importe quelle information vue sur votre écran, comme un moteur de recherche pour votre propre activité.
Dès son annonce, Recall a provoqué un tollé. Le chercheur Alexander Hagenah a publié TotalRecall, un script Python qui démontrait qu’à l’époque, les données étaient stockées en clair dans une simple base de données SQLite, accessible sans authentification.
Face au scandale, Microsoft a retardé le lancement et remanié l’architecture : chiffrement AES-256-GCM, enclave VBS (Virtualization-based Security), authentification obligatoire via Windows Hello par reconnaissance faciale, empreinte digitale ou code PIN. Le rappel a finalement été relancé en avril 2025 avec ces garanties.
Alexander Hagenah a récemment publié TotalRecallReloadedune nouvelle version de son outil qui s’attaque cette fois à Recall dans sa version dite « plus sécurisée ». Résultat : il est possible d’extraire toutes les données enregistrées par Recall, sans droits d’administrateur, sans exploit noyau et sans contourner la cryptographie. Et dans certains cas, sans même déclencher une invite Windows Hello.
L’outil est basé sur une technique classique d’injection de DLL. Cible rechargée TotalRecall AIXHost.exele processus responsable de l’affichage de la chronologie du rappel. Ce processus ne bénéficie d’aucune protection particulière : pas de PPL (Protected Process Light), pas d’AppContainer, pas de respect de l’intégrité du code. Tout processus exécuté sous le même compte utilisateur peut y injecter du code, et c’est précisément ce défaut de conception qu’exploite TotalRecall Reloaded.
Une fois à l’intérieurAIXHost.exela charge utile utilise les mêmes API COM que l’interface légitime de Recall pour récupérer les données décryptées : captures d’écran en pleine résolution, texte OCR, métadonnées, URL visitées, titres de fenêtres, chemins de fichiers, temps passé sur chaque application ou site Web. Tout ce que Recall a enregistré depuis l’activation.
L’outil propose plusieurs modes d’utilisation. Le mode --launch simuler un raccourci clavier gagner + J. pour ouvrir Recall, qui déclenche une invite Windows Hello visible par l’utilisateur. Une fois authentifiée, l’extraction démarre silencieusement en arrière-plan.
Le mode --stealth est plus discret. Il corrige une fonction dans AIXHost.exe pour empêcher l’accès aux données d’être révoqué lorsque l’utilisateur ferme Recall, puis attend que l’utilisateur ouvre et ferme Recall de lui-même. L’accès aux données persiste alors en mémoire et l’extraction peut être effectuée à tout moment sans nouvelle invite.
Le mode --wait attend juste que l’utilisateur ouvre Recall naturellement, sans aucune interaction synthétique.
Données accessibles même sans authentification
Au-delà de l’extraction post-authentification, Hagenah a également identifié plusieurs opérations pouvant être effectuées sans aucune invite Windows Hello. Le mode --preauth de TotalRecall Reloaded permet de récupérer la dernière capture d’écran enregistrée par Recall en pleine résolution, jusqu’à 4K, sans que l’utilisateur ait à s’authentifier. Une API initialement destinée à afficher une vignette dans la barre des tâches n’a pas de limite de résolution, ce qui permet de l’utiliser pour extraire l’image complète.
Plus inquiétant encore, la suppression de l’intégralité de l’historique de Recall est également possible sans authentification. La fonction DeleteEvents() efface toutes les données enregistrées sans jamais demander Windows Hello. Hagenah a confirmé via une analyse binaire que la vérification des autorisations n’a tout simplement jamais été intégrée dans ce chemin de code. Un attaquant qui ne pourrait pas lire les données aurait donc la possibilité de les détruire entièrement, ce qui ouvre la porte à des scénarios anti-forensic.
Enfin, il est possible de surveiller l’activité de Recall en temps réel sans authentification, en interrogeant une fonction qui renvoie le nombre de captures réalisées et la taille totale du stockage. De quoi savoir si Recall est actif sur une machine sans jamais avoir à s’y connecter.
Microsoft ne parle pas de failles de sécurité
Hagenah a suivi un processus de divulgation responsable en soumettant ses recherches au Microsoft Security Response Center (MSRC) le 6 mars 2026, accompagnées d’un rapport complet, du code source et des instructions de compilation. Microsoft a ouvert le dossier trois jours plus tard. Après plusieurs semaines d’enquête, la réponse est tombée le 3 avril : le comportement observé n’est pas considéré comme une vulnérabilité. Pour Microsoft, cela est cohérent avec la conception documentée de Recall.
Dans un communiqué envoyé à The VergeDavid Weston, vice-président en charge de la sécurité chez Microsoft, indique que les accès démontrés par l’outil sont cohérents avec les protections existantes et ne constituent pas un contournement des frontières de sécurité. Microsoft met en avant un mécanisme de timeout et une protection anti-hammering pour limiter l’impact des requêtes malveillantes.
Haguena conteste cette lecture. Il souligne que son outil contourne justement ce timeout, et que la promesse initiale de Microsoft, selon laquelle l’architecture empêche les malwares de « profiter » de l’authentification des utilisateurs pour voler des données, ne tient pas dans la pratique. TotalRecall Reloaded a été rendu public le 9 avril, six jours après que Microsoft ait clôturé l’affaire.
L’étendue des données collectées par Recall
Avant de conclure, il est utile de rappeler l’étendue des données que Recall collecte, et donc ce qui est potentiellement extractible via TotalRecall Reloaded. La fonctionnalité ne prend pas seulement des captures d’écran. Il analyse chaque image via OCR pour en extraire tout le texte visible, identifie les entités nommées (personnes, organisations, adresses, adresses e-mail, dates), catégorise le contenu par thème et génère des descriptions en langage naturel de l’activité en cours.
Chaque capture est associée à un ensemble de métadonnées précises : titre de la fenêtre active, nom et chemin de l’application, URL complète du site visité, chemin du fichier ouvert, coordonnées en pixels de la fenêtre, horodatage à la nanoseconde près et durée passée sur chaque application ou site. Les données sont conservées 90 jours par défaut, avec un seuil de stockage de 75 Go.
Cela inclut les e-mails ouverts, les documents consultés, les mots de passe à l’écran, les conversations, l’historique de navigation complet, les commandes saisies dans un terminal. Tout ce qui s’est passé sous les yeux de l’utilisateur depuis l’activation de Recall est potentiellement là, indexé et consultable, y compris par un outil comme TotalRecall Reloaded.
Bien chiffré, mal isolé
Hagenah est le premier à reconnaître que Microsoft a fait du bon travail sur la partie cryptographique. L’enclave VBS est robuste, les clés ne quittent jamais le monde sécurisé, le cryptage par page est techniquement irréprochable et le modèle d’authentification n’a pas échoué malgré des milliers de tentatives. Le problème n’est pas là.
Le problème est ce qui se passe après le décryptage. Une fois les données extraites de l’enclave, elles sont transmises à AIXHost.exeun processus ordinaire, sans protection, accessible à tout code exécuté sous le même compte utilisateur. Hagenah résume la situation avec une déclaration concise : « La porte du coffre est en titane. Le mur à côté est en placo. »
Microsoft pourrait résoudre ce problème en appliquant AIXHost.exe le même niveau de protection que aihost.exeson processus hôte protégé. Ce n’est pas une question de cryptographie, mais d’architecture.
En attendant, la recommandation reste la même que depuis le début : si vous n’avez pas spécifiquement besoin de Recall, désactivez-le, voire désinstallez-le 😊.
