ThreatFox: Evilginx IOCs

Hunt Hypothesis

This detection rule identifies adversary behavior where Evilginx utilizes man-in-the-middle attacks to impersonate legitimate login pages and steal user credentials through compromised websites or malicious email redirects. A SOC team should proactively hunt for these indicators in Azure Sentinel because Evilginx’s sophisticated session hijacking capabilities allow attackers to bypass traditional multi-factor authentication, necessitating early detection of its specific IOCs to prevent unauthorized access.

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(["45.61.177.23", "45.154.98.207"]);
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(["45.61.177.23", "45.154.98.207"]);
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 5 specific false positive scenarios for the ThreatFox: Evilginx IOCs detection rule, tailored to an enterprise environment with suggested filters and exclusions:

• Scenario: Internal MFA Proxy Redirections

  • Context: Enterprise environments often use internal Single Sign-On (SSO) proxies (e.g., Okta, Azure AD B2C, or Ping Identity) that redirect users through multiple subdomains before presenting the final login page. Evilginx relies heavily on analyzing URL structure and redirection chains; legitimate SSO flows can mimic the “redirect-to-login” pattern of an Evilginx attack.
  • Filter/Exclusion: Exclude traffic where the destination IP belongs to the internal corporate subnet or specific cloud provider CIDR ranges (e.g., 10.0.0.0/8 for on-prem, 20.0.0.0/16 for Azure AD). Additionally, add a filter to ignore redirections where the final destination domain matches the organization’s primary SSO FQDN (e.g., *.company-sso.com).

• Scenario: Scheduled Security Awareness Phishing Simulations

  • Context: Security teams frequently run automated phishing campaigns using tools like KnowBe4, Proofpoint Security Awareness, or SafeGuard. These simulations often deploy custom landing pages that mimic the look and feel of corporate login portals to train users, triggering the “legitimate impersonation” logic of the Evilginx rule.
  • Filter/Exclusion: Create an exclusion list for known simulation source IPs and domains (e.g., *.knowbe4.com, *.proofpoint.com). Implement a time-based filter to suppress alerts during scheduled campaign windows (e.g., “Exclude if event occurs between 09:00–17:00 on weekdays when the ‘Phishing Sim’ tag is