ThreatFox: Evilginx IOCs

Hunt Hypothesis

This detection identifies adversary activity involving known Evilginx indicators of compromise that facilitate advanced phishing attacks capable of bypassing multi-factor authentication through session token theft. SOC teams should proactively hunt for these IOCs within Azure Sentinel to rapidly identify and contain potential credential compromises before attackers can establish persistent access or exfiltrate sensitive data.

IOC Summary

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

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Evilginx
let malicious_ips = dynamic(["49.235.153.53", "69.164.245.180"]);
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(["49.235.153.53", "69.164.245.180"]);
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

Here are specific false positive scenarios and corresponding exclusions for the ThreatFox: Evilginx IOCs detection rule in an enterprise environment:

• Scenario: Legitimate Cloud Identity Provider Connections

  • Context: Enterprise environments often utilize cloud-based identity providers (e.g., Okta, Azure AD, Ping Identity) that host phishing-resistant login portals. The Evilginx IOCs may overlap with the IP ranges or domain hashes of these trusted providers when users access them via corporate browsers.
  • Suggested Filter/Exclusion: Create a whitelist exclusion for traffic originating from internal subnets (e.g., 10.x.x.x, 192.168.x.x) connecting to known Identity Provider domains (*.okta.com, login.microsoftonline.com). Additionally, exclude specific SHA-256 hashes of the legitimate provider’s login pages if they match the Evilginx signature.

• Scenario: Scheduled Security Scans and Phishing Simulations

  • Context: Automated security tools like Tenable Nessus, Qualys, or internal phishing simulation platforms (e.g., KnowBe4) frequently deploy mock login pages that mimic real-world authentication flows. These simulations often generate network traffic patterns identical to Evilginx attacks, triggering the rule during scheduled campaign windows.
  • Suggested Filter/Exclusion: Implement a time-based exclusion or tag-based filter for alerts generated by specific service accounts (e.g., svc-qualys-scan, svc-knowbe4-phish). Configure the detection logic to suppress alerts if the source process is identified as a known security scanner executable (e.g., nessus.exe, phishing_sim_agent.exe) during business hours.

• Scenario: Admin Tasks Involving External SSO Integrations

  • Context: System administrators frequently perform maintenance on Single