SOP-34: Outbound Threat-Intelligence Matched Connection

Not all TI indicators have equal confidence. Check the ThreatIntelligenceIndicator.ConfidenceScore field — scores below 50 have a higher false positive rate and warrant extra verification before isolating an endpoint. MSTIC-attributed APT indicators (confidence 80+) are near-certain and justify immediate containment.

The ThreatIntelligenceIndicator table in Sentinel stores all IOCs from connected TI feeds. When joined against DeviceNetworkEvents or DnsEvents, it surfaces every host that contacted a known-bad IP or resolved a known-bad domain. The first check is the indicator's ConfidenceScore and ThreatType fields — a ConfidenceScore of 80+ from MSTIC or abuse.ch with ThreatType "C2" or "Botnet" requires no further validation; the match itself is your evidence. Separately check ExpirationDateTime — expired indicators (stale IOCs) have a much higher false positive rate as infrastructure gets repurposed.

• 1In Threat Intelligence, search for the matched IP or domain. Review: Confidence Score, Threat Type (C2, Botnet, Phishing, Malware), Source (MSTIC, abuse.ch, OTX), and Tags (e.g. "Cobalt Strike", "Qakbot", "LockBit C2"). This context determines your response urgency.
• 2Run the TI join KQL query below. Set the time range to Last 24 hours — also check if this IOC had earlier hits in the past 7 days that may have been missed (indicators often sit unmatched for days before escalating).
• 3For each matching host, note InitiatingProcessFileName and InitiatingProcessCommandLine in DeviceNetworkEvents. A legitimate process (chrome.exe, Teams.exe) connecting to a C2 IP indicates browser/app compromise or proxy injection. A suspicious process (svchost.exe with unusual parent, rundll32.exe, a randomly-named binary) confirms active implant.
• 4Check total bytes transferred (SentBytes + ReceivedBytes in DeviceNetworkEvents) — high received bytes indicate payload download; high sent bytes indicate exfiltration. Report the byte count to the data owner for breach notification assessment.
• 5Search the same IOC across ALL devices in your fleet — a shared C2 IP hit across multiple hosts indicates a coordinated deployment (mass phishing campaign, supply chain compromise, lateral movement from patient zero).

After confirming the IOC match, the second investigation layer is the communication pattern from the matched host. A legitimate one-off DNS resolution of a malicious domain (from clicking a phishing link that didn't load) has a very different risk profile from a persistent beacon: regular connections to the same C2 IP every 60 seconds with consistent byte counts. Beacon analysis reveals dwell time (how long the implant has been active), communication protocol (HTTP POST = command execution results; HTTPS = encrypted C2 channel), and urgency of containment (active C2 session vs dormant implant vs completed payload delivery).

• 1Run the beacon pattern query for the matched IOC IP. Look at the time interval between successive connections from the same host — a standard deviation of <30 seconds in connection intervals is a strong beaconing signature. Cobalt Strike default jitter is 30%, so intervals vary but cluster around a base (60s, 300s, 600s are common defaults).
• 2Check InitiatingProcessFileName for the beacon — known malware parent processes: rundll32.exe, regsvr32.exe, mshta.exe, wscript.exe, cscript.exe, unusual svchost.exe (check its exact commandline — should be svchost.exe -k netsvcs etc., not arbitrary args), and 0-character/random-name binaries in TEMP.
• 3Pivot to DeviceProcessEvents to build the full process tree: what launched the beaconing process, and what did the beaconing process launch. This reconstructs the attack chain from initial access through to current implant activity.
• 4Review SentBytes and ReceivedBytes totals over the beacon history. High ReceivedBytes on initial beacon connections = payload staging. High SentBytes later = active exfiltration. Low symmetric byte counts = heartbeat-only (minimal risk; implant waiting for commands).