Notifications
Clear all
Topic starter
27/06/2026 1:46 pm
TL;DR: Microsoft Teams messages can carry malicious files and links through compromised vendor accounts and external tenants, while native scanning may occur up to 48 hours after delivery, creating a dwell-time window for users to click, according to Abnormal AI. The governance gap is not collaboration itself, but the trust model that assumes internal context is safer than it actually is.
NHIMG editorial — based on content published by Abnormal AI: Microsoft Teams Security Risk, malicious files and phishing in chat
By the numbers:
- Native Microsoft Teams tools may scan attachments up to 48 hours after delivery, leaving a window for users to click malicious content.
Questions worth separating out
Q: What breaks when Teams messages are only scanned after delivery?
A: A delayed scan leaves a window in which users can open malicious files or links before enforcement happens.
Q: Why do collaboration platforms complicate phishing defence?
A: Collaboration platforms blend internal staff, vendors, and guests into one trusted-looking interface, which makes malicious requests look routine.
Q: How do security teams know whether Teams remediation is working?
A: They should measure dwell time, removal latency, and the percentage of malicious messages removed before any user interaction.
Practitioner guidance
- Treat collaboration threads as governed trust surfaces Classify Teams and Slack as message delivery channels that require the same inspection standard as email, especially where vendors and guests can post files or links into active threads.
- Measure collaboration dwell time Track the interval between malicious message delivery, detection, and removal so you can see how long a dangerous file or URL stays visible to users.
- Automate message removal and tombstoning Use policy-driven remediation that removes malicious content inside the collaboration workflow while preserving a security notice and audit trail.
What's in the full article
Abnormal AI's full research covers the operational detail this post intentionally leaves for the source:
- Inline analysis workflow for malicious files and URLs shared inside Teams threads
- Policy-driven auto-remediation and tombstoning behaviour for removed messages
- Threat Log output and analyst workflow details for unified email and collaboration triage
- Borderline-message override logic and audit-trail handling for time-sensitive collaboration
👉 Read Abnormal AI's analysis of Microsoft Teams phishing and malicious file delivery →
Teams phishing risk: what IAM and security teams need to do?
Explore further
27/06/2026 3:13 pm
Teams phishing is a collaboration trust problem before it is a malware problem. The platform merges employees, vendors, contractors, and guests into one conversational space, so legitimacy cues are built into the interface itself. That makes the attack look operationally normal even when the payload is hostile. Security teams should stop treating collaboration as a low-risk channel and start treating it as a governed trust boundary.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who is accountable when a malicious message arrives through a vendor account?
A: Accountability spans collaboration security, third-party access governance, and identity lifecycle management. The team that owns external access, the team that monitors the channel, and the team that approves vendor connectivity all have a role. Shared responsibility only works when ownership is explicit and reviewed.
👉 Read our full editorial: Microsoft Teams phishing risk exposes the collaboration trust gap
