I wanted to take a quick and dive into this week’s Sunday Funday challenge but didn’t have a whole lot of time, I basically set a timer for an hour or so at the end of the day and found as much as I could, and then compiled it all today. Gotta set a time limit or else the rabbit-hole never ends 🙂

Oleg has already shared his answer and done a decent amount of work to answering the questions. I’m not going to be reinventing the wheel a whole lot, just expanding on what has already been found.

(Note: I’m not going to be answering all of the questions)

I have Teams on a few devices, but I decided that I was going to look at it on my Mac for this challenge. The only reason being that my wife has appropriated my Windows computer iu90(and populated it with her own Teams data….hmmm🧐)

Where are the artefacts?

I did a search for Teams under my user profile and found references in the following places. I wouldn’t expect there to be much in the Applications folder, but I guess there could be.

Location	Notes
./Library/Application Support/Microsoft/Teams	Large amount of the data of interest Chats are stored in the IndexedDB folder
./Library/Application Support/com.microsoft.teams	Nothing of value, a few folders An nskeyedarchive plist called “metadata” which doesn’t seem to have anything in it.
./Library/Saved Application State/com.microsoft.teams.savedState	Folder containing data pertaining to the last state of the app
./Library/Preferences/com.microsoft.teams.plist	Small plist that didn’t have anything I’d consider valuable.
./Library/Logs/Microsoft Teams	Empty on my system
./Library/Caches/com.microsoft.teams	A database called Cache.db and an empty folder called net.hockeyapp.sdk.mac. Hockeyapp is a Microsoft thing.
./Library/Caches/ com.plausiblelabs.crashreporter.data/com.microsoft.teams	Crashdata by plausiblelabs Crash reports are output as protobuf-encoded messages, and may be decoded using the CrashReporter library or any Google Protobuf decoder….Ugh of course they are…

./Library/Application Support/Microsoft/Teams

This is where the bulk of useful data in found, and from looking at Oleg’s screenshot, mostly matches up across MacOS and Windows.

As Oleg found, the conversations are held within the IndexedDB folder, which contains a leveldb database. More information on leveldb can be found on Google’s repository and also this fun website I found. Definitely something that should be bookmarked for later.

On my system the database was named 000004.log. There are a few ways of parsing a leveldb database; strings is probably the easiest to read but I wanted to see how Googles tool parsed it. I’m not sharing a screenshot but the answer was not well. The tool that Google provides is more of a library, and there are other ways of parsing the data. I believe Magnet AXIOM supports it, but I haven’t tested what it parses specifically.

I didn’t have chance to look for a proper leveldb viewer; I found a few that required compiling but effort. Any suggestions would be welcome. I think Cellebrite’s file viewer may also support the format.

Some fun observations though; On my tenant I don’t have rights to delete messages, just edit them. In the interface I couldn’t see a way of reviewing the contents of my edits though. That’s ok, we’re forensicators after all, so lets go into the database.

I sent a message to a colleague.

---

And can easily see this in the strings of the database.

But then I edited it.

And found my edit in the database as well.

Interestingly, the screenshot that I displayed earlier was taken after I did the edit. So the text that originally was posted is still in there. I haven’t dived in to match up times, but there are text-based timestamps in UTC. Likely one of them will indicate the edit time.

It’s likely that deleted messages will remain for a period as well. I found this post by Kevin Kwok on recovering deleted entries; so it is possible provided compaction hasn’t taken place. Something else someone can test is if you log into another device does that either a) trigger compaction upon the sync event, b) copy just the new records across, or c) copy the whole database which means we can get deleted data from that too?.

I didn’t look into the call history, file transfer, or meeting history questions because time.

But what else did I see!? Various files that appear like a standard Chromium-based web browser. I think it’s an Electron app, they all seem to look like Chrome because Electron is based on the Chromium browser rendering engine.

• Network Persistent State – Various Microsoft urls, Does list the tenant name in a sharepoint link.
• Preferences JSON file – Contained a Device_ID_salt. It looks base64 but not sure what it means.
• databases directory contained an sqlite database with nothing in it.
• desktop-config.json – JSON file containing your login username (upnWindowUserUpn). Various other settings that look interesting like machineId and deviceInfoId. Even has location on the screen where teams last was for some reason.
• preauth.json – Configuration details. Unsure if there’s anything valuable in here.
• settings.json – As above, lots of configuration settings, but not sure how useful.

Two other files that were super interesting were storage.json and log.txt

Storage.json had an auth_tenant_users_map field with an entry for each user that had logged into teams. This included their name, email address, and the IP address from which they logged in last (I believe. Someone test this when we can go outside again!). Auth_time is a unix timestamp. Not sure what it means but may be the first time the user account logged in.

Log.txt was really interesting from a DFIR perspective. Sure content is great, but we like metadata! All of the timestamps in here were in local time, but they have a timezone, so that’s great. Here you can see the change from daylight savings time.

If you do a grep for “tenant” you should find the users tenant ID. Not sure if you’ll find any other tenant IDs from communicating with others.

You can also grep for “scenarioName: desktop_app_launch” and see when the app was launched. It’ll also tell you which version of macOS and teams was running. I believe that searching for “reason userInitiated” will indicate that the user has opened the app themselves rather than it automatically opening but haven’t properly gone through to test it.

Another grep to run is for the “info” event relating to “https://login.microsoftonline.com” which typically showed me the time that I logged into Teams.

You can also see when the user closed the app by looking for things like “Closing the app”, “main window closed”, and “main window is closing”.

There may be other useful info in here so it’s worth a deeper dive should Teams be involved in a case.

The other interesting thing is that the log.txt file doesn’t appear to roll. Mine goes back to when I either installed or first logged into teams (may have been the same day, not sure, was back in February. That was like…a decade ago now?)

Further work (for someone else to do!):

Mobile:

Microsoft Teams runs on iOS and Android; I’m assuming that the data will come out with a standard backup, so should be relatively easy to examine. Might not though.

I’m curious how much overlap there is. Considering the backend file types chosen probably quite a bit.

Cloud:

There’s likely additional useful information in the cloud, but I don’t have admin rights to access the Compliance Centre on our corporate tenant – which is fair, I break things.

Magnet advertises that their CYBER product can be used to investigate cloud data though, possibly also the Cloud addon for AXIOM.

You can also use Microsoft’s eDiscovery tool to search across Teams data. Or here’s a Powershell script I found that I haven’t tested and don’t claim any responsibility for 🙂

Skype for desktop

Just looking at the folder structure of the Skype app data on my Mac; likely very similar codebase and artefacts. Probably just another Electron app.

---

I’m glad Sunday Funday is back, even if it’s taking away time from things I should be doing. It’s good to have hobbies 🙂

Alright, back to writing