Score:2

Microsoft Teams filling Security Log with seProfileSingleProcessPrivilege

mx flag

Recently, we started seeing a phenomenon where any machine running Microsoft Teams (office 365 E3 version) will emit event 4673 at a high rate, indicating a failed attempt to use the seProfileSingleProcessPrivilege. Counting one random second's worth of these entries, I saw 120. The volume of these audit failures is causing the security log to fill and overwrite so quickly that no valuable information can be retained.

By policy, we audit both success and failure on privilege use, so turning off audit is not an option. Granting the privilege to all users seems like a poor security practice as well.

I do not see chatter about this issue, so I am wondering if we are alone with this symptom.

I can't explain why Teams would be attempting to grant this privilege to itself.

We can't find any indications of compromise and have installed teams on a fresh laptop and see this symptom.

I would love to hear any ideas on how to convince Teams to stop this behavior.

joeqwerty avatar
cv flag
Open a support case in your Office 365 tenant. It's free. They'll help you figure this out.
Score:1
mx flag

We opened a case with Microsoft Support. They dug a bit and found that Teams is written on top of Chromium. Chromium is calling QueryWorkingSetEx. It is unclear why this is interesting, but QueryWorkingSetEx requires seProfileSingleProcessPrivilege. It is unclear if QueryWorkingSetEx just fails or if it does something interesting even if it can't enable the privilege. Microsoft is still reviewing at this time.

Update 1/19/2023 - Microsoft closed the case on this with no action. They could update Chromium so that this behavior is mitigated. They chose not to. They adamantly don't care about this issue and their official recommendation was to stop logging the error.

LeeM avatar
cn flag
I love it how they're blaming "Chromium", when it's their own code ("WebView2") running on top of their *highly modified* version that the Edge browser runs on. They might as well stop claiming Edge is a separate browser if it's so impossible to fix. https://office365itpros.com/2021/06/25/teams-2-webview2-replaces-electron/ Also, unfortunately, there are a lot of "false positive" audit errors of this kind in products going back many years (not just Edge-based) that MSFT doesn't bother fixing.
Score:0
in flag

I don't think there is anything you can do on your end, other than temporarily stop auditing privilege use (which IMHO is largely useless anyways since it just creates noise) and possibly increase the log of the security event log.

Since this privilege is used for performance monitoring and you only just recently discovered it, it seems that this was added in a recent Teams update. It sounds like a bug in the software where maybe a developer was profiling something and they forgot to take it out.

Would be interesting to see if older versions of Teams do the same thing, if you have some computers with an older version.

LeeM avatar
cn flag
Probably not that error, but the whole point of their migrating away from the old Electron version was supposedly because "WebView2" on Edge isn't such a memory hog (the Electron version is horrible at gobbling RAM). I wouldn't be surprised if that profiling "error" is actually used as a prompt for it to stop or garbage-collect some threads.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.