Suspicious IP address outbound to our Team workload

Admin-Patrick 0 Reputation points
2026-10-13T09:38:18.33+00:00

I get a suspicious IP address on my Teams workloads when I run a KQL query in Sentinel. No one in ICT knows the IP address. How can I investigate this issue further?

In the interim, we have blocked the IP address on the Firewall.

Microsoft Security | Microsoft Sentinel
0 comments No comments

1 answer

Sort by: Most helpful
  1. AI answer

    2026-10-13T09:39:16.9866667+00:00

    Keep the temporary firewall block as containment while correlating the IP to the originating device, user, process, and destination service; remove or narrow it only after confirming whether the address belongs to a required Microsoft 365 endpoint.

    1. Establish exactly what the event represents

    In Microsoft Sentinel → Logs, inspect the original result and record:

    • Time range and time zone
    • Source and destination IPs
    • Source device
    • Destination port and protocol
    • Action (Allowed, Blocked, or equivalent)
    • User, URL/FQDN, bytes transferred, and originating data table

    Do not assume that an IP shown in a “Teams” query is owned by Teams. For CEF firewall data, SourceIP identifies the source and DestinationIP the destination; DestinationPort, DestinationHostName, and DestinationProcessName can provide additional context.^1^

    For CommonSecurityLog, pivot on the suspicious destination:

    let SuspiciousIP = "[IP Address]";
    CommonSecurityLog
    | where TimeGenerated > ago(14d)
    | where DestinationIP == SuspiciousIP or SourceIP == SuspiciousIP
    | project TimeGenerated, DeviceName, SourceIP, DestinationIP,
              DestinationPort, Protocol, DeviceAction,
              DestinationHostName, SourceUserName,
              SentBytes, ReceivedBytes
    | order by TimeGenerated desc
    

    Replace the example address. Determine whether one endpoint or many contacted it, whether connections were successful, and whether the traffic is periodic or high-volume.

    2. Pivot through the IP entity

    In the Microsoft Defender portal, open the IP address as an entity:

    1. Review Overview for ASN, organization, geography, first/last seen, and prevalence.
    2. Review Observed in organization for devices that communicated with it.
    3. Review Incidents and alerts for related detections.
    4. Review Threat Intelligence Insights for reputation and infrastructure relationships.
    5. If Sentinel is onboarded, inspect Sentinel events for its timeline, anomalies, bookmarks, and network insights.
    6. Select Go hunt or Investigate in Activity log to pivot into the underlying records.

    The IP entity page is specifically intended to identify devices communicating with an external IP and expose related incidents, reputation, network activity, DNS, WHOIS, certificates, and services.^2^

    If this IP appears in a Sentinel incident and the analytics rule mapped it as an entity, select Incidents → incident → Investigate, expand the IP, account, and host nodes, and run the available exploration queries. The investigation graph requires entity mapping and supports incidents up to 30 days old.^3^

    3. Identify the endpoint process

    If the affected devices are onboarded to Microsoft Defender for Endpoint, run this separately in Defender → Hunting → Advanced hunting:

    let SuspiciousIP = "[IP Address]";
    DeviceNetworkEvents
    | where Timestamp > ago(14d)
    | where RemoteIP == SuspiciousIP
    | project Timestamp, DeviceName, RemoteIP, RemotePort, RemoteUrl,
              ActionType, Protocol, InitiatingProcessFileName,
              InitiatingProcessCommandLine, InitiatingProcessAccountUpn,
              InitiatingProcessSHA256
    | order by Timestamp desc
    

    DeviceNetworkEvents contains the remote IP/URL, device, port, and initiating-process identity. It only returns data when Defender for Endpoint is deployed.^4^

    Investigate immediately if the process is unexpected, unsigned, launched from a user-writable directory, or contacting the IP independently of a Teams session. Also pivot on its hash, command line, parent process, and other contacted destinations.

    4. Validate whether it is Microsoft 365 traffic

    Check the current Microsoft 365 endpoint data rather than relying only on WHOIS or an employee recognizing the address. The endpoint web service returns the current Microsoft 365 IP ranges, URLs, ports, service area, category, and whether connectivity is required.^5^

    • Select the correct cloud instance: Worldwide, China, USGovDoD, or USGovGCCHigh.
    • Check whether the IP falls inside a published CIDR range, not merely whether it appears as an exact string.
    • For Teams, inspect the Skype service area together with Common, which is automatically included as a prerequisite.
    • Correlate the range with the observed destination port and FQDN.

    If it is a required Microsoft endpoint and the device/process/FQDN evidence is consistent with legitimate Teams use, replace the single-IP block with rules based on the published Microsoft 365 endpoint data. If it is not published, that alone does not prove compromise—continue with the endpoint and identity evidence.

    5. Check Teams and identity activity around the same time

    Use OfficeActivity and SigninLogs to examine the implicated account and time window for:

    • Teams sign-ins from the suspicious IP
    • Failed and successful sign-ins from different IPs
    • Newly added external users
    • Users added and quickly removed
    • New Teams bots or applications
    • Unexpected owner-role changes or bulk team deletions

    Microsoft’s Teams Sentinel guidance documents these hunting patterns and recommends correlating Teams activity with Entra sign-in data.^6^

    6. Respond based on the result

    • Confirmed Microsoft service traffic: narrow or remove the temporary block and monitor for recurrence.
    • Unknown but no malicious evidence: retain a time-limited block if business impact is acceptable, document the evidence, and monitor devices/users that previously connected.
    • Suspicious process, sign-in, or data transfer: isolate the affected endpoint, revoke the user’s active sessions, investigate the process and downloaded files, reset credentials if account compromise is established, and hunt for the IP/hash across the environment.
    • Confirmed malicious IP: from the incident’s Entities pane, select the IP’s menu → Add to TI, enter classification/validity details, and use the indicator in Sentinel analytics.^7^

    References

    1. CEF and CommonSecurityLog field mapping
    2. IP address entity page in Microsoft Defender
    3. Investigate incidents with Microsoft Sentinel (legacy)
    4. DeviceNetworkEvents
    5. Microsoft 365 IP Address and URL web service
    6. Microsoft Sentinel and Microsoft Teams
    7. Add entities to threat intelligence in Microsoft Sentinel
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.