{"id":7840,"date":"2026-04-16T12:18:13","date_gmt":"2026-04-16T12:18:13","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=7840"},"modified":"2026-04-16T12:18:13","modified_gmt":"2026-04-16T12:18:13","slug":"microsofts-windows-recall-still-allows-silent-data-extraction","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=7840","title":{"rendered":"Microsoft\u2019s Windows Recall still allows silent data extraction"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

Microsoft\u2019s Windows Recall feature remains vulnerable to complete data extraction despite a major security overhaul, according to a cybersecurity researcher who says malware running in a user\u2019s context can quietly siphon off everything Recall has captured, without administrator privileges, kernel exploits, or breaking encryption.<\/p>\n

Alexander Hagenah, executive director at Z\u00fcrich-based financial infrastructure operator SIX Group, made the claim in a LinkedIn post, where he also published a proof-of-concept tool called TotalRecall Reloaded to demonstrate the issue.<\/p>\n

Hagenah first exposed Recall\u2019s security flaws in 2024, forcing Microsoft to pull the feature from preview<\/a> and rebuild it. Microsoft relaunched Recall in April 2025, saying the new architecture would restrict \u201cattempts by latent malware trying to \u2018ride along\u2019 with a user authentication to steal data.\u201d Hagenah said it does not.<\/p>\n

\u201cWhen you use Recall normally, TotalRecall Reloaded silently holds the door open behind you and then extracts what Recall has ever captured. That is precisely the scenario Microsoft\u2019s architecture is supposed to restrict,\u201d he wrote in the post<\/a>.<\/p>\n

Hagenah wrote in the post that he disclosed the research to Microsoft\u2019s Security Response Center on March 6, submitting full source code and reproduction steps. Microsoft reviewed the case for a month and closed it on April 3, telling him the behavior \u201cdoes not represent a bypass of a security boundary or unauthorized access to data.\u201d<\/p>\n

\u201cMicrosoft says this is by design,\u201d Hagenah wrote. \u201cThat worries me.\u201d<\/p>\n

Hagenah\u2019s research does not challenge Microsoft\u2019s encryption, which he said is sound. The gap, he told CSO, is in how decrypted data is handled once it leaves the enclave.<\/p>\n

\u201cPlaintext screenshots and extracted text end up in an unprotected process for display,\u201d he told CSO. \u201cAs long as decrypted content crosses into a process that same-user code can access, someone will find a way in.\u201d<\/p>\n

What a fix would require<\/h2>\n

A fix is technically feasible, Hagenah said.<\/p>\n

\u201cThe short-term fix is fairly straightforward. Microsoft could add stronger code integrity and process protections to AIXHost.exe, the process that renders the Recall timeline. Right now, it has none, which makes the injection path possible. That would block the specific technique I demonstrated and materially raise the bar,\u201d he said.<\/p>\n

The longer-term problem runs deeper, he said. \u201cMicrosoft should rethink how decrypted data is handled after it leaves the enclave. The cryptography and enclave design are genuinely well done, and I want to be clear about that. The problem is that plaintext screenshots and extracted text end up in an unprotected process for display. As long as decrypted content crosses into a process that same-user code can access, someone will find a way in,\u201d he said.<\/p>\n

\u201cA durable fix would mean either rendering inside a protected process or adopting a compositing model where raw data never leaves the trust boundary. That is a bigger effort, but it is the only way to close this class of issue properly,\u201d he said.<\/p>\n

Exploitation risk<\/h2>\n

The barrier to weaponizing this technique is lower than Microsoft\u2019s security messaging would suggest, Hagenah said.<\/p>\n

\u201cThey only need code running in the user\u2019s context and a way to reuse the authorized Recall session,\u201d he said. \u201cThat is a much lower bar than many people would assume from Microsoft\u2019s security messaging.\u201d<\/p>\n

While Recall\u2019s limitation to Copilot+ PCs and its opt-in status reduce the scale of exposure, targeted abuse is a realistic near-term risk, he said. \u201cFor targeted abuse, surveillance, or high-value user collection, this is absolutely realistic,\u201d he said.<\/p>\n

Hagenah said he published the source code deliberately so defenders, EDR vendors, and security teams could build detections before threat actors operationalize the technique independently. \u201cIn my view, that gives the defensive side a valuable head start,\u201d he said.<\/p>\n

Independent security researcher Kevin Beaumont reached a similar conclusion after separately testing the current Recall implementation. \u201cYep, you can just read the database as a user process,\u201d Beaumont wrote on Mastodon on March 11<\/a>. \u201cThe database also contains all manner of fields that aren\u2019t publicly disclosed for tracking the user\u2019s activity. No AV or EDR alerts triggered,\u201d he wrote.<\/p>\n

Microsoft did not immediately respond to a request for comment.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

Microsoft\u2019s Windows Recall feature remains vulnerable to complete data extraction despite a major security overhaul, according to a cybersecurity researcher who says malware running in a user\u2019s context can quietly siphon off everything Recall has captured, without administrator privileges, kernel exploits, or breaking encryption. Alexander Hagenah, executive director at Z\u00fcrich-based financial infrastructure operator SIX Group, […]<\/p>\n","protected":false},"author":0,"featured_media":7841,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-7840","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/7840"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=7840"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/7840\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/7841"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=7840"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=7840"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=7840"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}