ThreatFox: Cobalt Strike IOCs

Hunt Hypothesis

This hunt hypothesis targets adversaries leveraging Cobalt Strike to establish persistent command-and-control channels for initial access and lateral movement across the network. Proactive hunting in Azure Sentinel is critical because detecting these specific IOCs early allows the SOC team to disrupt post-exploitation activities before attackers can deepen their foothold or exfiltrate sensitive data.

IOC Summary

Malware Family: Cobalt Strike Total IOCs: 6 IOC Types: ip:port

Type	Value	Threat Type	First Seen	Confidence
ip:port	`45[.]87[.]53[.]6:8881`	botnet_cc	2026-07-31	100%
ip:port	`45[.]87[.]53[.]6:8887`	botnet_cc	2026-07-31	100%
ip:port	`45[.]87[.]53[.]6:8884`	botnet_cc	2026-07-31	100%
ip:port	`45[.]87[.]53[.]6:8886`	botnet_cc	2026-07-31	100%
ip:port	`81[.]70[.]21[.]248:22`	botnet_cc	2026-07-31	100%
ip:port	`103[.]41[.]19[.]111:8080`	botnet_cc	2026-07-31	100%

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Cobalt Strike
let malicious_ips = dynamic(["45.87.53.6", "103.41.19.111", "81.70.21.248"]);
CommonSecurityLog
| where DestinationIP in (malicious_ips) or SourceIP in (malicious_ips)
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort, DeviceAction, Activity
| order by TimeGenerated desc

KQL: Ip Hunt Device

// Hunt in Defender for Endpoint network events
let malicious_ips = dynamic(["45.87.53.6", "103.41.19.111", "81.70.21.248"]);
DeviceNetworkEvents
| where RemoteIP in (malicious_ips)
| project Timestamp, DeviceName, RemoteIP, RemotePort, InitiatingProcessFileName, ActionType
| order by Timestamp desc

Required Data Sources

Sentinel Table	Notes
`CommonSecurityLog`	Ensure this data connector is enabled
`DeviceNetworkEvents`	Ensure this data connector is enabled

References

ThreatFox — Cobalt Strike

False Positive Guidance

Here are 4 specific false positive scenarios for the ThreatFox: Cobalt Strike IOCs rule, including suggested filters or exclusions tailored for an enterprise environment:

Scenario: Internal Penetration Testing & Red Team Exercises
- Context: Security teams frequently deploy Cobalt Strike beacons during scheduled vulnerability assessments or Red Team engagements to simulate attacker behavior. These legitimate activities generate the exact same network signatures (e.g., specific HTTP User-Agents, beacon callbacks) that the rule is designed to detect as malicious.
- Suggested Filter/Exclusion: Create a whitelist based on Source IP ranges assigned to the internal Security Operations Center (SOC) or dedicated Red Team jump hosts. Additionally, exclude traffic occurring during specific maintenance windows defined in the calendar (e.g., TimeOfDay between 08:00–18:00 on Tuesdays/Thursdays).
Scenario: Scheduled Backup and Monitoring Agents
- Context: Enterprise backup solutions (such as Veeam, Rubrik, or Commvault) often utilize custom HTTP headers or specific connection patterns that mimic Cobalt Strike’s beacon communication. Similarly, endpoint monitoring tools like Datadog or SolarWinds may poll agents using similar intervals and payload structures.
- Suggested Filter/Exclusion: Implement an exclusion based on Process Name and Parent Process. If the detected activity originates from known backup services (e.g., vbrsvc.exe, rubrik-agent.exe) or monitoring daemons, suppress the alert. Alternatively, filter out traffic where the destination port is a known management port used by these specific tools rather than the standard Cobalt Strike beacon ports.
Scenario: Automated Deployment and Configuration Management
- Context: DevOps teams utilize automation platforms like Ansible, Puppet,