Pre-hijacking Attacks of user accounts are on the rise
Most computer users are aware that criminals may gain access to their online accounts, for instance, by stealing or guessing the password, through phishing or other forms of attack.
Many may not be aware of a new attack type that is creating accounts with a user's email address before the user does so. Malicious actors use account pre-hijacking attacks to prepare user accounts for full takeovers. The attacker creates accounts on sites and services using a victim's email address. Various techniques are then used to "put the account into a pre-hijacked state". Once a victim has recovered access to the account, after finding out during sign-up that an account with the victim's email address exists already, attacks are carried out to take over the account fully.
Not all websites and services are vulnerable to account pre-hijacking attacks, but security researcher Avinash Sudhodanan believes that a significant number is. Sudhodanan published the research paper "Pre-hijacked accounts: An Empirical Study of Security Failures in User Account Creation on the Web" in May 2022 in which he describes five types of pre-hijacking attacks.
The creation of online accounts has evolved on the Internet. Previously, users used an identifier and password to create accounts. These accounts were linked to a user's email address usually. The method is still available on today's Internet, but sites started to support federated authentication as well, often in addition to supporting traditional account creation processes.
Federated authentication, for example, Single Sign-On, adds a new layer of complexity to the user creation process, as sites and services often support both options. Companies such as Facebook, Microsoft or Google support federated authentication and act as identity providers. Users users may sign-up to third-party services that support Single Sign-On and the user's identity provider. Some sites allow users to link classic user accounts to Single Sign-On providers, which unlocks the ability to sign in using a username and password, or the identity provider.
Websites and services have a strong incentive to support identity providers according to Sudhodanan, as "it improves the experience for users". Users may re-use accounts that they have created in the past across multiple services; this makes the account creation process easier, faster and may eliminate the need to set up account passwords. Previous research has shown that Single Sign-On providers become high value targets for attacks.
Research focused on security implications for existing accounts and less on the account creation process itself up to this point.
Account Pre-Hijacking Attacks
In his research, Sudhodanan demonstrates that an entire class of account pre-hijacking attacks exists. All have in common that the attacker is performing actions at a target service before the victim does. None of the five different attack types that Sudhodanan describes in the research paper require access to a victim's Identity Provider account.
Attackers need to target services that victims will likely sign-up for in the future. Additional information, for instance about existing accounts or interests, may help with the selection of targets, but attackers may also pick targets by popularity, trends or even press releases if organizations are the target.
The goal of account pre-hijacking attacks is the same as that of classic account hijacking attacks: to gain access to the victim's account.
Depending on the nature of the target service, a successful attack could allow the attacker to read/modify sensitive information associated with the account (e.g., messages, billing statements, usage history, etc.) or perform actions using he victim’s identity (e.g., send spoofed messages, make purchases using saved payment methods, etc.)
An attack consists of three phases:
- Pre-hijack -- The attacker uses the email addresses of victims to create accounts at target services. Knowledge of the email address is required to carry out the attack.
- Victim action -- The victim needs to create an account at the target or recover the account that exists already.
- Account takeover attack -- The attacker attempts to take over the user account at the target service using different attack forms.
Classic-Federated Merge Attack
The attack exploits interaction weaknesses between classic accounts and federated accounts at a single provider. The attacker may use a victim's email address to create an account at the provider; the victim may create an account using the federated provider instead using the same email address. Depending on how the service merges the two accounts, it could result in both parties having access to the same account.
For the attack to be carried out successfully, it is required that the target service supports classic and federated accounts. Additionally, email addresses should be used as the unique account identifier and the merging of both account types needs to be supported.
Once the victim creates the account using the federated provider, the target service may merge the accounts. Depending on how that is done, it may give the attacker access to the target service using the specified password.
Unexpired Session Attack
This attack exploits that some services do not sign-out users of their accounts if a password is reset. A victim may reset an account password at a service if the service informs the victim that an account exists already.
The attack works if the service supports multiple concurrent sessions and if users are not signed-out of accounts if passwords are reset. The attacker needs to stay signed-in to the account to keep the session active.
Trojan Identifier Attack
The attacker creates an account at the target service using the victim's email address and any password. Once done, a second identifier is added to the account, e.g., another email address that the attacker controls.
When the victim resets the passwords, the attacker may use the secondary identifier to regain access to the account.
Unexpired Email Change Attack
The attack exploits a vulnerability in the email changing process of target services. The attacker creates an account using the victim's email address and any password in the beginning. Afterwards, the attacker begins the process of changing the account's email address; this leads to a confirmation email being sent to the new email address.
Instead of clicking on the provided link right away, the attacker waits for the victim to reset the account password of the account and to recover the account. The attacker will then activate the link to take control of the victim's account.
The attack works only if the target service is not invalidating links after a set period.
Non-verifying IdP Attack
The attack mirrors the Classic-Federated Merge Attack. The attacker creates an account at a target service using an Identity Provider that "does not verify ownership of an email address when creating a federated identity".
The victim would have to create a classic account at the target service. If the service combines the two, the attacker may be able to access the account.
Closing Words
Sudhodanan examined 75 sites of the Alexa top 150 sites to find out if these are vulnerable to one or multiple of the described attacks. He found 252 potential vulnerabilities and 56 confirmed vulnerabilities during the analysis. Dropbox, Instagram, LinkedIn, WordPress.com and Zoom were found to be vulnerable to one of the described attacks.
The research paper is accessible here.
Now You: what do you do with account creation emails for accounts that you did not initiate?
The blame is on how the services implement their controls when managing accounts creation and changes.
They should step up their game. This paper shows clearly that some companies do not give a sh*t about their clients, letting them get screw by any of these methods.
Forget about federated or not – when you sign up for any website with your email address, they send you a verification link to activate your account. Unless the attacker has already gained access to your email address, how tf is he going to bypass the verification step? And if you get an account verification mail from a service you didn’t sign up for, how moronic do you have to be to click on it instead of getting suspicious?
I did not understand “what I need to do if I find out that my email already exist in Instagram ?”
Truth is I am getting Instagram emails with unknown name in my email box as my a/c. I did not open Instagram a/c, so as per above article it is pre attack. Ok. But what should I do now ?
Click the email to highlight it and then hit Ctrl + U to open the headers. That will show you where the email was sent from. Copy same to Notepad.
From there contact the email service provider for your account and send them the headers. They can initiate the necessary steps to have the sender taken offline.
Use a dedicated e-mail program and pipe all instagram mails into garbage whilst marked as read. I don’t interact with spam, even by real companies. That is how they know your account is maintained.
I ran into this. Someone successfully opened a PayPal account tied to an old email address that I rarely use.
As an experiment, I tried to reset the password, but it was linked to a phone that wasn’t mine. PayPal support didn’t want to reset the password either – without the phone they couldn’t verify my identity, and it was possible that *I* was the scammer.
But they have a procedure for this sort of thing. If you contact UnsolicitedEmail@PayPal.com, they remove your email from any associated PayPal accounts. It seemed to work well.
What do I do with creation emails for accounts I didn’t create? Never got any, but I’d you know, make a note of the service it was for and then move the email to my IOC-IOA folder for future reference. Or if the email had a “did you not perform this action?” button, report it here, I’d use that if I knew what the service was. But more likely than not it’d be the first option.
I have to say, I’m sorta mildly surprised that 58 sites or w/e the # was were vulnerable to any of those “attacks” of the top 150 (though this was in 2020 for the most part). Then I quickly looked at what the top 150 were, and became much less surprised. Nearly all are simply godawful services with plenty of past data breaches and whatnot. Sites like that (very popular) have almost no choice but to accomodate the legacy nature of their user base and opt for convienience over security in all aspects. Way more suprising was that OneLogin and Okta allowed non-verified emails to be added into developer/test accounts and then used in the real world. Yikes!
It’s sort of amusing how all the diagrams and some of the data is courtesy of MS, plus they funded the research study itself; their Defender for Identity and Defender for Cloud Apps modules of the MS Defender 365 solution just so happens to completely mitigate or render useless all 5 (and several other pre-hijacking) attack methods discussed in addition to informing you ahead of using a service exactly which threat vectors it’s vulnerable to in the signup security, sevice use security, etc. areas. Coincidence I’m sure…
I skimmed the research source link and I gotta say, a number of the explanations for some of these attacks are borderline spurious, or rather some of the assumptions required for attacks to be possible are. The victim has to ignore every account verification email they’re sent. That’s sort of asking a lot. I’m not really sold on the premise that you can just go create an account for an email you don’t own, I mean you can try to but you can’t finish the workflow as it requires you to validate the email, and until you do no account is actually created. Though, I have used sites that permit some use prior to validation but the service was worthless to attack and allowed use without any login at all, just to a lesser degree… But most dubious was that basically every attack required successfully executing a CSRF attack on the victim to get them to unknowingly trigger a PW reset or an email change confirmation, most often while logged into a session concurrently. I’m pretty sure pulling that off in and of itself is a helluva lot harder than any of the other actions required of an attacker for any of the attacks themselves.
On the plus side, the study brought to my attention that using plus (+) addressing when I sign up for services not only helps to filter and categorize your inbox/password manager, it entirely mitigates this whole class of attacks, as the second requirement for all attacks is prior knowledge of the email to be used when the victim signs up for the service. For organizational reasons, I always plus into my email an abbreviation of the service it’s for. Like, if I was signing up for gHacks for example, I’d give the email mike+ghck or mike+hacks@example.com. Also, on services where I have tons of accounts, If I ever get an account already exists error, I never reset the password, it’s so much easier to just change the plus address to something that isn’t in use, apparently rendering all pre-hijacking attacks in place total failures. Neat! (If your email provider doesn’t support + addressing in 2022, they sorta suck…)
This article also made me recall one you wrote a month ago-ish about MS, Google and Apple all working together to standardize passwordless logins next year. That will entirely negate this entire class of threats, including but ranging out way past just pre-hijacking, to virtually any attacks on the signup/validation/signin process one could conceieve of.
Cool article!
There’s something I don’t understand.
– Attackers need to target services that victims will likely sign-up for in the future.
This means of course that the attacker is creating an account on a service for which I have no account, otherwise the attacker couldn’t use my e-mail address
– I later on try to create an account on a service where an account has been previously opened by the attacker with my e-mail address : the service will state that an account with my e-mail is already created.
Where’s the risk? If I try to open an account and the service tells me an account with my e-mail already exists I conclude my e-mail address has been hijacked and I propose another e-mail address and consider the hijacked address should be deleted, if possible and possible it is with alias e-mail addresses (Disposable Email Addresses).
I don’t quite understand the risk. The only issue seems to be more an information than an issue : I discover my e-mail address has been hijacked, and it’s better to know it than to ignore it once it’s been effectively hijacked. What am I missing? Pre-hijacking attacks seem complicated, certainly more than I understand.
The attack relies on the idea that people sign up for dozens and dozens of accounts over the course of many years, possibly with different email addresses, and may not be certain that they haven’t signed up for an account previously with their current email address. So, when the user’s attempt to create a new account fails with the message that they already have an account, the user assumes that they have simply forgotten that they registered, “regains” their credentials, and logs into the pre-compromised account set up by the attacker.
Users also have uncertainty because some sites delete old accounts and log-ins.
We’re at a point in time when many users have been online for decades. That’s decades worth of accounts created various places, and plenty of time to forget whether you have an account somewhere tied to your current email address. Even most comment sections require accounts (This site excepted.).
While this scenario may not seem plausible to those with memories like a steel trap, I can say that I personally wasn’t immediately sure whether or not I had an account with a website at my current email address a month or so ago. Someone asked me and I told them I’d have to check. Once I got into it, I recognized the screen name and old transactions I’d made, but what if I hadn’t? I had already basically bought into the idea that it was my account.
Knowing that this is a thing will hopefully cause me to be more cautious in the future.
@John, many thanks, I think I finally understood.
The user wants to create a new accont
He’s told that an account with his email already exists
He cannot create a new account SO he assumes that he had created an account on that site previously
He then asks to change his password and the trap starts…
OK. It’s the path from not being able to create a new account to assuming he had this account previously that I had missed in my ordering of events.
I hate not understanding what is not relevant of knowledge but of good sens.
I still don’t understand.
Any reputable sites would notify users by email that a new account has been created, or ask for email verification for the account to be activated.
Someone used my emails to register to several sites before and they sent me email regarding the new account.
I just asked the site to delete my account and blocked the site email further after that. Where’s the risk in this? I don’t input any password or info to the site, they only have my email address and ip.
I understand this point of view also, but as someone else stated, if I try to sign up, and I’m told an account already exists, I may think I just forgot about, so I recover the account, and while doing so I’d obviously change the password and/or security questions, so the original attacker who opened it would not have the new sign on credentials. What am I missing?
And by changing the password and/or security questions I also mean very any other info/device that may be tied to the account like a cell to get codes, or something like that.
Oh, and wait. If someone tries to register my email they would need to have access to that email already to confirm when a confirmation email is sent. So I’d have to already be hacked. The more I think of this the more I’m confused. You can’t confirm my email if it’s secured.
@Tom Hawack, I agree your point of view. I have thought the same as you, “This means: avoid federated authentication. Is that the moral of the story?”, because it seems that obviously the answer should be yes, mostly considering that the federated autenthication seems not trustable by itself. However, if you and me were wrong, does it mean that any kind of security online is weak and the culprit is the end company that handles the user information? So bad in such the case, isn’t it?
I don’t get it either, if you regain control over an account someone else made, doesn’t the password change automatically?
> Fake account, Fake password + victim email
> regain control
> fake account + new password + victim email
So how does the attacker get it back? Some lousy security question aka “Your mums maiden name” (placed by attacker)
And the whole single signon, i never use! How creepy that companies want to link all to your google or github account.
> sign in to 3rd party using github
No way!
@John G. : hourra! I’m not alone to wonder as I wander in this pre-hijacking attack (that shouldn’t rejoice me!).
There are 5 attack schemes. Martin pointed out that a federated authentication is not concerned in the case of the Trojan Identifier Attack. I’ve read the description and I still cannot understand the chronological happenings …
> “if you and me were wrong, does it mean that any kind of security online is weak and the culprit is the end company that handles the user information? So bad in such the case, isn’t it?”
I guess the culprit is a combination of two factors,
1- Nothing is perfect, including any login process;
2- Smart guys with black hats have the talent to find imperfections and the vice to exploit them.
But everyday brings its lot of problematic scenarios until these are improved. Then we (1) and (2) carry on, again and again. Ad vitam aeternam.
@Tom Hawack & @John G.
The take-away is certainly NOT to avoid Federated Authentication, it’s in fact far safer than classic email & password use. The source research publication actually states that the methods used were selected for the purpose of demonstrating what an attacker with average to weak capability can achieve. Here’s a direct excerpt from the paper ([…] ellipses inserted for brevity while retaining the key points):
” Our work builds upon their example, but
assumes a significantly weaker attacker. Specifically, they
consider an attacker who has gained control of the victim’s
federated identity (e.g., the victim’s IdP account). Although
this is certainly possible, as they demonstrate in the same
work [17], it goes beyond the standard web attacker threat
model. […] Nevertheless, their attack is more powerful than any of ours, since once
a victim’s IdP account has been compromised, this can be used
to hijack even the existing RP accounts of the victim. […] In contrast, we
show that there exists a class of account pre-hijacking attacks
that are possible without compromising the victim’s federated
identity. These attacks are thus significantly easier to execute,
as demonstrated by our analysis in Section 5.2. ”
So, there are really two critical take aways (assuming assigning a ‘culprit’ is part of your perrogative). John G. correctly identified the root cause here, or the culprit, as being the services themselves (specifically the service you’re signing up for but also the IdP being used to Federate should be highly trustworthy and competent [Microsoft, Google, Apple, Amazon all meet this standard]). The study called out OneLogin and Okta as they made it possible to abuse their developer programs as Non-verifying IdPs. However, that’s trivial in comparison to the Service Providers, Instagram, Dropbox, LinkedIn, WordPress.com, Zoom in the case of this paper were used to demonstrate examples of Services that left much to be desired in their handling of account signups and Federated Identities. All services found vulnerable to this nature of attack were notified of their vulnerabilities and more likely than not are right now far less vulnerable if at all.
Of course, this is of little help to users as they have no role in how a service operates. This brings us squarely to the take away that really matters and can be used to protect yourself. Martin eluded to it and it’s User Awareness of this type of attack, or more accurately it’s user UNawareness that provides the danger here, as is the case in nearly all security threats.
If you’re looking for a “so what do I do to ensure my account isn’t pre-hijacked” practical answer then that’s fairly easy to provide. The research notes that were MFA (Multi Factor Authentication/2nd Factor Authentication) to be enacted upon initial access to the services, all discussed avenues of attack would fail. This applies to Federated login and well as classic login. This should be the first thing you do on accessing any new account of any value. Enable the strongest MFA/2FA option offered by the service first and in services that provide recovery options or trusted devices, secondary contacts, etc. make sure to look at each area and if you discover any methods of access you didn’t enact yourself to be enabled – just disable/remove them. Google provides a LOT of these, even so 5-7 minutes of browsing the Security/Access areas of the account is plenty to view and uncover any settings that should not be in use but could be.
Another requisite for all pre-hijacking attacks is prior knowledge of the login credential that will be used to identify you, your email is assumed to be this for these attacks. The co-requisite assumption necessary in addition is the supposition that the victim will ignore and dismiss any account confirmation requests received via email. Do not ignore these. Pre-hijacking does not have anything to do with compromising your email (were this to occur, the attacker would have all they need to takeover almost any accounts you create with relative ease). Your email being already in use by somebody else doesn’t mean they can access your email account. As such, take note of and save security notifications/account verifications you get for any service even if you don’t use it. You shouldn’t get these often at all so keeping them in a dedicated folder for easy reference can make an easy reference point later on. It also tells you quite simply what email somebody may be waiting for you to use for a given service.
Do you have an iPhone or a Mac (or any Apple device)? If so, then you’ve got an AppleID, even without a device you can create for free an AppleID. They act as an IdP who allows you to Federate into any service that offers a Sign in wih Apple option. The magic here is that unlike nearly every other IdP, Apple does NOT pass alonge your email to a service you use with them to Single-Sign-On to. Instead, for each service you sign up with via an AppleID, Apple generates a random 24+ character alphanumeric prefix to an @apple.com email address that they pass to the service as your email and relay emails from the service to that random address to your actual email so the services you use never need to know your real address. Obviously, this mitigates any pre-hijacking by design.
Many email providers support the (+) plus addressing spec. This is where you are able to dynamically generate unlimited email aliases as you like by simply taking your regular email, for example tom@example.org and using in its place, tom+anythingyouwanthere@example.org, or tom+a@example.org, all email sent to tom+xxx@example.org will arrive in your inbox like email sent to your real address. This also defeats pre-hijacking by design.
In any event, the more you pay attention to things and keep up with, to at least a cursory degree, the evolving threatscape by reading and learning what you can, the odds become increasingly slim of getting tripped up by a bad actor.
There are certain risks, especially if users are unaware of these kind of attacks.
“Federated authentication, for example, Single Sign-On, adds a new layer of complexity to the user creation process, as sites and services often support both options.”
“For the attack to be carried out successfully, it is required that the target service supports classic and federated accounts.”
If I understand correctly, no federated authentication (together with classic authentication) = no possible pre-hijacking vulnerability.
This means : avoid federated authentication. Is that the moral of the story?
For my part, I NEVER use federated authentication, for privacy reasons. This new vulnerability confirms that such authentication is a bad choice.
I hope I’ve got it right this time…
Here’s a real life example – Someone I know wanted to sign up for a facebook account. Typed mobile no. for sign up and after submitting OTP account became active. I was there the whole time monitoring the process and you guessed it right – It was a case of young person(me) assisting slightly older fella. To my surprise the account already had a profile picture. First warning. It was created three months ago from Indonesia when account info was searched. Second warning. Infact account was frozen and a notification arrived – thanks for confirming mobile number and enjoy full account features since it was suspended because mobile no. wasn’t verified. Then I went to delete account permanently for which it asked OTP. Refused to submit it and minutes later, it got suspended due to different IP address since I don’t live in Indonesia. On suspended page I reported the account and it got permanently suspended. Whole experience was odd and fb is a poor company which can’t afford real customer interaction(since users are customers), I did what I could – permanent suspension of that account and reporting it for hacking. As expected never got anything from fb, but account is permanently suspended.
I used to consider myself slightly better than normies which was why I was helping a normie in the first place. But after that I refuse to submit OTP for anything.
This article sounds familiar.
Federated authentication is used in some of the attacks, but not all of them. There is the Trojan Identifier Attack, which does not use it at all.
@Martin, thanks but I still don’t understand (it all anyway). Let’s forget little old me. The article is complete, I’m encountering a brain bug. I’ll have to spare some time, eat fish for brains and coffee for enlightenment then dig into the 5 attack schemes. Sometimes one’s brains just can’t make it, i.e. I’ve always had problems with combinatorial analysis in maths :=) A synapse mutiny on the Bounty-Brains perhaps!