Forensic Applications of Microsoft Recall

Written by Zach Stanford, Yogesh Khatri, Phill Moore on 5 June 2024

Introduction

Microsoft’s recent preview of upcoming feature Recall has kicked off a debate about the potential new uses of AI and associated privacy concerns.

However, as with all new features in operating systems, forensic opportunities are created. CyberCX’s Digital Forensics and Incident Response (DFIR) team has obtained Copilot+ Recall for testing and provides an overview in this blog of the forensic value it can provide to investigators.

Recall utilises Windows Copilot Runtime to help you find anything you’ve seen on your PC. Effectively, it will do this by taking screenshots of your screen periodically and storing them locally along with processing the data obtained from it with Copilot running on your device.

As Microsoft describes the feature in Retrace your steps with Recall:

“With Recall, you have an explorable timeline of your PC’s past. Just describe how you remember it and Recall will retrieve the moment you saw it. Any photo, link, or message can be a fresh point to continue from.”

Here is an overview of how CyberCX tested the new feature for its forensics investigation capabilities and a look at the results.

Setup

While Recall is currently only supported by hosts with Neural Processing Unit (NPU) chips and new Copilot+ enabled PCs, researchers have found ways to enable the feature on ARM64  CPUs.

We used the tool “AmperageKit” to enable Recall on an Azure VM which we conducted the rest of the testing on. Here are the steps we took:

1 – Create an ARM-based Azure Virtual Machine – Windows 11 Preview 24H2 ARM64

2 – Download and install KB5037850

3 – Download and install Windows AI workloads for ARM64

4 – Download AmerpageKit. Unpack the AI workloads in the same folder and run amperage.exe /install

5 – Enable Save Snapshots

Windows lets you know that it’s now taking snapshots as seen below.

Artefact Summary

The application of this artefact is almost endless. As long as the actor or user is using the GUI you will be able to see what/when commands were run, what/when files where opened, deleted content and much more.

While the data may not capture every little change, as it is dependent on when the screenshot is captured, in our testing it did capture much of the activity we performed. The Optical Character Recognition (OCR) of window text also makes searching for activities much faster as well. An application developer can choose to exclude their application from being captured, and as such, when a web browser is running in incognito/private mode there is only limited activity recorded.

Information Included

• Evidence of Execution
• Evidence of File Folder Interaction
• Evidence of Presence/Existence
• Timestamps of Activity

Location

C:\Users\*\AppData\Local\CoreAIPlatform.00\UKP\*\

Files

Artefact Details

The main SQLite database ukg.db has the following tables:

App & AppDwellTime Tables

The App table provides information on processes that create windows. The AppDwellTime table includes both the time when the window was created as well as the process responsible for it and also the overall tracking of how long the window has been open.

WindowCapture Table

This table is the most important one to analyse as it includes information on when windows are created, changed and when a snapshot is taken. It includes window titles and IDs that you can enrich with the App table.

Events of Note

The WindowCaptureEvent includes the GUID of the image that can be found in the ImageStore folder.

The referenced snapshot image for the token id highlighted df52e14a-0880-46c6-8de5-c8cd88228e94 is shown below. Files are stored in JPEG format, just devoid of the .jpg extension.

A closer look at these images reveal that they also contain the metadata associated with the WindowCapture event.

JPEG metadata

Metadata is stored in an EXIF tag (0x927C) which represents “Makernote”, a custom property defined by the manufacturer and can be used to store any kind of data. This can be seen in the screenshot below. Much of the data seen in the database is also stored in the image itself.

Recall stores metadata in a fairly simple key-value format which can be easily parsed out.

The key value format was recreated and read using the following structures:

typedef struct {
  int32 length;
  char  name[length];
} Str;
typedef struct {
  int32 key_type; // always 0x0C (Str)
  Str   key;
} Key;
typedef struct {
  int32 val_type;
  // data here is variable depending on val_type;
} Value;

The following data types have been observed.

Based on the definitions above, the EXIF data for the image shown earlier (df52e14a-0880-46c6-8de5-c8cd88228e94) parses out to the following.

The WindowChangedEvent table also references changes for specific windows. For example, below is an instance of edge.exe which had a “WindowId” of “524882” and tracked the changes to the Window Title.

WindowCaptureAppRelation Table

An examiner can enrich the WindowCapture events with the App table by pulling in data from the WindowCaptureAppRelation table.

The query to enrich WindowCapture events with process information:

SELECT datetime(WindowCapture.TimeStamp/1000, 'unixepoch') as ts, WindowCapture.Name, WindowCapture.WindowTitle,
  App.Name, App.Path
FROM WindowCapture 
    LEFT JOIN
    (SELECT WindowId as wid, AppId
      FROM WindowCapture LEFT JOIN WindowCaptureAppRelation
      ON Id=WindowCaptureId
      WHERE WindowId is not NULL and AppId is not NULL
      GROUP BY WindowId, AppId
      ORDER BY WindowId
    ) WindowApp
    ON WindowCapture.WindowId=WindowApp.wid
LEFT JOIN App ON App.Id=WindowApp.AppId
ORDER BY TimeStamp

WindowCaptureTextIndex_content Table

This table contains the processed OCR text from the Window snapshots. These events appear to only be recorded when a WindowCaptureEvent is taken rather than on every WindowChangedEvent.

The WindowCaptureTextIndex_content table can be queried to select all events with OCR text and associated process information as follows:

SELECT datetime(WindowCapture.TimeStamp/1000, 'unixepoch') as ts, WindowCapture.Name, WindowCapture.WindowTitle, WindowCaptureTextIndex_content.c2 as OcrText, App.Path
FROM WindowCaptureTextIndex_content
    LEFT JOIN WindowCapture
        ON WindowCapture.Id=WindowCaptureTextIndex_content.c0
    LEFT JOIN WindowCaptureAppRelation
        ON WindowCaptureAppRelation.WindowCaptureId=WindowCaptureTextIndex_content.c0
    LEFT JOIN App
        ON App.Id=WindowCaptureAppRelation.AppId
WHERE OcrText IS NOT NULL

As a test, we ran some commands in the Windows Terminal app to see if the window tracking would record them. Not only did it record the commands but the outputs too in a searchable text format as text from the entire window is saved. Normally in order to get this kind of logging, we have to rely on a skilled administrator configuring this beforehand, or a threat actor saving the output.

The WindowCapture event image (cropped to show only the Terminal) was the one shown below:

Our database query returned the following output.

The full OcrText field data can be seen here:

More on Incognito Mode

While the Window title change events provide insight into activity that is typically not recorded in existing browser forensic artifacts, it is basically limited to the title changes.

WindowCaptureEvents will NOT record Incognito windows in the image snapshots. It will render them out of the screenshot entirely. This may be related to the SetWindowDisplayAffinity functionality which can be used by an application to control what is captured in a Recall screenshot.

The view from our Azure VM with an active Edge Incognito window in the background:

The Snapshot image from Recall with the incognito window removed and showed what was under the Incognito Edge session:

Velociraptor Artefacts

We’ve created two quick artefacts to view the Recall database events.

Windows.System.Recall.WindowCaptureEvent

The first focuses on the WindowCaptureEvent events, and enriches them with associated process information, the OCR-ed text and their associated image in Velociraptor.

Link: https://docs.velociraptor.app/exchange/artifacts/pages/windows.system.recall.windowcaptureevent/

Windows.System.Recall.AllWindowEvents

The second is a more generic search that pulls back all the event types in the WindowCapture table and enriches them with process information.

Link: https://docs.velociraptor.app/exchange/artifacts/pages/windows.system.recall.allwindowevents/

Additionally we created a KAPE Target file to allow examiners to collect this folder during an investigation.

Where is the AI?

During our testing we were unable to get the contextual AI engine to return results based on the data Recall recorded. For example, in one test we browsed images of puppies, then searched for “dogs” in Recall. This did not return results of the puppy images we had browsed.
We believe this may be a limitation of the current way we enabled Recall “unofficially”, rather than a reflection of any fundamental flaws with the tool.
We also noted that some tables such as File and Topic were not populated which may not reflect the final product once launched more widely.

Conclusion

To the forensic investigator, Recall can thus provide fine-grained evidence of execution such as commands typed into a terminal, app execution and continued usage, evidence of persistence/existence of file/folders/apps as well as provide the investigator the same Desktop view that the end user (or threat actor) had at a particular point in time.

While Recall is a long way from being standard in enterprise environments, it provides a huge amount of investigatory value… if it’s enabled. But given the initial reaction from privacy experts and concerns raised by cyber security experts, it may become rare occurrence.