Account-Übernahme

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Autorisierungsproblem

Es sollte versucht werden, die E-Mail eines Accounts zu ändern, und der Bestätigungsprozess muss geprüft werden. Wenn er als schwach befunden wird, sollte die E-Mail auf die des beabsichtigten Opfers geändert und dann bestätigt werden.

Unicode-Normalisierungsproblem

  1. Das Konto des beabsichtigten Opfers victim@gmail.com
  2. Es sollte ein Konto mit Unicode erstellt werden
    zum Beispiel: vićtim@gmail.com

Wie in this talk erklärt, kann der vorherige Angriff auch durch Missbrauch von third party identity providers durchgeführt werden:

  • Erstelle ein Konto beim third party identity provider mit einer E‑Mail, die der des Opfers ähnelt, und verwende dabei ein Unicode‑Zeichen (vićtim@company.com).
  • Der third party provider sollte die E‑Mail nicht verifizieren.
  • Wenn der identity provider die E‑Mail verifiziert, kannst du eventuell den Domain‑Teil angreifen, z. B. victim@ćompany.com, diese Domain registrieren und darauf hoffen, dass der identity provider die ASCII‑Version der Domain generiert, während die victim platform den Domainnamen normalisiert.
  • Melde dich via diesem identity provider bei der victim platform an, die das Unicode‑Zeichen normalisieren sollte und dir Zugriff auf das Opferkonto ermöglicht.

Für weitere Details, siehe das Dokument zur Unicode‑Normalisierung:

Unicode Normalization

Wiederverwendung von Reset-Token

Falls das Zielsystem erlaubt, dass der reset link wiederverwendet werden kann, sollte versucht werden, mit Tools wie gau, wayback oder scan.io weitere reset links zu finden.

Pre Account Takeover

  1. Die E‑Mail des Opfers sollte zur Registrierung auf der Plattform verwendet werden, und es sollte ein Passwort gesetzt werden (ein Versuch zur Bestätigung sollte unternommen werden, wobei fehlender Zugriff auf die E‑Mails des Opfers dies unmöglich machen kann).
  2. Man sollte warten, bis das Opfer sich über OAuth registriert und das Konto bestätigt.
  3. Ziel ist, dass die reguläre Registrierung bestätigt wird, wodurch Zugriff auf das Opferkonto möglich wird.

CORS-Fehlkonfiguration zur Account-Übernahme

Wenn die Seite CORS-Fehlkonfigurationen enthält, kannst du möglicherweise sensible Informationen vom Nutzer stehlen, um sein Konto zu übernehmen oder ihn dazu bringen, Authentifizierungsinformationen zu ändern, um dasselbe Ziel zu erreichen:

CORS - Misconfigurations & Bypass

CSRF zur Account-Übernahme

Wenn die Seite für CSRF verwundbar ist, könntest du den Nutzer dazu bringen, sein Passwort, seine E‑Mail oder seine Authentifizierung zu ändern, sodass du anschließend darauf zugreifen kannst:

CSRF (Cross Site Request Forgery)

XSS zur Account-Übernahme

Wenn du in der Anwendung eine XSS findest, könntest du Cookies, local storage oder Informationen von der Webseite stehlen, die dir eine Übernahme des Kontos ermöglichen könnten:

XSS (Cross Site Scripting)

  • Attribute-only reflected payloads auf Login‑Seiten können document.onkeypress hooken, Tastatureingaben über new Image().src exfiltrieren und Anmeldeinformationen stehlen, ohne das Formular abzusenden. Siehe Attribute-only login XSS behind WAFs für einen praktischen Workflow.

Same Origin + Cookies

Wenn du eine eingeschränkte XSS oder eine Subdomain‑Übernahme findest, kannst du mit den Cookies spielen (z. B. durch Fixierung), um zu versuchen, das Opferkonto zu kompromittieren:

Cookies Hacking

Angriff auf Password-Reset-Mechanismus

Reset/Forgotten Password Bypass

Security-question-Resets, die client-seitig gelieferte Benutzernamen vertrauen

Wenn ein “update security questions”-Flow einen username-Parameter akzeptiert, obwohl der Aufrufer bereits authentifiziert ist, kannst du die Wiederherstellungsdaten beliebiger Konten (inkl. Admins) überschreiben, weil das Backend typischerweise UPDATE ... WHERE user_name = ? mit deinem nicht vertrauenswürdigen Wert ausführt. Das Vorgehen ist:

  1. Melde dich mit einem Wegwerf‑Benutzer an und erfasse das session cookie.
  2. Sende über das reset‑Formular den Benutzernamen des Opfers plus neue Antworten.
  3. Authentifiziere dich sofort über den security-question login endpoint mit den gerade injizierten Antworten, um die Privilegien des Opfers zu übernehmen.
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.) is now exposed without touching the real answers.

Enumerated usernames can then be targeted via the overwrite technique above or reused against ancillary services (FTP/SSH password spraying).

Response Manipulation

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.

OAuth to Account takeover

OAuth to Account takeover

Host Header Injection

  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.

Response Manipulation

  1. Code Manipulation: Der Statuscode wird auf 200 OK geändert.
  2. Code and Body Manipulation:
  • Der Statuscode wird auf 200 OK gesetzt.
  • Der Response-Body wird auf {"success":true} oder ein leeres Objekt {} geändert.

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

E-Mail der aktuellen Sitzung ändern

From this report:

  • 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

This also happened in this report.

Bypass email verification for Account Takeover

  • Attacker logins with attacker@test.com and verifies email upon signup.
  • Attacker changes verified email to victim@test.com (no secondary verification on email change)
  • Now the website allows victim@test.com to login and we have bypassed email verification of victim user.

Old Cookies

As explained in this post, 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.

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.

  • Identifiziere ein trusted-device cookie (SameSite=None, long-lived), das verwendet wird, um recovery checks zu lockern.
  • Finde einen first-party endpoint, der diese Geräte-ID in JSON zurückgibt (z. B. ein OAuth code exchange, der machine_id zurückliefert), aber nicht cross-origin lesbar ist.
  • Nutze eine batch/chained API, die das Referenzieren früherer subresponses ({result=name:$.path}) und das Schreiben in einen attacker-visible sink (page post, upload-by-URL, etc.) erlaubt. 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
  • Lade die batch URL in ein verborgenes <iframe>, sodass das Opfer das trusted-device cookie sendet; die JSON-path-Referenz kopiert machine_id in den attacker-controlled post, obwohl die OAuth-Antwort für die Seite nicht lesbar ist.
  • Replay: Setze das gestohlene device cookie in einer neuen Session. Recovery behandelt den Browser nun als trusted und ermöglicht oft schwächere „no email/phone“-Flows (z. B. automated document upload), um eine attacker email hinzuzufügen, ohne Passwort oder 2FA.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks