Pre-Authentication Account Take-Over

  1. I’ve just choose to register through the FORM, so I put my email address as (which in real case victim’s email) and register my self, but one interesting thing happen which is there no email verification done by the application. Now I’ve access to all the functionality of the application without any restriction.
  1. [Attacker Step] Navigate to the target application and register a new account using the victim user’s email. Since the application also has a Google Authentication option, I used a Gmail account for registration as a victim account.
  2. Observe that the application successfully logs in a user upon registration process completion, and all the features of the applications are accessible.
  3. Now, log out and navigate back to the target application’s login functionality.
  4. [Victim Step] This time, use Google Authentication and login to the application using the same Email address that is used in Step-1
  5. Observe that the login is successful and the victim user can access the application. Then, perform any changes in the application, such as profile update.
  6. [Attacker Step] Now, In a separate browser window, attempt to log in using the Email: Password used for registration in Step-1 .
  7. Observe that the attacker is successfully logged in to the victim user’s account and can see all the changes that the victim performed.
  8. This allows an attacker to keep persistence access in the victim user’s account as long as the victim manually changes the account’s password.
  1. Since there is no email confirmation, an attacker can easily create an account in the application using the Victim’s Email. This allows an attacker to gain pre-authentication to the victim’s account.
  2. Further, due to the lack of proper validation of email coming from Social Login and failing to check if an account already exists, the victim will not identify if an account is already existing. Hence, the attacker’s persistence will remain.
  3. An attacker would be able to see all the activities performed by the victim user impacting the confidentiality and attempt to modify/corrupt the data impacting the integrity and availability factor.
  4. This attack becomes more interesting when an attacker can register an account from an employee’s email address. Assuming the organization uses G-Suite, it is much more impactful to hijack into an employee’s account.
  5. The overall severity usually lies from High to Critical depending upon the data that is being stored.
  1. The easiest remediation to this issue is to ensure that the email verification is adequately implemented and can not be bypassed.
  2. Further, by ensuring that the social logins are correctly implemented, the email extracted from the social login is verified against the existing user’s database to ensure that the victim asked to reset the password. By doing so, it is possible to remove the attacker’s persistence.




Garv se Bhartiya, Security Enthusiast.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Security Advisory: Mitiga Recommends All AWS Customers Running Community AMIs to Verify Them for…

CompTIA Security+ Study Resources


{UPDATE} German Quest Hack Free Resources Generator

{UPDATE} 3D Hunting : African Outpost Hack Free Resources Generator

MicroBT Whatsminer M30S 88 TH/s

{UPDATE} Peek-a-Boo Halloween Hack Free Resources Generator

The Best ‘Guilty Pleasure’ Security Podcasts

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Hemdeep Gamit

Hemdeep Gamit

Garv se Bhartiya, Security Enthusiast.

More from Medium

Business Logic Bug| Email Existing Bypass | Running 2 accounts with a single email

How I found High-Priority PII leak through web archive

One Click To Account Takeover

Unrestricted File Upload (Cloud fare Bypass )