Account Takeover

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

Authorization Issue

किसी account का email बदलने का प्रयास किया जाना चाहिए, और confirmation प्रक्रिया को ध्यान से जाँचा जाना चाहिए। यदि यह कमजोर पाई जाती है, तो email को लक्षित पीड़ित के email पर बदलकर पुष्टि कर ली जानी चाहिए।

Unicode Normalization Issue

  1. लक्षित पीड़ित का account victim@gmail.com
  2. Unicode का उपयोग करके एक account बनाना चाहिए
    for example: vićtim@gmail.com

जैसा कि this talk में समझाया गया है, पिछला हमला third party identity providers का दुरुपयोग करके भी किया जा सकता है:

  • third party identity में victim के समान email बनाकर account बनाएं, कुछ unicode character का उपयोग करके (vićtim@company.com)।
  • third party provider को email verify नहीं करना चाहिए
  • यदि identity provider email verify करता है, तो आप domain हिस्से को attack कर सकते हैं जैसे: victim@ćompany.com और उस डोमेन को register करके उम्मीद कर सकते हैं कि identity provider डोमेन का ascii version generate कर दे जबकि victim platform domain name को normalize करता है।
  • उस identity provider के माध्यम से victim platform में login करें जो unicode character को normalize करके आपको victim account तक पहुंच दे सकता है।

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

Unicode Normalization

Reusing Reset Token

यदि target system reset link to be reused की अनुमति देता है, तो gau, wayback, या scan.io जैसे tools का उपयोग करके और reset links खोजने का प्रयास किया जाना चाहिए।

Pre Account Takeover

  1. प्लेटफ़ॉर्म पर signup करते समय victim का email उपयोग किया जाना चाहिए, और एक password सेट किया जाना चाहिए (confirmation का प्रयास किया जाना चाहिए, हालांकि victim के emails तक पहुँच न होने पर यह असंभव हो सकता है)।
  2. इंतज़ार करना चाहिए जब तक कि victim OAuth का उपयोग करके signup न कर ले और account confirm न कर दे।
  3. उम्मीद की जाती है कि regular signup confirm हो जाएगा, जिससे victim के account तक access मिल सकेगा।

CORS Misconfiguration to Account Takeover

यदि पेज में CORS misconfigurations हैं तो आप user से संवेदनशील जानकारी steal कर सकते हैं ताकि आप उसका account takeover कर सकें या auth जानकारी बदलवा कर ऐसा करवा सकें:

CORS - Misconfigurations & Bypass

Csrf to Account Takeover

यदि पेज CSRF के लिए vulnerable है तो आप user को उसका password, email या authentication modify करने के लिए मजबूर कर सकते हैं ताकि आप बाद में उसे access कर सकें:

CSRF (Cross Site Request Forgery)

XSS to Account Takeover

यदि application में XSS मिलता है तो आप cookies, local storage, या वेब पेज से ऐसी जानकारी चुरा सकते हैं जो account takeover की अनुमति दे सकती है:

XSS (Cross Site Scripting)

  • लॉगिन पेजों पर attribute-only reflected payloads document.onkeypress को hook कर सकते हैं, new Image().src के माध्यम से keystrokes exfiltrate कर सकते हैं, और फॉर्म submit किए बिना credentials चुरा सकते हैं। व्यावहारिक workflow के लिए देखें Attribute-only login XSS behind WAFs।

Same Origin + Cookies

यदि आप limited XSS या subdomain take over पाते हैं, तो आप cookies (उदा. उन्हें fixate करना) के साथ खेलकर victim account को compromise करने की कोशिश कर सकते हैं:

Cookies Hacking

Attacking Password Reset Mechanism

Reset/Forgotten Password Bypass

Security-question resets that trust client-supplied usernames

यदि “update security questions” flow में username parameter लिया जा रहा है भले ही caller पहले से authenticated हो, तो आप किसी भी account की recovery data (admins सहित) overwrite कर सकते हैं क्योंकि backend आमतौर पर UPDATE ... WHERE user_name = ? आपके untrusted value के साथ चलाता है। पैटर्न यह है:

  1. एक throwaway user से Log in करें और session cookie capture करें।
  2. reset form के माध्यम से victim username और नए answers submit करें।
  3. जिन answers को आपने अभी inject किया है उनका उपयोग करके security-question login endpoint से तुरंत authenticate करें ताकि आप victim की privileges inherit कर सकें।
POST /reset.php HTTP/1.1
Host: file.era.htb
Cookie: PHPSESSID=<low-priv>
Content-Type: application/x-www-form-urlencoded

username=admin_ef01cab31aa&new_answer1=A&new_answer2=B&new_answer3=C

Anything gated by the victim’s $_SESSION context (admin dashboards, dangerous stream-wrapper features, etc.) अब वास्तविक उत्तरों को छुए बिना एक्सपोज़ हो जाता है।

सूचीबद्ध उपयोगकर्ता नामों को फिर ऊपर बताए गए overwrite technique के माध्यम से लक्षित किया जा सकता है या ancillary services (FTP/SSH password spraying) के खिलाफ पुन: उपयोग किया जा सकता है।

Response Manipulation

यदि authentication response को एक सरल boolean में reduced to a simple boolean just try to change false to true किया जा सकता है, तो बस false को true में बदलकर देखें और पता लगाएं कि क्या आपको कोई access मिलती है।

OAuth to Account takeover

OAuth to Account takeover

Host Header Injection

  1. पासवर्ड रिसेट request initiation के बाद Host header को modify किया जाता है।
  2. X-Forwarded-For proxy header को attacker.com में बदला जाता है।
  3. Host, Referrer, और Origin headers को एक साथ attacker.com में बदल दिया जाता है।
  4. पासवर्ड रिसेट प्रारंभ करने के बाद और फिर मेल को resend करने का विकल्प चुनने पर, उपरोक्त तीनों विधियों का उपयोग किया जाता है।

Response Manipulation

  1. Code Manipulation: स्टेटस कोड को 200 OK में बदल दिया जाता है।
  2. Code and Body Manipulation:
  • स्टेटस कोड को 200 OK में बदल दिया जाता है।
  • response body को {"success":true} या एक खाली object {} में संशोधित किया जाता है।

ये manipulation techniques उन परिदृश्यों में प्रभावी हैं जहां JSON डेटा ट्रांसमिशन और प्राप्ति के लिए उपयोग किया जा रहा है।

Change email of current session

From this report:

  • Attacker नए ईमेल के साथ अपना ईमेल बदलने का request करता है
  • Attacker को ईमेल बदलने की पुष्टि करने के लिए एक लिंक मिलता है
  • Attacker वह लिंक victim को भेजता है ताकि वह उस पर क्लिक कर दे
  • Victim का ईमेल attacker द्वारा बताए गए ईमेल में बदल जाता है
  • यह attack पासवर्ड रिकवर कर सकता है और account takeover कर सकता है

This also happened in this report.

Bypass email verification for Account Takeover

  • Attacker attacker@test.com से लॉगिन करता है और signup के समय ईमेल verify करता है।
  • Attacker verified email को victim@test.com में बदल देता है (no secondary verification on email change)
  • अब वेबसाइट victim@test.com को login करने की अनुमति देती है और हमने victim user की email verification bypass कर दी है।

Old Cookies

As explained in this post, यह संभव था कि किसी account में login कर के cookies को authenticated user के रूप में save किया जाए, logout किया जाए, और फिर से login किया जाए.
नई login के साथ, भले ही अलग cookies generate हों, पुराने ones फिर से काम करने लगे।

Trusted device cookies + batch API leakage

Long-lived device identifiers that gate recovery can be stolen when a batch API lets you copy unreadable subresponses into writable sinks.

  • Identify a trusted-device cookie (SameSite=None, long-lived) used to relax recovery checks.
  • Find a first-party endpoint that returns that device ID in JSON (e.g., an OAuth code exchange returning machine_id) but is not readable cross-origin.
  • Use a batch/chained API that allows referencing earlier subresponses ({result=name:$.path}) and writing them to an attacker-visible sink (page post, upload-by-URL, etc.). Example with Facebook Graph API:
POST https://graph.facebook.com/
batch=[
{"method":"post","omit_response_on_success":0,"relative_url":"/oauth/access_token?client_id=APP_ID%26redirect_uri=REDIRECT_URI","body":"code=SINGLE_USE_CODE","name":"leaker"},
{"method":"post","relative_url":"PAGE_ID/posts","body":"message={result=leaker:$.machine_id}"}
]
access_token=PAGE_ACCESS_TOKEN&method=post
  • batch URL को एक छिपे हुए <iframe> में लोड करें ताकि victim trusted-device cookie भेज दे; JSON-path reference attacker-controlled post में machine_id कॉपी कर देता है, भले ही पेज के लिए OAuth response unreadable हो।
  • Replay: नए session में चुराई हुई device cookie सेट करें। Recovery अब browser को trusted मानता है, अक्सर कमजोर “no email/phone” flows (e.g., automated document upload) उजागर करता है ताकि attacker email बिना password या 2FA के जोड़ा जा सके।

संदर्भ

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें