Why Does Teams Activity Appear in SharePoint Logs? And Why Does This Matter to Attackers?
Attachments in Teams chats use OneDrive under the hood, so they actually appear in SharePoint logs. Plus: why this matters for attackers disguising their actions.
From the outside, it can appear that detection engineering is mainly about finding attacker behavior.
In reality, it has everything to do with understanding the quirks of the environment.
Microsoft environments certainly have no shortage of quirks.
Here’s one: when users interact with attachments in Microsoft Teams chats, we see that activity in the SharePoint logs instead of the Teams logs.
Let’s walk through some examples.
Example 1: Downloading a file sent in Teams
Here’s a screenshot of my own SharePoint logs in Petra.
So, how can we tell that a file here came from Teams?
We see in these File Downloaded SharePoint events that the backend workload is OneDrive. But, the relative URL is Documents/Microsoft Teams Chat Files.
This tells us that even though it’s SharePoint/OneDrive activity, it matches up with the file I sent in Teams.
Example 2: Uploading a file to a Teams chat, then deleting it
I uploaded this file to a Teams chat (File Uploaded), then realized I actually wanted to send a different file.
So, I deleted it before sending the message.
Deleting an attachment without sending it generates a File Recycled event.
Despite this all happening in Teams, it’s categorized and logged as SharePoint activity.
Example 3: Uploading a file to a Teams chat, then sending it
This example is much more involved than the first two. Let’s walk through each operation:
File Uploaded - The file was uploaded to Teams.
Anonymous Link Created - OneDrive generated a sharing link for the file.
Sharing Set - Sharing permissions were defined for the link. The default permissions for an anonymous link allow anyone with the link to access the file.
Added to Group - My teammate was added to the group with these permissions.
Sharing Inheritance Broken - The file’s default permissions (anyone with the link can access) were overridden.
Sharing Set - Specific sharing permissions were defined directly on the file to specify who can access it.
Added to Group – My teammate was added to the group with these updated permissions, so only he can access it.
In summary, here’s what’s happening on the backend:
The file is uploaded and initially generates a broadly accessible link.
Access to the link is immediately tightened by overriding the default inherited settings, ensuring that only my teammate can access the file.
Also worth noting - Microsoft automatically adds the “1” suffix because I’d previously sent a doc via Teams called test3.pdf.
Before I sent this message, Teams gave me the option to re-share the old file, but I declined. So, it uploaded this file with the “1” suffix to distinguish between the two versions.
Takeaway: There’s a big gap between what’s happening in the real world and what we see in the logs
A simple action like uploading a file in a Teams chat can generate an avalanche of telemetry. To complicate things more, the telemetry all shows up in the SharePoint log stream instead of the Teams log stream.
If an attacker had done this, it would be pretty tricky to conclude from these 7 SharePoint logs that they were actually sending a Teams message with an attachment.
Oftentimes, the gap between what’s happening in the real world and what we see on the backend is quite large.
Attackers view this as opportunity.
They know that most defending teams are not ingesting SharePoint and Teams data––let alone digging deep into the log events and tying them back to real behavior.
Bridging that gap between the logs and real-world behavior is incredibly important if we want to keep the bad guys out.
—
Don’t be a stranger. If you’re monitoring and defending Microsoft environments, reach out and come chat with us at RSA.