ThreatFox: XMRIG IOCs | SOC Hunt Feed

Hunt Hypothesis

This rule detects the presence of known XMRIG indicators, which are frequently used by adversaries to deploy cryptocurrency miners for resource exhaustion and financial gain. Proactively hunting for these IOCs in Azure Sentinel allows the SOC to identify compromised assets before the miners consume excessive compute resources or establish persistence mechanisms.

IOC Summary

Malware Family: XMRIG Total IOCs: 8 IOC Types: ip:port

Type	Value	Threat Type	First Seen	Confidence
ip:port	`194[.]116[.]236[.]129:53`	botnet_cc	2026-09-12	100%
ip:port	`156[.]229[.]165[.]166:53`	botnet_cc	2026-09-12	100%
ip:port	`107[.]175[.]114[.]96:443`	botnet_cc	2026-09-12	100%
ip:port	`216[.]9[.]226[.]82:443`	botnet_cc	2026-09-12	100%
ip:port	`194[.]116[.]236[.]129:443`	botnet_cc	2026-09-12	100%
ip:port	`156[.]229[.]165[.]166:443`	botnet_cc	2026-09-12	100%
ip:port	`107[.]175[.]114[.]96:53`	botnet_cc	2026-09-12	100%
ip:port	`216[.]9[.]226[.]82:53`	botnet_cc	2026-09-12	100%

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - XMRIG
let malicious_ips = dynamic(["156.229.165.166", "194.116.236.129", "216.9.226.82", "107.175.114.96"]);
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(["156.229.165.166", "194.116.236.129", "216.9.226.82", "107.175.114.96"]);
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 — XMRIG

False Positive Guidance

Legitimate CPU Stress Testing by DevOps/Performance Engineering: Engineers often use XMRIG as a lightweight, cross-platform tool to generate consistent CPU load for benchmarking new application servers or validating thermal throttling behavior in CI/CD pipelines.
- Filter/Exclusion: Exclude processes running from specific CI/CD agent directories (e.g., C:\Jenkins\workspace\, C:\AzureDevOps\) or command lines containing arguments like --cpu-test or --benchmark rather than mining pool addresses.
Internal Performance Benchmarking by QA Teams: Quality Assurance engineers may deploy XMRIG on staging environments to simulate high-load conditions for database or API stress tests, especially when standard tools like sysbench are unavailable or need specific thread affinity control.
- Filter/Exclusion: Correlate with user context; exclude executions initiated by service accounts named qa-service, perf-test, or benchmark-agent, or restrict detection to non-production network segments (e.g., VLAN 10-20).
Scheduled Resource Contention Tests by Infrastructure Teams: Infrastructure engineers schedule periodic jobs to verify that monitoring agents (e.g., Datadog, New Relic) correctly capture CPU saturation metrics during peak load windows, using XMRIG as a predictable, controllable load generator.
- Filter/Exclusion: Exclude processes spawned by scheduled task runners (e.g., schtasks.exe, cron, systemd-timer) where the parent process is a known task scheduler and the execution window aligns with the documented maintenance window (e.g., 02:00-04:00 UTC).
Legacy Application Compatibility Validation: Some legacy Java or .NET applications rely on specific CPU instruction set utilization; engineers may use XMRIG to verify that virtualization layers (e.g., VMware, Hyper-V)