Microsoft Recall Flaw Exposes Decrypted User Data, Researchers Find

10 de Abril de 2026, 04:44

TotalRecall

When Microsoft reintroduced its redesigned Recall feature, security took center stage. The architecture was built around hardened components, including Virtualization-Based Security (VBS) enclaves, AES-256-GCM encryption, Windows Hello authentication, and a Protected Process Light (PPL) host. On paper, this layered approach suggested a tightly sealed system where sensitive data, screenshots, OCR text, and metadata would remain protected at every stage. However, findings from TotalRecall Reloaded reveal that, while the vault itself is secure, the path data that results from decryption raises serious concerns.

A Strong Core with a Fragile Edge

Recall’s encryption model is technically sound. Data resides inside a secure enclave, with cryptographic keys never leaving its boundary. The use of AES-256-GCM encryption ensures both confidentiality and integrity. But the weakness does not lie in storage; it lies in how decrypted data is handled once it exits the enclave. The process responsible for rendering Recall’s timeline, AIXHost.exe, lacks the protections applied elsewhere. Unlike aihost.exe, which runs under PPL, AIXHost.exe operates without PPL enforcement, AppContainer isolation, or strict code integrity checks. This creates a critical gap where other processes running under the same user account can interact with it. Once a user authenticates through Windows Hello, decrypted Recall data begins flowing through AIXHost.exe. At that moment, the system implicitly trusts everything inside that process, whether legitimate or malicious.

How TotalRecall Exploits the Gap

TotalRecall Reloaded takes advantage of this trust boundary issue. It uses a classic DLL injection technique to embed itself into AIXHost.exe. The tool consists of two parts: an injector (totalrecall.exe) and a payload DLL (totalrecall_payload.dll). Using standard Windows APIs like CreateToolhelp32Snapshot, VirtualAllocEx, WriteProcessMemory, and LoadLibraryW, injects code into the target process. No administrative privileges or kernel exploits are required. The attack relies entirely on user-level permissions and legitimate system functionality. This is important because Windows allows processes under the same user to interact freely by default.

Authentication: Timing Instead of Bypassing

Importantly, TotalRecall Reloaded does not bypass Windows Hello. Instead, it waits for authentication to occur naturally or triggers it indirectly. In “launch” mode, it simulates the Win+J shortcut, prompting the user to authenticate. Once authenticated, decrypted data becomes accessible. In “stealth” mode, the tool modifies the DiscardDataAccess function so that access is never revoked after Recall closes. It then waits for normal user activity and begins extraction silently, without triggering another authentication prompt. A third mode, “wait,” simply monitors for Recall activity and acts once authentication occurs.

What Data Gets Extracted

Once embedded, the payload uses Recall’s own internal COM interfaces to extract data. This includes:

Full-resolution screenshots (PNG format)
OCR text, including lines and individual words with pixel-level bounding boxes
Metadata such as application names, URLs, timestamps, and window dimensions
Named entities like people, locations, and email addresses
AI-generated activity descriptions

Recall captures data every few seconds, building a detailed behavioral profile. It stores this in an encrypted SQLite database (ukg.db) protected by AES-256-GCM encryption. Default retention is 90 days with a 75 GB storage limit. The dataset includes everything from browser activity and document edits to terminal commands and messaging conversations, fully indexed and searchable.

Pre-Authentication Concerns

Some functions exposed by Recall do not require Windows Hello authentication at all. For example, GetRecentCaptureThumbnail can return a full-resolution screenshot simply by requesting a large size. Similarly, IDataStoreManager::DeleteEvents allows complete deletion of the recall history without authorization checks. Additional metadata, such as storage paths, database size, and capture counts, can also be accessed without authentication. Microsoft’s design assumes that data remains safe within the enclave and PPL-protected processes. However, once decrypted data reaches AIXHost.exe, that assumption no longer holds. There is no verification of which code is making requests inside AIXHost.exe. Whether it’s legitimate UI logic or injected malware, the system treats all requests equally. This effectively ends the trust boundary too early, leaving decrypted data exposed.

Inconsistent Access Controls

Further issues arise from inconsistent COM interface protections. Some methods enforce access restrictions properly, returning errors when accessed without authorization. Others, such as alternate interface versions, allow access to the same data without checks. This inconsistency enables attackers to bypass intended safeguards by simply calling different interfaces. Once Windows Hello authentication is completed, the authenticated state is cached in the PPL-protected aihost.exe for the entire Windows session. Restarting AIXHost.exe does not reset this state. By patching the DiscardDataAccess function, TotalRecall Reloaded ensures that access persists indefinitely. Even after Recall is closed, the tool can reinject itself and continue extracting data without further prompts or user awareness.

The Bigger Picture

Recall’s underlying technologies—VBS enclaves, AES-256-GCM encryption, TPM-backed keys, and Windows Hello- are implemented correctly. The issue is not cryptographic weakness or flawed authentication. It is the decision to pass decrypted data into a process that lacks equivalent protections. In simple terms, the vault is secure, but once opened, its contents are left unguarded. This research was submitted to the Microsoft Security Response Center (MSRC) on March 6, 2026. After review, the case (109586) was closed on April 3, 2026, as “Not a Vulnerability.” Microsoft stated that the observed behavior aligns with the system’s documented security design.

Tested Environment

OS: Windows 11 25H2 (Build 26300.8155)
Architecture: ARM64
AIXHost.exe version: 2126.7602.0.0
Privilege level: Standard user (medium integrity, no elevation)

Visualização normal

Why a Windows Hello PIN Beats a Password for Enterprise Security