Status of api.ipify.org — Part 2: 2026 Verdict Update

Hunt. Analyze. Respond. Repeat. ∞

Edison NewWorld — Real samples. Raw analysis. No vendor spin.

THREAT//INTEL Verdict Update IOC Retrospective Part 2 of 2

Malware Analysis · Nine Years Later

Status of api.ipify.org — Part 2
Did the 2026 Verdict Change?

In 2017 I called api.ipify.org clean but abused. Nine years, a Suricata rule, a Splunk detection, a wave of sandbox verdicts, and one GitHub Actions false-alarm later — I went back and checked whether that verdict still holds.

newWorld · Follow-up to the August 2017 original · 2026 Update

Verdict: Still Not Malicious — Confidence Increased

01 / Recap: The 2017 Call

Clean Service, Abused Purpose

Back in August 2017 I wrote a post asking a simple question: is api.ipify.org malicious or not. The answer then was straightforward. api.ipify.org is a legitimate public IP lookup API. It kept showing up in malware traffic, so I dug into VirusTotal, cross-checked the URLs and files calling it, and concluded the domain itself was clean — malware was abusing a benign service, not the other way around.

That article kept climbing in views for years. Enough that it deserves a real follow-up instead of one verdict left standing untested forever. So I pulled fresh data — sandbox reports, detection rulesets, vendor research, and one live incident — and checked whether 2026 tells a different story.

Original 2017 Finding

api.ipify.org never hosted malware, never served payloads. Samples called it for exactly one reason: to fetch the infected machine's public IP address. The service was innocent; the traffic pattern around it was the tell.

02 / Nine Years, Five Data Points

What Actually Changed Since 2017

The core fact hasn't moved. What changed is how much better documented, and how much more institutionalized, the abuse pattern has become.

01

A named detection rule now exists

Proofpoint's Emerging Threats ruleset carries ET POLICY External IP Lookup api.ipify.org, categorized as "Device Retrieving External IP Address Detected." Pure policy signature — fires on the pattern, not on maliciousness.

02

Splunk built SIEM content around it

A Cisco NVM-based detection watches api.ipify.org alongside ipinfo.io, icanhazip.com, checkip.amazonaws.com and others — explicitly described as recurring in post-exploitation frameworks, stealer malware, and advanced threat actor campaigns.

03

Sandboxes now tag it directly

ANY.RUN reports on api.ipify.org connections come back tagged evasion, verdict "Malicious activity" — a behavioral read, not an infrastructure one, but it lands as a red flag on the dashboard regardless.

04

The scale is now quantified

SANS research (analyst Jay Yanza, via IronNet) found api.ipify.org used as a third-party IP lookup in 205 of 7,747 unique malicious file hashes examined — with other lookup services combined exceeding 2,000 hits.

05

Even trusted infrastructure trips the alarm

In November 2024, StepSecurity's Harden-Runner flagged a wave of GitHub Actions runners across multiple customers calling api.ipify.org with no prior baseline. Traced back to GitHub's own infrastructure — benign, but a live demonstration of why the policy rule exists.

03 / A Legitimate Extension, An Undocumented Call

The Chrome Extension Case

IronNet's writeup includes a good illustration of why this domain keeps landing on watchlists even when nothing is wrong. Researchers traced an undocumented outbound connection in a PCAP back to a completely legitimate, widely-used Chrome extension quietly calling api.ipify.org. The vendor's own engineering team had to be looped in to confirm it was expected behavior — they didn't know either.

"External IP lookups, while not inherently bad, can be indications of anomalous or even malicious activity. Organizations should be aware of network behavior and permissions — both expected and unexpected." — IronNet, Investigating Undocumented Netcomms From a Legitimate Chrome Extension

That's the same conclusion the 2017 post reached, just with a better citation trail behind it now.

04 / Why Malware Keeps Calling It

The Motive Hasn't Changed — Just the Documentation

Three consistent reasons show up across the research for why malware families keep reaching out to services like this one:

• Sandbox and geofencing checks — comparing the returned public IP against known cloud/sandbox ranges, or against a target region, before deciding whether to detonate.
• C2 confirmation and beaconing — using the external IP as part of victim fingerprinting, or confirming live internet egress before continuing.
• Evasion of network-based attribution — detecting NAT, VPN, or proxy layers that need to be worked around.

None of it requires the API to do anything malicious. It just has to return an IP address reliably — which is exactly what it was built to do.

---

05 / Updated Verdict

So — Is It Malicious in 2026?

No. Same answer as 2017.

VirusTotal's community detections on the domain remain clean. OTX and other threat intel platforms list it as an observed indicator inside campaigns, not as malicious infrastructure in its own right. Functionally it's still exactly what it says on the tin — a single-purpose IP address API, no authentication, no payload delivery, no history of hosting anything harmful.

Assessment

What changed is confidence, not conclusion. In 2017 this took manual VirusTotal digging to establish. In 2026 it's baked into commercial detection rulesets and sandbox verdicts as a matter of course. The service is still innocent; the surrounding tooling has simply caught up to what was already true.

Signal Source	Verdict on api.ipify.org itself	Status
VirusTotal community detections	No malicious infrastructure flags	CLEAN
OTX / threat intel platforms	Listed as observed IOC in campaigns	CONTEXTUAL
ANY.RUN sandbox tagging	Behavioral "evasion" tag on connection pattern	BEHAVIORAL
ET POLICY / Suricata	Policy signature, not malicious signature	MONITORED
Splunk / Cisco NVM content	Named in stealer & post-exploitation detection logic	MONITORED

06 / Recommendations

For Defenders Running These Rules Today

1. Don't blocklist the domain outright. Legitimate software, browser extensions, and CI/CD infrastructure all use it — you'll break things that have nothing to do with an incident.
2. Treat unexpected calls as worth a second look. An undocumented request to any IP-lookup service from a non-browser process — especially one with no reason to check its own public IP — deserves triage.
3. Use it as telemetry, not a verdict. A hit on this domain alone is not proof of infection. It's one data point in a chain that should include the calling process, its parent, and what happens right after the IP comes back.
4. Start from the existing rulesets. Pull the ET POLICY signature and the Cisco NVM/Splunk detection logic referenced above as a baseline, then tune the exclusion list to your own known-good processes.

Operational Risk

The November 2024 GitHub Actions incident is the cautionary example here: a completely benign explanation still needed a full investigation before anyone could rule out compromise. Treat every hit with the same discipline, regardless of how likely it is to be nothing.

07 / Conclusion

Nine years on, the mist from the original title is still the same mist: the service was never the problem. It's what gets built on top of it that matters.

That part hasn't changed, and honestly, I don't expect it to.

Part 1 of this series: Status of api.ipify.org - is it malicious or non malicious? (2017)

Sources referenced: Proofpoint Emerging Threats ruleset · Splunk Security Content (Cisco NVM detection) · ANY.RUN sandbox reports · IronNet, "Investigating Undocumented Netcomms From Legitimate Chrome Extension" (2023) · StepSecurity, "Harden-Runner Detects Anomalous Traffic to api.ipify.org" (Nov 2024) · SANS research via Jay Yanza

THREAT//INTEL · Verdict Update Edison NewWorld — Hunt. Analyze. Respond. Repeat. ∞