We monitor reports of breached websites constantly. After the Drizly breach (July 2020), Foodara breach (June 2020), and Wishbone breach (May 2020), we were amongst the first to jump into action to help. We track hundreds of breaches containing of millions of usernames.
But, let's back up. Let's talk about what a 3rd party website breach means for you and your team. After all, it's not your website. And after all, you only rely on the breached website occasionally. What trouble could it possibly cause for you, if a website like Drizly gets breached, and you have an account there?
If your company is like most, your employees have accounts on numerous websites. So many sites, in fact, that you might not even quite know all of the accounts they have. Some of them are accounts on 3rd party sites that you or your IT folks have blessed (e.g. payroll, CRM, accounting, and benefits sites). Others are more like Shadow IT sites -- ones that your team has concluded they need, regardless of whether the IT folks have blessed it (drizly.com, we're staring in your direction).
But, what these sites all have in common, is that they contribute to the sprawl of usernames, passwords, and other personally identifiable information related to your employees. Think payment cards, dates of birth, mothers maiden names, and other security questions/answers. That's the information that your team is (without any ill intent) unintentionally spreading across a multitude of 3rd party website databases. But, all is well until/unless one or more of those sites get hacked, right?
We mentioned earlier that we track reports (and datasets) of hundreds of breached websites. That's not an exaggeration. Here is a very small sample of the hundreds of website breaches whose information has shown up on the dark web over the years:
When a website breach happens, we tend to get calls from companies that know their employees had accounts on the breached website. Sometimes we hear from CEOs, sometimes from founders, sometimes from CTOs. But the line of questioning has been similar over the years. Paraphrasing and anonymizing, the question is:
"If my employees had accounts on website XYZ that got breached, at least it wasn't our website or corporate network! Since it's not our site, does that leave my company with any cybersecurity issue at all?"
It's wishful and hopeful thinking. Unfortunately, companies whose employees have accounts on breached sites, are now a target on the dark web. How so? Hackers that breach a 3rd party site almost always make at least a portion of the breached website data available on the dark web. At a bare minimum, hackers tend to want to show proof that they've successfully breached the website (a reputational matter in that community). But, more often, they want to share the supermajority or the entirety of the breached data -- either for monetary profit (sale/purchase on the dark web) or for other motivations. So, once "firstname.lastname@example.org" is known to be in the dataset of a breached website, there is a tremendously likely chance that his information remains in a dark web breach database into perpetuity:
Still, at this stage of the game, the breached data has not yet been used in any type of exploit that lands back on the original user's RADAR. And that moment won't necessarily come in the next step, either.
You've heard of "profile completion" perhaps? We all routinely log into websites that urge us to "complete our profile" by adding things like a profile picture, a link to our social media accounts, our job title or hobbies, our phone number, etc. Bad news: when hackers suddenly get access to breach contents from a new/recent breach, they know about profile completion as well. There is an extroardinarily high probability that many of the usernames in the recent breach, also have data elements in some pre-existing breaches already on the dark web. And, even if they don't, they have public records and (for the most dedicated of hackers) commercially available data.
Suddenly, a user who had accounts on last.fm, drizly.com, and modbsolutions.com might be a pivot table away from a hacker piecing together a profile including their: full name, phone number, date of birth, email address, IP address, your mother's maiden name, your favorite pizza topping, the model of your first car, and your gender. Oh, and either a hashed or (gasp) plaintext password. It doesn't all need to come from a single breach -- hackers with access to multiple breach datasets make quick work of profile completion.
Here's the punchline we wish we didn't have to deliver. Once hackers have the type of information described in the previous section, it's an easy leap to imagine what happens next. They could certainly (if one of the leaked passwords was plaintext) attempt to log into the newly-breached site. That's likely, but the damage only stops there in the most optimistic of scenarios. Far more likely, the tactics include the ones in the "Step 4" annotation in the below graphic:
With a user profile in hand containing the type of rich information that we tend to voluntarily supply to websites, you can expect that hackers will attempt to use your information to sign into other websites beyond the most recently breached site. Maybe they'll attempt to use security questions/answers to find their way through secondary security measures. Maybe they'll use social engineering to attempt to fool the support team of some additional website into providing access. These are just a sampling of the techniques and tactics that they might employ.
The above sequence, which is all too common, leaves a lot to think about. How to prevent it from happening in the first place? How to stay safe it it does happen? How to limit collateral damage when news of 3rd party breached websites shows up but the ramifications aren't yet clear?
We won't leave you waiting for long. We'll tell those parts of the story in a very soon upcoming blog post.