ThreatFox: Evilginx IOCs

Hunt Hypothesis

This hunt targets adversary behavior where threat actors leverage Evilginx infrastructure to execute advanced phishing campaigns that bypass traditional MFA by dynamically generating login pages and capturing session tokens. The SOC team should proactively search for these specific IOCs in Azure Sentinel to identify early-stage compromises before attackers can establish persistent access or exfiltrate sensitive credentials from the environment.

IOC Summary

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

KQL: Ip Hunt

// Hunt for network connections to known malicious IPs
// Source: ThreatFox - Evilginx
let malicious_ips = dynamic(["162.35.175.224", "64.23.182.12", "185.212.131.22"]);
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(["162.35.175.224", "64.23.182.12", "185.212.131.22"]);
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 for the ThreatFox: Evilginx IOCs detection rule in an enterprise environment, along with recommended filters or exclusions:

• Scheduled Endpoint Security Scans by CrowdStrike Falcon

  • Scenario: The CrowdStrike Falcon sensor performs a daily scheduled scan of network traffic and DNS resolution logs. During this process, the agent queries internal threat intelligence feeds that mirror public EVILGINX indicators for benchmarking purposes, generating legitimate hits against the rule’s IOCs without actual user interaction or malicious payload execution.
  • Filter/Exclusion: Exclude traffic originating from the CrowdStrike Falcon Sensor service account (e.g., svc-crowdstrike) and filter out DNS queries where the destination IP belongs to the internal CrowdStrike management subnet (10.x.x.x).

• Automated Phishing Simulation Campaigns via KnowBe4

  • Scenario: The IT Security team launches a monthly phishing simulation using KnowBe4. These simulations often utilize “decoy” URLs and email templates that intentionally mimic known APT behaviors, including Evilginx patterns, to test user awareness. This results in legitimate users clicking links or opening attachments that match the rule’s IOCs as part of the training exercise.
  • Filter/Exclusion: Create an exclusion for source IPs belonging to the KnowBe4 cloud infrastructure and filter events where the User Agent contains specific simulation identifiers (e.g., KB-Simulation-2023) or where the destination URL domain ends in .knowbe4.com.

• Patch Management Deployment via Microsoft SCCM/MECM

  • Scenario: During a major Windows Update deployment, System Center Configuration Manager (SCCM) pushes security patches that include updated threat intelligence definitions. The deployment agent (ccmexec) downloads these definition packages from the Microsoft Update servers, which may contain