The authors of the post were trying to find SSRF bugs within Microsoft Copilot after finding 2 but recently patched bugs. They found that when providing key phrases it was possible to trigger an internal HTTP request on behalf of the service. Naturally, making HTTP requests is an exciting thing to do!
When pointing the IP to Burp Collaborator, they got a ping back. When trying to do this against IMDS (internal metadata service for Azure instances), they got back an error though. They attempted to use a decimal value instead of a regular IP and using a domain that went to the internal IP but both of these returned an error.
The next technique they used as a classic: a 301 redirect response to a restricted host. Even this returned a 400. Upon checking out IMDS documentation, they discovered the header Metadata: true has to be used and it cannot contain X-Forwarded-For. Luckily enough, the editor for the request allowed for adding at the metadata header. Additionally, X-Forwarded-For header can be smuggled in via a multiline value with an invalid value.
Adding the headers alongside a 301 redirect made the SSRF attack work. With this, they had access to internal instance credentials. From these credentials, they checked various things to see what it had access to. They found a Cosmos DB that the instance had access to - both read and write permissions. However, it was only accessible from a select range of IPs.
They needed a URL to access the instance, a master key for the DB and the ability to make an HTTP request from Copilot with the proper headers. Although not explained very well, it appears that the master keys and credentials could be queried based upon their credentials. They could then reuse the SSRF to make a request to the database.