We're a small startup dealing with roughly US$14,000 in unauthorized Azure OpenAI usage overnight. A compromised API key exhausted our Microsoft for Startups credits and appears to have generated additional pay-as-you-go charges. We're still confirming the exact split between consumed credits and the remaining balance.
The activity was clearly abnormal: there was a huge spike in requests, traffic involving models we don't use, and unfamiliar source IP addresses. I rotated both keys as soon as we noticed, and the usage dropped to zero. MFA was already enabled, and we've since added budget and cost-spike alerts along with more detailed request logging.
We opened a support case with an incident timeline and evidence. Microsoft assigned an engineer and said they would investigate, but so far they've said they cannot process a waiver at the moment. They may restore the startup credits if they confirm the compromise, but they cannot guarantee that automatic collection will be paused while the investigation is underway.
We later found the likely root cause: our website was running an outdated Next.js version with a critical unauthenticated code-execution vulnerability. The website's container had the Azure key in its environment even though the site never used it. Scanners appear to have found the site soon after launch and extracted the key.
We patched Next.js, rotated the key, rebuilt the container from a clean image, checked the host for signs of further access, and limited each service to only the secrets it actually needs. The Azure key now exists only with the service that calls Azure.
Has anyone experienced something similar with compromised cloud or Azure OpenAI credentials? Did Microsoft waive the charges, provide a partial adjustment, restore consumed startup credits, or refuse? How long did the investigation take, and did billing continue while it was in progress? I'm especially interested in real outcomes and whether escalation or a one-time goodwill request made a difference.
3 Answers
Be completely candid about the exposure and fix the underlying issue before asking for credit restoration. Microsoft may be more cautious now because there are many credential-compromise cases, and unsecured secrets are generally treated as the customer’s responsibility. A one-time goodwill adjustment is still worth requesting, but it is not guaranteed. Also confirm that the attacker could not remain in the environment through the vulnerable container or another credential.
Open billing and subscription support cases, contact your cloud provider or CSP if you use one, and also open a case from the API-key or service area. Give them a precise timeline, the unfamiliar IP addresses, the usage graph, normal spending levels, and proof that rotating the key immediately stopped the traffic. Keep following up and request escalation because the difference between your normal usage and the spike is important evidence. In a similar case involving about $40,000, Microsoft investigated, confirmed there was no data movement, and refunded or voided the charges. That process took a couple of months, so don’t assume a quick answer means the case is closed.
Our normal token spend is around $1,000 at most, but the compromised period reached roughly 400,000 tokens in a short window. Rotating the credentials brought usage back to zero. I’m documenting that contrast and continuing to request escalation.
Store credentials in a proper secret-management system and restrict access as much as possible. A vault with private connectivity and service-specific permissions is safer than placing a broad API key in a web container. Key rotation, spending alerts, request logging, and rate limits can also reduce the damage if a credential leaks again.
We found the vulnerable Next.js deployment, patched it, rebuilt the container, checked the host, and moved the Azure credential out of the website environment. There’s no indication the attacker got beyond the container.