The Teams Message Came From a Colleague — But the Link Didn’t Belong There
It appeared in a normal Teams conversation. The sender was a real colleague. The language sounded familiar. Even the timing made sense.
But the link was pointing somewhere it should not.
“Agent Foskett, it came from Sarah’s account.”
“Does Sarah remember sending it?”
“She says she was in a meeting.”
“Splendid,” Agent Foskett replied. “The attacker has better calendar management than the rest of us.”

Case file: A trusted identity is not a trusted link
A fictional, evidence-led investigation of a suspicious Teams message, its destination, possible account misuse, click activity and follow-on authentication.
The message that looked perfectly ordinary
The recipient noticed the mismatch before entering any credentials and contacted the security team. The incident is fictional, but the investigation steps reflect practical Microsoft 365 workflows. All example timestamps and domains are illustrative.
Preserve the Teams evidence before changing anything
Depending on licensing, permissions and product capabilities, Teams messages can be investigated through Microsoft Purview eDiscovery and relevant Defender portal experiences. Do not assume that every Teams message is present in
EmailEvents or that Teams chat content is available as a general-purpose Advanced Hunting table. Document where each artefact was obtained.Start with the destination — not the display text
https://files-review.example/verify, a fictional demonstration domain. The analyst recorded the original URL, redirect chain, destination host and any observed landing-page behaviour in an isolated analysis environment.URL reputation is useful context, not a verdict. A newly registered or unfamiliar domain can be benign; a familiar domain can be abused. Correlate what the user actually opened with endpoint, network and identity evidence.
Hunt for clicks and URL activity in Defender XDR
UrlClickEvents for clicks involving the suspect domain. Coverage varies by product, licensing and the protection pathway; absence of a result does not prove that nobody clicked a Teams link.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
// Microsoft Defender XDR Advanced Hunting — UrlClickEvents, where available
let SuspiciousHost = "files-review.example";
UrlClickEvents
| where Timestamp > ago(7d)
| where Url has SuspiciousHost
| project Timestamp, AccountUpn, Url, ActionType,
ThreatTypes, DetectionMethods, Workload
| order by Timestamp ascCheck whether an endpoint contacted the site
DeviceNetworkEvents can provide additional evidence of outbound connections. This does not identify which Teams message caused the connection, and NAT, browsers, redirects or missing telemetry may complicate attribution. Pivot on the device, user, process and exact time window.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
// Microsoft Defender XDR Advanced Hunting — Defender for Endpoint data
let SuspiciousHost = "files-review.example";
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has SuspiciousHost
| project Timestamp, DeviceName, InitiatingProcessAccountUpn,
InitiatingProcessFileName, RemoteUrl, RemoteIP,
RemotePort, ActionType
| order by Timestamp ascWas the colleague’s identity misused?
Compare those findings with the sender’s recollection and normal workflow. A suspicious sign-in might explain an attacker-controlled session; alternatively, the message could have been sent by an authorised integration, a compromised device or even the colleague herself. Keep those hypotheses separate until evidence supports one.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
// Microsoft Sentinel / Log Analytics — requires Entra SigninLogs ingestion
let SenderUpn = "sarah@example.com";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ SenderUpn
| project TimeGenerated, UserPrincipalName, AppDisplayName,
IPAddress, Location, ResultType,
ConditionalAccessStatus, CorrelationId
| order by TimeGenerated ascLook for evidence of follow-on authentication
Investigate the recipient’s actual activity, including any authentication attempts that occurred after the click. Correlate timestamps and device context, and confirm whether the suspicious site attempted to imitate Microsoft sign-in pages.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
// Microsoft Sentinel / Log Analytics — requires Entra SigninLogs ingestion
let RecipientUpn = "alex@example.com";
let IncidentUtc = datetime(2026-10-20T09:14:00Z);
SigninLogs
| where TimeGenerated between (IncidentUtc - 30m .. IncidentUtc + 3h)
| where UserPrincipalName =~ RecipientUpn
| project TimeGenerated, UserPrincipalName, AppDisplayName,
IPAddress, ResultType, ConditionalAccessStatus,
CorrelationId
| order by TimeGenerated ascBuild a defensible incident timeline
The finding: familiar sender, unfamiliar destination
The sender’s sign-in review raised an anomalous session requiring further validation. The investigation therefore treated possible sender-account misuse as a working hypothesis, not a proven conclusion. Security staff preserved evidence, reviewed active sessions, checked app consent and sign-in activity, and coordinated credential/session remediation where justified.
Practical defensive lessons
For suspected account compromise, preserve evidence before revoking sessions or resetting credentials where operationally safe. Scope affected conversations and recipients, and communicate clearly that a genuine account can still be used to deliver a malicious link.
Final thought
“That is what the evidence shows,” Agent Foskett replied.
“Then we can trust it?”
Agent Foskett stared at the destination URL.
“We can trust that the message exists. The link will have to earn its own reputation.”
The Logs Already Knew!

