ThreatFox: Evilginx IOCs

Hunt Hypothesis

This hunt targets known indicators of compromise associated with Evilginx, a phishing-as-a-service tool frequently used by adversaries to intercept multi-factor authentication tokens and gain persistent access to user sessions. Proactively hunting for these IOCs in Azure Sentinel allows the SOC team to identify compromised endpoints or network connections before attackers can leverage stolen credentials to escalate privileges or move laterally within the environment.

IOC Summary

Malware Family: Evilginx Total IOCs: 3 IOC Types: ip:port

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Evilginx
let malicious_ips = dynamic(["209.74.86.250", "185.212.128.32", "157.230.7.115"]);
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(["209.74.86.250", "185.212.128.32", "157.230.7.115"]);
DeviceNetworkEvents
| where RemoteIP in (malicious_ips)
| project Timestamp, DeviceName, RemoteIP, RemotePort, InitiatingProcessFileName, ActionType
| order by Timestamp desc

Required Data Sources

References

• ThreatFox — Evilginx

False Positive Guidance

• Scenario: A security operations engineer manually tests the Evilginx phishing kit in an isolated lab environment or a dedicated “red team” subnet to validate detection coverage before a major campaign. The test generates the specific IOCs (e.g., unique certificate hashes, known malicious IP ranges, or specific User-Agent strings) that the rule is designed to catch.

  • Filter/Exclusion: Exclude hosts located in the Lab-Phishing-Validation VLAN or those with the hostname prefix sec-test- from the rule evaluation. Alternatively, create a maintenance window exclusion during scheduled security testing hours.

• Scenario: A DevOps team deploys a new reverse proxy configuration for a high-traffic web application that inadvertently uses a port or certificate chain matching one of the three IOCs (e.g., a shared intermediate CA certificate or a specific non-standard port like 8443 used for internal health checks). The rule triggers because the production server’s fingerprint matches the IOC signature.

  • Filter/Exclusion: Add an exclusion for the specific source_ip of the application load balancer if the IOC is IP-based, or exclude the specific certificate_hash if the IOC is certificate-based, after verifying the certificate is signed by the internal enterprise CA.

• Scenario: An automated vulnerability scanner (e.g., Nessus or Qualys) performs a full-spectrum scan that includes active probing of known Evilginx infrastructure to identify if any internal assets are still connected to or communicating with the phishing kit. The scanner’s active probing generates traffic patterns or connection logs that match the IOC criteria.

  • Filter/Exclusion: Exclude the source_ip of the vulnerability scanner appliances (e.g., 10.20.30.100 - 10.20.30.102) or filter out events where the process_name