How they hijack Microsoft Teams via tokens (and what to do while everyone sips their coffee)

In short: an attacker does not smash your mailbox to bits, they nick your pass and stroll straight in. It is subtler, neater and a hundred times worse for defenders. If an attacker has a valid token, MFA and passwords become mere decorations. Below is a hard-technical breakdown with a healthy dose of irony. Pass it to your tech lead, SOC team and whoever still says “but we have MFA”.

What exactly they steal and where it lives

The Microsoft Teams desktop client uses an embedded browser engine, WebView2 based on Chromium. Tokens and session cookies live in that engine’s profile, in sqlite cookie files, IndexedDB and localStorage. To avoid storing secrets in plaintext, the client encrypts these artefacts using Windows DPAPI. Sounds brilliant, until an attacker gets local access and walks off with the DPAPI keys in their pocket.

Key paths and artefacts to watch — yes, the places you never wanted to look: the WebView2 / Teams profiles under %LOCALAPPDATA%, the Teams cookie sqlite files, and %APPDATA%\Microsoft\Protect<SID>\ where DPAPI master keys sit.

The attack funnel, step by step and without tears

1. Attacker obtains local access: phishing leads to RCE, malicious MSI, compromised RDP, or a post-exploit foothold.

2. Attacker reads cookie sqlite / MSAL cache in the WebView2 profile.

3. Attacker extracts DPAPI master keys, either from the Protect folder or by dumping LSASS. Tools like Mimikatz make this embarrassingly straightforward.

4. Attacker decrypts blobs, extracts access and refresh tokens or session cookies.

5. Attacker presents the token to the cloud and acts as the user: mail, Teams, SharePoint, Graph — the lot.

It sounds straightforward because it is. Local compromise first, cloud exploitation next.

Why MFA is largely irrelevant here

MFA protects the authentication event, not a valid token in flight. If someone stole a valid token, the attacker is already authenticated. MFA is bypassed by design in that scenario. Relying on MFA alone is a bit like locking the front gate while leaving the back door wide open.

Tools attackers use (so you can build detections)

• LSASS dumps and secret extraction tools, e.g. Mimikatz.

• DPAPI parsers and offline decryptors.

• sqlite dump scripts for WebView2/Teams cookie databases.

• Scripts to present tokens to Graph and Teams APIs.

If you see unusual Graph activity from odd sources or at odd hours, that’s a bad sign.

Indicators of compromise to monitor right now

• Abnormal read/write activity under %APPDATA%\Microsoft\Protect<SID>\ and WebView2 profile paths.

• LSASS dumps, CryptUnprotectData calls from unexpected processes.

• Processes reading Teams / WebView2 sqlite cookie DBs en masse.

• Sudden spike in Graph API calls for a user at night or from strange networks.

• Creation of mail forwarding rules, bulk downloads, mass exports from SharePoint or OneDrive.

What to do immediately — pragmatic, not panic-driven

1. If you suspect compromise, revoke the user’s sessions. That invalidates refresh tokens and forces reauthentication. Do it via the Graph revokeSignInSessions endpoint or admin portal.

2. Isolate and quarantine the compromised device.

3. Turn on file activity monitoring for Protect and WebView2 paths.

4. Deploy EDR rules to detect LSASS dumps, CryptUnprotectData calls and bulk sqlite reads.

5. Minimise local admin rights: use LAPS, JEA/JIT, and deny unnecessary local admin accounts.

6. Enable Continuous Access Evaluation and reduce refresh token lifetimes where possible.

7. For high-risk roles, disallow the desktop Teams client; force use of a managed browser.

How to automate response — practical playbook

Signal in SIEM triggers a Logic App or Runbook that calls Graph revokeSignInSessions for the user, disables device network access and opens a SOC ticket. Automate the token take-down faster than a human can finish a coffee.

Pseudo logic:

Long-term architectural controls (so you can sleep better)

• Bind tokens to devices and use platform secure enclaves or HSMs for secret storage.

• Reduce trust in desktop clients for critical accounts; managed browsers have more predictable cookie handling.

• Deploy Credential Guard and virtualization-based security to harden LSASS.

• Use Conditional Access, CAE and strict monitoring of Graph APIs.

• Review token lifetimes and enforce rotation policies.

IR checklist for an incident — concrete steps

1. Isolate device and collect EDR artefacts.

2. Change user password and call revokeSignInSessions.

3. Audit Graph, Exchange and SharePoint logs for unauthorised activity.

4. Analyse LSASS dumps and access to %APPDATA%\Microsoft\Protect.

5. Decide on reimaging the device and restore from a trusted backup.

6. Implement post-incident measures: reduce rights, rotate keys, train users.

A dash of sarcasm, since you asked for it

• MFA is wonderful, up until the moment an attacker has a valid token. Then MFA looks like a decorative lock on a letterbox you never closed.

• DPAPI is sold as a treasure chest, which it is — provided the attacker doesn’t also have the house keys. If admins have excess local rights, those keys are often within reach.

• Desktop Teams is handy, friendly and full of features. It is also a convenient place where token crumbs accumulate. Choose convenience or ironclad security — occasionally you can have both, usually you need a compromise.

What I can prepare for your team tomorrow

• A PowerShell / Logic App playbook that automatically revokes sessions and isolates devices on SIEM alerts.

• An IOC package for EDR/SIEM ingest, with specific paths, processes and sqlite patterns.

• A short technical memo for management covering risk, cost and priorities for mitigation.

If you think “we are a small business, who cares about Teams”, remember this: mail, documents and corporate chat are keys to the kingdom. Losing a token is someone quietly walking in and taking the telly while everyone assumed they were safe.