I originally wanted to write a post about my thoughts on the twitter leak that happened a while back but thinking about what could be done with leak data generically, it took me on new paths, the twitter leak is a conduit for this thinking.
I think what is discussed will be novel, not for everyone but still a fun talking point, I've deleted quite a fair amount of this post as I cannot show you the full journey as an attacker and as a result there's not much point in sharing the command-line kung-fu, working on the data, the main driver for not showing you the full attack path is that it will probably fall under Section 1 of the CMA as a more learnered friend suggested, and possibly a little bit more on the nose from another was and I quote "just to be clear, you're going to have a kid soon, and you're looking to use leaked stolen data to hijack the accounts of people on a third party platform in another country" ... well, you're no fun Steve. - this post is wholly in the name of research and stimulating defence, but he's right, there's little value in me taking you on the full journey when theoretically it's sound.
The Adversarial Concern
What else can you do with this reasonably fresh breach data? you have the usual stuff, targetted phishing, platform use validation, suspicious domains and possibly identifying account owners at the hand of bad opsec such as personal email addresses tied to a sneaky account and then regarding this post I thought, I wonder how many of those accounts have email addresses to domains that are no longer registered, I wonder how many of them are verified I wonder how many of them are using twitter as an identity (auth) provider to other things... and that's it in a nutshell.
This isn't a risk to Twitter specifically, this is a risk to applications that allow for email-based authentication, but we'll go with Twitter as our punchbag
- Extract domains, including IDNs
- Sort Uniq
- Remove all the domains that are owned by corps
- Identify broken domains and look for expirations
- ensure a DNS Registrar is willing to sell you the domain
At this point, you're crossing legal boundaries, I would have loved to demonstrate this but smarter people than me have made it very clear they won't visit me in prison, so I'm not doing it, but if I was...
- Buy the domain
- Reconfigure the email name
- Password reset on many social accounts
- do evil things
- Get busted by NCSC
- Eat Porridge
So, that's the attack as 'end-to-end' as I can show you, but let's look at some other views ...
Obviously, there's domain hijacking too if they've not paid their hosting bills and there are means to acquire that host, but that's a bit of scope creep, it's an option that may be a bit Schrödinger but ... this is it's notable mention.
What can we do as defenders? do we want to? is this too hard?
One could query the domain expiration date of customers' domains from the email address via services (or roll their own), is that information worth extending to the user prior to domain expiration ? or is it more subtle to ensure they have a second means of identity (such as a phone number) or a backup email address, this is the bit I'm interested in, what's a user-friendly way to defend against this.
If you're an organisation that has a bit of a janky 'Joiners, Movers, Leavers' process (JML) for 3rd party suppliers that may integrate with systems new and old, is this a nice sweep to do every year?
While I appreciate this is an acceptable risk for many, I'm curious to hear from those who may care about it more
The skinny for me is: Likelihood is low, Impact is variable, is that worth it ?
It's probably relatively worth it, i.e. if you think it's important enough of a gap to plug, or an easy enough countermeasure... more meat for the sprint grinder.
If someone had passed away, or imprisoned, this might be gamed by people interested in those people, or those people's connections, I wouldn't be surprised if this was fair game for law enforcement looking for an advantage.