The ThreatFox: Mirai IOCs rule detects potential Mirai botnet activity by identifying network scans targeting known vulnerable IoT devices on common ports, which is a signature behavior of the malware’s initial compromise phase. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify and mitigate early-stage Mirai infections before they contribute to large-scale DDoS attacks.
IOC Summary
Malware Family: Mirai Total IOCs: 3 IOC Types: ip:port
| Type | Value | Threat Type | First Seen | Confidence |
|---|---|---|---|---|
| ip:port | 68[.]167[.]181[.]179:80 | payload_delivery | 2026-06-03 | 80% |
| ip:port | 170[.]9[.]16[.]186:80 | payload_delivery | 2026-06-03 | 80% |
| ip:port | 220[.]181[.]1[.]163:2375 | payload_delivery | 2026-06-03 | 80% |
// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Mirai
let malicious_ips = dynamic(["170.9.16.186", "68.167.181.179", "220.181.1.163"]);
CommonSecurityLog
| where DestinationIP in (malicious_ips) or SourceIP in (malicious_ips)
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort, DeviceAction, Activity
| order by TimeGenerated desc// Hunt in Defender for Endpoint network events
let malicious_ips = dynamic(["170.9.16.186", "68.167.181.179", "220.181.1.163"]);
DeviceNetworkEvents
| where RemoteIP in (malicious_ips)
| project Timestamp, DeviceName, RemoteIP, RemotePort, InitiatingProcessFileName, ActionType
| order by Timestamp desc| Sentinel Table | Notes |
|---|---|
CommonSecurityLog | Ensure this data connector is enabled |
DeviceNetworkEvents | Ensure this data connector is enabled |
Scenario: Scheduled System Updates via Puppet
Description: A Puppet agent runs a scheduled job to update firmware on IoT devices, which may include scanning for open ports as part of the update process.
Filter/Exclusion: Exclude IP addresses associated with internal Puppet master servers and any traffic originating from known internal update management systems.
Scenario: Network Discovery via Nmap
Description: A network administrator uses Nmap to perform a routine network scan to identify open ports and services on internal IoT devices for security assessment.
Filter/Exclusion: Exclude IP addresses associated with internal network scanning tools (e.g., Nmap) and traffic initiated from known security assessment tools.
Scenario: Telnet Configuration Audit via Telnet Client
Description: An admin uses a Telnet client to manually test Telnet connectivity to IoT devices to verify if Telnet is still enabled, as part of a security audit.
Filter/Exclusion: Exclude traffic from known admin workstations and any Telnet sessions initiated by users with elevated privileges (e.g., via SSH tunneling).
Scenario: IoT Device Firmware Upgrade via SSH
Description: A scheduled job uses SSH to push firmware updates to IoT devices, which may involve establishing SSH connections to devices on port 22.
Filter/Exclusion: Exclude IP addresses associated with internal CI/CD pipelines and traffic from known firmware update servers.
Scenario: Log Collection via Logstash
Description: Logstash is configured to collect logs from IoT devices, which may involve establishing connections to devices on port 23 or other ports for log retrieval.
Filter/Exclusion: Exclude IP addresses associated with internal log aggregation systems and traffic from known log collection tools (e.g., Logstash, Fluentd).