Agent Foskett Case File • Microsoft Teams • Defender XDR • Entra ID • KQL

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.”

Agent Foskett investigates a suspicious link delivered in Microsoft Teams
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.

✓ Preserve the original Teams message and URL
✓ Correlate click telemetry and identity sign-ins
✓ Separate observed evidence from assumptions

The message that looked perfectly ordinary

At 09:14 UTC, a project coordinator received a Teams message from a colleague with whom she had exchanged files for months. It read: “Can you check the revised supplier schedule before our call?” The link text resembled a SharePoint document, but the actual destination used an unrelated hostname.

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.
What looked trustworthyA genuine internal display name, an existing Teams chat and a plausible work request.
What did not fitThe destination URL was not the organisation’s SharePoint or OneDrive tenant.
What was not yet knownWhether the sender’s account was compromised, the recipient clicked, or credentials were entered.

Preserve the Teams evidence before changing anything

Capture the message timestamp, chat or channel context, sender identity, recipient, message text, full hyperlink target and any edits or deletions. Preserve screenshots as supporting context, but prefer the underlying message record and audit evidence when available.

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

The visible label said “Supplier schedule”. The hyperlink resolved to 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

The following queries run in Microsoft Defender XDR Advanced Hunting when the relevant Defender telemetry and tables are available. The first checks 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.
teams-suspicious-url-clicks.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 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 asc

Check whether an endpoint contacted the site

For a managed device onboarded to Microsoft Defender for Endpoint, 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.
teams-destination-network-events.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 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 asc

Was the colleague’s identity misused?

A message appearing under a colleague’s name does not by itself prove account takeover. Confirm the sender’s actual identity and message record, then examine their authentication history and relevant audit activity. In Microsoft Entra ID, review unfamiliar locations, device details, authentication methods, conditional access outcomes, session patterns and reported user activity.

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.
teams-sender-identity-signins.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 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 asc

Look for evidence of follow-on authentication

If the recipient opened the link, examine the relevant Entra sign-ins around the event and any MFA prompts or risky activity. Successful sign-in records do not automatically mean the suspicious URL captured credentials. Likewise, a blocked click does not establish that the sender’s account was safe.

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.
teams-recipient-signin-followup.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 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 asc

Build a defensible incident timeline

Keep the sequence of observations distinct from interpretation. The example below is illustrative and is not a record of a real customer incident.
09:14 UTC — Teams messageRecipient receives a document-themed message in an existing chat from a colleague’s account.
09:16 UTC — Suspicious URL identifiedRecipient checks the hyperlink target and reports the unexpected external host.
09:22 UTC — Evidence preservedAnalyst records message details, URL and chat context before remediation.
09:35 UTC — Telemetry reviewedDefender click and endpoint network evidence are checked for recipient activity.
09:48 UTC — Sender identity assessedEntra sign-ins and sender account activity are reviewed for unusual sessions.
10:15 UTC — Containment decisionTeam decides on targeted account/session, URL and endpoint actions based on verified findings.

The finding: familiar sender, unfamiliar destination

In this fictional case, the suspicious Teams message was confirmed and its URL did not belong to the expected collaboration service. The recipient reported it before submitting credentials. Available click and device telemetry showed no confirmed connection from the recipient’s managed device during the reviewed window, although telemetry limitations prevented an absolute claim that the link had never been opened.

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

Teach users to inspect the real destination of links even when messages appear in familiar Teams conversations. Maintain effective phishing reporting workflows for collaboration apps, not just email. Use appropriate Defender and Entra telemetry, conditional access controls, phishing-resistant authentication where feasible, and regular reviews of third-party application access.

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

“So the message really came from Sarah’s Teams account?” the analyst asked.

“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!

Agent Foskett’s conclusion

The message came from a familiar identity. That made it worth investigating — not automatically worth trusting. Verify the destination, reconstruct the timeline and let the evidence decide.
Develop IT.. Protect IT.. GEMXIT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT

The Certificate Was Valid — But Nobody Knew Who Was Using It

An illustrative Agent Foskett investigation into a Microsoft Entra ID workload identity using a valid certificate with no documented owner.

Microsoft Entra ID service principal investigation

Review certificate credentials, service principal sign-ins, directory audit logs, application permissions and downstream resource evidence.

Microsoft Sentinel KQL for workload identities

Example queries for AADServicePrincipalSignInLogs and AuditLogs when these tables are available through configured Entra diagnostic settings.