On 9 April 2024, TechCrunch reported that Microsoft employees had left an Azure-hosted storage server open to the internet without a password. The server held internal information relating to Microsoft's Bing search engine, including code, scripts and configuration files containing passwords, keys and credentials that employees used to reach other internal databases and systems. Three researchers at the security firm SOCRadar, Can Yoleri, Murat Özfidan and Egemen Koçhisarlı, found it and reported it to Microsoft on 6 February 2024. Microsoft secured the server on 5 March 2024, 28 days later. Microsoft said the credentials "should not have been exposed" but were temporary, reachable only from internal networks and disabled after testing. Microsoft did not say how long the server had been exposed or whether anyone other than SOCRadar found it. No misuse has been reported. The incident is a familiar one for Microsoft: in 2023 an over-permissive storage token exposed 38TB of its internal data.
Key takeaways
- A Microsoft storage server on Azure was publicly accessible without a password and held Bing-related code, scripts and configuration files containing passwords, keys and credentials, according to TechCrunch.
- The credentials were used by employees to access other internal databases and systems, so the exposed files were a map to more of Microsoft's internal estate.
- SOCRadar reported the server on 6 February 2024. Microsoft locked it down on 5 March 2024, 28 days later, and the exposure became public on 9 April 2024.
- Microsoft said the credentials were temporary, accessible only from internal networks and disabled after testing. No misuse has been confirmed, and Microsoft did not say how long the server was open.
- The identity lesson: configuration files are credential stores, and a storage location holding them needs the same access control as a vault, even for test credentials.
At a glance
| Organisation | Microsoft (Bing team) |
|---|---|
| When | Exposure start unknown; reported to Microsoft 6 February 2024; secured 5 March 2024; made public 9 April 2024 |
| Attacker | None known. Found by SOCRadar researchers Can Yoleri, Murat Özfidan and Egemen Koçhisarlı |
| Entry point | A storage server hosted on Microsoft Azure left open to the internet with no password protection |
| Identities abused | Passwords, keys and credentials in code, scripts and configuration files, used by employees to access internal databases and systems |
| Impact | Internal credentials and Bing-related code exposed for at least 28 days after the report; no confirmed misuse. Microsoft says the credentials were temporary and internal-only |
| Category | NHI. Incident class: exposure, no confirmed misuse (internal credentials in a publicly accessible storage server) |
What happened
SOCRadar, a threat intelligence company, routinely looks for exposed data belonging to large organisations. Its researchers found an open, public storage server hosted on Azure that was storing internal information relating to Bing. It was not password protected, so anyone on the internet who knew where to look could read it. According to TechCrunch, "The Azure storage server housed code, scripts and configuration files containing passwords, keys and credentials" that Microsoft employees used to access other internal databases and systems.
Can Yoleri of SOCRadar told TechCrunch that the data could help attackers identify other places where Microsoft stores internal files, which "could result in more significant data leaks and possibly compromise the services in use." SOCRadar reported the server to Microsoft on 6 February 2024. Microsoft secured it on 5 March 2024. CPO Magazine noted that Microsoft did not explain why the fix took almost a month.
Microsoft's Jeff Jones gave TechCrunch the company's position: "Though the credentials should not have been exposed, they were temporary, accessible only from internal networks," and were disabled after testing. "We thank our partners for responsibly reporting this issue," he added. Jones did not say how long the server had been exposed or whether anyone other than SOCRadar had found the data, and Tech Monitor reported that both questions remained open. The disclosure came during a run of Microsoft security problems, including the theft of an email signing key by China-backed hackers in 2023 and the Midnight Blizzard intrusion into corporate mailboxes disclosed in January 2024.
Timeline
| Date | Event |
|---|---|
| 6 February 2024 | SOCRadar researchers report the open Azure storage server to Microsoft. |
| 5 March 2024 | Microsoft secures the server, 28 days after the report. |
| 9 April 2024 | TechCrunch makes the exposure public with SOCRadar's findings and Microsoft's statement. |
| 11 April 2024 | Tech Monitor reports that it is unclear how long the server was exposed or whether others accessed it. |
| 16 April 2024 | CPO Magazine reports on the month-long gap between report and fix. |
How it happened: the identity attack path
- Credentials written into files. Code, scripts and configuration files for Bing-related work contained passwords, keys and credentials in readable form.
- Files kept in cloud storage. Those files were stored on a storage server hosted on Azure.
- Access control missing. The server was publicly reachable with no password, so the credentials inside were readable by anyone who found it.
- Discovery by a third party. SOCRadar found the server and reported it; none of the sources say Microsoft had detected the exposure itself.
- Slow remediation. The server stayed open for another 28 days after the report. Microsoft says the credentials were internal-only and disabled after testing.
Impact
- Confirmed: a Microsoft storage server holding code, scripts and configuration files with passwords, keys and credentials was publicly accessible, and stayed so until 5 March 2024.
- Microsoft's position: the credentials were temporary, accessible only from internal networks and disabled after testing.
- Unknown: how long the server was exposed before 6 February 2024 and whether anyone other than SOCRadar accessed it.
- Misuse: none reported. SOCRadar warned the data could help attackers find other internal storage and services.
What this means for NHI governance
The credentials in this case were the kind that rarely appear in an identity inventory: passwords and keys sitting inside scripts and configuration files, used by staff and tools to reach internal systems. They belong to no single person and are rarely rotated or monitored. Microsoft's answer, that they were temporary and internal-only, is a reasonable mitigation, but it relies on network position rather than on the secrets being protected. Network boundaries change, and an attacker already inside a network would find such a list very useful.
This is also the second time in under a year that Microsoft storage on Azure exposed internal secrets to the public; in 2023 a single over-permissive SAS token exposed 38TB of internal data. The lesson for every organisation is that storage holding configuration and code needs secret scanning and public access controls as standard. Our Secrets Management Guide and ISPM Guide cover how to find credentials in storage before someone else does.
Recommendations
- Revoke and rotate every credential found in exposed files. Even test credentials should be disabled and replaced once exposed, and their use reviewed in logs. See the Leaked Credential Response Playbook.
- Keep credentials out of scripts and configuration files. Fetch them at runtime from a managed secrets store such as a key vault. See our Secrets Management Guide.
- Block public access on cloud storage by default. Use policy to prevent anonymous access to storage accounts and alert when it is enabled. See our Cloud PAM and CIEM Guide.
- Scan cloud storage for secrets continuously. Treat configuration files and code in storage the same way as repositories. See our ISPM Guide.
- Set and meet a deadline for fixing reported exposures. A public server holding credentials should be closed within hours of a credible report, not weeks.
- Do not rely on network position alone. Internal-only credentials still need short lifetimes, an owner and monitoring for use from unexpected places.
Frequently asked questions
What did Microsoft expose in April 2024?
An Azure-hosted storage server holding Bing-related code, scripts and configuration files with passwords, keys and credentials was publicly accessible without a password. SOCRadar reported it on 6 February 2024, Microsoft secured it on 5 March and TechCrunch reported it on 9 April.
Were the exposed Microsoft credentials used by attackers?
No misuse has been reported. Microsoft said the credentials were temporary, accessible only from internal networks and disabled after testing, but did not say how long the server was open or whether anyone besides SOCRadar accessed it.
Who found the exposed Microsoft server?
Security researchers Can Yoleri, Murat Özfidan and Egemen Koçhisarlı of SOCRadar found it and reported it to Microsoft.
Related NHI Mgmt Group resources
Microsoft SAS Token Exposure 2023 · Microsoft Midnight Blizzard Breach 2024 · Mercedes-Benz GitHub Token Exposure 2024 · Secrets Management Guide · Leaked Credential Response Playbook
How NHI Mgmt Group can help
Secrets stored in scripts, configuration files and cloud storage are machine credentials that rarely have an owner. We help organisations find them, move them into managed storage and set rotation and response targets. See our NHI and AI agent security training.
References
- TechCrunch: Microsoft employees exposed internal passwords in security lapse (9 April 2024)
- Tech Monitor: Microsoft exposed employee passwords in recent data breach (11 April 2024)
- CPO Magazine: Microsoft's Unsecured Azure Cloud Server Exposed Internal Employee Credentials for a Month (16 April 2024)