For most of December, Microsoft left nearly 250 million customer-service and customer-support records exposed on the web for anyone to see.
Security researchers working with U.K. tech-news website Comparitech (opens in new tab) discovered the unprotected data, which consisted of five identical databases holding logs of conversations between Microsoft tech-support agents and customers.
Spanning 14 years (from 2005 to December 2019), the exposed logs included some customer email addresses, IP addresses, locations, descriptions of claims, case numbers and support agent's emails.
Microsoft said it had conducted an investigation into a "misconfiguration of an internal customer support database" in a notice posted on the Microsoft website (opens in new tab). No malicious use was discovered but customers had "personally identifiable information exposed."
"We want to be transparent about this incident with all customers and reassure them that we are taking it very seriously and holding ourselves accountable," Microsoft wrote.
How was the information exposed?
Microsoft said the problem stemmed from a change made to the database on Dec. 5 that contained misconfigured security rules that left the data unsecured.
Security researcher Bob Diachenko, who works with Comparitech to find unprotected databases online, notified Microsoft of the issue on Dec. 29 and Microsoft had locked down the database by Dec. 31.
Microsoft claims the issue was limited to an internal database used for support-case analytics and not commercial cloud services. That's critical because Microsoft requires data stored in support-case analytics databases to be redacted so that personal information is removed.
As a result, the "vast majority of records" didn't contain personal information, including email addresses, most of which were redacted.
What kind of information was left exposed?
Unfortunately, some data was left unredacted if it met certain conditions. Microsoft cited the example of information with a non-standard format, such as an email address in which there was a space instead of a dot before "com".
But the types of data exposed extended far beyond email addresses, according to Comparitech. Diachenko said IP addresses, locations, descriptions of claims, support-agent emails, case numbers and internal notes marked as "confidential" were also unprotected in at least some cases.
While truly sensitive data --- dates of birth, credit card info or email aliases --- were redacted or were never entered in the first place, the data left exposed could still be used by tech-support scammers.
With this information, the scammers could be more convincing when they called random people and claim to be legitimate Microsoft tech-support agents. For example, they could cite actual case numbers gathered from the exposed database.
What you can do to protect yourself
Microsoft didn't find evidence of any malicious use of the exposed data and the information contained on the databases is only moderately sensitive. Diachenko only noticed the database after it was indexed by a search engine on Dec. 28, and it's not clear if anyone else saw it.
Whenever Diachenko and his team find an unprotected database online, they often can't tell whether anyone else found it before they did, or took anything from it.
Still, Microsoft customers should be careful about email phishing scams and tech support scams. Remember, Microsoft agents will never proactively call you to ask about your device, so be suspicious if you didn't call first.
What is Microsoft doing to prevent another exposure?
Microsoft apologized for failing to secure customer information and promised to take further action to prevent a similar situation.
"We want to sincerely apologize and reassure our customers that we are taking it seriously and working diligently to learn and take action to prevent any future reoccurrence," the company wrote.
The company will now audit network security rules for internal resources, expand its scope of mechanisms that detect improper security rules, and add more alerting services for when rules aren't being properly followed.