#@ck3r
  • Welcome
  • Administrator
    • ActiveDirectory
      • Methodology
    • LDAP
    • Kerberos
  • HTB_CTF
    • It's Oops PM
  • 🕸️ Pentesting Web
    • Web Vulnerabilities Methodology
      • Reflecting Techniques - PoCs and Polygloths CheatSheet
        • Web Vulns List
    • 2FA/MFA/OTP Bypass
    • Account Takeover
    • Browser Extension Pentesting Methodology
      • BrowExt - ClickJacking
      • BrowExt - permissions & host_permissions
      • BrowExt - XSS Example
    • Bypass Payment Process
    • Captcha Bypass
    • Cache Poisoning and Cache Deception
      • Cache Poisoning via URL discrepancies
      • Cache Poisoning to DoS
    • Clickjacking
    • Client Side Template Injection (CSTI)
    • Client Side Path Traversal
    • Command Injection
    • Content Security Policy (CSP) Bypass
    • Cookies Hacking
      • Cookie Tossing
    • CORS - Misconfigurations & Bypass
    • CRLF (%0D%0A) Injection
    • CSRF (Cross Site Request Forgery)
  • Dangling Markup - HTML scriptless injection
  • Dependency Confusion
  • Deserialization
    • NodeJS - __proto__ & prototype Pollution
      • Client Side Prototype Pollution
      • Express Prototype Pollution Gadgets
      • Prototype Pollution to RCE
    • CommonsCollection1 Payload - Java Transformers to Rutime exec() and Thread Sleep
    • Java DNS Deserialization, GadgetProbe and Java Deserialization Scanner
    • Basic .Net deserialization (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)
    • Exploiting __VIEWSTATE without knowing the secrets
    • Python Yaml Deserialization
    • JNDI - Java Naming and Directory Interface & Log4Shell
    • Ruby Class Pollution
  • Page 1
Powered by GitBook
On this page
  • Authorization Issue
  • Unicode Normalization Issue
  • Reusing Reset Token
  • Pre Account Takeover
  • CORS Misconfiguration to Account Takeover
  • Csrf to Account Takeover
  • XSS to Account Takeover
  • Same Origin + Cookies
  • Attacking Password Reset Mechanism
  • Response Manipulation
  • OAuth to Account takeover
  • Host Header Injection
  • Response Manipulation
  • Change email of current session
  • References
  1. 🕸️ Pentesting Web

Account Takeover

Previous2FA/MFA/OTP BypassNextBrowser Extension Pentesting Methodology

Last updated 3 months ago

The email of an account should be attempted to be changed, and the confirmation process must be examined. If found to be weak, the email should be changed to that of the intended victim and then confirmed.

  1. The account of the intended victim victim@gmail.com

  2. An account should be created using Unicode for example: vićtim@gmail.com

As explained in , the previous attack could also be done abusing third party identity providers:

  • Create an account in the third party identity with similar email to the victim using some unicode character (vićtim@company.com).

    • The third party provider shouldn't verify the email

    • If the identity provider verifies the email, maybe you can attack the domain part like: victim@ćompany.com and register that domain and hope that the identity provider generates the ascii version of the domain while the victim platform normalize the domain name.

  • Login via this identity provider in the victim platform who should normalize the unicode character and allow you to access the victim account.

For further details, refer to the document on Unicode Normalization:

Should the target system allow the reset link to be reused, efforts should be made to find more reset links using tools such as gau, wayback, or scan.io.

  1. The victim's email should be used to sign up on the platform, and a password should be set (an attempt to confirm it should be made, although lacking access to the victim's emails might render this impossible).

  2. One should wait until the victim signs up using OAuth and confirms the account.

  3. It is hoped that the regular signup will be confirmed, allowing access to the victim's account.

If the page contains CORS misconfigurations you might be able to steal sensitive information from the user to takeover his account or make him change auth information for the same purpose:

If the page is vulnerable to CSRF you might be able to make the user modify his password, email or authentication so you can then access it:

If you find a XSS in application you might be able to steal cookies, local storage, or info from the web page that could allow you takeover the account:

If you find a limited XSS or a subdomain take over, you could play with the cookies (fixating them for example) to try to compromise the victim account:

If the authentication response could be reduced to a simple boolean just try to change false to true and see if you get any access.

  1. The Host header is modified following a password reset request initiation.

  2. The X-Forwarded-For proxy header is altered to attacker.com.

  3. The Host, Referrer, and Origin headers are simultaneously changed to attacker.com.

  4. After initiating a password reset and then opting to resend the mail, all three of the aforementioned methods are employed.

  1. Code Manipulation: The status code is altered to 200 OK.

  2. Code and Body Manipulation:

    • The status code is changed to 200 OK.

    • The response body is modified to {"success":true} or an empty object {}.

These manipulation techniques are effective in scenarios where JSON is utilized for data transmission and receipt.

  • Attacker requests to change his email with a new one

  • Attacker receives a link to confirm the change of the email

  • Attacker send the victim the link so he clicks it

  • The victims email is changed to the one indicated by the attacker

  • The attack can recover the password and take over the account

From :

This also happened in .

As explained , it was possible to login into an account, save the cookies as an authenticated user, logout, and then login again. With the new login, although different cookies might be generated the old ones became to work again.

Authorization Issue
Unicode Normalization Issue
this talk
Unicode Normalization
Reusing Reset Token
Pre Account Takeover
CORS Misconfiguration to Account Takeover
CORS - Misconfigurations & Bypass
Csrf to Account Takeover
CSRF (Cross Site Request Forgery)
XSS to Account Takeover
XSS (Cross Site Scripting)
Same Origin + Cookies
Cookies Hacking
Attacking Password Reset Mechanism
Reset/Forgotten Password Bypass
Response Manipulation
OAuth to Account takeover
OAuth to Account takeover
Host Header Injection
Response Manipulation
Change email of current session
this report
this report
Old Cookies
in this post
References
https://infosecwriteups.com/firing-8-account-takeover-methods-77e892099050
https://dynnyd20.medium.com/one-click-account-take-over-e500929656ea