TotalRecall Reloaded

Rompiendo Windows Recall. Otra vez.

image

Cuando Microsoft rediseñó Recall con enclaves VBS, cifrado AES-256-GCM, autenticación Windows Hello y un host de Proceso Ligero Protegido, el mensaje fue claro: los datos están bloqueados en una bóveda.

La bóveda es sólida. El camión de reparto no.

AIXHost.exe, el proceso que renderiza la línea de tiempo de Recall, no tiene PPL, ni AppContainer, ni cumplimiento de integridad de código. Cualquier proceso que se ejecute como el usuario conectado puede inyectar código en él y llamar a las mismas API COM que usa la interfaz legítima. Una vez que el usuario se autentica con Windows Hello, las capturas de pantalla descifradas, el texto OCR y los metadatos fluyen a través de AIXHost.exe como objetos COM en vivo. TotalRecall Reloaded se coloca dentro de ese proceso y extrae todo.

No se requiere administrador. Usuario estándar. Sin exploit de kernel. Sin bypass criptográfico. Solo llamadas COM.

Cómo funciona

La inyección

TotalRecall Reloaded consta de dos archivos: un inyector (totalrecall.exe) y una DLL de carga útil (totalrecall_payload.dll).

El inyector encuentra AIXHost.exe mediante CreateToolhelp32Snapshot, asigna memoria en el destino con VirtualAllocEx, escribe la ruta de la DLL con WriteProcessMemory y genera un hilo remoto apuntando a LoadLibraryW. Inyección DLL clásica. Nada sofisticado, porque no se necesita nada sofisticado. AIXHost.exe no tiene ninguna protección contra esto.

Esto funciona desde un usuario estándar sin privilegios. Sin elevación, sin SeDebugPrivilege. La DACL predeterminada de Windows permite que los procesos del mismo usuario tengan acceso completo entre sí. Verificado: el token se ejecuta en nivel obligatorio Medio con BUILTIN\Administrators establecido como solo denegación.

Autenticación

El enclave VBS no descifrará nada sin Windows Hello. La herramienta no lo evita. Hace que el usuario lo haga, viaja silenciosamente cuando el usuario lo hace, o espera a que el usuario lo haga.

--launch simula Win+J mediante keybd_event, el atajo de teclado que abre la línea de tiempo de Recall. El usuario ve un mensaje de Hello (rostro, huella digital o PIN), se autentica y el enclave comienza a servir datos descifrados. Desde la perspectiva del usuario, Recall se abrió normalmente. Desde la nuestra, la carga útil ya está dentro, esperando.

--stealth es el modo completamente silencioso. Funciona así:

1. Se inyecta en AIXHost.exe (siempre en ejecución) y parchea DiscardDataAccess para que sea un no-op
2. Espera silenciosamente a que el usuario abra Recall y se autentique normalmente
3. Cuando el usuario cierra Recall, Baker.dll intenta revocar la concesión de acceso a datos, pero el parche lo bloquea
4. AIXHost.exe muere y se reinicia. La herramienta detecta el reinicio y se reinyecta en el nuevo proceso
5. La concesión de autenticación persiste en aihost.exe (la revocación fue bloqueada). La extracción comienza de inmediato
6. Sin Win+J, sin mensaje de Hello, sin interfaz visible. Hasta 5 intentos de reinyección.

--wait es la contraparte pasiva de --launch. En lugar de simular Win+J, la herramienta permanece inactiva mientras el usuario abre Recall por su cuenta — desde la barra de tareas, un acceso directo o cualquier otra ruta. Cuando aparece AIXHost.exe y el usuario completa Hello de forma natural, se inyecta la carga útil y comienza la extracción. Útil en una máquina que está siendo observada, o cuando la sesión de Recall debe parecer completamente iniciada por el usuario sin entrada de teclado sintética.

La cadena de extracción

Una vez dentro de AIXHost.exe, la carga útil inicializa un apartamento COM con CoInitializeEx(COINIT_APARTMENTTHREADED) y configura el reenvío de identidad del proxy con CoSetProxyBlanket(EOAC_DYNAMIC_CLOAKING). Esto es crítico. Sin el encubrimiento dinámico, el proxy COM no lleva la identidad autenticada al servidor.

La extracción sigue el mismo camino que utiliza la interfaz legítima de Recall:

1. Inicialización del enclave: DataManager.Load() desencadena la carga de la clave del enclave. DataStoreManager.DecryptDatabase() (slot 37) prepara vistas descifradas. La carga útil consulta DataManager.DataStatus hasta que devuelve 3 (desbloqueado).

2. Enumeración de entidades: MemoryEntityStatics.GetLightMemoryItemsBefore() (slot 9) devuelve un vector de referencias de entidades ligeras. Cada una lleva un ID de contexto en el offset +8. En una máquina típica, esto devuelve cientos de entidades que abarcan días o semanas de actividad.

3. Extracción por entidad: Para cada ID de contexto, la carga útil carga la entidad completa mediante ContextEngine2.TryGetEntityForId() (slot 6), la desenvuelve a través de IEntityWrapper (slot 6) y QueryInterface a IMemoryEntity. A partir de ahí:

   • Metadatos (síncronos): título (slot 8), ID del modelo de aplicación (slot 9), nombre de la aplicación (slot 10), ruta del proceso (slot 11), URL (slot 12), dominio (slot 13), URI del archivo (slot 15), marca de tiempo (slot 7), límites de la ventana (slot 16). Mediante QI a IMemoryEntity2/3: capacidad de restauración, tiempo de permanencia en la aplicación, tiempo de permanencia en la web
   • Captura de pantalla (asíncrono): (slot 19) devuelve un . a , llamar a para obtener un mapa de bits WIC, codificar como PNG mediante

Cada llamada está envuelta en __try/__except porque una sola violación de acceso en una llamada al proxy COM mata permanentemente el canal RPC hacia aihost.exe. No hay recuperación. Tendrías que reiniciar AIXHost.exe. Los envoltorios SEH atrapan bloqueos causados por tipos de parámetros incorrectos y mantienen la sesión viva.

Capacidades previas a la autenticación

Varias operaciones funcionan sin ninguna autenticación de Hello:

Extracción de capturas de pantalla: RecallPrivacyIndicatorSettings (CLSID {42C63551-...}) expone GetRecentCaptureThumbnail(width, height) en el slot 13. El nombre del método dice "miniatura", pero el servidor no impone un límite de resolución. Pasar 3840x3840 devuelve la captura de Recall más reciente a resolución completa. El resultado IRandomAccessStream se convierte a un IStream mediante CreateStreamOverRandomAccessStream (shcore.dll) y se vuelca como BMP.

Destrucción de datos: IDataStoreManager::DeleteEvents() (slot 12) borra todo el historial de capturas. Sin parámetros, sin autenticación. El análisis en Ghidra confirmó: el manejador de eliminación en FUN_1802ddd10 contiene cero llamadas a la función de puerta de autorización. La verificación de autenticación nunca se conectó.

Divulgación de metadatos: Las rutas de almacenamiento (incluyendo el GUID UKP específico del usuario), el tamaño de la base de datos, la política de retención, el estado de la captura y el ID de contexto de la captura más reciente se pueden leer sin autenticación a través de IDataStoreManagerStatics y RecallPrivacyIndicatorSettings.

Uso

image``` totalrecall.exe --launch Open Recall, trigger Hello, extract everything totalrecall.exe --stealth Silent extraction (patches auth revocation, waits) totalrecall.exe --wait Wait for user to manually open Recall totalrecall.exe --preauth Grab latest screenshot + settings (no Hello) totalrecall.exe --search "password" Search OCR text in latest extraction totalrecall.exe --destroy Wipe all Recall data (confirmation required, no Hello)

| Modo | Autenticación requerida | Qué hace |
|------|:---:|-------------|
| `--launch` | Hello | Simula Win+J, el usuario se autentica, extracción completa |
| `--stealth` | Pasivo | Parchea la revocación de autenticación, espera a que el usuario autentique Recall, extrae silenciosamente |
| `--wait` | Hello | Espera a que el usuario abra Recall de forma natural, luego extrae |
| `--preauth` | **No** | Captura de pantalla más reciente + todos los ajustes |
| `--search` | No | Búsqueda de texto OCR sin distinción de mayúsculas/minúsculas en la extracción más reciente |
| `--destroy` | **No** | `DeleteEvents()`, irreversible, requiere escribir DESTROY para confirmar |

### Salida de ejemplo

**`--stealth` (primera ejecución, esperando al usuario):**```
[+] Target: AIXHost.exe  PID 8648 (stealth mode)
[*] Patching auth revocation...
[+] Waiting for Recall session...
[+] Recall session detected
[*] Waiting for user to close Recall...
[*] Recall closed, waiting for AIXHost to respawn...
[+] Extracting from AIXHost PID 26208
[+] Payload active
[*] Extracting
[##############################] 384/384 entities

EXTRACTION COMPLETE  6 min 51 sec
Screenshots       192   328.8 MB
OCR Text          184   535.2 KB
Metadata (CSV)    384    97.4 KB

--stealth (ejecución posterior, sesión en caché):``` [+] Target: AIXHost.exe PID 27532 (stealth mode) [] Patching auth revocation... [+] Waiting for Recall session... [+] Cached session found, extracting... [] Extracting [##############################] 398/398 entities

**`--launch`:**```
[+] Target: AIXHost.exe  PID 14636  Memory 60 MB
[*] Triggering Recall via Win+J...
[*] Waiting for Hello authentication authenticating
[+] Recall ready  PID 14636  Memory 242 MB
[*] Extracting
[##############################] 212/212 entities

EXTRACTION COMPLETE  3 min 59 sec
Screenshots       104   184.0 MB

--preauth (no se requiere Hello):``` [+] Target: AIXHost.exe PID 27532 (pre-auth mode) [*] Injecting payload (pre-auth only)... [+] Payload active

PRE-AUTH EXTRACTION COMPLETE 0 min 1 sec

Screenshot 4K (3840x2464) 36.1 MB

Settings Storage Path C:\Users<user>\AppData\Local\CoreAIPlatform.00\UKP{...} Storage Size 178.3 MB Capture Count 0 Retention Days 90

**`--search`:**```
Searching for: "password"
In: extraction_20260406_152736

[1] === [12] ctxId=90443 Settings | Chrome ===
     Saved passwords and passkeys
[2] === [47] ctxId=91201 inbox | Thunderbird ===
     Your temporary password has been reset

Directorio de salida```

extraction_20260404_143052/ screenshots/ Full-resolution decrypted PNGs screenshots/*.txt Per-image OCR text thumbnails/ Thumbnail PNGs (fallback when full screenshot unavailable) ocr_text.txt Combined OCR text for all captures recall_data.csv Structured metadata settings.txt Storage path, size, retention, capture state latest_capture_4k.bmp Pre-auth screenshot of most recent capture extraction.log Detailed extraction log with timing

## Construcción

**Requisitos:** Visual Studio con ARM64 C++ tools, Windows 11 ARM64 con Recall habilitado.```
make.bat

Produce totalrecall.exe y totalrecall_payload.dll. Ambos deben estar en el mismo directorio al ejecutarse.

Modelo de Confianza de Recall```

VTL1 (Secure World) +--------------------------------------------------+ | VBS Enclave: AES-256-GCM, sealed keys | | snapshot_support.dll / storage_support.dll | | Keys never leave here. Crypto is sound. | +--------------------------------------------------+ ^ CallEnclave | VTL0 (Normal World) +--------------------------------------------------+ | aihost.exe (PPL, Signer=5) | | +-- Microsoft.Windows.AI.Platform.dll (6.9 MB) | | 44 methods on IDataStoreManager alone | | Enclave bridge. Protected. Can't touch it. | | | | AIXHost.exe (NO PROTECTION) | | +-- Baker.dll: OCR, NER, AI classification | | +-- Receives decrypted data for rendering | | +-- CreateRemoteThread = game over | +--------------------------------------------------+

La jerarquía de claves: Hello -> NGC ECDH P-384 (respaldado por TPM) -> autenticación mutua VTL1 -> material de clave sellado en el enclave -> AES-256-GCM por página con nonces aleatorios y AAD de número de página. Seis capas de derivación de claves. La criptografía es genuinamente sólida.

El problema es lo que ocurre después del descifrado. El texto plano cruza hacia `AIXHost.exe`, un proceso desprotegido, inyectable y del mismo usuario. El enclave no distingue entre `Baker.dll` y código inyectado. No puede.

---

## Hallazgos Clave

### El Límite de Confianza Termina Demasiado Pronto

El [blog de arquitectura de Microsoft](https://blogs.windows.com/windowsexperience/2024/09/27/update-on-recall-security-and-privacy-architecture/) afirma que "los procesos fuera de las VBS Enclaves nunca reciben acceso directo a las instantáneas o claves de cifrado" y que el diseño "restringe los intentos de malware latente que intenta aprovechar la autenticación de un usuario para robar datos".

En la práctica, `AIXHost.exe` recibe cada captura de pantalla descifrada y resultado de OCR como un objeto COM en vivo. No hay verificación por llamante dentro del proceso. No hay una comprobación de "¿eres Baker.dll?". Si estás en el proceso, eres de confianza. El límite de seguridad es el enclave VBS y el PPL, no el proceso de renderizado. Los datos descifrados están a un `CreateRemoteThread` de distancia de cualquier aplicación del mismo usuario.

### La Elusión del Control de Acceso IResponse4

Una brecha de autorización directa.

Cuando llamas a `ContextDataSource.Search()` y obtienes un `IResponse`, la ruta natural es `IResponse.get_Items()` (slot 9) para obtener los resultados. En una sesión nueva, esto devuelve `0x80005473`, un código de error personalizado específico de Recall. El servidor está rechazando deliberadamente la llamada. `IResponse2.ItemsAfterIndex()` devuelve el mismo error. El control de acceso funciona.

Pero el objeto `IResponse` implementa cuatro versiones de la interfaz. `IResponse4.get_UnfilledItems()` (slot 9 en un IID diferente) devuelve la misma colección de datos subyacente sin ninguna comprobación de acceso.```
IResponse.get_Items()           -> 0x80005473 (ACCESS DENIED)
IResponse2.ItemsAfterIndex()    -> 0x80005473 (ACCESS DENIED)
IResponse4.get_UnfilledItems()  -> S_OK (all entities returned)

Mismos datos. Versión de interfaz diferente. Sin autorización. El método estaba pensado para la carga diferida interna en el proceso de búsqueda. La revisión de seguridad encontró get_Items e ItemsAfterIndex, pero omitió get_UnfilledItems. Este es el patrón que hace que la ingeniería de seguridad sea difícil: la comprobación existe en una ruta de código (lo que significa que alguien decidió que era necesaria) y falta en otra.

A partir de esos elementos, el ID de contexto de cada entidad conduce a ContextEngine2.TryGetEntityForId(), que carga la entidad completa con capturas de pantalla, OCR y metadatos. El enclave descifra todo bajo petición.

La omisión de DiscardDataAccess

Cuando el usuario cierra la ventana de Recall, Baker.dll llama a IDataProtectionManager3::DiscardDataAccess() para revocar explícitamente la concesión de acceso a datos en aihost.exe. Es por esto que la autenticación no persiste después de la sesión normal de Recall del usuario: Baker.dll se limpia a sí mismo.

La omisión: el código inyectado dentro de AIXHost.exe puede parchear la vtable del proxy COM para reemplazar DiscardDataAccess (slot 8) con una función no operativa (no-op). Una llamada a VirtualProtect, una escritura de puntero. Cuando el usuario cierra Recall, Baker.dll llama al slot parcheado, no pasa nada, y la concesión permanece activa en aihost.exe. Cualquier instancia posterior de AIXHost.exe hereda la concesión en caché de forma silenciosa.

En la práctica, --stealth despliega el parche en AIXHost.exe (que siempre se está ejecutando) y espera. La próxima vez que el usuario abra y cierre Recall normalmente, la limpieza se suprime y la concesión de acceso a datos persiste. La herramienta detecta el acceso, maneja los reinicios del proceso AIXHost mediante la reinyección automática (parcheando cada nueva instancia) y extrae todo de forma silenciosa. El parche es por proceso y por ejecución: protege la sesión de extracción actual. El uso posterior de Recall después de que la herramienta salga vuelve al comportamiento normal.

DeleteEvents: Destrucción sin autenticación

IDataStoreManager::DeleteEvents() borra todo el historial de capturas sin Windows Hello. Ghidra lo confirmó: el gestor de eliminación contiene cero llamadas a la función de puerta de autorización. La comprobación de autenticación nunca se conectó en la ruta de eliminación. Un atacante que no puede leer los datos aún puede destruirlos. Antiforense desde un usuario estándar.

Extracción de capturas de pantalla previa a la autenticación

RecallPrivacyIndicatorSettings.GetRecentCaptureThumbnail devuelve la captura de pantalla más reciente de Recall en la resolución que se solicite. El método está pensado para el pequeño indicador de privacidad en la barra de tareas. Nadie limitó la resolución. Cualquier proceso del mismo usuario puede capturar silenciosamente lo que estaba en pantalla por última vez, sin necesidad de Hello.

Conteo de capturas previo a la autenticación mediante GetSecureStorageInfo

GetWindowCaptureCount (slot 26) devuelve E_ACCESSDENIED sin Hello. Pero GetSecureStorageInfo (slot 27) devuelve una estructura StorageInfo con los mismos datos exactos, sin necesidad de autenticación. La estructura contiene NumberOfItems (número de capturas) y Size (tamaño total del almacenamiento cifrado en bytes). Un atacante puede monitorear esto para rastrear la actividad de Recall en tiempo real sin ninguna autenticación.

Persistencia del estado de autenticación

Una vez que se completa Hello, el estado de autenticación se almacena en caché en aihost.exe (PPL) durante toda la sesión de Windows. Matar y reiniciar AIXHost.exe no lo borra. Un atacante puede esperar a que el usuario abra Recall de forma natural y luego extraer datos silenciosamente horas después. Reextracción ilimitada sin avisos adicionales, sin ventanas visibles, sin que el usuario lo sepa.

Lo que Recall captura (y lo que se extrae)

Recall no solo toma capturas de pantalla. Construye un perfil de comportamiento completo de todo lo que haces en tu computadora. Cada pocos segundos, toma una captura de pantalla, ejecuta OCR y (supuestamente) clasificación de IA, y almacena el resultado en una base de datos SQLite cifrada.

Todo lo siguiente está confirmado a partir de dos fuentes independientes: los metadatos privados de WinRT (Microsoft.Windows.AI.Platform.winmd, analizados mediante cppwinrt.exe) y el binario del enclave VBS (storage_support.dll, que contiene el esquema completo de la base de datos en cadenas de texto plano).

Datos por captura

Nota: los nombres de campo a continuación están confirmados a partir de los metadatos de WinRT y las cadenas del binario del enclave. Las descripciones de lo que contiene cada campo se infieren de los nombres y tipos de las API, y no todas han sido verificadas dinámicamente en tiempo de ejecución.

Metadatos procesados por IA

Nota: la misma advertencia que arriba. Los nombres de clase y enumeración se enumeran a partir de los metadatos de WinRT y las cadenas del DLL del enclave; las descripciones de lo que representa cada uno se infieren de los nombres y el contexto y no se han verificado dinámicamente para cada entrada.

Además de la captura sin procesar, Recall ejecuta una clasificación de IA que produce:

• Reconocimiento de entidades nombradas (10 tipos): PersonName, Organization, Product, Address, Location, DateTime, Event, Duration, WebUrl, EmailAddress. Cada uno extraído del texto OCR con posición de origen.
• Clasificación de temas (23 categorías): Topic, Person, Emoji, App, FileKind, , , , , , , , , , , , , , , , , , . Cada uno con puntuaciones de confianza y cuadros delimitadores opcionales.

Pipeline de captura

Cada pocos segundos, el servicio de captura de Recall evalúa 12 políticas antes de decidir si tomar una captura de pantalla:

GameModeActive, BatterySaverActive, UserActivityIdle, UserPresenceIdle, StorageLow, PrivateWindow, BlockedByContentProtection, BlockedAppId, BlockedExecutable, BlockedURL, BlockedContentFilePath, BitLockerDisabled

Si ninguna de estas se activa, captura. La estructura de entrada por captura (de los metadatos de WinRT):``` WindowData { WindowId, Foreground, Title, Bounds, Minimized, PrivateState, InputScopePrivacy AppData { AppUserModelId, ProcessPath, IconUri, AppName, TileId RemoteClient, IsBrowserWindow } RestoreData { WebUrl, FilePath, ActivationUri, ActivityId, WebIconUri FileObjectId, VolumeId // NTFS persistent file identifiers SensitivityLabelData { State, Labels } } }

### La base de datos

La base de datos principal (`ukg.db`) utiliza SQLite SEE con cifrado AES-256-GCM. El esquema confirmado desde `storage_support.dll` (el binario del enclave VBS que contiene las sentencias CREATE TABLE en texto plano):

**Tablas principales (17):**```
WindowCapture              Id, Name, ImageToken, IsForeground, WindowId, WindowBounds,
                           WindowTitle, Properties, IsProcessed, Retry, ActivationUri,
                           ActivityId, FallbackUri, TimeStamp, DwellTime
WindowCaptureAppRelation   WindowCaptureId, AppId, IsBackground
WindowCaptureWebRelation   WindowCaptureId, WebId, IsBackground
WindowCaptureFileRelation  WindowCaptureId, FileId
WindowCaptureTopicRelation WindowCaptureId, TopicId, Score (float)
WindowCaptureTextIndex     FTS5 virtual table (WindowCaptureId, WindowTitle, OcrText)
App                        Id, WindowsAppId, IconUri, Name, Path, TileId, Properties
Web                        Id, Domain, Uri, IconUri, Properties
File                       Id, Path, Name, Extension, Kind, Type, ObjectId, VolumeId
Topic                      Id, Title, Properties
ScreenRegion               Id, WindowCaptureId, RegionKind, OcrText, Bounds
AppDwellTime               Id, WindowsAppId, HourOfDay, DayOfWeek, HourStartTimestamp, DwellTime
WebDomainDwellTime         Domain, HourOfDay, DayOfWeek, HourStartTimestamp, DwellTime
SearchHistory              SessionId, CorrelationId, TimeStamp, Kind, Text, Language
SearchFeedback             SessionId, CorrelationId, TimeStamp, Kind, Text, Language,
                           ItemChosenEventId, FeedbackType
IdTable                    NextId
_MigrationMetadata         Id, Version

Índice de búsqueda semántica (SemanticTextStore.sidb / SemanticImageStore.sidb):``` si_items Core embedding storage si_embedding_metadata Embedding type and source mapping si_diskann_graph DiskANN approximate nearest neighbor graph si_diskann_references Graph edge references si_diskann_config Index configuration si_diskann_info Index statistics si_application_values Application-level settings

En un día laboral típico, se acumulan cientos de capturas. La retención predeterminada es de 90 días con un límite de almacenamiento de 75 GB. Cada correo electrónico abierto, cada documento editado, cada sitio web visitado, cada comando de terminal en pantalla, cada conversación de mensajería visible. Todo procesado con OCR, extracción de entidades, clasificación de temas e indexación semántica.

Toda tu vida digital, indexada y buscable. Tal como se pretendía.

---

## Lo que Microsoft hizo bien

El enclave VBS es sólido como una roca. El material clave nunca sale de VTL1. El AES-256-GCM por página con nonces aleatorios es correcto según el libro de texto. La protección PPL de `aihost.exe` es efectiva, el kernel bloquea la inyección. CFG es completo en ARM64. Las consultas SQL están completamente parametrizadas (diez payloads de inyección, cero efectos secundarios). El modelo de autenticación es sin estado y libre de condiciones de carrera (miles de sondeos, cero bypasses).

El problema fundamental no es la criptografía, el enclave, la autenticación o el PPL. Es enviar contenido descifrado a un proceso desprotegido para su renderización. La puerta de la bóveda es de titanio. La pared de al lado es de yeso.

---

## Divulgación responsable

Esta investigación fue divulgada de manera responsable al Microsoft Security Response Center (MSRC).

### Cronología

| Fecha | Evento |
|------|-------|
| 2024-06-07 | Lanzamiento original de [TotalRecall](https://github.com/xaitax/TotalRecall) (Recall pre-cifrado) |
| 2024-06-13 | Microsoft retrasa el lanzamiento de Recall, anuncia rediseño con enclaves VBS |
| 2025-04 | Recall relanza con enclaves VBS, cifrado, autenticación Hello |
| 2026-03-06 | Informe enviado a MSRC: informe completo, código fuente, instrucciones de compilación |
| 2026-03-09 | MSRC abre el Caso 109586, estado: Revisión / Reproducción |
| 2026-03-27 | MSRC: "el equipo de ingeniería se encuentra actualmente en la etapa final de investigación" |
| 2026-04-03 | MSRC cierra el caso como **No es una vulnerabilidad**: "opera dentro del diseño de seguridad documentado actual" |
| 2026-04-09 | Lanzamiento público de TotalRecall Reloaded |

### Postura de Microsoft

Después de revisarlo con sus equipos de ingeniería, MSRC determinó que "el comportamiento observado opera dentro del diseño de seguridad documentado actual de Recall" y que "los patrones de acceso demostrados son consistentes con las protecciones previstas y los controles existentes". Citaron su [blog de arquitectura](https://blogs.windows.com/windowsexperience/2024/09/27/update-on-recall-security-and-privacy-architecture/), específicamente que la autorización "restringe los intentos de malware latente de aprovechar la autenticación de un usuario para robar datos" y que "los procesos fuera de los Enclaves VBS nunca reciben acceso directo a las instantáneas o claves de cifrado y solo reciben datos devueltos desde el enclave después de la autorización".

El caso fue cerrado como No es una vulnerabilidad.

Los hallazgos previos a la autenticación documentados aquí (destrucción de datos no autenticada, extracción de capturas de pantalla) fueron descubiertos durante una investigación de seguimiento después del cierre del caso.

---

## Entorno probado

| | Detalles |
|---|---|
| **SO** | Windows 11 25H2 (Build 26300.8155) |
| **Arquitectura** | ARM64 |
| **AIXHost.exe** | v2126.7602.0.0 |
| **Privilegio** | Usuario estándar (integridad media, sin elevación) |

---

## Trabajo anterior

- [TotalRecall](https://github.com/xaitax/TotalRecall) (junio de 2024), la herramienta original en Python para Recall pre-cifrado
- [Análisis de Kevin Beaumont](https://doublepulsar.com/recall-stealing-everything-youve-ever-typed-or-viewed-on-your-own-windows-pc-is-now-possible-da3e12e9465e), la investigación que lo inició todo

## Agradecimientos

Gracias a [Jeff McJunkin](https://x.com/jeffmcjunkin) y [Kevin Beaumont](https://cyberplace.social/@GossiTheDog) por las pruebas y validación.

---

**Alexander Hagenah ([@xaitax](https://x.com/xaitax))**