Weekly Update 6/6/2025

 OneDrive Evolution

OneDrive Evolution has been updated to OneDrive version 25.106.0602.0001. Starting with version 25.102.0527.0001, there is a new folder under settings named .Dbfs.dbfs_bootstrap. It is not known at this time what the folder pertains to, but it does contain a database (dbfs.db). Below is a screenshot of the contents of the database.

OneDrive Evolution 

SyncEngineDatabase.db Updates

Starting with version 25.105.0601.0001 of OneDrive, the SyncEngineDatabase.db schema has been updated to v38. A new table has been added to the database (od_ServiceOperationHistory).

SyncEngineDatabase Schema v38

 

OneDrive Evolution and Schema Updates

OneDrive Evolution Updates

OneDrive Evolution has been updated to v25.093.0514.0001

OneDrive Evolution

SyncEngine Schema Updates

 Schemas 34 - 37 have been added

• v34 brings a new table od_ThrottleHistory
• v35 adds archiveState column to od_ClientFile_Records table
• v37 adds lastFailedAttempt to od_CreateAddedFolderFailures table

All schemas can be found here.

OneDriveExplorer now supports Microsoft.FileUsageSync.db

Recently, I have been focused on adding support for Microsoft.FileUsageSync.db. See my previous post on Microsoft.FileUsageSync.db. The recent_files_formatted_spo table was the focus of this work. To my surprise, this table holds a wealth of information. Microsoft.FileUsageSync.db tracks how files are being used including email, meetings, events, Teams chats, notes, and SharePoint. Let's take a peak into the changes to OneDriveExplorer and these new data points.

OneDriveExplorer Interface Changes

Off the bat you will notice a new sidebar containing the data points I mentioned earlier. The data points will be enabled once data has been added that pertains to that particular data point.

The next big change comes to the file menu. OneDrive settings has been changed to OneDrive metadata. This made more sense because the menu contains more options besides the OneDrive settings items. Parsing has been simplified. You can now select the Profile option, point it to a users OneDrive profile, and OneDriveExplorer will take care of the rest. There is an option to load individual files and import saved data from the command line version of OneDriveExplorer.

Loading individual files has become more intuitive with the new menu. It contains options for all supported files by OneDriveExplorer.

Import JSON has stayed the same but there is a slight update to Import CSV. This is because OneDriveExplorer saves the Microsoft.FileUsageSync.db to a separate csv.

Unmanaged Error Handling

OneDriveExplorer now can handle unmanaged exceptions and write to a log.

Microsoft.FileUsageSync.db Data

What kind of data does the Microsoft.FileUsageSync.db hold? Email, meetings, events, Teams chats, notes, and SharePoint data. I'll walk through what this data looks like in OneDriveExplorer.

Email Data

The email section contains data for files that have been shared through email. Please note that this information does not contain the body of the email. On the left will be a list of emails by sender, subject and date. When selected, the data will be presented in a familiar format resembling what you might see in an email client. Below that will contain the information about the file being shared. And there is a lot! Way too much to list here.

Meeting/Events Data

The meeting and events sections are very similar in nature. These sections hold data for files that have been shared via meeting or events. Like the email data, a list of meetings/events will be listed on the left. The middle contains various metadata that pertains to the meeting/event along with the metadata of the file being shared. Meeting/event participants are listed on the right.

Chat/Notes Data

The chat/notes sections contain the same type of data. These are files that are shared through Teams. The only difference is that notes are files shared with oneself. Chat/Note subject is on the left. If there is a subject, the list will be populated with the subject. If there is no subject, the list of participants will be combined like in Teams. The file metadata will be in the middle and participants on the right.

SharePoint Data

The SharePoint section contains data on files that have been shared through SharePoint. On the left will list the SharePoint site. The middle will list the files being shared. When a file is selected, the metadata for that file will be populated.

File Metadata

The file metadata contains too much information to list it all here. There is one thing I would like to show. There is a section in the file metadata call activity. It's not always populated but when it is, it can show various activities such as:

• You commented on this
• You edited this
• You recently opened this
• You shared this in a Teams chat
• activity.message_format
• {0} edited this
• {0} mentioned {1}
• {0} replied to a comment
• {0} sent this
• {0} shared this in a Teams chat
• {0} shared this in a meeting invite
• {0} shared this with you

Conclusion

As you can see, Microsoft.FileUsageSync.db holds a lot of information. And remember, this is only one column from one table in the database. You can find the latest version of OneDriveExplorer on GithHub.

OneDrive Microsoft.FileUsageSync.db

I recently started to look into the Microsoft.FileUsageSync.db. The database can be found in %localappdata%\Microsoft\OneDrive\ListSync\Business<1-9>\settings. It is not documented in OneDrive Evolution because it only appears in OneDrive for Business. OneDrive Evolution's data is collected from personal only. It's not known what version this database first appeared in. Just like Microsoft.ListSync.db, this database is used by Microsoft.SharePoint.exe but is not related to the Offline Mode for web feature that I am aware of. There is some interesting data in the recent_files_formatted_spo table. The FormattedValue column holds JSON data that isn't the prettiest to look at.

To make the data easier to read, I wrote the following script to convert the JSON data into CSV format.

import sqlite3
import pandas as pd
import json

db_path = "Microsoft.FileUsageSync.db"

conn = sqlite3.connect(db_path)

query = "SELECT FormattedValue FROM recent_files_formatted_spo"

df = pd.read_sql_query(query, conn)

conn.close()


def parse_json(value):
    try:
        value = value.encode().decode('unicode_escape')

        return json.loads(value)
    except Exception as e:
        print("JSON Parse Error:", e)
        return None


df_parsed = df["FormattedValue"].apply(parse_json)

df_expanded = pd.json_normalize(df_parsed.dropna())

df_expanded.to_csv('output.csv', index=False, encoding='utf-8')

So what type of data does this table hold? Unfortunately, I cannot show you the data because I don't have a development environment so I'll do my best to explain what I found.

To give you an idea, when the data is parsed out, we have the following headers:
file.Id, file.@odata.id, file.FileModifiedTime, file.LastModifiedDateTime, file.FileCreatedTime, file.FileExtension, file.FileSize, file.StorageProviderContext, file.IsEmptyCopy, file.SharePointItem.SiteId, file.SharePointItem.WebId, file.SharePointItem.ListId, file.SharePointItem.UniqueId, file.ItemProperties.Shared.LastSharedWithMailboxOwnerByDisplayName, file.ItemProperties.Shared.LastSharedWithMailboxOwnerBySmtp, file.ItemProperties.Shared.LastSharedWithMailboxOwnerDateTime, file.ItemProperties.Shared.SubjectProperty, file.ItemProperties.Shared.AttachmentItemReferenceId, file.ItemProperties.Shared.AttachmentReferenceId, file.ItemProperties.Shared.ImmutableFileItemReferenceId, file.ItemProperties.AggregatedActivities.LastUserActivityDateTime, file.ItemProperties.AggregatedActivities.LastModifiedDateTime, file.ItemProperties.AggregatedActivities.MailboxOwnerTopInsights, file.ItemProperties.AggregatedActivities.IsHidden, file.ItemProperties.SemanticProperties.Title, file.UserRelationship.LastSharedDateTime, file.Visualization.Title, file.Visualization.AccessUrl, file.Visualization.Type, file.AllExtensions.SharingHistory.Instances, file.FileName, file.SharePointOnlineFacetStatus, file.Document.Title, file.WorkingSetId, activity.message_format, activity.type, activity.users, activity.timestamp, activity.extended_info.subject, file.UserRelationship.LastSharedById, file.Document.Author, file.SharePointItem.ModifiedBy, file.PrimaryItemLocation, file.SharePointItem.ContentClass, file.SharePointItem.SitePath, file.ItemProperties.Default.SiteTemplateId, activity.extended_info.sharing_medium, file.Visualization.ContainerTitle, file.Visualization.ContainerUrl, file.Visualization.PreviewImageUrl, file.FileOwner, file.SharePointItem.ContentTypeId, file.SharePointItem.ListItemId, file.SharePointItem.DocId, file.SharePointItem.ModifiedByDisplayName, file.SharePointItem.FileUrl, file.SharePointItem.ParentId, file.ItemProperties.Default.AuthorOWSUSER, file.ItemProperties.Default.EditorOWSUSER, file.ItemProperties.Default.DocumentLink, file.ItemProperties.AggregatedActivities.MailboxOwnerHistograms, file.ItemProperties.ClientAccessByMailboxOwner.LastAccessDateTime, file.ItemProperties.SemanticProperties.Url, file.ItemProperties.SemanticProperties.ContainerName, file.ItemProperties.SemanticProperties.ContainerUrl, file.UserRelationship.FrequentlyUsedSiteWeight, file.UserRelationship.LastAccessDateTime, file.ItemProperties.Default.ProgID, file.ItemProperties.Shared.TeamsMessageThreadId, file.ItemProperties.Direct.ColorHex, file.UserRelationship.LastModifiedDateTime, file.ItemProperties.Default.RecordingStartDateTime, file.ItemProperties.Default.RecordingEndDateTime, file.ItemProperties.Default.MeetingOrganizerId, file.ItemProperties.Default.MeetingICalUid, file.ItemProperties.Default.BaseType, file.ItemProperties.Default.ListTemplateTypeId, file.ItemProperties.Default.ListIcon, file.ItemProperties.Default.ListColor, activity.extended_info.navigation_id

It appears to hold information on files that are not necessarily in your OneDrive, but files that are shared from OneDrive. This can include files that were shared to you via email, Teams, and whiteboards to name a few.

Another interesting table is recommended_files. This table appears to hold a max of 20 files. One of the things that stood out to me was a description in the JSON data. The description is the first couple lines of the file so it could give us a good indication of what the file contains.

The last table I want to talk about is top_collaborators. This one holds information on people the user interacts with the most. We could potentially glean work relationships from this data.

The plan is to add this data into OneDriveExplorer once I can get it sorted out. Until then, use the script to explore this sure to be valuable forensic resource.

OneDriveExplorer Offline Mode Edition

Changes to OneDriveExplorer (ODE)

With this release, there are a few things to be aware of that have changed with the GUI and command line version.

GUI

The ODE GUI now has a profile selection. This is to make things easier so we don't have to point to certain files/folders for parsing settings data and logs. The options are still there but this is meant more for if you have a loose collection of files.

With the profile option, all we need to do is select the profile folder %LOCALAPPDATA%\Microsoft\OneDrive and ODE will do the rest. Logs will only be parsed if the Enable ODL log parsing option is enabled in the preferences.
The GUI can now indicate if the account is Personal or Business.

Command Line

With the command line, there is a new argument (--output-dir) to designate the save folder location. There is no longer a need to add a directory to --csv, --html, or --json. These arguments are now used to indicate what type of output you want the data stored in. Also, --csvf has been dropped.

New Additions

OneDrive Offline Mode

OneDrive for Business has a feature called Offline Mode that allows you to continue to use the web version of OneDrive without an internet connection. If you want to learn more, I had written about it in another article. In order for the database (Microsoft.ListSync.db) to populate, Offline Mode needs to be set up. First off, the feature needs to be pushed to your tenant by Microsoft (I believe Microsoft has finished rolling this out). Offline Mode is enabled by default but can be disabled via group policy. When you navigate to OneDrive for web, if you see a computer icon in the upper right of the page, Offline Mode is enabled and ready.

Once this is done, the Offline Mode database will be populated. There are also some limitations that might not allow Offline Mode to be enabled. See the Current limitations of offline mode section for more information.

What does this bring to OneDriveExplorer

With new features bring new data. So what kind of data does OneDriveExplorer get from Offline Mode? In addition to knowing a file/folder is shared, we can now see who it is shared with.

Another interesting artifact of this is seeing what other people have shared and to whom. If we look at a folder that was linked to OneDrive, the shared data is present, even though we did not do the sharing.

Another data point Offline Mode brings to ODE is OCR (Optical Character Recognition). Here is an example of the data in ODE verses the actual image.

More to come

There is still a lot of data to go through with Offline Mode that can be added to ODE. Additional work will be done to have a dedicated parser for Microsoft.ListSync.db for instances where that is the only file you have available. The latest version of OneDriveExplorer can be found here.

OneDrive Offline Mode (Recallish vibes)

Back in April 2024, Microsoft announced a new feature coming to OneDrive for Business called Offline Mode. The feature allows you to continue to use the web version of OneDrive without an internet connection. It works by downloading your file metadata and running a web server (Microsoft.SharePoint.exe) located in Program Files\Microsoft Onedrive\<OneDrive_Version>\. Now, as many of you may already know, I dabble in OneDrive forensic artifacts so when I finally got the feature in December I started to poke around. I found some pretty interesting things in the database that drives Offline Mode.

The database in question is called Microsoft.LinkSync.db. It is located in %LOCALAPPDATA%\Microsoft\OneDrive\ListSync\Business1\settings. This database contains the file metadata to help run Offline Mode. According to Microsofts own documentation,

"To accomplish this, a copy of your file metadata that powers OneDrive web app is securely stored locally on your device. These data on your device are only available to you. If someone else were to sign in on your device, these local data on the device wouldn't be available to them. We adhere to privacy guidelines outlined in the Microsoft Privacy Statement.

A secure local web server on your device handles the operations that you perform on your files, such as viewing, sorting, renaming, moving, and copying where traditionally these operations would need to be handled by the OneDrive cloud service. This results in fast and smooth interactions with your files like loading your files and folders, sorting, renaming, moving, renaming, and more. And all of these operations will continue to work even when you are offline, lose your internet connection, or run into a service disruption in the app."

I find this statement to not be true. How can this data be "securely stored" when there are no protections on the database? Microsoft.LinkSync.db is sitting there in an unecrypted state. I can grab this database and copy it to where ever I want, open it and view it. Even to another device. "these local data on the device wouldn't be available to them", I was able to access the database with an account with admin privileges and the data was available to me. Now I know you're saying but you had admin rights. True but according to Microsoft, it should not be available to me. Also, I'm not a hacker but I'm sure there are other ways to get to it. Lets take a peak at the data in this "securely stored" database that can be exfiled and read by anyone.

OCR data

In my quick look over of Microsoft.LinkSync.db, I came across a couple tables named list_<listID>_<siteID>_rows. One of them had a column named MediaServiceOCR. The data appears to be related to this feature. Nice feature, until recently, when the data is being stored locally, unsecured. Here is a small sample of the data:

But why should I be concerned. Not all of these images are stored locally, some can be online only. If someone were to start downloading images from the cloud, there would be traces in the Unified Audit Log (UAL). And if it were a lot of files, it would make some noise. So why not grab the database and not even touch OneDrive. Sound familiar (Recall)? The other issue with this is the user might not even realize that when they take a screenshot with something like Snipping tool, the default in Windows 11 is to save it to OneDrive whether they decided to save it or not. And there could be concerns about HIPAA and other regulations that need to be followed.

What other fun things can we find?

There is another table called site_<siteID>_users that, you guessed it, contains user information for your organization.

Along with all the usual things like file/folder names, paths, etc. I'm probably missing some things but again, this was a quick look.

What lead me to write this?

A couple days ago, SwiftOnSecurity posted a Tweet (yes I still call them that) that I had responded to.

This caught the attention of vx-underground. Even though they are more malware related, they like me for some reason.

It's just one poll but it looks like people don't want this data laying around unsecured. The collaboration with xv-underground lead to Smelly releasing a tool to "Tool designed to exfiltrate OneDrive Business OCR Data". In turn, I decided to release the python version of this I had been working on.

vx-underground OCRMe
Beercow OCRMe

I've done all I can to raise my concerns so I'll leave it up to the community to decide if this is truly a concern or not.

Running Autopsy Auto Ingest in Headless Mode

In this post we are going to look at running auto ingest in a headless state. This will allow the auto ingest server to be rebooted without the need for human interaction to start the auto ingest node.

Auto Ingest

Auto Ingest is a experimental feature in Autopsy. It's best used in a multi-user cluster to help automate case workloads. One thing in the documentation that didn't make sense to me was the following: "Note that if the computer running Autopsy in auto ingest mode is restarted, someone must log into it to restart Autopsy. It does not start by itself." This is not entirely true as we will see in a minute.

Turns out, there is an undocumented feature to run auto ingest as a service. I started my journey into headless mode by looking for any clues in the documentation. I was unsuccessful at this so I turned to GitHub to see if there was anything in the various commits over the years. I was able to find a commit that was briefly added and then [removed[(https://github.com/sleuthkit/autopsy/commit/a02f02b700748c0dfd72cabdcdbedeaab43a6d78) from the documentation. It stated "Note that if the computer running Autopsy in auto ingest mode is restarted and the auto ingest node is not running as a service, someone must log into it to restart Autopsy." Interesting! It seems like, at some point, auto ingest was able to run as a service. The next step was to look at the source code.

Back to GitHub to look at the auto ingest code. After searching through various files, I came across the piece I was looking for in AutoIngestControlPanel.java. There is a definition called ‎RUNNING_AS_SERVICE_PROPERTY that looks like the key to this mystery.

Putting it Together (Headless Mode)

Autopsy can be ran as a service so a user does not need to log into the auto ingest node to start it.

1. -J-Dautoingest.runningasservice=true needs to be added the the default_options in the autopsy.conf file.

   
   # options used by the launcher by default, can be overridden by explicit
   
   # command line switches
   
   default_options="--branding autopsy -J-Xms24m -J-Xmx4G -J-XX:MaxPermSize=128M -J-Xverify:none,
   -J-XX:+UseG1GC -J-XX:+UseStringDeduplication -J-Dprism.order=sw -J-Dautoingest.runningasservice=true"
   
   

2. Download NSSM. In the same folder as NSSM, create a batch file named auto_ingest_service.bat with the following content:

   
   @echo off
   
   nssm install Autopsy <PATH_TO_AUTOPSY>\Autopsy-4.20.0\bin\autopsy64.exe
   
   nssm set Autopsy DisplayName Autopsy Auto Ingest
   
   nssm set Autopsy Description Automated ingest service for Autopsy
   
   nssm set Autopsy Start SERVICE_AUTO_START
   
   nssm set Autopsy ObjectName LocalSystem
   
   nssm start Autopsy
   
   

3. From a command prompt, run auto_ingest_service.bat. If everything was successful, you should see the following output:

   C:\nssm-2.24\nssm-2.24\win64>auto_ingest_service.bat

   Service "Autopsy" installed successfully!

   Set parameter "DisplayName" for service "Autopsy".

   Set parameter "Description" for service "Autopsy".

   Set parameter "Start" for service "Autopsy".

   Reset parameter "ObjectName" for service "Autopsy" to its default.

   Autopsy: START: The operation completed successfully.

With this setup, auto ingest is now running as a service and can survive reboots without having to log into the server and starting auto ingest.