TotalRecall Reloaded

Breaking Windows Recall. Again.

image

Microsoft が Recall を再設計 し、VBS エンクレーブ、AES-256-GCM 暗号化、Windows Hello 認証、Protected Process Light ホストを導入したとき、そのメッセージは明確でした。データは金庫に鍵をかけられている、と。

金庫は頑丈です。しかし配達トラックは違います。

AIXHost.exe は Recall のタイムラインをレンダリングするプロセスですが、PPL も AppContainer もコード整合性の強制もありません。ログイン中のユーザーとして実行されているプロセスは、コードを注入し、正当な UI が使用するのと同じ COM API を呼び出すことができます。ユーザーが Windows Hello で認証すると、復号されたスクリーンショット、OCR テキスト、メタデータがライブの COM オブジェクトとして AIXHost.exe を流れます。TotalRecall Reloaded はそのプロセス内部に潜み、すべてを抽出します。

管理者権限は不要。標準ユーザー。カーネルエクスプロイトも暗号の迂回もなし。COM 呼び出しだけです。

仕組み

インジェクション

TotalRecall Reloaded は2つのファイルで構成されています。インジェクター (totalrecall.exe) とペイロード DLL (totalrecall_payload.dll) です。

インジェクターは CreateToolhelp32Snapshot で AIXHost.exe を見つけ、VirtualAllocEx でターゲットにメモリを割り当て、WriteProcessMemory で DLL パスを書き込み、LoadLibraryW を指すリモートスレッドを生成します。古典的な DLL インジェクションです。特別なことは何も必要ありません。なぜなら AIXHost.exe にはそれに対する防御が一切ないからです。

これは 標準ユーザー 権限で機能します。昇格も SeDebugPrivilege も不要です。デフォルトの Windows DACL は、同一ユーザーのプロセスが互いにフルアクセスできるようにしています。確認済み: トークンは Medium 必須レベルで実行され、BUILTIN\Administrators は拒否専用に設定されています。

認証

VBS エンクレーブは、Windows Hello なしでは何も復号しません。このツールはそれを回避しません。ユーザーに実行させ、その際に静かに同乗するか、ユーザーが実行するのを待ちます。

--launch は keybd_event を介して Win+J (Recall タイムラインを開くキーボードショートカット) をシミュレートします。ユーザーは Hello プロンプト (顔、指紋、または PIN) を確認し、認証すると、エンクレーブは復号されたデータの提供を開始します。ユーザーから見れば、Recall が通常通り開いただけです。私たちから見れば、ペイロードはすでに内部にあり、待機しています。

--stealth は完全にサイレントなモードです。次のように動作します:

1. AIXHost.exe (常に実行中) に注入し、DiscardDataAccess を NOP にパッチ
2. ユーザーが Recall を開いて通常通り認証するのを静かに待機
3. ユーザーが Recall を閉じると、Baker.dll はデータアクセス許可の取り消しを試みるが、パッチがそれをブロック
4. AIXHost.exe が終了し、再起動。ツールは再起動を検出し、新しいプロセスに再注入
5. 認証許可は aihost.exe に残る (取り消しがブロックされたため)。即座に抽出を開始
6. Win+J も Hello プロンプトも UI も表示されない。最大5回の再注入試行。

--wait は --launch の受動的な対応版です。Win+J をシミュレートする代わりに、ツールはユーザーが自分で Recall を開くのを待ちます (タスクバー、ショートカット、その他の経路)。AIXHost.exe が現れ、ユーザーが自然に Hello を完了すると、ペイロードが注入され抽出が開始されます。監視下にあるマシンや、Recall セッションが完全にユーザー主導で見える必要がある場合に便利です (合成キーボード入力なし)。

抽出チェーン

AIXHost.exe 内部に入ると、ペイロードは CoInitializeEx(COINIT_APARTMENTTHREADED) で COM アパートメントを初期化し、CoSetProxyBlanket(EOAC_DYNAMIC_CLOAKING) でプロキシ ID 転送を設定します。これは重要です。動的クローキングがないと、COM プロキシは認証済みの ID をサーバーに伝えません。

抽出は、正規の Recall UI が使用するのと同じ経路をたどります:

1. エンクレーブ初期化 : DataManager.Load() がエンクレーブキーのロードをトリガー。DataStoreManager.DecryptDatabase() (スロット 37) が復号されたビューを準備。ペイロードは DataManager.DataStatus が 3 (ロック解除) を返すまでポーリング。

2. エンティティ列挙 : MemoryEntityStatics.GetLightMemoryItemsBefore() (スロット 9) が軽量エンティティ参照のベクターを返す。各参照はオフセット +8 にコンテキスト ID を持つ。一般的なマシンでは、数日から数週間のアクティビティにわたる数百のエンティティが返される。

3. エンティティごとの抽出 : 各コンテキスト ID について、ペイロードは ContextEngine2.TryGetEntityForId() (スロット 6) で完全なエンティティをロードし、IEntityWrapper (スロット 6) でラップを解除し、IMemoryEntity に QueryInterface する。そこから:

   • メタデータ (同期) : タイトル (スロット 8)、アプリモデル ID (スロット 9)、アプリ名 (スロット 10)、プロセスパス (スロット 11)、URL (スロット 12)、ドメイン (スロット 13)、ファイル URI (スロット 15)、タイムスタンプ (スロット 7)、ウィンドウ境界 (スロット 16)。IMemoryEntity2/3 への QI 経由: 復元機能、アプリ滞在時間、Web 滞在時間
   • スクリーンショット (非同期) : TryGetBitmapCaptureAsync() (スロット 19) が を返す。 に し、 を呼び出して WIC ビットマップを取得し、 で PNG としてエンコード

すべての呼び出しは __try/__except でラップされている。COM プロキシ呼び出しでの1回のアクセス違反が aihost.exe への RPC チャネルを恒久的に破壊するからだ。復旧はできない。AIXHost.exe を再起動する必要がある。SEH ラッパーは間違ったパラメータ型によるクラッシュをキャッチし、セッションを維持する。

認証前の機能

いくつかの操作は、Hello 認証なしで機能します:

スクリーンショット抽出 : RecallPrivacyIndicatorSettings (CLSID {42C63551-...}) は スロット 13 で GetRecentCaptureThumbnail(width, height) を公開する。メソッド名は "thumbnail" だが、サーバーは解像度の上限を強制しない。3840x3840 を渡すと、最新の Recall キャプチャがフル解像度で返される。IRandomAccessStream の結果は CreateStreamOverRandomAccessStream (shcore.dll) で IStream に変換され、BMP としてダンプされる。

データ破壊 : IDataStoreManager::DeleteEvents() (スロット 12) はキャプチャ履歴全体を消去する。パラメータも認証も不要。Ghidra 分析により確認: FUN_1802ddd10 にある削除ハンドラには、認証ゲート関数への呼び出しがゼロ。認証チェックはそもそも配線されていなかった。

メタデータ漏洩 : ストレージパス (ユーザー固有の UKP GUID を含む)、データベースサイズ、保持ポリシー、キャプチャ状態、最新のキャプチャコンテキスト ID はすべて、IDataStoreManagerStatics と RecallPrivacyIndicatorSettings を介して認証なしで読み取り可能。

使用方法

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)

| モード | 認証必須 | 機能 |
|------|:---:|-------------|
| `--launch` | Hello | Win+Jをシミュレート、ユーザーが認証、完全抽出 |
| `--stealth` | Passive | 認証取り消しをパッチし、ユーザーがRecallを認証するのを待ち、静かに抽出 |
| `--wait` | Hello | ユーザーが自然にRecallを開くのを待ち、その後抽出 |
| `--preauth` | **No** | 最新のスクリーンショット + すべての設定 |
| `--search` | No | 最新の抽出全体での大文字小文字を区別しないOCRテキスト検索 |
| `--destroy` | **No** | `DeleteEvents()`、不可逆、確認のためにDESTROYと入力する必要がある |

### 出力例

**`--stealth` (初回実行、ユーザーを待機中):**```
[+] 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 (後続の実行、キャッシュされたセッション):``` [+] 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 (ハロー不要):``` [+] 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

出力ディレクトリ```

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

## ビルド

**必要条件:** Visual Studio with ARM64 C++ tools, Windows 11 ARM64 with Recall enabled.```
make.bat

totalrecall.exe と totalrecall_payload.dll を生成します。実行時には両方が同じディレクトリにある必要があります。

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 | +--------------------------------------------------+

鍵階層: Hello -> NGC ECDH P-384 (TPM-backed) -> VTL1相互認証 -> エンクレーブでシールされた鍵素材 -> ページごとのAES-256-GCM（ランダムノンスとページ番号AAD）。6層の鍵導出。暗号技術は真に堅牢です。

問題は復号後の動作です。平文は`AIXHost.exe`（保護されておらず、注入可能で、同一ユーザーのプロセス）に渡ります。エンクレーブは`Baker.dll`と注入されたコードを区別できません。できません。

---

## 主な発見

### 信頼境界が早すぎる終了

Microsoftの[アーキテクチャブログ](https://blogs.windows.com/windowsexperience/2024/09/27/update-on-recall-security-and-privacy-architecture/)では、「VBSエンクレーブ外部のプロセスは、スナップショットや暗号鍵に直接アクセスすることはありません」と述べられており、設計が「潜伏マルウェアがユーザー認証に便乗してデータを盗もうとする試みを制限します」としています。

実際には、`AIXHost.exe`は復号されたすべてのスクリーンショットとOCR結果をライブCOMオブジェクトとして受け取ります。プロセス内に呼び出し元ごとの検証はありません。「お前はBaker.dllか？」というチェックもありません。プロセス内にいれば、信頼されます。セキュリティ境界はVBSエンクレーブとPPLであり、レンダリングプロセスではありません。復号されたデータは、同一ユーザーの任意のアプリケーションから`CreateRemoteThread`一つで取得可能です。

### IResponse4アクセス制御バイパス

直接的な認可のギャップ。

`ContextDataSource.Search()`を呼び出して`IResponse`を取得した場合、結果を得るための自然なパスは`IResponse.get_Items()`（スロット9）です。新しいセッションでは、これは`0x80005473`（Recall固有のカスタムエラーコード）を返します。サーバーは意図的に呼び出しを拒否しています。`IResponse2.ItemsAfterIndex()`も同じエラーを返します。アクセス制御は機能しています。

しかし、`IResponse`オブジェクトは4つのインターフェースバージョンを実装しています。`IResponse4.get_UnfilledItems()`（別のIID上のスロット9）は、アクセスチェックなしで同じ基盤データコレクションを返します。```
IResponse.get_Items()           -> 0x80005473 (ACCESS DENIED)
IResponse2.ItemsAfterIndex()    -> 0x80005473 (ACCESS DENIED)
IResponse4.get_UnfilledItems()  -> S_OK (all entities returned)

同じデータ、異なるインターフェースバージョン。認証なし。このメソッドは、検索パイプラインでの内部的な遅延ロードを目的としていました。セキュリティレビューではget_ItemsとItemsAfterIndexを発見しましたが、get_UnfilledItemsを見逃しました。これがセキュリティエンジニアリングを困難にするパターンです。つまり、あるコードパスにはチェックが存在し（誰かが必要と判断した）、別のパスにはそれが欠落しています。

それらのアイテムから、各エンティティのコンテキストIDはContextEngine2.TryGetEntityForId()につながり、スクリーンショット、OCR、メタデータを含む完全なエンティティをロードします。エンクレーブは要求に応じてすべてを復号します。

DiscardDataAccessのバイパス

ユーザーがRecallウィンドウを閉じると、Baker.dllはIDataProtectionManager3::DiscardDataAccess()を呼び出し、aihost.exe内のデータアクセス権限を明示的に取り消します。これが、通常のRecallセッション後も認証が永続しない理由です。Baker.dllが自動的に後片付けを行います。

バイパス方法:AIXHost.exe内に注入されたコードは、COMプロキシのvtableにパッチを当て、DiscardDataAccess（スロット8）を何もしない関数に置き換えることができます。VirtualProtect呼び出し1回、ポインタ書き込み1回です。ユーザーがRecallを閉じると、Baker.dllはパッチが適用されたスロットを呼び出し、何も起こらず、権限はaihost.exe内でアクティブなままです。後続のAIXHost.exeインスタンスは、キャッシュされた権限を静かに継承します。

実際には、--stealthはパッチをAIXHost.exe（常に実行中）に展開し、待機します。次回ユーザーがRecallを通常通り開いて閉じると、クリーンアップが抑制され、データアクセス権限が永続化します。このツールはアクセスを検出し、自動再注入（新しいインスタンスごとに再パッチ）によってAIXHostプロセスの再起動を処理し、すべてを静かに抽出します。このパッチはプロセスごと、実行ごとに有効で、現在の抽出セッションを保護します。ツール終了後の後続のRecall使用は通常の動作に戻ります。

DeleteEvents: 認証なしの破壊

IDataStoreManager::DeleteEvents()は、Windows Helloなしでキャプチャ履歴全体を消去します。Ghidraで確認済み: 削除ハンドラには認証ゲート関数への呼び出しがゼロ個含まれています。認証チェックは削除パスに配線されていませんでした。データを読み取れない攻撃者でも、それを破壊することは可能です。標準ユーザーからのフォレンジック対抗策。

認証前のスクリーンショット抽出

RecallPrivacyIndicatorSettings.GetRecentCaptureThumbnailは、要求された任意の解像度で最新のRecallスクリーンショットを返します。このメソッドはタスクバーの小さなプライバシーインジケーターを目的としています。誰も解像度を制限しませんでした。同じユーザーのプロセスであれば、Helloを必要とせずに、最後に画面に表示されたものを静かに取得できます。

GetSecureStorageInfoを介した認証前のキャプチャ数の取得

GetWindowCaptureCount（スロット26）はHelloなしではE_ACCESSDENIEDを返します。しかし、GetSecureStorageInfo（スロット27）は、認証不要でまったく同じデータを含むStorageInfo構造体を返します。この構造体にはNumberOfItems（キャプチャ数）とSize（暗号化ストレージの総バイト数）が含まれます。攻撃者はこれを監視して、認証なしでRecallアクティビティをリアルタイムに追跡できます。

認証状態の永続化

一度Helloが完了すると、認証状態はWindowsセッション全体にわたってaihost.exe（PPL）にキャッシュされます。AIXHost.exeを強制終了して再起動してもクリアされません。攻撃者はユーザーが自然にRecallを開くのを待ち、数時間後に静かにデータを抽出できます。追加のプロンプトなし、表示されるウィンドウなし、ユーザーの認識なしでの無制限の再抽出が可能です。

Recallがキャプチャするもの（および抽出されるもの）

Recallは単にスクリーンショットを撮るだけではありません。それはあなたがコンピュータ上で行うすべてのことの包括的な行動プロファイルを構築します。数秒ごとに、スクリーンショットを撮影し、OCRを実行し、（おそらく）AI分類を行い、結果を暗号化されたSQLiteデータベースに保存します。

以下はすべて、2つの独立したソースから確認されています: プライベートWinRTメタデータ（Microsoft.Windows.AI.Platform.winmd、cppwinrt.exeで解析）とVBSエンクレーブバイナリ（storage_support.dll、プレーンテキスト文字列で完全なデータベーススキーマを含む）です。

キャプチャごとのデータ

注: 以下のフィールド名はWinRTメタデータおよびエンクレーブバイナリ文字列から確認されています。各フィールドの内容の説明はAPI名と型から推測されたものであり、すべてが実行時に動的に検証されたわけではありません。

AI処理されたメタデータ

注: 上記と同じ注意事項が適用されます。クラス名と列挙型名はWinRTメタデータとエンクレーブDLL文字列から列挙されています。それぞれが表すものの説明は名前とコンテキストから推測されており、すべてのエントリについて動的に検証されたわけではありません。

生のキャプチャに加えて、Recallは以下を生成するAI分類を実行します:

• 固有表現認識（10タイプ）: PersonName、Organization、Product、Address、Location、DateTime、Event、Duration、WebUrl、EmailAddress。それぞれOCRテキストとソース位置から抽出されます。
• トピック分類（23カテゴリ）: Topic、Person、Emoji、App、FileKind、、、、、、、、、、、、、、、、、、。それぞれ信頼度スコアとオプションのバウンディングボックスが付与されます。

キャプチャパイプライン

数秒ごとに、Recallのキャプチャサービスはスクリーンショットを撮る前に12のポリシーを評価します:

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

これらのいずれもトリガーしない場合、キャプチャします。キャプチャごとの入力構造（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 } } }

### データベース

メインデータベース (`ukg.db`) は、AES-256-GCM 暗号化を使用した SQLite SEE を使用しています。スキーマは、`storage_support.dll` (CREATE TABLE 文をプレーンテキストで含む VBS エンクレーブバイナリ) から確認されました。

**コアテーブル (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

セマンティック検索インデックス (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

典型的な勤務日の中で、何百ものキャプチャが蓄積されます。デフォルトの保持期間は90日間、ストレージのしきい値は75GBです。開かれたメール、編集されたドキュメント、訪問されたWebサイト、画面上のターミナルコマンド、表示されたメッセージング会話のすべて。すべてOCR処理され、エンティティ抽出され、トピック分類され、セマンティックインデックスが作成されます。

デジタルライフ全体がインデックス化され、検索可能になります。意図された通りに。

---

## Microsoftが正しくやったこと

VBSエンクレーブは極めて堅牢です。鍵素材は決してVTL1から出ません。ランダムなナンスを使用したページごとのAES-256-GCMは教科書通りに正しいです。`aihost.exe`のPPL保護は効果的で、カーネルはインジェクションをブロックします。ARM64ではCFGが包括的に適用されています。SQLクエリは完全にパラメータ化されています（10件のインジェクションペイロード、副作用ゼロ）。認証モデルはステートレスでレースフリーです（数千回のプローブ、バイパスゼロ）。

根本的な問題は、暗号、エンクレーブ、認証、PPLではありません。復号されたコンテンツをレンダリングのために保護されていないプロセスに送信していることです。金庫の扉はチタン製です。隣の壁は乾式壁です。

---

## 責任ある開示

この研究は、Microsoft Security Response Center (MSRC) に責任を持って開示されました。

### タイムライン

| 日付 | イベント |
|------|---------|
| 2024-06-07 | オリジナルの [TotalRecall](https://github.com/xaitax/TotalRecall) 公開（暗号化前のRecall） |
| 2024-06-13 | Microsoft、Recallのローンチを延期、VBSエンクレーブによる再設計を発表 |
| 2025-04 | RecallがVBSエンクレーブ、暗号化、Hello認証で再ローンチ |
| 2026-03-06 | MSRCレポート提出：完全な文書、ソースコード、ビルド手順 |
| 2026-03-09 | MSRCがケース109586を開設、ステータス：審査/再現中 |
| 2026-03-27 | MSRC：「エンジニアリングチームは現在調査の最終段階です」 |
| 2026-04-03 | MSRCがケースを**脆弱性ではない**としてクローズ：「現在の文書化されたセキュリティ設計の範囲内で動作している」 |
| 2026-04-09 | TotalRecall Reloaded 公開 |

### Microsoftの見解

エンジニアリングチームとのレビューの結果、MSRCは「観察された動作は、Recallの現在の文書化されたセキュリティ設計の範囲内で動作している」および「示されたアクセスパターンは、意図された保護と既存の制御と一致している」と判断しました。同社は自社の[アーキテクチャブログ](https://blogs.windows.com/windowsexperience/2024/09/27/update-on-recall-security-and-privacy-architecture/)を引用し、特に認証は「ユーザー認証に便乗しようとする潜伏マルウェアによるデータ窃取の試みを制限する」こと、および「VBSエンクレーブ外のプロセスは、スナップショットや暗号鍵に直接アクセスすることはなく、認証後にエンクレーブから返されたデータのみを受け取る」と述べています。

このケースは「脆弱性ではない」としてクローズされました。

ここに文書化されている事前認証の発見事項（未認証のデータ破壊、スクリーンショット抽出）は、ケースクローズ後のフォローアップ調査中に発見されました。

---

## テスト環境

| | 詳細 |
|---|---|
| **OS** | Windows 11 25H2 (ビルド 26300.8155) |
| **アーキテクチャ** | ARM64 |
| **AIXHost.exe** | v2126.7602.0.0 |
| **権限** | 標準ユーザー (中程度の整合性、昇格なし) |

---

## 先行研究

- [TotalRecall](https://github.com/xaitax/TotalRecall) (2024年6月)、暗号化前のRecall用のオリジナルPythonツール
- [Kevin Beaumontの分析](https://doublepulsar.com/recall-stealing-everything-youve-ever-typed-or-viewed-on-your-own-windows-pc-is-now-possible-da3e12e9465e)、すべての始まりとなった研究

## 謝辞

テストと検証に協力してくれた [Jeff McJunkin](https://x.com/jeffmcjunkin) と [Kevin Beaumont](https://cyberplace.social/@GossiTheDog) に感謝します。

---

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