Outlook for Windows

Outlook for Windows is Microsoft’s latest free email client. The app, available from the Microsoft Store (as well as now coming by default on Windows 11), effectively replaces the built-in Mail app from Windows 10 and 11. It does not (currently) appear to be a replacement for the Outlook desktop application that is part of Office.

Outlook for Windows is a Windows Desktop application that utilises Microsoft Edge WebView2 (WebView2). WebView2 uses Microsoft Edge (based on Chromium) as the rendering engine to display web content. Because of this, the artefacts produced by Outlook for Windows share many similarities with artefacts produced by other Chromium based browsers/applications.

Being a Windows Store app, we are used to those app’s artefacts being stored within C:\Users\<username>\AppData\Local\Packages\, and although a set of folders get created there, the artefacts we’re interested in for this Outlook app can be found in the following location:

• C:\Users\<username>\AppData\Local\Microsoft\Olk\

Within the Olk folder, you may find a file called “UserSettings.json”. This JSON file contains a key named “Identities” in which the email addresses (two email accounts in this case) in use by the Outlook for Windows client can be found, along with a string of hexadecimal characters sometimes referred to as an InternetUID. Furthermore, another key called “AccountLocalBackup” exists associating a UUID with the email address:

Within this location, a folder called “EBWebView” exists. A folder called “EBWebView” or “EBWebView2” is a good marker to be looking out for to identify applications using Edge WebView. Inside here we’ll find the customary “Default” profile folder containing the usual Chromium/Electron folder/file names:

As with an increasing number of websites/web apps, a lot of useful data can be found stored in an IndexedDB. Being as this app is based on Edge Webview2 (Chromium), the IndexedDB data is stored within a LevelDB data store. We’ve already covered these data structures in detail in a previous blog: https://www.cclsolutionsgroup.com/post/indexeddb-on-chromium. In short, IndexedDbs are a key-value store of JavaScript objects and values could consist of further key-value objects.

One of the most powerful tools we have for understanding how Web apps store data is the developer tools built into browsers; luckily we can still make use of these tools in this Webview application by running it with the following command:

By clicking on “Application” from the menu in the DevTools window, we can see the different data storage objects, including IndexedDB:

Although it isn’t quite the same as a relational database such as SQLite, we can draw some analogies to make things feel a little familiar: IndexedDB can contain a number of databases which each contain a number of object stores. You can think of object stores like tables, which like in relational databases can also have indices to speed up data access. Object stores contain records, which are like rows in a table (but structured as a hierarchy rather than a row).

Figure 5 shows a screenshot of the databases in the IndexedDB during testing. Two email accounts were added to this instance of Outlook. The two sets of databases ending in two different UUID relates to these two different email accounts. These are the same UUIDs found identified in the “UserSettings.json” file.

IndexedDB databases contain data structures called Object Stores. Some of these can be seen in figure 6:

In figure 6, the Object Stores can be seen with the icon:

The other items that can been seen are indices. The “owa-offline-data-<uuid>” database contains many of the object stores that are of interest to us. Figure 7 shows some of the databases and object stores that could be of interest.

settings Object Store

Looking in the “settings” object store within the “owa-offline-data-<uuid>” database, we can also find information about the account that particular database (and any other with the same UUID) relate to.

Looking for a record with a key called “userConfig” and expanding that record, we can see more information about the account including the email address and display name:

messages Object Store

The “messages” object store contains various information relating to messages. Each record relates to an email and includes dates and times, sender, recipients, the email subject and a textual preview of the message, amongst other information. This object store’s data appears to relate to what is seen in the table view when viewing the different folders (e.g. Inbox, Sent Items, Draft etc.).

messageBodies Object Store

Perhaps even more useful than the “messages” object store is the “messageBodies” object store. Again, each record relates to a specific email.

The “messageBodies” object store contains similar information to “messages”, however the body of the email (usually in HTML) also exists for each record. This is usually under a key (in the record’s value) called “NormalizedBody” (occasionally it may be under another key called “Body”).

The screenshot below (figure 11) shows an expanded “messageBodies” record showing the body of the email (a very short email in this instance). The screenshot also shows the “Sender” and the “ToRecipients” showing two email addresses and associated information.

The “messageBodies” record also contains information about attachments to the email. Below (figure 12) is an extract from a “messageBodies” record of an email with two attachments. Amongst the information is a file name, file size and an “AttachmentId”.

Once the app’s cache is parsed (… Olk\EBWebView\Default\Cache\Cache_Data), email attachments can be identified by cross-referencing the cache item’s key against the “AttachmentId” values from the “messageBodies” records. This is expanded upon later in this article.

There is also an “Attachments” folder within the “Olk” folder. However, during testing, attachments only got created in here temporarily when a user saved an attachment.

How can we extract this data?

Luckily CCL already have a solution for this. By going to ccl_chromium_reader you’ll find a free, open-source Python library for dealing with all manner of chromium type artefacts, including IndexedDB and Chrome cache.

A simple example of how to print (to the terminal) some of the values from the “messageBodies” object store(s) can be seen in figure 13. This will print:

• DateTimeSent,
• Sender (a string showing the name and email address),
• Recipients (a string showing the name and email address of all recipients listed – additional keys exist for CcRecipients and BccRecipients)
• Subject
• Preview

Obviously, a finished script will be a bit more sophisticated than this, but this should show how simple it is to extract data with the ccl_chromiun_reader library.

If you want to extract the NormalizedBody (or Body) and write the html to a file, you could do something like the following (figure 14):

We can then view the body of the email:

To get a list of attachments from a “messageBodies” record, a function similar to figure 16 could be used:

The above code will give us a string like the following that shows two attachments – a PNG image and a PDF file:

During testing, attached files were identified as “Cache” items.

The “ccl_chromium_reader” library contains a script called “ccl_chromium_cache”. The main function of this takes two arguments; a path for the cache folder (…Olk\EBWebView\Default\Cache\Cache_Data) and a path for an output folder. The script will dump all the cache items to a folder called “cache_files”. Each cache item will be named by its SHA256 hash value. A CSV file will also be created called “cache_report.csv”.

From the “key” column in the “cache_report.csv” file, we can see there’s a record containing “GetFileAttachment?id=” matching the same attachment ID from above. Note: some common forensics tools may not provide the entire key and therefore make identifying the correct attachment more difficult.

Note that the forward slash character “/” is shown as the URL encoding representation of “%2F” and the “+” character as “%2B” in the “cache_report.csv” file.

Unfortunately, at the time of testing, the wealth of data stored in IndexedDB doesn’t extend to a browser’s storage when accessing the Outlook website via a web browser. But, the now default mail client, Outlook for Windows could provide investigators with a large source of data from which potential evidence could be found.

This highlights the need to look deeper than what is recovered by the standard tools. Furthermore, having an understanding of browser technologies and being able to extract artefacts not supported by other tools could prove vital in identifying crucial evidence.