> For the complete documentation index, see [llms.txt](https://hacking-notes.jord4n.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-notes.jord4n.pro/es/web/authentication/username-enumeration-via-account-lock.md).

# Enumeración de nombres de usuario mediante bloqueo de cuentas

Notas sobre Enumeración de nombres de usuario mediante bloqueo de cuentas para los laboratorios de PortSwigger Web Security Academy, incluido el flujo de explotación, pruebas de payload, validación en Burp Suite y contexto de mitigación.

### Enumeración de nombres de usuario mediante bloqueo de cuenta

La aplicación establece un bloqueo de cuenta después de varios intentos fallidos, pero la lógica es imperfecta. Puede utilizarse para:

1. Encontrar un nombre de usuario válido.
2. Forzar tu contraseña por fuerza bruta.
3. Ir a la página de su cuenta.

Las listas proporcionadas son:

* El **bloqueo de la cuenta** ocurre \*\* solo si el nombre de usuario es válido\*\*.
* Para usuarios inexistentes, incluso después de varios intentos, el comportamiento sigue siendo diferente (sin bloqueo real, mismo mensaje/respuesta).
* Por lo tanto, se puede distinguir un usuario existente de uno inexistente solo observando las respuestas.

<figure><img src="https://754079710-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-4488912695921502b1626a6ca9fa2cdcedab8fc9%2F%7B990C1E33-5174-47C2-A076-89DB667CAD9C%7D.png?alt=media" alt=""><figcaption></figcaption></figure>

#### 1. Detección de un nombre de usuario válido

1. Enviar solicitudes de inicio de sesión en **modo Intruder** con la **Cluster Bomb** técnica:

* Un conjunto de candidatos para el campo de nombre de usuario.
* Un conjunto de contraseñas para provocar varios fallos.

2. Configura una \*\*regla de coincidencia (regex)\*\* para filtrar las respuestas que contienen el mensaje:

* `Nombre de usuario o contraseña no válidos.`

<figure><img src="https://754079710-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-3e97305bc93da5a693364b53788001c7f8381f82%2F%7B51BE5C26-72E2-49CE-B656-0A5E055B0999%7D.png?alt=media" alt=""><figcaption></figcaption></figure>

* Analiza los resultados:
* **Inválido** las cuentas mantienen un comportamiento consistente.
* Para una \*\*cuenta válida\*\*, después de un número de pruebas fallidas, la respuesta cambia (bloqueo).

<figure><img src="https://754079710-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-4551c97ca1337e410d484590a9baf8ad859cd78d%2F%7B5623C231-62EC-451F-A3C0-D01CED6E3857%7D.png?alt=media" alt=""><figcaption></figcaption></figure>

1. Observando las respuestas, notamos que el nombre de usuario **`akamai`** difiere de los demás y revela este comportamiento relacionado con el bloqueo de la cuenta. / → \*\*`akamai` se identifica como un nombre de usuario válido. \*\*

#### 2. Fuerza bruta de la contraseña de una cuenta válida

1. Una vez `akamai` se ha identificado como un usuario válido, Intruder se reinicia en **modo Sniper**:

* El campo de nombre de usuario permanece fijado a `akamai`.
* Solo la **contraseña** se utiliza con la lista de palabras proporcionada ( contraseñas del laboratorio de autenticación ).

<figure><img src="https://754079710-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-7ee48f3d67ff83b1c239afe2b336017cdac80cf1%2F%7B61A289C6-CD3D-4AA5-9EDF-5811F764EF0E%7D.png?alt=media" alt=""><figcaption></figcaption></figure>

1. Las respuestas se revisan de nuevo, incluyendo:

* El \*\*código de estado HTTP\*\*.
* El tamaño del cuerpo de la respuesta.
* Ausencia o modificación del mensaje de error.

2. Al probar la **`chelsea`** contraseña, la respuesta es diferente (por ejemplo, \*\*código HTTP diferente\*\* de otros intentos). / → Se deduce que la pareja **`akamai` / `chelsea`** es correcta.

<figure><img src="https://754079710-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl4EVJpcOrsgjSGsLI7p2%2Fuploads%2Fgit-blob-cc02873fb961a6cd8baf85ef86e5a5db5ea8333d%2F%7B49B33C8D-8AAB-4470-8A77-2C2A510ED0E5%7D.png?alt=media" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://hacking-notes.jord4n.pro/es/web/authentication/username-enumeration-via-account-lock.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
