Suspicious Windows Public IP Address Discovery via DNS

This threat brief focuses on the behavioral pattern of Windows-based processes querying public IP address discovery web services. Threat actors utilize these lookups as an initial reconnaissance step to confirm network connectivity, determine their egress IP, or identify network environment restrictions before initiating command-and-control (C2) operations.

The activity is particularly concerning when performed by Living-off-the-Land binaries (LOLBins) such as powershell.exe, bitsadmin.exe, or rundll32.exe, as well as unsigned binaries or processes executing from high-risk user-writable directories (e.g., \Users\Public or \ProgramData). Defenders must distinguish between this malicious reconnaissance and routine administrative tasks performed by managed system updaters or endpoint security agents. Because both benign and malicious software leverage the same common public IP services, detection engineering teams must utilize process lineage, code signing status, and network connection correlation to reduce false positives.

Attack Chain

1. An attacker gains initial access or code execution on a Windows host.
2. The attacker selects a LOLBin or drops an unsigned malicious binary into a writable directory.
3. The process initiates a DNS lookup for a public IP discovery service (e.g., api.ipify.org or checkip.amazonaws.com).
4. The operating system resolves the domain via DNS, leaving an artifact in host-level network logs or Sysmon Event ID 22.
5. The process receives the resolution, verifying external internet connectivity.
6. The attacker establishes a network connection to a C2 infrastructure or exfiltrates data, often using the previously verified egress path.

Impact

Successful reconnaissance via IP discovery services indicates that an attacker has achieved a foothold and is actively preparing for further malicious operations. If left undetected, this stage often leads to full C2 communication, internal network scanning, lateral movement, and data exfiltration. The impact varies depending on the attacker's objective, but identifying this stage provides a critical window to disrupt the attack chain before significant damage occurs.

Recommendation

• Deploy the provided Sigma rule to detect DNS queries to known IP lookup services from suspicious processes and tune based on internal administrative software profiles.
• Enable Sysmon (specifically Event ID 22) or equivalent DNS telemetry to capture dns.question.name and process association.
• Correlate DNS query events with child process creation and network connection logs to identify C2 initiation.
• Do not create exceptions based solely on the IP lookup domain or process name; require verification of the process hash, code signing certificate, and parent process lineage.