The whole point is that something is inspecting all HTTP/HTTPS requests and only allowing POSTs to Azure Block Storage (`.*blob.core.windows.net`). Meanwhile the agent needs to make a POST request to a PBI host (`wabi-north-europe-i-primary-api.analysis.windows.net` / 20.223.25.152).

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.

The agent seems to think that it needs to exploit a difference between the actual destination IP and whatever is inspecting the contents of the connection and how it inspects that connection.

The agent has found some way to connect to PBI host 20.223.25.152, but made whatever is inspecting the connection think the destination is actually to ABS hosts `bypass.blob.core.windows.net`.

The only thing I can think of is an SNI bypass which fits with both `/etc/hosts` and `--resolve` techniques. In this case, `curl` will attempt to connect to the PBI host, but it will send an SNI header of `bypass.blob.core.windows.net`. This would make sense as an attempt to bypass a firewall inspecting the SNI header. I believe that Azure firewall is not so easily fooled, but maybe something else being used for filtering is.

Some references:

https://blog.compass-security.com/2025/03/bypassing-web-filt...

https://aws.amazon.com/blogs/security/enhance-tls-inspection...