ThreatFox: Evilginx IOCs

Hunt Hypothesis

This hunt detects adversary behavior where attackers leverage Evilginx’s advanced phishing infrastructure to bypass multi-factor authentication and compromise user credentials through sophisticated session hijacking techniques. The SOC team should proactively hunt for these specific IOCs in Azure Sentinel because Evilginx attacks often evade traditional detection mechanisms, requiring immediate identification of compromised sessions to prevent lateral movement and data exfiltration before the adversary establishes persistence.

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(["195.242.119.86", "34.81.234.183"]);
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(["195.242.119.86", "34.81.234.183"]);
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

False Positive Scenarios for “ThreatFox: Evilginx IOCs” Rule

• Scheduled Phishing Simulation Campaigns

  • Scenario: The enterprise security team utilizes a platform like KnowBe4 or Proofpoint to run automated phishing simulations. These campaigns often inject simulated malicious URLs that mimic the structure of Evilginx domains (e.g., using similar TLDs or subdomain patterns) to test user responsiveness, triggering the IOC match.
  • Filter/Exclusion: Create a rule exclusion for traffic originating from the internal IP ranges of the security simulation platform’s gateway servers and whitelist specific campaign URLs known to be part of the current month’s training schedule.

• Third-Party MFA Provider Integration

  • Scenario: The organization uses an external Identity and Access Management (IAM) solution, such as Okta, Azure AD, or Duo Security. These providers frequently update their authentication endpoints or utilize subdomains that share structural similarities with Evilginx IOCs. When users authenticate via these services during peak hours, the detection logic may flag legitimate MFA redirects as suspicious.
  • Filter/Exclusion: Add a filter to exclude traffic destined for the official IP address blocks and domain suffixes of the specific IAM provider (e.g., *.okta.com, login.microsoftonline.com) when the source is an internal workstation performing standard authentication flows.

• Automated Cloud Backup and Sync Jobs

  • Scenario: Scheduled tasks running via tools like Veeam, Rubrik, or OneDrive for Business often establish connections to cloud storage endpoints that may share DNS patterns with the Evilginx threat landscape. During nightly backup windows, these agents generate high-volume traffic to specific cloud regions that could match the rule’s IOC signatures.
  • Filter/Exclusion: Implement a time-based exclusion