ThreatFox: Evilginx IOCs

Hunt Hypothesis

This detection rule identifies adversary activity leveraging Evilginx phishing campaigns that utilize advanced session token theft to bypass multi-factor authentication and compromise user credentials. A SOC team should proactively hunt for these indicators in Azure Sentinel because Evilginx attacks often evade traditional MFA controls, necessitating early identification of compromised sessions before lateral movement occurs within the enterprise environment.

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(["185.212.128.170", "185.212.129.152"]);
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(["185.212.128.170", "185.212.129.152"]);
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 rule, tailored to an enterprise environment with corresponding filters and exclusions:

• Scenario: Scheduled Cloud Backup Agent Authentication

  • Context: The Microsoft Azure Backup agent or Veeam Backup & Replication service performs nightly authentication against cloud storage gateways using a specific OAuth token that matches the Evilginx signature pattern. This often triggers on POST requests to /api/v1/auth/token.
  • Filter/Exclusion: Exclude traffic originating from the dedicated backup subnet (e.g., 10.50.20.0/24) where the destination is known cloud storage endpoints (e.g., *.azure.com, *.veeam.com). Additionally, filter out requests containing a specific User-Agent string like Veeam.Backup.Agent or MSFT-BackupService.

• Scenario: Corporate SSO Redirects via Okta/Azure AD

  • Context: During the morning login rush, users accessing internal applications (e.g., ServiceNow, Salesforce) are redirected through the Identity Provider. The Evilginx rule may flag the complex redirect chain involving idp.okta.com or login.microsoftonline.com as a phishing proxy attack due to similar URL structures and cookie handling.
  • Filter/Exclusion: Create an exclusion for traffic where the source IP is within the corporate WAN range (172.16.x.x) and the destination domain matches known SSO providers (e.g., *.okta.com, login.microsoftonline.com). Ensure the filter checks that the HTTP status code is 302 or 301 followed by a successful 200 on the final landing page.

• Scenario: Automated CI/CD Pipeline Artifact Deployment

  ---