Don't Ban the Hijacked Exit: Reading hijacked_proxy Without Punishing Victims

Most antifraud stacks treat every proxy-class signal as "hostile egress — ban the account." That is the wrong move for one of the ten signals on IP99 by ThreatHunter: hijacked_proxy. The documented meaning is an address that has been pressed into proxy service after compromise — often malware on a real household or SMB machine. The person whose account just hit your login or checkout may be the victim, not the pool operator. Hard-banning them for the IP alone turns a supply-side signal into collateral damage.

This walkthrough stays on the free, no-key GET /v1/ip/{ip} endpoint. Live samples were captured on 2026-11-04 (~13:10 UTC). Product docs and the English API guide: IP99, API, detect proxy / VPN.

What hijacked_proxy is (and is not)

IP99's free lookup returns a 0–100 risk.score that measures freshness and strength of verifiable risk evidence, not "probability this user is an attacker." risk.level is derived from the score (0 → none, 1–29 → low, 30–69 → medium, 70–100 → high). Signals appear only when they hit; missing keys mean unknown, not zero.

Among the risk tags:

Official generic guidance (not a contract): score 0 → do not stamp the IP "clean"; 1–29 → observe; 30–69 → captcha / throttle / second factor rather than a hard ban; 70–100 → block only when cost allows. The docs call out hijacked_proxy specifically: that address should not be banned outright. Before any IP ban, Pulse customers also check share_tier (T0–T3) for blast radius — free /v1/ip does not return share_tier, so on the free tier lean harder on step-up and signal type.

Do not invent Tor or other tags that are not in the JSON. Do not treat IP99 scores as identical to every other ThreatHunter dataset you may have seen elsewhere — this article only claims what /v1/ip returns.

Live contrast: clean hosting attribute vs leftover hijack tags

curl https://ip99.com/v1/ip/8.8.8.8

Captured 2026-11-04T13:09:55Z:

{
  "ip": "8.8.8.8",
  "computed_at": "2026-11-04T13:09:55Z",
  "evidence_state": "none",
  "geo": {
    "continent": "NA",
    "country": "US",
    "region": "California",
    "city": "Mountain View",
    "tz": "America/Los_Angeles"
  },
  "network": { "asn": 15169, "usage_type": "IDC" },
  "risk": {
    "score": 0,
    "level": "none",
    "signals": ["hosting"]
  }
}

hosting here is a network attribute on public DNS infrastructure. evidence_state: none with score 0 means no verifiable proxy-class evidence on file — not a clean bill of health, and not a hijack.

Now a residential demo address that has historically shown proxy-supply tags. Full address works in curl; tickets and screenshots should mask the last octet.

curl https://ip99.com/v1/ip/27.22.66.200

Captured 2026-11-04T13:10:00Z (last octet masked in the body):

{
  "ip": "27.22.66.x",
  "computed_at": "2026-11-04T13:10:00Z",
  "evidence_state": "stale",
  "geo": {
    "continent": "AS",
    "country": "CN",
    "region": "Hubei",
    "city": "Xiangyang",
    "district": "Yicheng",
    "tz": "Asia/Shanghai"
  },
  "network": { "asn": 4134, "usage_type": "DYN" },
  "risk": {
    "score": 0,
    "level": "none",
    "signals": ["dialup_pool", "hijacked_proxy", "proxy"]
  }
}

evidence_state: stale forces the score to 0, but leftover signal slugs remain as a weak feature. Seeing hijacked_proxy beside proxy and dialup_pool on DYN (residential broadband) space is exactly the shape where "ban the IP → ban the household" is the wrong first move. Prefer step-up auth, device binding, or a temporary hold while you check whether the account looks like a farm.

When evidence_state is active and score is mid/high with hijacked_proxy, the same rule holds: treat the egress as contaminated, not the human as proven fraud. Combine with non-IP signals (device, payment, velocity). If you only have free /v1/ip, you lack share_tier — so default to verification over permanent IP bans on residential / mobile usage types.

A practical branch for login and support

1. Read evidence_state (active / stale / none).
2. Read risk.signals.
3. If hijacked_proxy is present:
     - Do NOT auto-ban the account for IP alone.
     - Prefer MFA / captcha / cool-down.
     - For support tickets: offer "your network may be infected or shared" language, not "you are a proxy reseller."
4. Else if proxy / vpn / dialup_pool / cloud_phone without hijacked_proxy:
     - Apply your normal supply-side policy (step-up vs block by score + product cost).
5. Never mark score 0 + evidence_state none as "trusted clean."

Anonymous quota is 500 lookups/day per public IP (60/min); a free logged-in key raises the daily cap. Check remaining with GET https://ip99.com/v1/me or the X-Daily-* response headers. OpenAPI: https://ip99.com/openapi.json. Weekly aggregates of newly captured proxy-class exits (no address lists): https://ip99.com/en/proxy-exits.

Try it

curl https://ip99.com/v1/ip
curl https://ip99.com/v1/ip/8.8.8.8
curl https://ip99.com/v1/me

IP99 is a ThreatHunter product. Use the free lookup to separate hijacked residential exits from intentional VPN/proxy supply before your ban hammer hits the wrong person. Start at https://ip99.com and the English API notes at https://ip99.com/api.