Mastodon
Go back

IP-Lookup, Proxy-Judge, and Proxy-Pool Destinations to Hunt For in Your Logs

hrbrmstr

da_667 dropped some “things you should watch for” in a Mastodon thread yesterday, and I figured a larger list from destinations captured in the logs from the sensor fleet Glenn & I run might be useful (other forms of this list have been put together by others over the years and some are still maintaied; I assert this is an additive contribution, not a replacement).

Watching for these destinations in DNS and egress logs matters because they are the external “phone-home” points of reconnaissance and proxy-testing tooling. An internal host that resolves ip-api.com, ifconfig.me, or any judge endpoint is almost never doing it for a business reason; it is either malware confirming its own egress, an operator probing your exit IP, or an automated harness fingerprinting your relays with the ?Z<id>Q1 and ?_hp_chain markers. DNS queries give you the earliest signal, since resolution precedes CONNECTion and often precedes any firewall block on the IP itself. CONNECTion and proxy logs give you confirmation and volume. Together they let you spot compromised hosts, unauthorized VPN or web-proxy use, and deliberate scanning of your egress infrastructure before any of it touches a crown-jewel system.

NOTE: some of the destinations were point-in-time (i.e., spun up for the campaign and taken down later), but you never know when they’ll be re-upped.

IP lookup / what-is-my-IP

This section is the fleet asking “what is my address?” Services here answer with the caller’s public IP, and often include geolocation, ISP, and ASN metadata. Most saw plain HTTP GETs to a root path or an /ip-style endpoint. A subset saw only CONNECT requests, meaning the client opened a TLS tunnel to the host even though the service itself answers in cleartext. A few were in ssh and telnet sensor command logs.

Proxy check / judge / proxy detection

This section is a bit different in intent. These endpoints do not report the caller’s address for its own sake, but exist to test whether an egress point is a proxy and to reveal what the request looks like when it arrives. The “judge” services echo back headers, TLS fingerprints, and source IP as the server saw them. Most of this traffic arrived as CONNECT, and the azenv.php paths are a classic probe artifact: that script prints server environment variables and leaks proxy-added headers.

Proxy service / pool / web proxy

The last section is not detection at all. These are the proxy providers themselves: VPN brands, proxy pool APIs, and web-proxy frontends the fleet connected to in order to route traffic, not to test a route. The distinction matters when reading the logs: section two tells you something probed a relay, section three tells you something used one.

FIN

A quick note regarding two request patterns:

Join the conversation:follow@hrbrmstr@rud.ison the fediverse to read and reply to this post from your own instance.

1 comment.

Next Post
Auditing the Auditors