ThreatFox: Evilginx IOCs

Hunt Hypothesis

This hunt detects adversary behavior involving Evilginx phishing campaigns that utilize advanced session hijacking to bypass multi-factor authentication and steal user credentials. A SOC team should proactively hunt for these specific IOCs in Azure Sentinel to identify compromised accounts early, as Evilginx’s ability to mimic legitimate login flows often evades standard real-time detections.

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(["87.199.203.248", "77.246.111.132"]);
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(["87.199.203.248", "77.246.111.132"]);
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 mitigation strategies for the ThreatFox: Evilginx IOCs detection rule in an enterprise environment:

• Corporate Phishing Simulation Campaigns

  • Scenario: Security teams utilize platforms like KnowBe4, Proofpoint, or GoPhish to conduct internal phishing simulations. These tools often host simulated login pages that mimic the structure of popular SaaS applications (e.g., Office 365, Google Workspace) and may share IP ranges or certificate patterns with known Evilginx infrastructure, triggering a match on the detection logic.
  • Filter/Exclusion: Create an exclusion rule to whitelist traffic originating from internal simulation subnets or specific hostnames (e.g., *.knowbe4.net, *.proofpoint.com) during scheduled campaign windows (typically 09:00–17:00 on weekdays).

• Automated SaaS Provisioning and Identity Sync Jobs

  • Scenario: Scheduled tasks running via Microsoft Azure AD Connect, Okta Workforce Automation, or ServiceNow often perform background synchronization of user identities. These jobs frequently initiate outbound connections to cloud identity endpoints that utilize similar TLS fingerprints or redirect chains as Evilginx proxies, causing the rule to flag legitimate provisioning traffic as suspicious.
  • Filter/Exclusion: Implement a filter based on process names (e.g., AzureADConnect.exe, okta-agent) and exclude traffic where the source user context is identified as a “Service Account” or “System” rather than an interactive human user.

• Third-Party Security Scanning Appliances

  • Scenario: Enterprise network security tools such as Tenable Nessus, Qualys, or CrowdStrike Falcon Discover perform continuous vulnerability scanning and asset discovery. These agents often probe external endpoints and may connect to shared CDN