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?