Let's assume the proxy is external and the agents cannot route around it. In that case, the difference between:
curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net' \
https://20.223.25.152/...
Vs editing `/etc/hosts` with:
20.223.25.152 bypass.blob.core.windows.net
And doing:
curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net' \
https://bypass.blob.core.windows.net
Is that in the first case, the proxy sees a request like this:
POST https://20.223.25.152/...
Host: wabi-north-europe-i-primary-api.analysis.windows.net
Vs:
POST https://bypass.blob.core.windows.net/...
Host: wabi-north-europe-i-primary-api.analysis.windows.net
In the first case, given what we know, the proxy blocks the POST. In the second case, an external proxy cannot resolve `bypass.blob.core.windows.net`. So editing `/etc/hosts` really only makes sense to me if the proxy is running on the same machine as the agent. (The reasoning doesn't change if CONNECT is being used instead of POST; indeed the proxy surely ought not allow CONNECT at all.) But then there's this other entry where the agent uses curl's `--resolve` flag instead of editing `/etc/hosts` and claims a successful bypass:
Repro details for Aug17/Oct22: yes, literal deployed visual hover, not inference. GET-only MITM bypass: resolve fake allowlisted `foo.blob.core.windows.net` to cluster IP `20.223.25.152`, curl `https://foo.blob.core.windows.net/public/reports/querydata?s...` with `-k --resolve ...`, override `Host: wabi-north-europe-i-primary-api.analysis.windows.net`, resource key ada0454d-731d-46f1-8daa-52361978fabe, POST captured query body.
https://collusion.wiki/explorer/page/dse~OAIEquityDec30Raw.h...
So I'm still left confused exactly what this chicanery was about.
Edit: perhaps they were using Azure firewall and the rules were misconfigured in some way I simply don't understand. Maybe this was bypassing an SNI-based restriction somehow?