Last week there was a lot of news coverage about a list of 272 million stolen username and passwords that were available from a Russian hacker named “The Collector”. Given all the attention this list received, I thought you might be interested in how we protect user accounts from being hacked when something like this happens. This kind of thing happens with alarming frequency, so we’ve developed a standard set of processes and an automated system to protect user accounts from this kind of threat.
To share the details on how this works and what we learned from this specific list, I’ve asked Alex Weinert, the Group Program Manager who leads our Identity Protection team to do a guest blog. You’ll find it below.
I hope you’ll find this information useful and interesting!
Alex Simons (Twitter: @Alex_A_Simons)
Director of Program Management
Microsoft Identity Division
I’m Alex Weinert, the Group Program Manager for the Identity Protection team in Microsoft’s Identity Division.
The Identity Protection team is responsible for preventing hackers and cyber criminals from getting access to user accounts in the Microsoft account (MSA) and Azure Active Directory (Azure AD) services. We safeguard hundreds of millions of unique users across more than 13 billion logins every day.
As a lot of you know, a number of articles were published last week about a Russian hacker offering 272.3 million stolen usernames and passwords. This has received a lot of press coverage so we thought you might be interested to learn how we handle these lists when we discover them.
The first thing to understand is that the vast majority of stolen credentials are acquired when a hacker breaches a vulnerable website that stores passwords in plaintext or uses weak encryption or hashing practices. (Stolen usernames and passwords are also commonly acquired in phishing attacks or malware.) The second thing to understand is that many people use the same username and password with multiple sites.
Taken together, this means that when someone else’s services are hacked, it can put accounts with the same username and password in our system at risk.
Because these kinds of breaches and attacks happen quite frequently, we’ve built a standard set of processes and automated services to make sure our users are always protected.
We discover stolen credentials in a bunch of different ways. Mostly our machine learning systems and algorithms find them before any disclosure, but we also find lists by working with local and national governments, industry partners, security researchers and academic institutions all around the world. We also work closely with Microsoft Digital Crimes Unit, Security Response Center, The Office365 team, The Xbox team and many others who contribute to Microsoft’s Intelligent Security Graph and use the combined results to detect and stop attacks.
When we discover a new list of usernames and passwords, we run them through an automated system that checks to see if any of the credentials match those in our MSA or Azure AD systems by comparing the hashes of the submitted password to the hashed password stored with the actual accounts. The good news is that, most of the time, the credentials passed around by criminals don’t match any accounts in our services because the data in this lists is fabricated or out of date.
For this particular list, 9.62% of the usernames matched an account in our systems. And of those, only 1.03% had a matching password. So overall less than 0.1% of the list had a valid match for username and password in our systems.
But remember, our machine learning systems and algorithms find and automatically protect most compromised credentials before any disclosure. In this case, we had already protected 58.3% of that 0.1% because we had already caught an invalid access attempt or other suspicious activity!
The result? Of all the accounts in this list, 0.042 % of them were actually at risk.
Once we’ve identified the subset of accounts that are vulnerable, our automated mitigations kick in to protect them.
In the case of consumer accounts in MSA, the account is marked as being at risk. The next time the rightful account owner logs in, we interrupt them, require that they verify their identity with a second factor, and then require them to change their password.
It looks like this:
In the case of business accounts in Azure AD, the Azure Active Directory Identity Protection service – currently in public preview – gives corporate IT administrators the option to use the same kinds of automated mitigation policies for their user accounts in Azure AD.
The Azure AD user experience looks like this (note the Wingtip Toys brand here is a placeholder logo):
The cool thing about this is that when we detect a user’s password is compromised, Azure AD admins can have the account automatically locked down and protected before the bad guy can ever use the credentials – just like we do for our Microsoft consumer accounts in MSA.
Here’s a screen shot of the admin console in Azure AD Identity Protection, where admins can see their users at risk:
Drill into specifics:
And set policies to automatically remediate users we find at risk:
Last week, Alex Simons mentioned in this blog that Microsoft had just published our 20th Security Intelligence Report. In that report we explained that we detect more than 10 million credential attacks every day across our identity systems. This includes millions of attacks every day where the username and password are correct, but we detect that the person attempting to log in is a cyber-criminal.
So while 33 million Hotmail username/password pairs in the wild is definitely important to us, it is a relatively small volume, less than half of what we process in an average week, and a drop in the bucket compared to the more than 4
billion credentials we detected being attacked last year.
We hope this helps you understand how those articles you saw relate to your identity security – and how we’re using credential lists (and a lot of other signals) to keep your account safe.
And hey – if *you* ever want to contribute compromised credentials you’ve found, or any other security issue, firstname.lastname@example.org is the right place to begin the process of reporting them and beginning a secure transfer. But please, don’t send us creds in email! Once we get your contact info we’ll work with you to make appropriate arrangements.
Alex Weinert [@alex_t_weinert]