Microsoft Recall: anatomía de un launch sin threat modeling

El 20 de mayo de 2024, en el evento de presentación de Copilot+ PCs en Redmond, Microsoft anuncia Windows Recall. La idea: el SO captura cada pocos segundos un screenshot del escritorio, le pasa OCR y embeddings con un modelo local, y deja todo indexado para búsqueda semántica. “Recuérdame esa receta de pasta que vi la semana pasada”, “abre el documento donde aparecía la cifra de Q3”. Vendido como photographic memory del PC.

Dos semanas después, Kevin Beaumont publica el análisis en DoublePulsar. La base de datos de Recall es una SQLite plana en el perfil del usuario, sin DPAPI, sin protección a nivel de proceso. Cualquier proceso con los permisos del usuario lee toda la historia visual del equipo. Alex Hagenah suelta una herramienta (TotalRecall) que automatiza la extracción en segundos. James Forshaw (Project Zero) confirma que ni siquiera hace falta elevación. El 7 de junio Microsoft retrocede: Recall pasa a opt-in, se exige Windows Hello, se cifra la base de datos, y se retrasa la disponibilidad para Insiders.

Esta entrada no es PoC en lab montado por nosotros (Recall vivió solo en Copilot+ PCs y la base de Beaumont/Hagenah está documentada en sus repos). Lo que hacemos aquí es threat modeling sobre un producto que se anunció listo para producción y resultó ser un dataset de exfiltración a la espera de ser leído.

El producto

Lo que Microsoft enseñó el 20 de mayo:

• Captura periódica del escritorio. Snapshots cada pocos segundos (Microsoft no dio cifra exacta en el anuncio; análisis posterior estimó ~5s) mientras el usuario trabaja.
• OCR sobre cada captura. El texto visible en pantalla (emails, mensajes de Signal/WhatsApp Web, código en VS Code, contraseñas de gestores que se ven al copiar, números de tarjeta en checkout) se extrae y se indexa.
• Embeddings + búsqueda semántica. El usuario puede consultar en lenguaje natural “the article about quantum computing I read” y Recall navega al timestamp donde apareció.
• Procesado local. Microsoft insiste en que nada sale del dispositivo. Es cierto: el dato no se envía a la nube, vive en %localappdata%. El problema es exactamente que vive ahí y cómo vive.

Lo que el anuncio no dijo, y lo que aparece en el análisis técnico de finales de mayo: dónde se guarda, en qué formato, y bajo qué garantías.

Threat modeling — el ejercicio que faltó

Tres actores que cualquier threat modeling decente habría enumerado en la pizarra antes del primer commit:

1. Malware con permisos de usuario. El escenario más común. Infostealer (RedLine, Vidar, Lumma, los que se compran por $200/mes en foros) corriendo en el contexto del usuario. No necesita admin, no dispara UAC.
2. Insider con acceso físico breve. Alguien con 30 segundos delante del laptop desbloqueado: un compañero de oficina hostil, un hotel staff, una pareja en proceso de divorcio. Copia %localappdata%\CoreAIPlatform.00\ a un USB. Ya lo lee tranquilo en casa.
3. Robo / pérdida del laptop. El modelo de amenaza de toda la industria desde 2010. Aquí no agravado porque BitLocker está activo… pero solo mientras el atacante no consiga el password.

Para cada actor, dos preguntas. ¿Qué necesita para leer el historial visual completo del usuario? ¿Qué tendría que costarle?

Lo que Beaumont y Hagenah enseñan a finales de mayo: en los tres casos, el coste es trivial. Y Microsoft no había puesto barreras.

Dónde vive el dato

Lo que Hagenah documenta en TotalRecall (repo público GitHub, 4 de junio de 2024):

C:\Users\<USER>\AppData\Local\CoreAIPlatform.00\UKP\{GUID}\ukg.db

ukg.db es una SQLite estándar. Sin DPAPI, sin SQLCipher, sin EFS, sin nada. Las tablas relevantes que enumera el README:

• WindowCaptureTextIndex_content: texto OCR extraído de cada captura, en plaintext.
• App: el binario que tenía foco en cada momento.
• Window: título de la ventana cuando se hizo la captura.

Adicionalmente, en el mismo directorio se guardan los PNG de las capturas en ImageStore/. Sin cifrar.

El flujo de extracción que TotalRecall implementa cabe en cuatro líneas conceptuales:

# (Conceptual — sobre una copia de la DB extraída)
sqlite3 ukg.db ".tables"
# WindowCaptureTextIndex_content  App  Window  WindowCapture ...

sqlite3 ukg.db "SELECT c1 FROM WindowCaptureTextIndex_content LIMIT 10;"
# (devuelve texto OCR — mensajes, código, contraseñas visibles, lo que sea)

El primer release de TotalRecall asumía admin para esquivar las ACLs del directorio. James Forshaw publica en X (versión corta) que esa asunción es innecesaria: el token del usuario propietario del perfil ya tiene los permisos necesarios; basta con cargar el contexto adecuado. Su frase exacta: “Turns out I was wrong about Recall being secure.” TotalRecall se actualiza a las 48 horas siguiendo esa nota y deja de pedir admin.

Resultado neto: un proceso ejecutándose como el usuario actual lee toda la historia visual del equipo en menos de un segundo. No hay UAC, no hay diálogo de consent, no hay log de auditoría. Recall es transparente al proceso.

Asunciones rotas

El diseño de Recall asume cosas que no son ciertas en Windows desktop:

• Asunción 1: “si vive bajo el perfil del usuario, está protegido por las garantías del perfil del usuario”. Esta es la versión hand-wave del modelo. En Windows, cualquier código que ejecute el usuario tiene los mismos privilegios que el usuario. Recall convierte una infección estándar (un PDF malicioso, una extensión de navegador comprometida, un instalador NPM con postinstall) en exfil completo del historial visual con coste cero adicional. DPAPI existe precisamente para meter una barrera entre “el usuario me ejecutó” y “el usuario quiere darme su credencial maestra”. Recall no la usó.

• Asunción 2: “el dato local es seguro porque no sale del dispositivo”. Esta es la frase favorita de los press releases on-device AI. El problema es que lo local es exactamente lo que el malware del usuario lee primero. La amenaza moderna no es un sniffer en el cable; es un infostealer que recorre %appdata% y %localappdata% durante 15 segundos antes de borrarse. La concentración del dato (todo el historial en una SQLite indexada y búscable) convierte el local en mejor crown jewel que cualquier vault remoto.

• Asunción 3: “BitLocker resuelve el at-rest”. Resuelve el robo del laptop apagado. No resuelve nada cuando el usuario está sentado delante, ni cuando un proceso en el contexto del usuario está leyendo. BitLocker es ortogonal a este modelo de amenaza.

Lo grave no es que el diseño tuviera estos huecos: el diseño temprano de muchas features los tiene. Lo grave es que se anunció como ready to ship con fecha de salida (18 de junio en los primeros Copilot+ PCs) sin un threat model público que cubriera estos tres actores. La pregunta que un revisor de seguridad razonable plantea en sprint review (“qué pasa si un infostealer normal corre como el usuario”) produce, en este diseño, el peor resultado posible.

La marcha atrás

El 7 de junio, Pavan Davuluri (President, Windows + Devices) publica en Windows Experience Blog los cambios:

• Opt-in por defecto. Recall ya no se instala activado en los Copilot+ PCs. Hay que aceptar explícitamente durante el setup.
• Windows Hello obligatorio para activar Recall. Sin biometría / PIN configurados, no hay Recall.
• Proof of presence para consultar el timeline. No basta con sesión iniciada — hay que reautenticar con Hello para que se descifren snapshots.
• Cifrado just-in-time con Enhanced Sign-in Security (ESS). Las capturas se descifran solo durante la sesión autenticada del usuario. Cifrado del search index database.
• Retraso del lanzamiento. Lo que iba a salir el 18 de junio se mueve a Insiders. Disponibilidad pública vuelve a retrasarse en agosto (octubre) y otra vez en octubre (diciembre).

Lo que enseña la lista: las tres asunciones rotas tienen un parche correspondiente. Falta DPAPI/ESS → encryption. Falta una barrera entre “el usuario está logged in” y “el dato es accesible” → Hello proof-of-presence. Falta opt-in para hacer ineficaz el escenario “mi madre compra un Copilot+ PC y no sabe que existe Recall” → opt-in.

Ninguno de esos cambios es difícil. Todos son obvios para cualquiera que haya escrito un threat model durante una review interna. El problema no fue capability técnica; fue de proceso.

Lecciones operativas — para producto, no para press release

Sin sermón. Tres lecturas que nos sirven para el siguiente producto AI que toque revisar:

1. On-device no es secure-by-default. El argumento “se procesa en local” es de privacidad respecto a la nube, no de seguridad respecto al malware local. Cualquier feature que cree un dataset estructurado del comportamiento del usuario en disco es crown jewel para infostealers. Si va a vivir local, vive cifrado at-rest con clave derivada de credencial del usuario (DPAPI / ESS / claves protegidas por TPM + Hello), y solo se descifra durante uso autenticado.

2. Captura agresiva exige threat model agresivo. Recall no es Windows Search ampliado: es un componente nuevo que graba pantalla. El delta de capability comparado con baseline obliga a un threat model en condiciones (actores, capabilities, asunciones explicitadas, mitigaciones). Publicar un blog con “está cifrado y vive en local” no es threat model; es marketing.

3. Disclosure responsable de parte del vendor también es disclosure. Microsoft podría haber publicado el threat model junto al anuncio. No lo hizo. El threat model lo escribieron Beaumont y Forshaw a posteriori, con peor PR para Microsoft y peor protección para los primeros usuarios. La asimetría (vendor sabe cómo funciona, defensores tienen que ingeniería inversa el binario para descubrirlo) es una decisión de producto. Se puede romper publicando arquitectura detallada en el día del anuncio.

Por qué este caso vale para 2024

Recall es el exhibit A de un patrón que se va a repetir el resto del año: feature AI con capability nueva (captura masiva, agentic action, computer use), lanzada con threat model implícito “trust me, it’s secure”, retirada o restringida tras dos semanas de análisis externo. Veremos el mismo arco en Computer Use (octubre, indirect injection vía pantalla — cubrimos en su técnico), en MCP (noviembre, confused deputy a nivel protocolo), y en o1 (septiembre, CoT como nueva superficie de ataque).

Lo que cambia en Recall respecto a los otros casos: el bug no es exclusivo de AI, es threat modeling clásico de Windows desktop (concentración de dato sensible en perfil del usuario sin DPAPI). La parte AI justifica el por qué del dataset; la parte rota es la de los 90s.

Como CISO que reciba la pregunta “¿debemos desplegar Recall en la flota?” en julio 2024: la respuesta corta es “esperad a que se publique el post-mortem técnico de los cambios de Microsoft y a que CISA / SANS publiquen guías”. La respuesta larga es “diseñad la política antes del despliegue — qué clases de equipos no llevan Recall (workstations con secretos: finance, legal, dev), qué retención aplicáis (no necesitáis 3 meses), y qué evento de SIEM cubre la creación / acceso al directorio CoreAIPlatform.00\”.

Referencias

• Microsoft, Introducing Copilot+ PCs (Yusuf Mehdi, 20 mayo 2024): https://blogs.microsoft.com/blog/2024/05/20/introducing-copilot-pcs/
• Kevin Beaumont, Stealing everything you’ve ever typed or viewed on your own Windows PC is now possible with two lines of code — inside the Copilot+ Recall disaster (DoublePulsar, mayo 2024): https://doublepulsar.com/recall-stealing-everything-youve-ever-typed-or-viewed-on-your-own-windows-pc-is-now-possible-da3e12e9465e
• Kevin Beaumont, Microsoft Recall on Copilot+ PC: testing the security and privacy implications (DoublePulsar): https://doublepulsar.com/microsoft-recall-on-copilot-pc-testing-the-security-and-privacy-implications-ddb296093b6c
• Alex Hagenah (xaitax), TotalRecall — extracción automatizada de Recall (GitHub, junio 2024): https://github.com/xaitax/TotalRecall
• James Forshaw, hilos en X / Mastodon sobre el bypass de admin: https://infosec.exchange/@tiraniddo
• Pavan Davuluri (Microsoft), Update on the Recall preview feature for Copilot+ PCs (7 junio 2024): https://blogs.windows.com/windowsexperience/2024/06/07/update-on-the-recall-preview-feature-for-copilot-pcs/