alt Hacker News> So a proxy should block any POST to 20.223.25.152 unless that IP somehow overlaps with ABS. But in that case, there's no reason for the agent to mess with `/etc/hosts` not `--resolve`. The agent could just use `curl` with the PBI IP in URL and the PBI Host header. But it doesn't do that.
I think this is the part I'm not following, and sorry if I've missed something. There are two ways to construct the request you showed. One is to mess with /etc/hosts. Another is to use `--resolve`. Just because the agent chose one doesn't mean it couldn't have done the other. What makes you think it couldn't have used `--resolve` as well?
Your initial question was how do we know that the proxy blocks POST requests. Perhaps I went on a tangent with my answer, but we know that because the agents were trying to find a way around the proxy.
So then I assumed that editing `/etc/hosts` was an attempt to fool a proxy co-located on the same host as the agent, which editing `/etc/hosts` would do, but using `--resolve` would NOT do.
But after looking into it more I no longer think that's the case. It turns out that some of agents did use `--resolve` while others used `/etc/hosts`. This only makes sense as an SNI bypass, which once I downloaded the full dataset and searched for, is what the agents believe they were doing:
https://news.ycombinator.com/item?id=49570417
So the agents were skipping the proxy entirely, then getting past additional network restrictions that should have prevented them from doing so by exploiting a weakness in whatever was supposed to be preventing them from doing so by lying about the SNI hostname.